I taught myself software engineering, so I know what it feels like to stare at a concept that everyone else in the room seems to already understand. The way through, for me, was always the same: find the simplest case that's actually true, make sure I really believe it, and build from there. I picked up that habit studying physics, but it turned out to be the most useful thing I brought to writing.

When I explain a technical subject, I try to give readers the explanation I wish I'd had. I retrace the path I would need if I were learning it myself, put the pieces in the right order, and leave the gotchas intact. I've learned to trust that the places where I once got stuck are usually where a reader will get stuck too.

That's the kind of writing I do now, mostly for software companies. I write customer stories, engineering posts, and comparison guides where vague writing quietly costs something. I still work as an independent engineer alongside the writing, which keeps me honest. I can read the codebase behind a story, sit in on a technical interview without slowing it down, and notice when a draft has smoothed over a detail that an engineer reading it would catch. Good technical writing can be accurate, thoughtful, and genuinely enjoyable to read.

If you have a story sitting in a Slack channel that no one has time to write up, or a product whose technical depth keeps getting lost in review, I'd love to help you tell it properly.