Why I'm Doing a Mental Health Series on an Engineering Blog

The habits that make for good engineering stories, working alone, being the only person who can fix something, carry a cost that rarely gets mentioned next to them. This opens a two-week series about that cost, from someone who is not a mental health professional and isn't offering treatment advice.

Most of what shows up here is about infrastructure: NOGnet, Magatama, the LLM training rig in the corner pulling more power than any reasonable budget allows. People come here for config changes and for the moment a deploy takes down something nobody expected it to touch, or for a read on where the network-operator industry is headed since the last post.

Starting in a couple of weeks, the last two weeks of September will look different. Twelve posts, roughly one a day, about the parts of building things alone that never make it into a changelog. I'd rather explain why before the first one goes up, because a technical blog suddenly running a mental health series needs more than an announcement.

One pattern keeps showing up in my own writing. The best stories on this blog usually have a moment where I am the only person who understands a system well enough to fix it before things get worse. Told one way, that's a competence story: fixed it at three in the morning before anyone else even noticed there was a problem. Told honestly, it also describes being on call permanently, with no backup rotation and no one to hand the pager to. Both descriptions are true of the same event.

Running your own server fleet has a similar shape. Past a certain size, it keeps running only because you keep tending it. Nobody else has root. Nobody else remembers why one particular service needs a restart every few weeks instead of a real fix. The knowledge lives in one head, and that head has to stay reasonably functional for the whole thing to keep standing.

There is also a quieter version of this, one that never shows up as an outage. Writing about an established industry as someone who came to it sideways means carrying a background process that keeps asking whether people who have done this for twenty years would recognize what I build as real work, or as a hobbyist playing at their job. That question does not resolve. It just gets louder or quieter depending on the week.

None of this is unique to me, and none of it is exotic. It rarely gets discussed next to the technical war stories that usually get the attention, the outage postmortems and the clever fixes. A blog about building things solo that never mentions what solo actually costs is leaving out half the story. That felt worth fixing, even if it makes for a stranger two weeks than the usual content here.

Before I start

A few things need saying up front. I'm not a mental health professional, and nothing in these posts is treatment advice or a diagnosis of anything you might be dealing with. I'm not qualified to tell anyone what they have or what to do about it, and I'm not going to try. What I can offer is honest reflection from someone who has spent a long time building things mostly alone, and who has decided the patterns are worth taking seriously instead of laughing off as normal founder behavior.

The series won't turn into a wellness blog, and there won't be a course or a framework waiting at the end of it. After these two weeks, the regular programming comes back: server configs and whatever breaks next. I just wanted one stretch of this blog where the cost gets mentioned alongside the war stories, instead of only after someone asks.