How we write these tutorials
A tutorial that only explains a topic has taught you nothing you can do. Every page here has to walk you through a procedure and end with you having done it. This page is the standard we hold them to, the checks that enforce it, and — the part most sites leave out — what we do when we cannot verify something ourselves.
- Every tutorial carries at least 3 steps you can actually follow
- We run the commands and compare the real output to what the page claims
- When we could not run something, the page says so, in plain sight
Four things, every single step
A step that says “configure the firewall as needed” has handed the work back to you. Every step on this site answers the same four questions, so you never have to guess what you are looking at.
| Label | What it must tell you |
|---|---|
| Go: | Exactly where — the app, the screen, the menu, the folder. Not “the appropriate section”. |
| Do: | Exactly what to type or click, with the real button named as it appears. |
| You should see: | The observable proof it worked, so you know before moving on. |
| If not: | The real thing that goes wrong on a real machine, and the real answer. |
The fourth line is the one that earns the format
Anyone can write the happy path. “If not” is where we name the menu item that does not exist on mobile, or the setting your operating system saved somewhere else. It is the difference between a tutorial that works on the author's machine and one that works on yours.
We run the code, then compare
A tutorial can be well written and still be wrong. The only way to know is to run it.
Every code block is pulled out of the page
Not a sample. Every one, in the order you would meet them.
Each one is executed
In the interpreter the page tells you to use, building on the earlier steps exactly as you would.
The real output is compared to the page's own promise
If the page says you should see something, the something it prints has to match. A mismatch is a defect and the page is fixed before it ships.
What could not be run is labelled as such
Some steps need a phone in your hand, a Windows machine, or a screen only you can see. Those are marked on the page itself, naming what was not captured and why.
This catches things reading never does
One page promised a program would print Rex says woof. Run, it printed Rex makes a sound — correct code, wrong promise, and invisible to anyone proof-reading it. Another told you to save one file when the steps produced two. Both were found by running the page, not by reading it.
“Updated” means the words changed
Plenty of sites re-stamp every page nightly so everything looks fresh. Ours cannot: the date on a page is derived from a fingerprint of the words you actually read.
Moves the date
- Rewriting a step
- Correcting something that was wrong
- Adding or replacing an explanation
Does not move it
- Re-publishing the site
- Changing styling or scripts
- Touching the file without touching the words
Things we have chosen not to do
No third-party trackers
No analytics service, no advertising pixel, no embedded widgets. Nothing on these pages loads from anyone else's server — every script, style, font and image comes from ours.
No badges, no testimonials, no logos
You will not find quoted praise, certification seals or client logos on this site, because we have not published any. We would rather you judged the work in front of you.
No pretending we tested something
Where a step could not be run on our machines, the page says so instead of showing you output that looks captured. An honest gap is worth more than a convincing one.
No vague filler
“Configure as needed” and “navigate to the appropriate section” are not allowed. If a choice can be made for you, we make it and name one option rather than listing five.
Found something wrong?
Tell us which page and what happened instead. A tutorial that fails on your machine is the most useful thing you can send us — it is the case our own checks could not reach.
Or write to contact@finkatana.com. Every page carries the date it last changed.