How I test

The equipment

A home lab I built and maintain myself, plus the production experience behind it. Specifically:

• MikroTik RB5009UG+S+IN — physical hardware, RouterOS 7.x. This is where the MikroTik articles are run unless stated otherwise.
• MikroTik CHR on VMware Workstation — used for anything that would lock me out of the physical device, and for testing the same command across versions.
• Cisco 2800 series — real hardware, and old. It runs a classic IOS train, not IOS-XE, so where a command differs on current Cisco platforms I say so rather than pretending the output transfers.
• GNS3 — for topologies I cannot build with two routers and five switches.
• VMware Workstation on Ubuntu 22.04 — the lab host itself.

Where an article covers something I only have virtualised, I say so in the article. Where behaviour differs between hardware and CHR, that difference is the article.

The process

1. Start from a real state. Either a device already in service or a clean install taken through the defaults a normal deployment goes through — not a configuration built to make the article come out neatly.
2. Run every command. Nothing is written from memory or from vendor documentation. If a command is in an article, it was pasted into a terminal.
3. Capture the actual output. The output blocks are what the device printed, trimmed only for length and with addresses and identities changed. Where something is redacted it is marked.
4. Break it, then fix it. Where an article says a setting is dangerous, I confirm the exposure exists before recommending the fix, and confirm the fix closes it.
5. Record the version. Every article carries the exact software version it was verified on. Behaviour changes between releases, and an undated guide is worse than none.

Screenshots

Every image is my own capture from my own equipment. No vendor marketing images, no stock photography of server rooms, and nothing generated. If a screenshot shows a lab device rather than production, the caption says so.

Where AI is used, and where it is not

I use AI tools for drafting, structuring and background reading — the way I use a search engine or a colleague to check my reasoning. It is not used to invent command output, and it is not used to write about equipment I have not run.

Every article is edited, fact-checked and verified by hand before publishing. Throughput here is limited by how fast I can test things, not by how fast text can be produced. That is why the cadence is two articles a month and not twenty.

Redaction

Public addresses, identities, serial numbers, keys and client details are replaced before anything is published. Where an address appears it is from documentation ranges or my own lab. Nothing here exposes a network I do not own.

When I get it wrong

Some of it will be wrong, and versions move. If you find an error, send it to hello@codesecho.com. I retest, correct the article, and change the update date so the correction is visible rather than quietly folded in. Substantive corrections are noted at the foot of the article.