Every time I talk to an engineer who’s thought about starting a newsletter or a blog, this is the sentence that comes up.

Sometimes it’s framed as a question: “what would I even write about?” Sometimes it’s a confession: “I want to but I don’t have anything to say.” Sometimes it’s a defensive joke: “haha, who would even read it?”

The mechanics are the same underneath. The engineer in question has decided their work isn’t interesting enough, their experience isn’t unique enough, their thoughts aren’t sharp enough to be worth publishing.

This is, almost without exception, completely wrong. Engineers have more raw material to write from than almost any other profession. They just haven’t been told what counts as material.

The wrong frame

Most writing advice tells you to “write what you know.” That sounds reasonable and produces nothing. It implies the way to find a topic is to scan your knowledge for areas where you’d be qualified to teach. Which is exactly the frame that makes engineers freeze.

By the time you’ve been an engineer for 2+ years, the things you actually know feel obvious. The hard parts aren’t hard anymore. The decisions you struggled with at year two are automatic at year ten. So when you scan your own knowledge looking for something worth writing about, you find a flat landscape. Everything looks settled. Nothing looks interesting because nothing feels difficult.

This is the trap. The engineers most qualified to write are usually the ones least able to remember what was confusing about the things they now know. The expertise itself makes the material invisible.

But the material isn’t actually missing. It’s just hidden in places engineers don’t think to look.

What engineers actually do all day

Take an honest inventory of an engineer’s week. Most of it isn’t writing code. Most of it is: architectural arguments, code review pushback, technology evaluations, planning meetings where people disagree about scope, retrospectives where teams disagree about what went wrong, discussions about which framework to adopt, debates about whether to use a managed service or roll your own, conversations about why a previous decision didn’t work, hallway chats about the stack at the engineer’s last company versus this one.

Hell! Engineers are constantly arguing!

I noticed this recently when I was thinking about why engineers love newsletters and blog posts so much. Engineers are debate-prone in a way most professions aren’t. We have strong opinions about microservices, monoliths, REST versus GraphQL, ORMs, type systems, code coverage, agile, design patterns, and a hundred other things. We argue about them in meetings. We argue about them on Hacker News. We argue about them in private Slack channels with our trusted peers.

Every one of those arguments is potential content. Every position you’ve taken in a meeting and successfully defended is a blog post. Every position you’ve taken and lost is a more interesting blog post, because losing required you to update, and the update is the story.

This is the material engineers have that most other professionals don’t. Lawyers don’t argue about how to lawyer. Doctors don’t argue about how to doctor. They have professional disagreements, but those disagreements aren’t the texture of their daily work the way they are for engineers. We live in a profession where the right way to do almost anything is contested, and we know it.

That’s the gold mine. Not what you know but what you’ve argued about.

What this looks like in practice

If you genuinely can’t think of anything to write about, ignore “what do I know” entirely and ask different questions:

What’s a technology choice your team made that you still think was wrong? What’s a tool everyone praises that you find overrated? What’s a piece of conventional wisdom in your stack you’ve stopped believing? What’s something you keep having to explain to junior engineers? What did you believe at year three that you no longer believe at year ten?

Each of these points at a piece. Not a tutorial. Not a definitive guide. A take. A specific position grounded in a specific experience, written by someone who’s earned the right to hold it.

The reason these work where “write what you know” fails is that they don’t ask you to be authoritative. They ask you to be honest. Authority is exhausting and makes you freeze. Honesty is sustainable and makes you productive.

Why your honest take is more valuable than you think

Engineers are afraid that nobody will care about their position because it’s just one engineer’s opinion. That fear is upside down. The reason your position is valuable is precisely because it’s grounded in your specific experience. The internet has plenty of comprehensive guides. What it lacks is people willing to say “I tried this and here’s what actually happened.”

The most-read engineering posts of the last few years aren’t comprehensive. They’re specific. “Here’s why I stopped using Kubernetes.” “Here’s what nobody tells you about microservices.” “Here’s why we chose Postgres over MongoDB and what we’d do differently.” These pieces work because they’re someone naming a specific position publicly, with the texture of the actual experience behind it.

You can do this. Every engineer who has been doing the work for more than a couple of years can do this. You don’t need to discover something new. You need to say something true that you’ve been saying to colleagues but haven’t said in public.

The actual blocker

Once you’ve accepted that you have material, there’s a second thing worth naming: most engineers who say “I have nothing to write about” don’t actually mean that. They mean they’re afraid to publish.

Here’s the part nobody warns you about clearly enough. You won’t actually be wrong in public very often. The fear is mostly imagined. But you will feel stupid. Not because you are, and not because anyone is calling you that, but because publishing a position means committing to it, and committing to it means at some point you’ll change your mind, or someone will prove you wrong, or you’ll reread something you wrote a year ago and wince at how confidently you said it.

Nobody else will think you’re an impostor. You will. That’s the part you have to get over, and it’s the hardest part. There isn’t a trick for it that I know of. You can’t argue your way out of an internal feeling.

The only thing that works is doing it anyway. The first time you publish something you have a position about, you’ll probably feel terrible for a few days. The third time, uncomfortable. The tenth time, you’ll just feel like an engineer who writes.

The willingness to feel stupid in public is the only meaningful skill. Everything else is technique.

Where to start

If you’ve been waiting for permission, here it is. Pick the argument you’ve had at work most recently. The one where you had a strong position and successfully defended it, or had a strong position and lost. Write 600 words about why you think what you think.

You don’t need to publish it yet. Just write it. See what comes out when you give yourself permission to take a position rather than explain a topic.

Most engineers who do this discover the same thing. They had material the whole time. It was sitting in their last week of meetings.

If this resonates and you're an engineer who's been thinking about writing but hasn't started, hit reply. I'd like to know what you'd write about. Even if you don't end up publishing it, telling someone the topic out loud is the first step.

​P.S. I publish these on Commune, the open alternative to Substack I'm building. The discussion threads on each piece are where most of the interesting replies happen lately. If you want to read what other engineers are saying about this one, or take your own position publicly: https://usecommune.com/n/franmendez
​​
No signup needed to read. If you want to comment, that takes about 30 seconds.