Why Write Articles When Everything Has Already Been Written
When I started blogging, a colleague asked me directly: “Why? Stack Overflow already has answers to everything, Medium is flooded with tutorials, and there are dozens of books on any technology. Who needs yet another blog?” I couldn’t give a clear answer back then. Now, after several years of blogging and working as an engineering manager, I can.
Spoiler: it has nothing to do with readers.
Writing Is Thinking in Slow Motion
The main reason to write articles is not to share knowledge, but to structure it for yourself. When you solve a problem in code or explain a concept to a colleague verbally, your brain runs on autopilot. You rely on intuition, skip steps, and fill gaps with assumptions.
But when you sit down to write, the illusion of understanding collapses. You try to explain why you chose this design pattern - and realize you can’t articulate clear criteria. You describe an architectural decision - and notice inconsistencies you didn’t see during implementation. You write about trade-offs between two approaches - and realize you haven’t fully understood one of them.
Writing forces you to think slowly, sequentially, with full logical exposition. It’s like a code review for your own thoughts. I regularly start writing an article “about something I know” and finish with the realization that I only knew it superficially.
A Real-World Example
Recently I was writing a note about choosing between a monolith and microservices for a new project. I thought the topic was exhausted and I’d just document the obvious solution. In the process of writing, I realized my selection criteria were intuitive, not rational. I had to stop, re-read several articles, and formulate a clear decision matrix. We ended up choosing a different architecture than I originally planned. The article was never published, but it saved the project from a wrong start.
External Memory That Doesn’t Expire
Memory is unreliable. Solved a complex problem three months ago? Half the details are already gone. Six months later you’ll face a similar task and solve it from scratch, wasting time on the same mistakes.
Articles are an external hard drive for experience. Not in the format of “copy-pasted code into Notion,” but as structured knowledge with context, reasoning, and alternatives. I regularly return to my old articles as documentation - my own knowledge base, written in my language, with my examples, in my logic.
Moreover, the writing process itself improves retention. When you formulate a thought in writing, more neural connections are engaged than with simple reading or practice. Even if you never return to the article, you’ll remember the material better than if you’d just “done it and moved on.”
The Rubber Duck Effect on Steroids
You know the rubber duck method? You explain a problem to a toy - and find the solution in the process. Writing works similarly, but more powerfully.
When you write for an imaginary reader, your brain automatically switches into explanation mode. You can’t write “well, it’s obvious here” or “just do it like this.” You have to unfold the logic, explain the prerequisites, anticipate questions.
More than once I started writing an article about a bug I couldn’t solve for a week, and found the solution halfway through the draft. Simply because describing the problem forced me to formulate it more precisely - and the precise formulation already contained the clue.
A Skill That Pays Off in Everything
As an engineering manager, I write constantly: design documents, RFCs, post-mortems, justifications for stakeholders, feedback letters, architecture descriptions. The ability to structure thoughts and explain complex things simply is not an additional skill - it’s the primary work tool.
Blogging is a gym for this skill. Without deadlines, politics, or pressure. You write at a comfortable pace, experiment with structure, and learn to explain technical concepts to people with different backgrounds.
Writing blog posts made me better at writing work documents. I started formulating ideas faster, arguing decisions more clearly, expressing myself more concisely. And this directly impacts career - documents are read and remembered, verbal discussions are forgotten.
Career Perspective
In interviews for senior positions and above, the ability to communicate often matters more than knowledge of specific technologies. A blog is a portfolio of communication skills. It shows that you can not only write code, but think systematically, explain decisions, and consider different perspectives.
Several times I’ve been offered jobs specifically because of articles. Not because I was the best expert, but because employers saw: I can structure thoughts and share knowledge. For manager and lead positions, this is critical.
Contributing to the Community (But Not How You Think)
Yes, a million articles have already been written. But your article will be unique because you have a unique experience and perspective.
An article “Introduction to Docker” from someone who uses it for ML experiments will differ from one written by someone deploying microservices in production. Your context, your pain points, your solutions - that’s what’s missing from books and official documentation.
Moreover, people learn differently. Some prefer academic texts from books, others - short practical notes from blogs. Some need Python examples, others Go. Your “yet another article about X” might be the one that clicks for a specific person.
But honestly, community contribution is a pleasant side effect, not the main motivation. If you write only “for others,” you’ll burn out fast.
Product Thinking as a Manager
For an engineering manager, blogging is also practice in product thinking in miniature. You have “users” (readers), a “product” (content), and feedback (comments, statistics).
You learn to think: what problems does this article solve? Who is the target audience? How can I make the material more useful? How do I simplify the complex without losing precision? These are the same questions you ask when your team designs a feature.
Blogging builds empathy for the user. When you write, you constantly put yourself in the reader’s position: is this clear to someone who isn’t in context? Am I assuming too much prior knowledge? This muscle works when you’re designing an API too, and when you’re writing an internal tool for the team.
Tracking Growth
A year or two after mastering a technology, it feels like you always knew it. Memory erases the learning path, leaving only the result. A blog captures that path.
When you return to articles from a year ago, you see how your level has changed. An article you thought was deep then now seems superficial. Problems that seemed hard you now solve automatically. This is tangible proof of growth - not an abstract “I got better,” but concrete artifacts of progress.
This matters for long-term motivation. When you’re stuck on a plateau, when it feels like you’re not developing - you return to old notes and see the path you’ve traveled.
Creating Luck
There’s an observation: luck comes to those who create a “surface area for luck” - make their work visible, share ideas, exist in public space.
A blog expands this surface. An article can lead to:
- A job offer
- An interesting collaboration
- An invitation to speak at a conference
- Meeting like-minded people
- Unexpected feedback that pushes your ideas further
I’ve received messages from people I later worked on interesting projects with. It always started with “I read your article about X, I have a similar problem, let’s talk.”
This isn’t a guarantee, but a probability. The more content you create, the more points of contact with the world.
Antidote to Impostor Syndrome
Paradox: the more you know, the more acutely you feel how much you still don’t know. Impostor syndrome grows alongside expertise. It seems like you’re not good enough to write because there are people who know more.
Blogging helps with this. When you write, you realize: I know enough to formulate valuable thoughts. When you receive feedback - you see that your experience is genuinely useful to others.
Moreover, publishing articles reduces the fear of making mistakes. Made an error in an article, someone pointed it out in the comments - corrected it, thanked them, everyone won. It’s a normal part of the process, not a catastrophe. This attitude toward mistakes transfers to work as well.
So Why Write?
Not for readers. Not for the community. Not for career.
You should write because it makes you a better engineer and manager. It structures knowledge, improves thinking, develops communication skills, and tracks growth.
Articles are a byproduct of your professional development. If they help someone - great. But the main beneficiary is you.
Yes, there are already a million articles. But there’s not a single one written by you, with your experience, your mistakes, your insights. And no one will write that article but you.
So write. Not for the audience, but for yourself. The rest will follow.