Subscribe
Recent content on Refactoring English
The first time I saw Michelangelo’s David in person, I wept. Never in my life have I witnessed a more beautiful piece of content.
I wasn’t the only one who felt that way. Museum patrons all around me were looking up from their phones to admire David as well. Despite it being legacy content, David was so scrollstoppingly captivating that it generated stronger engagement than TikTok and Instagram combined, despite those platforms offering fresher, more personally relevant content.
A good design doc can save you years of development time. Writing a design doc forces you to think through important decisions before you waste time on the wrong implementation or paint yourself into a corner. It’s also the best way to coordinate design decisions among teammates and partner teams.
I’ve written design docs as a developer at Google, Microsoft, and within my own companies. The specifics vary, but the underlying principles remain the same. A design doc should articulate the hard problems you’re solving and help your teammates give you feedback.
I created three design docs for the same open-source web app:
I generated the AI versions in a few minutes. I fed the agents a prompt that included the design docs chapter of my book and a skeleton design doc structure. The agents who wrote the AI-generated docs did not see the version I wrote.
I’ve worked as a developer for 20 years, and I’ve always cared about clear writing. When I join a new team, the first thing I do is ask to update the onboarding documents. As I ramp up on the team, I document what I learn and encourage my teammates to do the same.
Sometimes, other developers ask me why I invest so much into writing. Programming is technical, so why spend time on a “soft skill” like writing? Isn’t that why we have technical writers and product managers?
With 2025 wrapped up, I can finally answer a question I’m curious about every year: who were the most popular bloggers of Hacker News?
Who counts as a blogger?
I explain more in my methodology page, but it’s basically anyone who blogs as an individual rather than as part of a company or a team. For example, John Graham-Cumming blogged while he was the CTO of Cloudflare, so I count his personal blog but not his posts to the Cloudflare company blog.
One of my favorite programming books is Crafting Interpreters by Bob Nystrom. It teaches you how to build a programming language from scratch. Along the way, you learn about text parsing, data structures, virtual machines, and several other skills that make you a stronger developer.
I was re-reading the book recently and realized that its introduction is delightfully effective. Developers are terrible at writing introductions, so it’s worth studying what makes the Crafting Interpreters intro so compelling.
You’ve spent weeks carefully writing a design document for your software project, but what happens next? How can you get useful feedback from your teammates? How do you prevent your design review from devolving into petty arguments?
I’ve been through many design reviews in my career as both the author and reviewer, and I have a special fondness for effective reviews. Through trial and error, I’ve learned techniques that help the review process move smoothly and yield material improvements to the design.
You’ve spent weeks carefully writing a design document for your software project, but what happens next? How can you get useful feedback about it from your teammates? How do you prevent your design review from dragging on for months?
I’ve been through many design reviews in my career as both the author and reviewer, and I have a special fondness for effective reviews. Through trial and error, I’ve learned techniques that help the review process move smoothly and yield material improvements to the design.
Adam Gordon Bell is a developer, blogger, and the host of the software engineering podcast, CoRecursive. I interviewed Adam about writing and his success at attracting customers through his blog posts when he worked at Earthly.
We talk about:
Note: I’ve lightly edited the transcript for brevity.
For the past eight months, I’ve been working on my book, Refactoring English: Effective Writing for Software Developers. I’m publishing the book incrementally as I write, which means readers give me feedback about the book in real time.
I started writing the chapters I felt most confident readers would like, but now that I’m about 50% complete, I want to make sure the remaining chapters are things my readers actually want to learn.
For software developers, there’s tremendous value in writing effective emails. Good emails save time, reduce misunderstandings, and earn you recognition within your company.
A release announcement showcases how the user’s experience is better today than it was yesterday. That sounds obvious, but most release announcements seem to forget that there’s a user at all.
So many release announcements just enumerate new features in a way that’s totallly divorced from how real people use the software. The announcement is essentially just a changelog with better writing.
For example, here’s a “changelog” style of announcing a new feature:
I recently spoke to a developer who tried blogging but gave up because nobody was reading his posts. I checked out his blog, and it was immediately obvious why he didn’t have any readers.
The developer had interesting insights, but he made so many mistakes in presenting his ideas that he was driving everyone away. The tragedy was that these errors were easy to fix. Once you learn to recognize them, they feel obvious, but some bloggers make these mistakes for years.
This exercise tests your ability to recognize the passive voice in the context of developing software.
For each sentence, click:
Does this sentence contain passive voice?
Accuracy: 0%
This exercise tests your ability to recognize the passive voice in the context of developing software.
For each sentence, click:
Does this sentence contain passive voice?
Accuracy: 0%
Your high school English teachers probably warned you that passive voice is dangerous and forbidden. Then, when you were an adult, some guy in a leather jacket told you that passive voice is cool and should be used whenever it’s desired.
Well, the tide has turned again. If you’re a software developer, stop using the passive voice.
In English, sentences can have one of two structures: passive voice or active voice.
