Lesson 3: Writing That People Actually Read
you know what kills most writing from technical people? they think it needs to be comprehensive, technically precise, and formal. it doesn't. it needs to be clear. a clear, slightly oversimplified post that people read beats a perfectly precise post that people scroll past.
The core reframe: write like you talk, then edit like you code. your first draft should be messy and human. then you refactor — cut every sentence that doesn't carry weight, delete filler words, tighten structure. same instinct as cleaning up a function.
Why Engineers Fail at Writing
three reasons. they're all fixable.
reason 1: you write for correctness, not for reading. engineers optimize for being right. readers optimize for being able to finish the paragraph. these are in tension. a technically perfect sentence that takes 3 reads to parse is worse than an 85%-accurate sentence that's immediately understood. err toward clarity, not precision.
reason 2: you front-load context. engineers explain from first principles. "before i get to the point, let me establish the background..." — no. nobody needs the background until they care about the point. lead with the interesting thing. backfill context only if it's necessary.
reason 3: you think formality = credibility. corporate tone, passive voice, hedging ("it may perhaps be the case that...") — all of this signals insecurity, not expertise. people who actually know things say them directly. formality is a trust killer on social platforms. it reads like you're afraid of being wrong.
The one-line test: if someone scrolled past your post and only read the first line, would they know exactly what you're talking about and why they should care? if not, rewrite the first line. the first line is your function signature — it sets expectations for everything that follows.
The Structure That Works Every Time
here's a format template. don't use it for every single post — that gets repetitive and the algorithm will flag it. but internalize the pattern. it works because it maps to how people actually read on social platforms:
[hook: surprising claim / contrarian take / personal story]
[one-sentence explanation of why this matters]
[core content: bullet breakdown, numbered steps, or narrative]
[concrete example or personal experience — makes it real]
[closing: question, hot take, or "what do you think" — triggers replies]
let me show you what this looks like in practice.
bad post (engineer brain):
"I've been reflecting on the role of structured thinking in software engineering, and I wanted to share some observations about how we approach problem decomposition. In my experience, there are several methodologies that can be applied..."
good post (same idea, readable):
"most engineers overcomplicate problems because they're allergic to doing the obvious thing first.
here's what i mean:
- step 1 of debugging should be 'restart it.' we skip this because it feels too simple.
- step 1 of architecture should be 'draw it on paper.' we skip this because it's not code.
- step 1 of writing docs should be 'explain it to a rubber duck.' we skip this because it feels silly.
i spent 4 hours last week debugging a race condition. the fix was restarting the container. i'm not proud.
what obvious thing do you skip because it feels too simple?"
Same idea. Same author. Same credibility. the second version gets read. the first version gets scrolled past. the difference isn't knowledge — it's knowing that readers aren't sitting down with a cup of tea to study your post. they're scrolling on a phone while waiting for coffee. write for that person.
The 5 Rules for Engineers Who Want to Write Well
1. kill the preamble
nobody needs your "for context" paragraph. nobody needs "i've been thinking about..." or "lately i've noticed..." or "a thread 🧵". start at the interesting part. you can backfill later if you must. but honestly, you usually don't need to.
# instead of this:
"I've been reflecting on my journey as a software engineer and wanted to
share some thoughts about the interviewing process..."
# do this:
"the tech interview is broken, and here's the part nobody talks about."
If you catch yourself writing a preamble, delete it. then check if the post still makes sense. 90% of the time it does. the preamble was for you, not the reader. it was you warming up. do that in a draft, then cut it.
2. one idea per post
not one idea per paragraph. one idea per post. threads are for multiple ideas. single posts are for single ideas. if you have three things to say, write three posts or a thread. cramming multiple ideas into one post dilutes all of them.
3. specificity is credibility
# vague (boring, skippable):
"we improved our API performance significantly"
# specific (interesting, credible):
"we rewrote the search endpoint and p99 latency dropped from 2.1s to 87ms"
numbers, names, timestamps, dollar amounts, file paths — these are your tests. they prove the code works. "i increased revenue" is noise. "i rewrote the checkout flow and conversion went from 1.2% to 2.7% in 3 weeks" is a story.
Generalized claims sound like theory. Specific claims sound like experience. if you say "deadlines are usually unrealistic," that's an opinion anyone could have. if you say "my team was asked to ship a real-time dashboard in 2 weeks, and here's what we actually managed vs what we cut," that's a war story. war stories build trust.
4. rhythm matters more than grammar
short sentences hit harder. medium sentences flow and connect ideas together. long sentences, the kind that keep going with clauses stacked on clauses and asides tucked into asides, lose people somewhere around word 20 and never get them back. alternate sentence lengths. it creates a reading cadence that keeps people scrolling.
read your post out loud. if you trip on a sentence, rewrite it. if you run out of breath, it's too long. if every sentence is the same length, it feels monotonous even if the content is good.
5. the scroll-stop is visual, not intellectual
long blocks of text get scrolled past. break everything into chunks of 1-3 lines max. use line breaks aggressively. a 280-character tweet with no line breaks is invisible. the same tweet with 4 line breaks gets read.
# invisible:
"here's something i learned about debugging: most engineers jump straight to the most complex possible cause because solving a hard bug feels more satisfying than finding a simple one but that instinct wastes hours and the fix is usually something obvious"
# readable:
"here's something i learned about debugging:
most engineers jump to the most complex possible cause.
not because it's likely — but because solving a hard bug feels more satisfying than finding a simple one.
that instinct wastes hours. the fix is usually something obvious."
Do not mistake "short paragraphs" for "shallow thinking." the most nuanced, complex ideas in the world have been expressed in simple, readable formats. if you can't explain your idea in a way that's scannable, you might not understand it as well as you think.
The Format Cheat Sheet
pick one per post. these are proven patterns that work across platforms:
| format | opener | when to use |
|---|---|---|
| contrarian take | "most people think X. here's why they're wrong." | when you have a genuinely unpopular or underexplored opinion |
| pattern recognition | "i've noticed something about [industry]. it happens everywhere and nobody talks about it." | when you've spotted a consistent behavior or failure mode |
| personal story + lesson | "i did [dumb thing]. here's what it taught me." | when you have a concrete experience with a clear takeaway |
| data reveal | "we tested [thing] for [time period]. the results were not what i expected." | when you have actual numbers or A/B test results |
| how-to | "here's exactly how i [did thing], step by step." | when you can break down a process into actionable steps |
| curation | "5 things i read this week that changed how i think about [topic]." | when you're consuming good content and can add your own commentary |
Writing with Voice (The Part Engineers Skip Entirely)
voice is what makes your writing sound like you and not like a documentation generator. it's the difference between someone thinking "interesting point" and "i want to hear more from this person."
Voice is not a gimmick. it's not emojis. it's not "being funny." it's the consistent set of choices you make about how to communicate — sentence length, vocabulary, what you assume the reader knows, what you find worth commenting on. voice is the fingerprint of your thinking.
how to develop voice:
- write first drafts in a text editor with no formatting. don't let markdown or bullet points steer you. just type what you'd say if you were explaining this to a smart friend over coffee.
- notice what you naturally do. short sentences? analogies? sarcasm? earnestness? whatever it is, don't suppress it. that's your voice trying to come through.
- edit for clarity, not for voice. your first pass should make it readable. don't polish the personality out of it.
- read writers you like and notice how they say things, not just what they say. steal sentence structures, not ideas.
The fastest way to find your voice: write a post that makes you slightly uncomfortable to publish. if it feels a little too honest, a little too opinionated, a little too you — that's the post that will resonate. the posts you write while thinking "does this sound professional enough?" are the posts nobody will remember.
Quick Check
Practice: Write and Ship
Find a recent popular post in your niche that you found boring or hard to read. Rewrite it using the structure template and the 5 rules from this lesson. Compare the two versions. What did you cut? What did you restructure? What made it better?
Using the format cheat sheet, pick one format and write a post. Rules:
- No preamble. Start at the interesting part.
- One idea. Don't try to say three things.
- Line breaks every 1-3 sentences.
- End with a question that invites replies.
- Publish it. Don't overthink. Ship it.
If you're nervous about publishing, remind yourself: nobody is paying as much attention to you as you think they are. Your post will be forgotten in 24 hours by everyone except the few people it resonated with — and those are the people you're writing for.
The first 50 posts you write will be mediocre. that's expected. you can't skip the mediocre phase. the only way through it is volume. write, publish, repeat. writing skill is a function of reps, not insight.
1. 1. What's the biggest mistake engineers make when writing for social platforms?
2. 2. Which of these post structures hooks a reader better?
3. 3. Why is specificity more credible than generality?
4. 4. The 'one-line test' for a post asks:
5. 5. What's the best way to develop your writing voice?