Writing for Developers • Piotr Sarna & Glauber Costa
Engineer and author Piotr Sarna discusses his evolution from a reluctant writer to a book author, detailing a pattern-based approach to creating high-quality technical content and overcoming the common fears engineers face when writing.
In a conversation with Glauber Costa, Piotr Sarna, co-author of “Writing for Developers,” shares his journey from being “gently forced” to write blog posts at ScyllaDB to becoming an author. Initially terrified by a form of “stage fright,” Sarna’s experience provides a playbook for engineers on how to approach, structure, and benefit from technical writing.
The Engineer’s Mindset and the Fear of Writing
For many engineers, the prospect of writing is daunting. Sarna’s initial reluctance stemmed from several common fears:
- Fear of Being Obvious: A concern that the topic is too simple or uninteresting to a wider audience. Sarna notes that even a post he considered “super boring” about a filtering implementation was later cited by users who learned from it.
- Fear of Being Wrong: The anxiety that a technical mistake will lead to public shame. However, Sarna found that in practice, feedback is almost always constructive criticism, if it comes at all.
- Imposter Syndrome: The feeling that one is not qualified to write on a topic, which is closely related to the fear of being obvious.
Over time, Sarna learned to balance technical depth with accessibility. You cannot go down every rabbit hole. A key insight was learning to make posts concise, comparing the editing process to minimizing a program: “Just keep dropping things. If after dropping it’s still a complete article, then it’s better because it’s shorter.” This respects the reader’s short attention span and makes the core message more impactful.
A Pattern-Based Approach to Technical Content
A core idea from the book “Writing for Developers” is that most successful technical blog posts fall into recognizable patterns. Identifying these patterns can help writers structure their thoughts and find ideas for content.
-
The Bug Hunt: This is Sarna’s favorite pattern, framed as a “detective story.” It details the process of investigating and solving a complex bug. Its strength lies in showing the entire problem-solving journey, including dead ends and the tools used. This format is highly educational, as it equips readers with new techniques and a memorable narrative.
-
We Rewrote It in X: A popular and often contentious pattern where a team describes rewriting a piece of software in a new language (e.g., Rust, Go). These posts attract significant attention and debate, tapping into language loyalties and evangelizing for a particular technology.
-
How We Built It: Typically authored by large companies, these posts detail the architecture of systems built at a massive scale. They serve as powerful educational resources and recruiting tools, showcasing interesting problems and sophisticated solutions. It’s a way of “flexing” that signals to potential hires, “come work with us because we have 100,000 GPUs.”
-
Lessons Learned: This pattern focuses on sharing experiences—good and bad—from a project, such as a database migration or a system outage. The goal is to allow others to learn from your mistakes without having to make them firsthand. It often takes the form of a retrospective or a post-mortem.
-
Thoughts on Trends: Described as the “black belt of writing,” this pattern is best utilized by individuals who have already established credibility in a field. It involves commenting on a current trend, and its success depends heavily on the author’s reputation.
-
Benchmarks and Test Results: This is a notoriously difficult pattern, as the author is considered “guilty until proven innocent.” Readers will inherently suspect that the benchmarks are engineered to favor the author’s product. Success requires a transparent, sound methodology, though a segment of the audience will always remain skeptical.
On Feedback and Public Speaking
As writing leads to a public profile, dealing with feedback becomes essential. Sarna advises simply not looking at comment sections, as most criticism is not constructive. He notes, “I inherently do not really care that much about criticism that isn’t constructive at all.”
This mindset extends to public speaking. After being unexpectedly scheduled for a talk, Sarna discovered that the fear is often worse than the reality. The audience is either genuinely interested or not paying attention. It’s perfectly acceptable to say “I don’t know” and follow up later.
For non-native English speakers, the message is clear: don’t let language skills be a barrier. The technical substance is what matters. As Sarna puts it, “If somebody nitpicks your grammar, that means that the technical part was already spotless. So, it’s great.”