Why I Started Writing About Engineering (And What I've Learned)

I resisted writing for a long time. I told myself I was too busy, that nobody would care, that I should wait until I had something truly original to say. Those were all excuses. The real reason was that writing felt exposing. Code hides behind a compiler. Words don't.

The thing that finally pushed me was a conversation with a teammate. I had just finished explaining a tricky architecture decision in a design doc, and he said, "You should write this up as a blog post." I laughed it off. But the idea stuck.

What Writing Actually Does for You

Writing about engineering isn't about building an audience or personal branding. Those things might happen, but they're side effects. The real value is internal.

When I write about a technical topic, I'm forced to organize my thinking. I have to move from "I sort of get this" to "I can explain this clearly to someone who doesn't have my context." That gap is where learning lives.

What I think I know:
"RecyclerView performance is about ViewHolder patterns and DiffUtil."

What I actually know after writing about it:
"RecyclerView performance involves item view type management,
nested scrolling coordination, prefetch tuning, stable IDs for
animation, payload-based partial updates, and the interaction
between layout manager and item animator lifecycles."

The act of explaining reveals the gaps. Every time I sit down to write a post, I discover at least one thing I was wrong about or didn't fully understand.

The Process That Works for Me

I don't outline first. I start by writing the sentence that made me want to write the post in the first place. Usually it's a claim or observation that I believe strongly.

Then I try to prove it. If I can't, I either find out why I was wrong (which makes the post better) or I realize the topic isn't ready yet.

My typical flow:

1. Start with one strong claim. "Observability matters more than testing at scale." Something I believe and can defend.
2. Write the argument. Why do I believe this? What evidence do I have? What would someone who disagrees say?
3. Add the code. Not toy examples. Real patterns from real systems. If I can't show it in code, I probably don't understand it well enough.
4. Cut ruthlessly. My first drafts are always too long. I cut anything that doesn't directly support the argument.
5. Read it out loud. If a sentence sounds like a textbook, I rewrite it.

What I've Learned

Writing is thinking. I've solved more engineering problems while writing about them than while staring at code. The constraint of explaining something clearly forces a different kind of thinking.

Short posts are harder than long ones. Anyone can write 3,000 words. Writing 800 words that say the same thing takes twice as long.

Nobody cares about perfect. My most-shared posts have been the ones I almost didn't publish because I thought they were too obvious. The topics that feel basic to you are genuinely useful to someone a year behind you on the same path.

Consistency beats quality. One post every two weeks beats one perfect post every six months. The writing muscle atrophies fast.

Your perspective is the value. There are thousands of "how to use Jetpack Compose" posts. There's only one "how I think about Jetpack Compose after using it on a product with 500 million users" post. That's the one worth writing.

The Unexpected Benefits

Writing has made me a better code reviewer. When you practice explaining technical decisions in writing, you get better at articulating why a piece of code should change during review.

It's made me a better communicator in design docs. The structure of a good blog post (claim, evidence, trade-offs, conclusion) is the same structure of a good technical proposal.

And honestly, it's made me a better engineer. Not because writing teaches you new APIs or frameworks. But because it forces you to be honest about what you know and what you don't. That honesty is the foundation of getting better at anything.

If You're Thinking About Starting

Don't wait until you're senior. Don't wait until you have a unique take. Don't wait until you're at a brand-name company. Write about what you're learning right now. The best engineering writing comes from someone who just figured something out and still remembers what it felt like to not understand it.

Start with a problem you solved this week. Explain it like you're talking to yourself six months ago. That's a blog post.