Why Every Developer Should Write Publicly (Even If You Suck at Writing)
You don't need to be a good writer. You need to write.
The Excuses I Used
- "I'm not a good writer" — Neither was I. Still wrote.
- "I have nothing new to say" — You do. You just haven't realized it.
- "Nobody will read it" — True for the first 10 posts. Then it compounds.
- "I should focus on coding instead" — Writing IS coding. For humans.
- "Experienced devs will judge me" — They're too busy to judge. And if they do, they'll respect the effort.
What Writing Actually Does For You
1. Teaching Deepens Understanding
Reading about closures: "I think I understand."
Writing about closures: "Wait, let me explain this... hmm, actually..."
Teaching closures: "Now I REALLY understand."
The Feynman Technique in action: you only truly know something when you can explain it simply.
2. Documentation You'll Actually Reference
I've Googled my own articles at least 50 times. "How did I set up that Docker thing?" → reads own article → "Ah right, there it is."
3. Career Insurance
Scenario A: No public presence
Recruiter: "Send me your GitHub"
You: "It's private"
Recruiter: "Ok... what have you built?"
You: "A lot of stuff... internally"
Scenario B: 30+ articles on Dev.to
Recruiter: "I saw your article on Docker deployment"
You: "Thanks! That one got 15K views"
Recruiter: "We need someone who can document things"
4. Unexpected Opportunities
Since I started writing:
- 3 companies reached out via Dev.to DMs about job opportunities
- Got invited to write for a tech publication
- Connected with 200+ developers I wouldn't have met otherwise
- Someone sponsored me $50/month on GitHub after reading my posts
- Got freelance referrals from readers
Writing is networking on autopilot.
5. Personal Knowledge Base
Every article is a snapshot of what I knew at that time. Reading my old articles shows:
- How much I've grown
- What concepts I used to struggle with
- Patterns I've evolved beyond
It's a journal of my professional development.
How to Start (Even If You Hate Writing)
Rule 1: Write about what you JUST learned
Don't write about advanced topics. Write about what you figured out yesterday:
Bad topics: "A comprehensive guide to distributed systems"
Good topics: "I spent 3 hours debugging a Docker networking issue. Here's what I learned."
Rule 2: Keep it practical
# What people want:
✅ "Here's a problem → Here's my solution → Here's the code"
# What people don't want:
❌ "In this article we will explore the theoretical foundations of..."
Rule 3: Be honest about your level
❌ "Docker is simple and everyone should use it"
✅ "Docker confused me for months. Here's what finally clicked."
Vulnerability builds trust. Perfection builds distance.
Rule 4: Set a tiny goal
Not "write an article every week." Start with:
- "Write 200 words about something I learned today"
- That's 3 paragraphs. Anyone can do that.
- Some of those 200-word posts will become articles. Most won't. That's fine.
Rule 5: Don't edit while writing
Write the entire draft first. Then edit. Then edit again.
The biggest writing killer is re-reading and editing sentence 1 while you're supposed to be writing sentence 20.
Where to Publish
| Platform | Pros | Cons | Best For |
|---|---|---|---|
| Dev.to | Large audience, easy editor, good SEO | No custom domain | Getting started |
| Hashnode | Custom domain, markdown, community | Smaller audience | Bloggers |
| Medium | Big audience, paywall revenue | Low pay, no code highlighting | General tech |
| Personal blog | Full control, SEO, brand | No built-in audience | Long-term |
| GitHub Gist | Quick, code-focused | Not discoverable | Code snippets |
My strategy: Publish on Dev.to for reach, cross-post to personal blog for ownership.
My Writing Stats (After 40 Articles)
| Metric | Value |
|---|---|
| Total articles | 40 |
| Time to write one | 20-45 min (AI-assisted) |
| Average views per article | 500-2000 |
| Total views | ~25,000 |
| Followers gained | ~50 |
| Time investment | ~25 hours total |
| Direct income from writing | $0 (yet) |
| Indirect income (leads, reputation) | $2,000+ |
The income came indirectly. Someone read my Docker article → needed help with their deployment → became a $500 consulting client. That never would have happened without the article.
The Article Template I Use
# [Catchy Title with Specific Topic]
*One-sentence hook that makes people want to read.*
## The Problem
[What pain point does this solve? Why should the reader care?]
## The Solution
[Step-by-step with code examples]
## Here's the Code
language
// Actual working code, not pseudocode
## Why This Works
[Brief explanation of the underlying concept]
## Common Mistakes
[What NOT to do — people learn from failures too]
## Quick Reference
[Table or checklist for skimmers]
---
*Question for the comments*
*Follow me for more*
The Hardest Part
Starting.
Not the writing. Not the editing. Not the publishing. The blank page.
Here's my trick: Start with code. I write the code example first, then wrap the article around it. Code is easy. Explaining code is what I'm practicing.
Final Thought
You're a developer. You solve problems every day. Each problem you solve is a potential article. Each article is a potential connection. Each connection is a potential opportunity.
Write. Publish. Repeat. The compound effect is real.
What's stopping you from writing? Let's talk about it in the comments.
Follow @armorbreak for more honest developer content.
Top comments (0)