Writing Skills Every Software Engineer Needs
Learn a simple writing system that turns notes into crisp tickets, PRs, and RFCs. Cut review cycles, reduce Slack pings, and help your team ship faster with fewer meetings.
Productive engineers ship faster when their writing sets direction.
If your design notes and tickets are crisp, you get fewer review cycles, fewer Slack pings, and fewer meetings.
You do not need to write online to get this benefit, although it helps. Start at work, write to point the team in one clear direction, write clean ticket descriptions and PR comments, and things will move faster.
“You don’t feel ready to start showing your work, but your work won’t be ready unless you start showing up.”
In this post, you’ll learn:
How publishing weekly sharpens design, debugging, and code reviews
A simple writing system I use, idea log → post → reflection
How feedback loops from readers carry into RFCs and PRs
Writing sharpens your engineering thinking
Writing forces clarity. You cannot hide behind vague words, same as you cannot hide behind vague code. Turning a bug report into a clean repro with steps is the writing version of a minimal failing test.
Publishing beats polishing. If you wait for a killer doc, you never start. Weekly cadence builds a shipping mindset, like pushing small PRs on a steady rhythm.
Each thing you write creates momentum. Once the loop runs, stopping feels harder than shipping. The next thing you want to propose, write a small one-pager to communicate your point.
But don’t think you know everything already. Your writing outputs are only good if you keep getting good inputs in your head. If you write everything with an LLM, the only way to get a good output is with a good prompt.
I made stronger code review comments after revisiting some important software engineering books. Since reading Clean Code again, I spot issues faster in reviews and in my own diffs. The first time I read it I missed concepts. Now the rules click and my comments are tighter. When I had Sam Newman’s work fresh, my contributions to a design review landed better. Constant learning, through reading and writing, creates better engineering.
I also learned that taking action on knowledge takes twice the time of consuming it, and action is the only thing that moves the needle.
Writing creates a feedback loop that accelerates growth
Feedback is the fastest teacher. Comments and questions expose gaps you did not see. I thought I had a solid stance on a topic, then a reader’s reply forced me to check my assumptions and tighten my claim.
The same skill makes code reviews and RFCs sharper. You learn to target an audience, use plain words, keep attention, and remove anything that does not earn its place.
Learning the vocabulary of good software pays twice. It makes your prompts to AI precise, and it improves your reviews of other people’s work. I realized the highest leverage activity was learning the theory and keywords of software engineering, then using that language to prompt AI better. Nobody needs a zero-to-hero AI prompting course. You need the concepts that drive better prompts, better questions, and better designs.
Writing builds visibility and influence
Writing makes invisible work visible. Work logs and brag docs help, but publicly shared documents and comments have higher reach. If you practice writing, handing your manager a clean list of outcomes becomes easy. Contributing to a document that will be read by higher-ups is also easier.
Recruiters and peers will reach out more. That creates real job security. Not because your company cannot fire you, but because you have redundancy, people who know you and like working with you.
I’ve been reached out to about open roles and offered referrals just because people knew about me. Nobody will reach out if they don’t know about you. And that doesn’t work only if you write online or post on social media. You have a public presence at work, too. Maybe you’re not considering moving to a new company, but that doesn’t matter. Wouldn’t you want to have the options and be the one choosing?
The point is simple: visibility gives you options.
Writing as a system, not inspiration
I used to think writers waited for a spark. Then I read how pros work, and it is boring on purpose. Show up, same time, same system, and the pages appear.
Inspiration always finds me at 9 am at my desk
My system is simple. Idea log → weekly post → reflection.
Capture raw notes daily. If I do not log experiences, they did not happen.
Expand into short posts and one weekly long form for the newsletter.
Review the log to spot patterns I missed.
You start to see what works at work and in your career. Almost nobody journals about work. Everyone who does finds value.
And once again, this isn’t only applicable to people who write online. You can capture the pain points of your team, write a one-pager, and plan to solve the pain point, and hand it to your manager to get permission to execute on it. Writing is what converts this pain point into a plan to solve it.
As software engineers, we have a lot of idle time. When code is building, when code is deploying, when AI is writing my code... I try to read and find those pain points during the idle time. For example, I took a tech talk on Agent-to-Agent protocols and left the talk with my mind clear about why we should build an agent, not an MCP.
The trade-offs
Everything has a cost, even if it’s not about money.
Vulnerability: If you write something at work, you expose yourself. People could disregard it, nitpick it, or just ignore it.
Time. You may write something that nobody wants to read, or you’ll share it and it’ll never be implemented.
The fix for me is to have cadence over polishing any single proposal. Don’t think everyone will agree with you or will think your writing is great. Get the bad draft out. Get feedback on both the writing and the proposal. The good writing, same as the good software engineering proposals, comes after the bad writing and proposals hit the page.
“If you struggle about writing, show me your bad writing” - Seth Godin
Read like a writer: the 3 phases that turn you into a better writer
If you’re really into improving your writing, everything starts with reading:
The 3 phases of reading:
Phase 1, consumption, fire and forget
Skim, close tab, nothing sticks.
Symptom: You cannot explain one idea five minutes later.
Phase 2, content recall
You remember facts, like after a movie.
Symptom: You can summarize the idea but not reproduce the structure.
Phase 3, creator mode
You reverse engineer research, outline, hook, proof, and CTA.
Symptom: You can rebuild the post from bones to the final draft.
Failure modes and fixes:
Too slow, spending 45 minutes per post you read and analyze
Timebox to 10 minutes, accept an ugly blurb. Repeat often, and patterns will surface.
Abstract notes with no real applicability
End each deconstruction with a 120-word remix. It forces application.
Copying style, losing your voice
Keep the structure, swap examples for your stack and stories.
Conclusion
Clear writing isn’t a nice-to-have for productive engineers.
When your doc is clear, you skip meetings. When your PR comment is clear, you save one review cycle. When your ticket is well written, people deliver faster. Writing cleanly is how productive engineers ship fast.
I learned this after years of rushing and thinking “they’ll get it.” People didn’t “get it”. I got follow-up pings, misaligned reviews, and rewrites. Once I treated writing like refactoring code, we started delivering projects faster.
If you want to move fast, write clearly. It’s the hidden multiplier of engineering velocity.
Write the next doc as if clarity is your main deliverable. Because it is.
This is an article inside our system’s transition from phase 1 to phase 2. I’m building this system for paid subscribers. You can upgrade to paid to get all the benefits.
🗞️ Other articles people like
P.S. This may interest you:
Are you in doubt whether the paid version of the newsletter is for you? Discover the benefits here
Could you take one minute to answer a quick, anonymous survey to make me improve this newsletter? Take the survey here
Are you a brand looking to advertise to engaged engineers and leaders? Book your slot now
Give a like ❤️ to this post if you found it useful, and share it with a friend to get referral rewards
Absolutely support this!
Writing an RFC (Request for Comment) or having a Technical Design document has transformed my team’s delivery.
It empowers engineers and allows space for structured creativity.
The approach avoids lengthy meetings where decisions are not clear.
Additionally, it enables the team to easily align with the entire organisation using just one document!