# 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](https://opentofu.org/) (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.