Writing

Two kinds of writing: plain guides for business owners on phones, payments and automation, and engineering notes on the problems behind the free tools.

For business owners

Engineering notes

Notes on the problems behind the tools: usually the ones where the error message sends you looking in the wrong place. Most of them end at a free browser tool that checks the thing being described.

There is a pattern to what gets written here, and it is worth stating plainly: almost every piece exists because the obvious reading of some output is wrong. Asterisks in a traceroute are read as a broken path when they usually mean a router declined to reply. Flushing DNS is read as a fix when your machine is one cache in four. A 502 is read as a network fault when the code itself is proof the network carried the request there and the answer back.

Those misreadings are expensive because they are confident. They send people to the wrong team, produce tickets that cannot be actioned, and get repeated until they become folklore. Correcting one properly, with the evidence and the check that settles it, is worth more than another summary of what a protocol is.

Certificates and TLS

Certificate failures often share the same underlying problem: the machine complaining is not the machine at fault. A browser quietly repairs a chain that curl will not, a corporate proxy reissues every certificate it sees, and a Java client consults a trust store nobody remembered existed. The newer TLS pieces cover protocol changes where the same rule still applies: prove what the client negotiated instead of trusting a capability label.

Reachability and routing

Refused, timed out and unreachable are three different answers, and the difference is the diagnosis. A refusal means something replied. Silence is what a firewall looks like. An ICMP unreachable came from a router that gave up, not the host you were asking about. These also cover the fault that looks least like a network problem and almost always is one: small packets work, large ones vanish.

Security operations

A vulnerability identifier, a severity score and evidence of exploitation answer three different questions. Good triage keeps them separate, confirms the asset is actually exposed, and makes urgency change the order of work without deleting change control.

HTTP status codes

A status code is evidence the network worked. For any number to reach you, the name resolved, a connection opened, TLS negotiated, your request arrived and a reply came back: five things, all successful. So the useful question is never what the code means, which MDN answers perfectly well, but whose fault it is, and, for a 503, whether it was a decision.

DNS

Flushing the cache is the first thing everyone tries and usually changes nothing, because your machine is one cache among four and the stale answer is normally in one of the other three. Both pieces give the commands, then the check that tells you whether flushing could possibly have helped.

Addressing and subnetting

The reference material, done carefully. Most published mask tables get /31 and /32 wrong, most VLSM explanations skip the rule that makes it work: allocate largest first, and start every block on a multiple of its own size.

Email authentication

SPF, DKIM and DMARC fail in a way that is unusually cruel: the record stays valid-looking while it stops working. An SPF record one DNS lookup over the limit is a permanent error, and most checkers still report it as present and correct.

Data centres

Infrastructure at the scale where the answers stop being intuitive. These start from the numbers that get quoted without context: gallons, megawatts, efficiency ratios, and work out what they actually measure, because most of them describe a design decision rather than a quantity.

The job itself

Less about errors, more about where the work is going. What the 2027 CCNA actually changed (read from Cisco's published blueprints rather than the commentary) and what AI does and does not do in a network, separated by evidence rather than by enthusiasm.

Running the work

The other half of infrastructure work: the projects, the change windows and the paperwork that decides whether any of it goes smoothly. Written for engineers who were handed a project without being handed any training for it, so the test applied throughout is whether a practice survives a two-person job, rather than whether a methodology endorses it.