5 posts tagged with "Documentation"

According to internet lore the quickest way to get an answer on a technical forum is to use a sockpuppet account to post the wrong answer to your own question. People rush to correct the mistake, when they would otherwise have ignored the original question.

I've been thinking about documented standards again, particularly why getting that first draft written is so difficult. We're paralysed by the need to write it perfectly. But like that sockpuppet posting the wrong answer, sometimes the quickest way to get a good standard is to put out an imperfect one.

I recently got drawn into a bit of LinkedIn rage bait: a post with a CCNA level question asking people to identify the broadcast domains in a given diagram. The diagram was simple enough and it was pretty clear what the question was trying to test, an understanding of what a broadcast domain is. The question did, however, elicit a lot of discussion. It left enough ambiguity that there was a valid answer for multiple interpretations.

I've been thinking about why network documentation always feels incomplete. You know the feeling - you've got spreadsheets full of device details, beautiful network diagrams, and configuration backups. But when something breaks at 3am, you're still calling Dave from the pub because he's the only one who knows why VLAN 247 exists.

The problem isn't that we don't document things. It's that we're only capturing the bottom layer of what we actually need.

Since Anthropic open sourced the Model Context Protocol last year there have been lots of notable implementations across many areas of tech. Every day I seem to see a breathless introduction on LinkedIn to some new MCP front end to a service or dataset.

The topic of documentation always comes up in tech and it's one that has had a lot of attention in world of software development which has led to some excellent solutions. In the world of infrastructure, however, the solutions have not been as readily available or adopted.