Writing More as a Senior Engineer
Moving into a senior role shifts the work from writing code to writing documentation, design decisions, and specifications - a change that catches many engineers off guard.
A common assumption about senior engineering that I had is that it means writing code faster, going deeper on technical problems, and being the most technically capable person on the team. That picture is accurate but incomplete.
In practice, a significant - and often underestimated - portion of senior engineering work is writing. Not code. Documentation, architecture decision records, design specifications, API contracts, runbook entries, and code review comments that explain why, not just what.
I say this from experience, because I've seen what it looks like when you're not doing this.
About eight months ago, at my previous company, I was writing things down - but not meaningfully. I was taking notes for the sake of taking notes. There was no structure, no intent behind it. Looking back, I think I was just waiting for my pager to go off. The company wasn't really investing in its engineers - it was more focused on chasing the next big thing financially - and that environment shaped how I showed up. I wasn't writing defensively, meaning I wasn't documenting things for future use, for accountability, or for anyone but myself in that moment. The nature of the work made it hard to care about the long game.
That changed when I moved to my current role.
The technology stack isn't radically different, but the architecture is. And because so much is genuinely new to me, I've had to write to keep up. Now, whenever I work on a feature, I take screenshots of the UI, capture unit tests as they pass, and document anything I learn in relation to the ticket or story I'm working on. I do it so I don't forget - and because I've realized that having things written down gives me something to stand on. It feels like a second brain that actually makes sense.
The thing is, I've started to enjoy it. That surprised me.
One of the more useful frameworks I've picked up is thinking about two distinct types of writing: ownership docs and decision docs.
An ownership doc is where you track what you've worked on - not just the features, but what specifically you did, what you were accountable for, and what the impact was. If you can attach a metric to it, even better. This becomes invaluable during performance reviews, when you're building a case for promotion, or simply when you want to remember what you actually shipped last quarter.
A decision doc is different. It's a record of the choices you made and the trade-offs behind them. As you grow in your career, you start to realize that almost everything in software is a trade-off. Documenting those trade-offs - at the time you made them - is what separates reactive engineering from intentional engineering. For example: you might choose not to implement an Outbox pattern on a notifications service because you were deliberately prioritizing delivery speed over resiliency at that stage. That's a valid call. But if you don't write it down, six months later it looks like an oversight rather than a decision.
What I'm learning as a senior engineer isn't really new technology. I'm still using the same languages, the same tools. What's new is everything running in parallel to the code - the communication, the accountability, the deliberate documentation of what I know and why I did what I did.
Writing is how I'm keeping up with that. And I think it's one of the habits that will compound the most over time.