Before I wrote code professionally, I wrote about code — and about automotive systems, engineering workflows, and product specifications, as a senior technical writer. People sometimes treat that as a detour on the way to engineering. I've come to see it as the on-ramp.
Writing is system design with words
To document a system well, you have to actually understand it — the components, how they fit, where the edges are, what happens when something fails. You can't paper over a fuzzy mental model with a working build. The page is merciless: if you don't understand the architecture, the documentation reads like you don't.
That's the same muscle engineering uses. Designing a service is mostly deciding what the pieces are, what they're responsible for, and how they talk. I'd been doing a version of that for years, just in prose.
Clarity is a transferable skill
The best thing technical writing gave me is an allergy to vagueness. A spec that says "the system handles errors gracefully" is useless — which errors, handled how? I carry that into design reviews and API contracts now. Define the error responses. Name the states. Say exactly what happens.
Empathy for the reader becomes empathy for the next developer
A technical writer's whole job is to imagine the person on the other side and make their path easier. Swap "reader" for "the next engineer who touches this code" and you've described good software craftsmanship. Clear names, honest comments, an API that explains itself — it's all writing for someone who isn't in the room.
I didn't abandon writing to become an engineer. I just started writing in a language the computer also reads. And I still write the other kind — some of it ends up here.