· 8 min read
The Engineer's Guide to Writing That People Read
Most engineers have more to share than they realize. Here's how to start writing technical content that's clear, useful, and actually gets read.
By Tanner Goins
I’ve been blogging about engineering and technology for a couple of years now. This site has posts about Svelte 5 migrations, LLM evaluation pipelines, AI product architecture, and rewriting backends in Go.
None of them went viral. Most of them found their audience anyway. A few have generated consulting leads. Several have helped me organize my own thinking in ways that made me a better engineer.
If you’re a developer who’s thought about writing but hasn’t started (or who’s tried and felt like nobody read it), this post is for you.
Why Engineers Should Write
Let me skip the generic “building your personal brand” pitch. Here’s what writing actually does for you:
It forces clarity. When you try to explain something you built or learned, you discover the gaps in your own understanding. The parts you wave your hands through in conversation? You can’t do that in writing. You either understand it well enough to explain it, or you don’t. This process makes you a better engineer, not just a better writer.
It creates a reference you can share. How many times have you explained the same concept to different people? A blog post is a force multiplier. Instead of repeating yourself in Slack threads and code reviews, you link to the post you already wrote. This is especially valuable for senior engineers whose growth depends on multiplying their impact.
It compounds over time. A post you write today continues to attract readers months or years later. Search engines surface technical content long after publication. Your collection of posts becomes a portfolio that shows how you think, not just what you’ve built.
It opens doors. Conference talks, consulting opportunities, and hiring conversations all benefit from having a body of written work that demonstrates expertise. I’ve landed projects specifically because someone read a post I’d written and thought, “this person thinks clearly about this problem space.”
The Biggest Mistake: Trying to Be Original
The number one thing that stops engineers from writing is the belief that they need a novel insight.
“Someone smarter already wrote about this.” “There are a hundred tutorials on this topic.” “I don’t have anything new to say.”
Here’s the thing: your perspective is the original part. The way you explain something is shaped by your experience, your mistakes, and the specific context you learned it in. Two engineers can write about the same topic and both posts are useful because they approach it differently.
Nobody has your exact combination of experience. That’s your angle.
Finding Topics
You don’t need to invent topics. You just need to notice them. Here’s where to look:
Things You Just Figured Out
Did you spend an afternoon debugging a weird issue? Did you finally understand a concept that had been confusing you? Did you make an architectural decision and have reasons for it?
Write that down. The best technical posts come from real problems with real solutions. Posts like “How I debugged X” or “Why I chose Y over Z” are genuinely useful to other engineers facing the same decisions.
Things You Explain Repeatedly
If you’ve explained something to three different people, it’s a blog post. Your team’s onboarding questions, the gotcha in that library everyone hits, the pattern you keep recommending in code reviews: these are all posts waiting to happen.
Things You Wish You’d Known
Think back to when you started learning something you now know well. What would you have wanted to read? The “beginner” perspective is valuable precisely because experts forget what it was like not to know things. If you just learned something, you’re in the perfect position to explain it to the next person.
Your Actual Work
This is the richest source, and most engineers overlook it. You build things every day. Write about the decisions behind what you build. Not the “what,” but the “why.”
- Why you chose this architecture
- Why you changed your approach halfway through
- What tradeoffs you accepted and why
- What you’d do differently next time
These posts are valuable because they show real engineering judgment, not just technical knowledge.
How to Structure a Technical Post
Most engineering blog posts fail at structure, not substance. The writer knows the topic well but doesn’t organize the information in a way that respects the reader’s time.
Here’s a structure that works for most technical posts:
1. Start With the Problem or Payoff
Don’t start with background. Start with why the reader should care. What problem are you solving? What will they understand by the end?
Weak opening: “In this blog post, I will discuss the various approaches to database migration strategies and their tradeoffs.”
Strong opening: “Our database migration took down production for 45 minutes. Here’s what went wrong and how we prevented it from happening again.”
The second opening creates a question in the reader’s mind. The first one sounds like a term paper.
2. Give Context Efficiently
After the hook, provide just enough context for the reader to follow. Don’t over-explain prerequisites. If someone needs to understand Kubernetes to follow your post, say “This assumes familiarity with Kubernetes” rather than spending 500 words explaining what Kubernetes is.
3. Show, Don’t Tell
Code examples, diagrams, and concrete scenarios are more useful than abstract descriptions. Instead of “the pattern improves maintainability,” show two versions of the code and let the reader see the difference.
Keep code examples focused. Show the minimum code that illustrates the point. If your example needs 50 lines, something is wrong. Either the example is too complex or you need to split it into multiple examples.
4. End With the Takeaway
What should the reader do differently after reading your post? Make this explicit. A clear takeaway, even a single sentence, gives the reader something to hold onto.
Writing Advice Specific to Engineers
Write Shorter Sentences
Engineers tend to write long, complex sentences with multiple clauses that try to capture every nuance and edge case in a single breath. (See what I did there?)
Short sentences are easier to read. If a sentence has more than one idea, split it into two sentences. If a paragraph is more than 5–6 sentences, split it into two paragraphs.
Cut the Qualifiers
Technical accuracy makes engineers want to hedge everything. “It’s generally considered a best practice to potentially consider using…” Just say “Use X.” If there are important caveats, address them separately.
Use Headers Aggressively
Most readers scan before they read. Headers let them find the section that answers their specific question. A post with no headers is a wall of text. A post with headers every 200–400 words is navigable.
Don’t Apologize
“I’m not an expert, but…” “This might not be the best approach, but…” “Sorry if this is obvious, but…”
Stop. If you wrote the post, you have something to share. State it directly. The reader will evaluate the content on its merits.
First Drafts Are Supposed to Be Bad
Get the ideas out first. Edit later. The mistake I see most often is engineers trying to write a perfect first draft. They write one paragraph, re-read it, hate it, delete it, and give up.
Write the whole thing badly. Then go back and make it good. The editing pass is where the real quality comes in.
Where to Publish
You don’t need your own site to start. Here are reasonable options:
Your own site/blog. Full control, but requires setup. If you’re technical (and you are), a static site generator or a platform like this one (SvelteKit + MDsveX) gives you complete ownership.
Dev.to or Hashnode. Free, easy to set up, built-in audience. Good for getting started. You can always move content to your own site later.
Company blog. If your employer has a tech blog, contributing there gives you a built-in editorial process and audience. The tradeoff is that the content lives on their domain, not yours.
No platform at all. Some of the most useful technical writing I’ve seen lives in GitHub READMEs, Notion docs, and internal wikis. Public is great, but internal writing counts too.
Consistency Over Volume
One post a month is better than seven posts in January and nothing for the rest of the year. Build a sustainable cadence. I aim for one or two posts a month and treat it like any other recurring commitment.
Getting Over “Nobody Will Read This”
They might not. At least not at first.
My earliest posts got single-digit views. That’s normal. Technical content accumulates readers over time as search engines index it and people share it. A post that gets 10 views in its first week might get 1,000 views over the next year.
But even if nobody reads it, you still benefited from the writing itself. You organized your thinking. You created a reference you can share. You practiced a skill that gets better with repetition.
The audience follows the consistency. Start writing, keep writing, and the readers will come.
Start Today
Here’s your assignment:
- Think of the last technical problem you solved this week
- Open a new document
- Write the first sentence: what was the problem?
- Keep writing until you’ve explained the solution
- Publish it somewhere, anywhere
It doesn’t need to be perfect. It doesn’t need to be long. It just needs to exist.
The engineers who write regularly aren’t the ones with the most talent or the most time. They’re the ones who decided to start and didn’t stop. You can be one of them.