The smartest devs i know obsess over a skill most engineers ignore

The fastest way to ship code is still the slowest skill in engineering: writing.

Every senior engineer I respect has one strange obsession. And it’s not Kubernetes, not Vim wizardry, not even mastering yet another JS framework.

It’s writing.

Yeah, the thing most of us were told was “extra.” The thing bootcamps skip because it doesn’t ship features. The thing juniors dismiss with the classic “the code speaks for itself.” (Spoiler: it doesn’t. At best, it mumbles in broken English at 2 AM.)

But here’s the twist: every time I’ve seen a catastrophic bug, a sprint go sideways, or a 2 AM pager alert, at least half the chaos could’ve been prevented if someone had just written things down. A design doc. A decent commit message. Even a debugging note. Writing isn’t fluff it’s how you keep a system (and your brain) from falling apart.

And now, with AI coding tools everywhere, this “useless” skill just got more critical. Copilot, Cursor, and GPT don’t magically read your mind they amplify whatever you feed them. Bad prompt? Garbage output. Clear, precise, written context? Suddenly AI feels like a mid-level dev you can trust.

TLDR: Writing is the most underrated dev skill. It’s not extra work it is engineering. In this article, I’ll show how our culture undervalues it, the disasters it prevents, how it scales with teams (and AI), and a playbook for training it without becoming a wannabe novelist.

Three ways engineers short-circuit themselves

If writing is so powerful, why do most engineers treat it like optional DLC? Three reasons keep popping up:

1. School and bootcamps never taught it

Universities obsess over algorithms and proofs. Bootcamps sprint toward shipping CRUD apps. Nobody grades you on design docs. Nobody makes you practice writing a clear spec. Writing is treated as “soft” when it’s really infrastructure for thinking.

2. The myth: “the code speaks for itself”

This is the junior dev’s favorite line. Seniors know better. Code documents what changed, but rarely why it changed. Without the why, every repo turns into an archeological dig. Future-you stares at a random function and mutters, “What the hell was I thinking?”

3. Speed culture: writing feels slow

At startups, writing gets shoved aside for “move fast.” But here’s the irony: skipping docs feels fast until you’re in prod at 3 AM, trying to reverse-engineer what “fast” shipped last quarter.

I watched a team skip documenting API edge cases because “we’ll figure it out later.” Six months later, prod blew up with random 502s. Two weeks of chaos followed. The cause? A nullable field that had been mentioned verbally in one meeting never written down.

Writing as debugging fuel (from prod bugs to git commits)

Debugging without writing is like trying to speedrun Dark Souls blindfolded. You can brute-force your way for a while, but eventually you’ll get stuck in the same death loop.

Debugging diaries = external RAM

Your brain has limited RAM. After three or four failed debugging attempts, you forget what you already tried and start repeating yourself. Writing breaks that loop.

I once chased a prod bug where an API only failed on the third retry. For hours I just reran tests, tweaked configs, and cursed. Finally, I opened a text file and wrote down every attempt. Ten lines later, I noticed the failure only happened when log rotation kicked in. Bingo. Writing exposed the pattern my brain had missed.

It’s rubber duck debugging but the duck is a Notion page, a GitHub issue, or even debug.log. The act of explaining the problem in words forces clarity. Half the time, by the time you’ve finished writing, you’ve solved it.

Commits = breadcrumbs for future-you

Commits are the other underrated form of writing. Code shows what changed. Commits explain why. And future-you will hate past-you if you leave no breadcrumbs.

I’ve had plenty of git blame moments where the culprit was me. The commit? git commit -m "fix stuff". Thanks, past-me. Real helpful.

Now I write commits like diary entries. Example:

git commit -m "Fix pagination in user API

The client broke when tokens contained slashes because we URL-encoded
incorrectly. Switched to base64 encoding to avoid breaking on certain
usernames. Added regression test for case."

That’s a breadcrumb trail. Compare it to:

git commit -m "fix user bug"

One is archaeology. The other is a map. Seniors write essay-length commits not because they love typing but because they’ve been burned enough to know it saves hours later.

Receipt: Chris Beams’ guide on commits.

Design docs: the cheat code nobody respects

If debugging notes and commits are survival tools, design docs are the real cheat code. They’re the difference between building a system and just winging it.

And yet, most engineers treat them like bureaucracy. “We’ll figure it out in code” sounds faster until production teaches you otherwise.

The disaster that could’ve been avoided

On one project, we skipped a design doc because the feature was “just a small API tweak.” Two months later, half the frontend broke when nobody agreed on how pagination tokens should work. Backend used one format, frontend assumed another, QA assumed none at all. A full sprint got burned rebuilding something that a single page of text could’ve prevented.

Why big orgs obsess over docs

This is why serious engineering orgs don’t treat docs as optional:

• Google has guidelines on writing design docs.
• Stripe is famous for its memo culture debates happen on paper, not in endless meetings. Stripe memo culture.
• Amazon requires six-page narratives before big decisions. Meetings start with everyone silently reading. Sounds brutal, but it forces clarity. Amazon 6-pager.

Docs aren’t red tape. They’re trade-off machines. They force you to answer questions early:

• What are we building?
• Why are we building it?
• What’s the downside?
• What could explode in prod?

Design docs are speed, disguised as slowness

Writing a doc feels like slowing down. But nothing slows you down more than re-architecting because nobody agreed on the system in the first place. A half-hour writing session can save three sprints of rewriting.

Design docs aren’t busywork. They’re what separates senior engineering from feature hacking.

Why writing matters more in teams (and with ai)

Here’s the dirty secret of engineering: the best idea doesn’t always win. The clearest one does.

I’ve sat through design reviews where two engineers had equally solid solutions. Guess which one got built? The one with the crisp doc: trade-offs laid out, diagrams included, risks spelled out. The other? Lost in Slack threads and half-finished sentences.

Writing = leverage

Writing multiplies your impact. A good Slack summary unblocks a whole team. A precise Jira ticket saves QA from guessing. A clear design doc can kill three weeks of circular meetings. It’s not “soft skills” — it’s leverage.

That’s why orgs like Stripe and Amazon obsess over memos. Whoever frames the problem best shapes the solution. If you want influence as an engineer, write better than you talk.

And then ai showed up

AI didn’t make writing irrelevant it made it unavoidable.

Here’s a bad prompt:

fix my api call

What you get back: garbage-tier guesses.

Here’s a good prompt:

Write a Python function to call the /users API.
- Must handle pagination tokens
- Retry up to 3 times with exponential backoff
- Log errors with request ID
- Idempotent: same input → same output

That’s not magic. That’s just clear, structured writing. The same skill that makes good design docs and commits makes AI actually useful.

People say “Copilot writes garbage.” No it writes garbage when you ask it garbage. Garbage in, garbage out. Engineers who thrive with AI are the ones treating prompts like design docs: detailed, precise, intentional.

Writing doesn’t just scale across teams it scales across humans and machines. If you can’t explain it, your teammates won’t build it and your AI won’t generate it.

Receipts: OpenAI Cookbook prompting.

A playbook for writing that saves your ass

Okay, cool theory but how do you actually practice this without turning into that guy who writes 3,000-word Jira tickets nobody reads?

Here’s the loadout I wish someone had handed me early in my career. Four tools, minimal fluff, maximum payoff.

1. Design docs → align before you build

• Rule of thumb: if it takes more than a day to code, take an hour to doc.
• Cover: what, why, trade-offs, gotchas.
• Use diagrams when words get clunky.
• Resource: Google eng doc guide.

2. Commits → write like future-you has amnesia

• Code shows what; commits explain why.
• A good commit is a breadcrumb trail for future-you at 3 AM.
• Keep the subject short, body detailed.
• Resource: Chris Beams’ commit guidelines.

3. Debug diary → stop thrashing

• Keep a running log while debugging: one line per attempt.
• Prevents “groundhog day” debugging loops.
• Helps spot patterns your tired brain can’t.
• Tool: Notion, Obsidian, even debug.log.
• Inspiration: Julia Evans zines.

4. Explainers → teach one thing a week

• Write one quick explainer (Slack, Discord, Notion) about a bug you fixed or a concept you learned.
• Doesn’t need polish clarity beats pretty.
• Bonus: half of these become blog posts later.

Decision table (when to write what)

This isn’t about writing novels. It’s about writing just enough that your team and future you doesn’t waste another sprint relearning the same painful lesson.

The choice that makes a 10x engineer

The whole “10x engineer” myth usually gets painted as some hoodie-wearing wizard slamming out code at midnight. But here’s what I’ve actually seen: the engineers who move teams, projects, and even companies forward aren’t the fastest typers. They’re the clearest explainers.

When you can frame a problem so well that everyone else understands it instantly, you’ve multiplied your impact. When your commit messages read like a story, future devs thank you. When your design docs surface risks early, your whole team avoids disasters. That’s not “extra work.” That is engineering.

AI just raised the stakes. A vague prompt makes your AI assistant worse than an intern. A clear, detailed one makes it feel like a staff engineer. The better you write, the more leverage you get not just with humans, but with machines.

So here’s the choice: you can treat writing like a chore, or you can treat it like a core engineering tool. Every senior I respect has already made their choice.

The real 10x skill isn’t cranking out lines of code. It’s being able to write your thinking so well that teammates, managers, and even AI systems can build on it.

And if you don’t believe me? That’s fine. Argue with me in the comments. Just make sure you write it down.

Helpful resources

If you want to sharpen your writing-as-engineering skills, these are worth saving:

• Google eng doc guide → how one of the biggest engineering orgs structures design docs.
• Julia Evans zines → comics and guides on debugging, documenting, and thinking clearly.
• Chris Beams on commits → the gold standard for commit messages.
• OpenAI Cookbook → practical recipes for prompting and using LLMs effectively.
• Rubber Duck Debugging → the classic method of writing/explaining problems out loud (or on paper).