The Myths That Keep Engineers From Writing
Some of the most valuable writing in technology comes from people who are convinced they have nothing to say. A few common myths stop engineers from publishing, and they’re worth examining one by one.
“You Have to Be Original”
This is the most common objection: someone has written about the topic already, so why bother? The useful counterpoint is to write from your own confusion. If you found something hard to understand, other people are likely in the same position, even if the information technically exists on the web. Information isn’t automatically absorbed by everyone who needs it.
A practical approach is to identify something you personally found confusing or interesting and write about that. Sometimes the search itself turns up an existing explanation you hadn’t seen. That’s not a failure — it’s a better resource for you, and your post can link to it.
Two important caveats: technology changes, so details from five years ago may be outdated, and personal stories are valuable on their own. Reading how one person uses a tool differently from you can be genuinely illuminating.
“You Have to Be an Expert”
You only need to know one or two interesting things the reader doesn’t. If you learned something yesterday, it’s guaranteed that plenty of people don’t know it yet. The “hey, I just learned this” post — learn something interesting, write a short piece about it — is a proven format for useful writing.
“Posts Need to Be 100% Correct”
Aiming for mostly correct is a workable standard. A useful strategy is adding qualifiers to uncertain claims: “My understanding is…” or “I think…” The extra wording saves fact-checking statements that are hard to verify, and it lets readers know where you’re less confident.
Real examples that work this way in practice:
I think people are replacing “how many golf balls can fit in the Empire State Building” with more concrete interview questions about estimating program runtime and space requirements.
I think the most important thing with bridges is to set up the route tables correctly. So far my understanding is that there are 2 route table entries you need to set: …
Etsy uses PHP, which I think means they can’t have long-lived persistent TCP connections
I think the MTU on my local network is 1500 bytes.
Those qualifiers do their job — it isn’t necessary to confirm every such statement before publishing. Conversely, it’s worth editing out qualifiers when you’re actually certain.
“Writing Boring Posts Is Bad”
The nature of internet distribution means interesting content gets amplified and boring content gets ignored. Readers will think any given post is more interesting than it may be, simply because they’re most likely to see your better work.
It’s difficult to predict what will land, so there’s little point in overthinking it. Treating writing as a volume game — making lots of things — is a more productive mindset.
“You Have to Explain Every Concept”
When writing about an advanced topic like how malloc works, it’s tempting to
include beginner definitions to broaden the audience. The result can end up
feeling written for no one: novices still can’t follow the jump from “what is
memory allocation” to internals, and experienced readers are turned off by
overly basic material.
A better starting point is to pick one person — a friend, coworker, or your past self — and write for them. Writing for a single known reader with a concrete context typically yields clarity that transfers to many other readers.
Writing Gets Harder With Experience
The gap between you and your audience grows as you become more expert. Knowing the material deeply makes it harder to relate to who’s reading. Experience improves the writing overall — more perspective is an asset — but it does feel more challenging.
“Page Views Matter”
Analytics rarely provide useful feedback. Individual comments have more impact:
Hey, @b0rk. Just wanted to let you know that this post really helped me to improve my skill of understanding a complex concept. Thanks! :)
Helping a single reader is a meaningful outcome. Silent readers multiply that reach without announcing themselves.
“More Material Is Always Better”
Deep-dive posts have their place, but short posts that deliver a couple of new things and stop are valuable too. Shorter posts are quicker to produce, and they’re easier to publish. A common failure mode is trying to include everything in one post and then never publishing anything. Making the post shorter and shipping it is often the better choice, even if short isn’t inherently “better.”
Dealing With Pedantic Comments
Ignoring comments rarely works for anyone who actually reads them. A working set of responses: don’t reply, even when the commenter is wrong; learn what you can from the rare constructive kernel; update the post if the comment reveals a mistake. Sometimes interpreting anger as confusion helps — a frustrated comment about missing DNS parsing logic in a toy resolver actually stemmed from readers who didn’t find that parsing obvious and wanted it shown. It inspired a more complete project that focused on parsing thoroughly.
“Everyone Should Blog”
Not true. Many excellent developers have no blog or personal site. Writing is worth doing because it’s enjoyable and helps organize thinking, not because it builds a brand.
