simskij

Oh man - I've created more than I can count at this point, but here's some of them:

- A chat-based web app for ad-hoc telemetry data visualization. - A firefox-extension meeting transcriber - A personal chief of staff - A web-based personal finance budgeting tool (no AI at runtime, obviously) - An iOS and Android app for solo work with a dead man switch if timely check-ins don't happen - A custom dotfile/machine config manager that works the way *I* want - A bookmarking tool/web clipper that puts together daily content-only collections from what I've been clipping and send them to my Kindle. This one I actually intended to make a SaaS, but meh. Being able to put together quite big projects by myself for myself in a reasonable amount of time is such a joy.

This - oh, so much this!

> They assume that documentation can provide enough context, and that human knowledge is not needed.

It's funny actually, because I fully agree with your reasoning. The only part were we differ is whether that's assumed, or even implied.

No documentation means running fully on tribal knowledge, or institutional knowledge if you prefer. Even if you capture your intent, imperfect and incomplete, in as little as 2 paragraphs, you'll get durable recorded memory, and intent you'll be able to reference. It does not eliminate ambiguity, but it adds framing, direction, and friction.

The examples are great, and they serve really well to prove another point that I intentionally left out: writing is not a one-shot activity. Documentation is living and should be treated as such. Unless it receives proper care continuously, it will wither and die. That could very well be the topic of a future post!

Thank you for reading and for providing thoughtful feedback!

That feels more familiar than I'd care to admit - definitely been there, done that. I think what most fail to realize is that it eventually turns into a ball and chain, decreasing your mobility within the organization. So the consequences of running an org on tribal knowledge and Sarahs is far worse, and direct, than that it won't work very well with agents.

This might be the best article I’ve read in months. Thanks for sharing it!

Author here.

That sounds exhausting to say the least.

It’s very easy to turn into the Sarah - or the Brent if you prefer the Phoenix Project analogy. As exciting as it might initially be to be the go-to person, it’s also, as you so elegantly put it, “endless work, just enough authority to do current task, not enough respect/authority to solve the symptom”.

Best wishes! I hope you manage to turn it around.

Because bug bounties are already dead.

have they though? i for one remember the "golden days" being much more about checking specific values for things you already know could happen than gathering telemetry to be able to ask questions you never would have even thought about asking at the time you set it up.

Out of curiosity, what relevance do you mean it would have for the specific topic I was writing about?

Author of the post here. I definitely agree with that assessment. Having multiple stacks monitor each other is a really good, albeit somewhat resource intensive, way to cover all of the *likely* cases. The cost of covering that last percent very quickly approaches the point of diminishing returns.

Still my favorite console. 40 years later, it remains plugged in and used regularly.

logs, traces and profiling were all viable parts of a good monitoring stack even prior to the term observability being coined.

which i think is the point of the article as well. :)

Hey guys!

I've put together a curated list on software architecture. Would be awesome if you'd like to contribute with your best resources on the topic.

Thanks