Why I am writing again?

I'm coming back to writing to get better at it. I've come to think that writing is one of the skills that separates a senior engineer from the next level up, and it's the one I've practiced least.

Where I stand

I've been writing software for more than ten years: Go, Python, JavaScript, infrastructure, security. Right now I maintain parts of OpenTofu (the language server and the VS Code extension) and work as an infrastructure engineer. Before that I led a small team, played CTFs with FireShell, and did a master's in Computing Systems at Georgia Tech.

Most of that is doing. Code gets merged, systems get deployed, bugs get fixed. When I looked at what a staff or principal engineer is actually expected to do, a different list showed up:

• Writing RFCs and design docs that other people can review and push back on.
• Recording architectural decisions (ADRs) so the reasoning outlives the meeting where it happened.
• Influencing teams you don't manage.
• Explaining technical work in terms of business outcomes.
• Having a public track record that people outside your company can see.

Every item on that list depends on writing. That's my biggest gap, and it's why I'm here.

Why writing, specifically

Writing is how influence scales. At senior level you can get a lot done by being the person who knows the code best. Beyond that, most of your impact goes through other people: a design doc that gets three teams to agree, or a review comment that changes how someone thinks about a problem. Will Larson's Staff Engineer and Tanya Reilly's The Staff Engineer's Path both come back to this again and again. A principal shapes decisions they don't directly own, and the main way to do that is to write things down clearly.

Writing exposes fuzzy thinking. I can convince myself I understand something until I try to explain it in a paragraph. A blog post works like an ADR with an audience: what was the problem, what did I try, why did I pick this option, and what did it cost?

Writing leaves a trail. I keep a brag document, and the "Visibility" section is the emptiest one. I have hundreds of merged PRs, but a PR shows what changed, not why it was the right call. Posts are a way to put the reasoning on the record.

It's practice. English isn't my first language, and like any skill, writing improves with reps. Short, regular posts are cheaper reps than waiting for the perfect long-form article.

What I'll write about

The topics I know well enough to say something useful about:

• Infrastructure and OpenTofu. Provider architecture, how the language server works, and what maintaining tooling for an open source project is really like.
• Go. Runtime internals, the scheduler, the GC, and the mistakes I keep making.
• Security as architecture. Supply chain security, pinning dependencies, and treating security as a design concern instead of something bolted on at the end. My background in CTFs and pentesting is the part of my profile that's least common among engineers, so I want to put it to use.
• Experiments. Small hacks such as load balancer tricks for backend challenges, where the interesting part is the trade-off rather than the code.
• What I'm learning. Notes from books like Designing Data-Intensive Applications and Fundamentals of Software Architecture, and the system design questions I'm still working through.

If you're also trying to grow beyond senior, I'd suggest the same thing: write more. Not because the posts will go viral, but because writing is what the job turns into.