Writing for Developers

Stockholm Syndrome to Serial Book Writer: Piotr Sarna’s Writing Journey

Glauber Costa: Welcome to the GOTO Book Club. I am your host for today, Glauber Costa, and I am joined today by Piotr Sarna. Piotr and I worked together a long time ago when I had a full head of hair at ScyllaDB, where I was one of the founding engineers. At the time, Piotr was an ascending engineer getting more awesome by the day pretty fast. And today, I believe,  Piotr, you could say, is an internationally acclaimed book author. You have just published a new book. You've been writing a lot of content. And today I think we'll love to talk about it. So Piotr, for starters, why don't you tell us more about yourself, your career and what got you here?

Piotr Sarna: Alright, thanks and hello everyone. My name is Piotr Sarna. People usually refer to me as Sarna first and foremost because it sounds funny in Portuguese and also it's easier to pronounce for most folks. I've been working on distributed systems most of my career, starting with ScyllaDB. I would also like to clarify that a full head of hair is a little bit of a long shot, but...

Glauber Costa: You're right, I'm being a little bit, yeah. It was already on its way out when we met. It's just the full transformation.

Piotr Sarna: I've seen the full transformation, that's true. Yeah, and while at ScyllaDB I was gently forced to write lots of content, which then kind of made me write books in plural. By now, yeah, and now I also do AI because it's trendy, but yeah, I'm still a distributed system developer deep down. That's me.

Glauber Costa: Awesome. And at ScyllaDB, we actually had a lot of Piotrs, right? It's a fairly common Polish name as far as I understand. So we kept having more and more Piotrs and we had to find a way to differentiate between you all. The last name is usually very hard to say, but in your case, it's easy. So we usually just went with Sarna. And Sarna, I'll keep referring to you like that as I'm used to. Tell us more about the book. So when did you release the book? What is the book all about? And let's dive into that.

Piotr Sarna: This book [Writing for Developers: Blogs That Get Read] is not really a technical book, it's a meta-technical book because it's about writing technical content. The main reason we wrote it with Cynthia was, first of all, because Cynthia came up with the idea and I couldn't resist. And second of all, it was kind of a natural continuation of the first book we wrote with two more people back then when I was still a developer. The previous one was about database performance. Then once you start releasing books, I suppose you can't really stop. I'm already kind of urged to write some more things, even though I don't have the faintest idea what more to write, but I really do want to do this. So it was kind of a natural continuation and the main motivation for the book was that Cynthia had this excellent idea that since she's an experienced writer, as in writer of actual English, and I can produce technical stuff, we have two different perspectives on how to write technical posts that are, well, I don't know, high quality, interesting. So we just combined those two perspectives into a single book so that people can hopefully learn more.

Glauber Costa: Somebody meeting you for the first time and getting to know you wouldn't guess right out of the bat that you would be so skilled at writing and doing this so much. In fact, there was usually something that people used to say at ScyllaDB that you were caught smiling once, right? So you don't seem like you're not a very friendly person. You're not an extrovert. So you have this persona of the engineer that is really writing code. And as I said, that changed at ScyllaDB when you were, what was the word you used, like gently forced to start writing content. I want to dig a little bit deeper into that experience. How did it feel for you? It must have been quite challenging and quite scary, quite honestly, in the beginning. So let's talk more about that.

Piotr Sarna: First of all I denounced being seen smiling once, somebody made it up. I didn't smile even once in my whole life. It was an urban legend. At first, when I heard that maybe I should write a post about something that I implemented, I just tried to figure out how to refuse without being fired, let's say. I think it was in the first month or two of my job. I was really excited to have joined Scylla and I didn't want to refuse an executive order to write. But I did have something that people usually probably experience at that stage, like this kind of stage fright that happens even though I … technically, when I think about it now, it makes absolutely no sense because I just wrote stuff offline and then published it so there's no stage, nobody’s staring at me. But I kind of had similar thoughts about it. I was terrified that somebody in the  general public could look at something that I produced, which made even less sense, thinking that I'd already spent a few years at open source projects by then. I both interacted with the community and published code, which is not much different. I really didn't want to do that. But I also figured that if I don't do that, then it's going to maybe be a problem in the future, in my professional future. So, I just did it.

Glauber Costa: Do you remember what was it about? The first experience, I guess we will never forget.

Piotr Sarna: It was a super boring piece about some filtering implementation that,  from a technical point of view, wasn't really that interesting. It was just catching up with features that virtually any other database had for 30 years. That was just that, which was one more reason why I was kind of unsure if I wanted to write about that, because I wondered if anybody would ever even look at it, glance at it, and think that it's interesting. But then I do remember some people quoting it at Scylla Summit and so on in person that they read this filtering piece and they learned something from it. Yeah, that was a little weird, but yeah.

Glauber Costa: I find that fascinating because I've been doing this for a long time. I was probably one of the people, I don't quite remember, but I was probably one of the people involved in forcing you. At the time, I was trying to help a lot with the content machine at Scylla and we needed more writers. I've been writing for a long time. I wrote a lot of pieces before that. I kept writing after I left. But even as an experienced person, there is always this fear. I'm speaking for myself, but from what you're saying, it seems that you feel the same thing. That people are just going to find it too obvious, right? Who even wants that? Sometimes it's a similar phenomenon, I guess, to imposter syndrome, because you do have this fear about like “Who in the world would pay attention to this thing that I wrote? Who cares?” But it turns out, in a lot of situations, I mean, it feels obvious to you, but people do care. I had the same feeling in a lot of situations when I write something that, for me, is the most obvious thing in the world. And then a subset of people, I mean, of course, some things are less obvious and some things are more obvious, but there's always a subset of people who enjoy it.

Piotr Sarna: I was worried, first of all, that people would find it too obvious and too uninteresting. But then I was also scared that there would be some obvious mistake and I would just publicly, know, shame myself saying something untrue or buggy in public, which actually never happened to me so far. Nobody actually approached me and said that something was wrong. And if they did it, it's actually constructive criticism, so it would be nice.

Recommended talk: Writing For Nerds - Blogging For Fun and (Not Much) Profit • Charles Humble • GOTO 2023

Technical Depth vs Simplicity

Glauber Costa: That is such an engineer-minded concern. If it's a politician, it's like I'm concerned that somebody will, it's the opposite, right? I'm just supposed to be lying and then maybe people are going to think I'm telling the truth. But for us as engineers, and you touched on a great point, I mean, like we always want to make sure that what we're writing is accurate. And at the same time, people who are reading your post, you don't know who they are, but you have to assume that they don't have the same level of knowledge that you have in this particular thing, of course, that you're writing about. So sometimes it's important to generalize things and come up with simpler explanations. Do you struggle with that or is it something that you acquire with time? Just to convey those things to an audience that is interested in the topic. And they're technical for sure, but they might not be domain experts in what you're writing about.

 Piotr Sarna: So there needs to be a balance here because you do want to go deep on some topics but you also can't go down the rabbit hole and be too technical. It's hard because you need to decide before writing, I suppose, if you're targeting the general public, if you want this post to be Hacker New trending or whatever, or if you would rather make a post that's more like your own personal documentation of something very deep down for a specific niche. I think I wrote both and I always tried to just usually refer to some third-party documentation if I want people to learn more about something. Stop at some point with the deep down very technical pieces and say, “If you want to learn a little more just look at this, this is a great article on the topic” and meanwhile I'll just continue with this higher level stuff to actually make the blog post concise enough so it’s possible to read it in 5 or 10 minutes, not 35.

Glauber Costa: You've done both, but I suppose that, and it touched on a great point that I want to get back to, but I suppose that there is a class of articles that usually, generally speaking, does better than others, right? So if you're writing something that is more like your mental dump, I would presume, and this does match my experience, but I would presume that you have a lot fewer readers than if you write a more general purpose thing that tries to keep it technical of course, but tries to raise the level of abstraction. Does that match what you've seen so far?

Piotr Sarna: How do I tackle this? I'm trying to figure out the specific examples from my pieces that I wrote or that I like. I think if you categorize your readers, let's say very interested readers that actually read the whole thing and then even interact with you on some comment section or or anything else, then you can write an article that fewer people will read, but 90% of them will actually be really interested in the topic. But then, if you really just want as many people as possible to just click on it and skim through it, then you can also achieve that, and then you don't go very deep and you just cover a few interesting pieces in a more shallow way and then it's more likely to land on Hacker News front page. But you should also expect, I think, that like 90% of comments’ authors just basically saw the title and then commented something.

Glauber Costa: I think this is a phenomenon that goes beyond just blog posts and articles. It's more of a modern, driven by social media I suppose, way of people behaving, which is like “I've seen the article and I've seen the title.” We do try to convey, I guess, a decent amount of information in the title and catch readers. And given, you know, there's so much information around that you're fighting for attention with so much content, that you have to have a catchy title, I presume. But then from that title, people sometimes think, “Hey, I understand, I know what this person means and I have an opinion about it.”  But they haven't even read the piece. We see a lot of that. I would say that, especially when you share something on social media, a decent chunk of people that are commenting, they haven't really read what you wrote, right? Then they're complaining about stuff that it's in the beginning.  It's just the way it is, right? Just the way it is. You touched on something. I remember my initial experiences were always, hey, look, it's almost like I'm writing a scientific article. So I want to put all the information here. I want to make sure that every single thing is covered. But then you end up writing something that takes like 20 minutes to read, 25 minutes to read, and or even 15 minutes to read. And at the end of the day, you know, from the point of view of how complete this is, it might be a “better” article. But then nobody reads it. And you see that there are people who read the introduction and people will read the conclusion. And you touched on that point. It's got to be short, right. People will read this and extract this one idea. And that's a heuristic that I developed over time. There is one idea that I want to convey in this post. Anything else might be important, but it's not the core of it. It's a tangent. So don't touch on it. How did you learn this? Is this something that, you know, somebody taught you and you listen or you were more of a stubborn guy like me that had you publish like a bunch of articles until you say, okay, I'll make peace with the fact that this is the way

Piotr Sarna: I have some strong opinions of how short attention span is nowadays. TikTok didn't help, let's say. I also noticed myself as a reader that I often skim through the general structure, like headers, first. And only then I qualify the article if I'm going to read it at all or not. And I did tend to ignore articles that were so long that I couldn't even find the scroll bar with my cursor. That suggests that I'm not going to spend time reading it anyway. Sometimes I do, or I should, but I just don't in practice. Well, but what made me do it? Well, at ScyllaDB, I think we even preferred those long scientific posts, at least to a degree, because nobody ever told me “Can we just drop this paragraph?”But  I do remember it once or twice from one of the Turso blog posts. I think it was a Zig piece maybe. It was reviewed and either you or one of the folks what was the name of this guy who

Glauber Costa: Probably Doug [Stevenson]. For a quick pause, a quick pause for context, after Scylla, we also worked together at Turso, which is the company where I am at today currently.  Piotr is sadly no longer with us, but we also wrote a bunch of content there too. So that's just because we haven't mentioned it before, I want to give the listeners this context.

Piotr Sarna: Yeah, I keep forgetting that the audience might not be aware of that. Yeah, we worked together for quite some time, including working on content. And either you or Doug pointed out a whole paragraph and said that while this is very nice and true and interesting, does anything actually change? Does the main goal of the article remain the same if we just drop this whole thing? And I said that actually, when I delete it, the article is still as coherent and complete as without it, so let's just reduce it to its minimal form.

Recommended talk: Intro to the Zig Programming Language • Andrew Kelley • GOTO 2022

Writing, Refactored

Glauber Costa: You do have this feeling, I guess, if you're too... We end up getting too married to the things we produce. That's true for software, for articles. Then there's this sense of like, I want to convey this information. But when you take a step back, mean, do I really need to convey this particular piece of information? Because the reality is that the reader will extract one point. mean, right? So putting more things might even distract from the main point. So you take it out to make this thing shine. And did you notice an improvement in the kind of reception that you had? Did you feel like your writing style improved when you started having this discipline about, now, it's as much about taking it out as it is about putting it in.

Piotr Sarna: This Zig piece was a success. I don't know if deleting this particular paragraph was the reason, of course, but it definitely didn't ruin it. I liked it because it's kind of like those, when you go technical for a moment, there are those automated ways of minimizing computer programs, but they just randomly delete some portions of it and check if they still pass all the tests and if they do, then then you just continue and iterate until you can't minimize further. You should kind of do that to a degree with a blog post as well, just keep dropping things. If, after dropping, it is still a complete article then it's better because it's shorter. More people will feed it into their five-second attention span and you just pretty much share mostly the same amount of information with less text, which is more optimal for everyone. So yeah, I do enjoy various optimizations on text right now, after spending quite some time posting.

What Motivates You to Write?

Glauber Costa: That's great. And what keeps you motivated to continue writing? Because you keep doing it, right? And as we said, not only you kept doing it, you've done more of it. You wrote two books, which I guess, it's a very different experience than writing blogs and articles. So first of all, I want to touch on that. I mean, why do you do it? Did you just fall in love with that? Or is there a reason for you to write? It's like a marketing reason for a company. It could be. I mean, that's part of the reason we do a lot of technical writing in my company, which is just like, this is one of the best ways that we have to reach an audience and to build trust with an audience of developers. But I guess there might be other reasons too. So what is the thing that keeps you pushing?

Piotr Sarna: So there are actually many many aspects to why I continue. The first clarification is not what but who, and Cynthia who pushes me towards writing more and more books in particular. But as for other reasons, the main one.. it may sound like a joke but I'm actually very serious… is that I'm very mean and I like screwing my future self and committing to writing something and then being mad at my past self for agreeing to work and now I need to deliver. Because it's how it works for me. I just do more things if I first commit to it even though I suspect that in the future I would rather be lazy and not do it. So that's one thing. With books, it's even easier because if you've got a publisher over your head and you really need to deliver stuff or they keep pinging you to death. Or Cynthia pings them to death if they don't.

Glauber Costa: You've been mentioning Cynthia a lot and she's definitely one of the luminaries in the book writing territory and articles in general. She's a great resource that Scylla has and is a person that I came to appreciate over time as well. But what's the main difference, in your experience, between writing a piece with a person like Cynthia that is helping you, that is directing you, that is a co-author of your work versus writing a piece by yourself?

 Piotr Sarna: I might be a little impaired, but now I can't really imagine writing a larger piece just by myself. Yeah, because it's easier with technical posts, because then you write mostly technical content and then it's still better, probably… If it's a corporate blog, then you just find somebody to edit it a little bit, make it a little bit more coherent. Even if you don't, then it's probably fine because it's technical content, it's the code snippets and benchmarks that matter more often than your perfect English. But for longer pieces, I couldn't imagine just figuring out how to write a whole book by myself because I mostly spurt out some barely coherent content and then leave it in the Google Doc. And then, after one or two days, it's rewritten in beautiful prose. So that's how it worked for me. Yeah, so I would struggle a lot. I would probably lack motivation to also write a whole book just by myself. because I probably get too technical, lack these prose writing skills to actually produce 300 pages of something that's readable.

Glauber Costa: I guess that is in the main topic, which is like technical writing and content blogs, articles, et cetera. As I said, I think part of the reason we do it is because you want to, as a professional, there are many benefits in communicating your work to others. There are benefits to you. A lot of people had said in the past that they've got job offers through blogs that they wrote. We actually hire people who wrote blogs in the past because there's a lot of signals in that. At the very least, there is a signal there that you're willing to put your face out and face the crowd. As you mentioned before, there's no stage fright because there's no stage, but there is definitely the comment section and you're putting yourself out there. For the company, there are benefits as well because if you do it right,  I guess you make your technology, make your services better known. I think a lot of people don't do it right, which is something that we can touch on as well. But when you ask somebody to write a piece as you describe when Scylla  first came to you and said, “Hey, write a piece about this filtering thing you've done.” And then they inform you that look, you know, somehow you doing well in this company is predicated or at least boosted by your writing. 

Engineering Blog Post Patterns

Glauber Costa: One of the things that happens is that people say, “Okay, I could write more, I could write more.” But how am I supposed to find out what to write about, how to generate those ideas? Now talking about your book a little bit, one of my favorite parts of the book, which I read thoroughly…, by the way, it's a fantastic book. But my favorite part is when you try to distill this into patterns. Don't know what you write about? Why not rewrite it in X? Thoughts on this, et cetera. So what are those patterns? How did you identify them? And what is your favorite pattern to write about?

Piotr Sarna: This patterns idea was one of the first things we figured out when we discussed how to structure the book. At first, we had the terrible idea – I'm so glad that we changed it –  about first figuring out those patterns but then writing a fake blog for each pattern. This would first of all make me write lots of fake blogs, and they would tend to get similar because how many of those can you write? And then it would be very artificial and boring. Yeah, I wouldn't really like to read it, not to mention write it. But then Cynthia again came with a brilliant idea of reusing the world's knowledge on this and just going through tons of blog posts and qualifying them for various patterns and then, based on those examples, just figuring out what are the common structures or ideas or some other features for every single pattern. So yeah, so we gathered, I think we read and went through hundreds of blog posts to get there. And yeah, the patterns we picked, let me just get the whole list so I don't miss any single one, was Bug hunt, then We rewrote it in X in something, not X from Elon, but X as a placeholder, How we built it…

Pattern 1: Bug Hunt

Glauber Costa: Let's go through all of them with a quick explanation. The first one is the Bug hunt. So what is Bug hunt and why do people like it?

Piotr Sarna:  Bug hunt is kind of like a detective story among blog posts, technical blog posts. Its main goal is that somebody was trying to find an interesting bug and either found it or not. Usually, they did, or they wouldn't have written about it. And it's also structured a little bit like a detective story, which is what I like most. It shows you the whole process of finding the solution, some dead ends. Actually, my favorite blog post of all time I think, one of the top, at least, was from a ScyllaDB engineer then, maybe even an intern, Michał Chojnowski, or maybe he was already an engineer, about the NUMA performance bug. This is also the first example. It was about how he couldn't at first find why, on a specific processor architecture, ScyllaDB performed worse. And then he tried a few very interesting scenarios and techniques. Some of them failed but gave him hints on what else to try, and then he finally found it. Yeah it was like really like reading a detective story with an ending where he finds out what was the problem and solves it and all the way down you also... 

Glauber Costa: I guess this is interesting because you're trying to get the reader in your mindset, right? You start by saying, “Hey, this is what we observed.” And as a reader, this is interesting because like we all love puzzles, stories. I mean, that's one of the most rewarding parts of being an engineer. So it's almost like if you go on a roller coaster ride, right? I think the reason people like amusement parks and roller coasters is that you're exposed to danger, but in a way that you know it's safe, right? So you don't actually want to be in danger, but you wanna be exposed to the thrill. And I guess it’s the same, like when you are an engineer, you love puzzles and you love finding those issues, but your job might be on the line, right, if it’s a real problem. So when you're reading somebody else's horror story, you're like, “None of this makes any sense and I've seen this thing, this is what we expected…” I would say that it sounds to me a little bit like being in an amusement park on a roller coaster ride. I'm in danger, but not really because it's already solved, it's already fixed. And to be honest, it's somebody else's problem, not mine, but I want to participate in the thrill. Is this why you like this or do you have... This is why I like it, but maybe you have your own reasons.

Piotr Sarna: There is this cathartic effect that you kind of experience someone's emotions which is usually rage in a controlled way. But I like it more for the educational aspect because after reading one, even one such blog, you come armed with some tools that somebody used for solving a problem and then you can, since those stories are so interesting, so it's easy to remember them even with some details. You might just remember, “Ooh I think something similar happened to this guy three years ago so let me look it up and maybe I'll use the same techniques and it will still work and it will still be the real issue.” So what I enjoy most is that now I can do the same magic things that Michał did when figuring it out. And before reading it, not necessarily. I could have missed something.

Pattern 2: We Rewrote It In X

Glauber Costa: Awesome. And what's the second pattern?

Piotr Sarna: The next pattern in the book is “We rewrote it in something.” So this is quite a self-descriptive pattern. We mostly figured out that it's a pattern because of Rust because there was a time where you couldn't…

Glauber Costa: Well, Go as well. There's a lot of things being rewritten in Go. Most recently, one of the best performing pieces I think I've ever seen, the team at Microsoft that wrote the TypeScript interpreter in Go. And I guess part of the reason why it does so well is that people love fighting, people love teaming, right? So there are always the people who “You say I rewrote this…”  and we recently had our own experience because we are in the process in our company of rewriting SQLite in Rust, right, which is a part of our strategy,  something very important that we're doing. We wrote posts about it as well. But what happens is that immediately you get the bait – and you don't do it because of that, but you know that there's going to be the people who come and say “Okay great, but why not Zig? Why not Go?” So everybody wants to question you on why you haven't done it in their favorite language, right? And then people start fighting and it's fascinating to see to some extent.

Piotr Sarna: It's actually this Microsoft and Go piece that fueled another article that I'm going to put in... Let's take a short side note. As part of promoting and continuing the book, we also started a small web page for gathering interesting pieces, like a continuation of those examples where we qualify blog posts and summarize them. It's called writethat.blog and I'm going to put a summary of a piece about choosing languages from Steve Klabnik. This is in another category which we're going to reach soon (Thoughts on Trends). But it just touches on that. It was obvious that there is a trend that people fight over languages and this article was about dealing with this trend, whether it's right or wrong and so on. So it's interesting how those are connected in a way. But yeah, the “we rewrote it” pattern is quite self descriptive, it's about rewriting things in another language. There are many purposes that this kind of article may serve. Some of them are genuine evangelism for a language. We wrote something in Zig, which is what I wrote and I genuinely enjoyed it so I decided to share it. That was one of the reasons. Then, since it's a popular topic, you might also take the form of a rant that the previous language really sucked or maybe that the new language really sucked in some ways so we can let off some steam. Yeah, that's also something that targets a specific audience really. Because it usually attracts people who either like or do not like the first language or the second language or are just here to fight over languages even if they didn't read anything but the title. Yeah, they are usually broadly discussed, where unfortunately most of the discussion is just about why one of the languages is superior over the other.

Pattern 3: How We Built It

Glauber Costa: And what's next on the list?

Piotr Sarna: Next is “How we built it,” which is also something I like to read, especially when it comes from corporate blogs. Normally, I prefer blogs from individual authors where they actually write about something personal, but those are usually interesting because some things you can only write at a huge scale. It's like if Netflix tells you how to write, how to implement something that handles 17 billion streams per second somewhere, it's not something that an average developer can pull off because they don't have the resources. So this pattern is kind of interesting because usually it's better the larger the company that produced it is and it's usually the opposite with the other patterns. So this is another category.

Glauber Costa:  I guess this does have a huge educational value, right? So like a lot of those companies will do, for example, when I was a Datadog, we did system interview questions for people who were interviewing at the company. And I guess you can learn a lot about system design at scale. Obviously there is a difference between learning and doing. And as you mentioned, like a lot of the very interesting things you can only do once you reach a certain scale. But at least reading those blogs can teach you a lot about how those companies are usually thinking about those problems.

Piotr Sarna: Especially if you don't work at a huge company, it's an interesting perspective to learn how they do it. I also kind of enjoy this bit because often… it's kind of maybe unintuitive why those companies would even describe how they build a huge system if they potentially could just spill those secrets to the competition. But often this...

Glauber Costa: And why do you think that is?

Piotr Sarna: Well, I'm pretty sure that mostly it's kind of like flexing and boasting, which is because often you can extend this title to “How we built it and you can't, haha.” Even if you have all this knowledge, you can't possibly pull the same scale.

Glauber Costa: I think it does play a role. It does play a role with hiring as well, which is a different kind of boasting. I guess, sure, your competition will read it, and they think, wow. But the people who are really mesmerized by those are the people who could, for engineers, especially the good engineers, want to work on interesting problems. So by showcasing to the world that you have interesting problems and you have a good methodology to solve those problems, you're going to give the engineers the freedom. It's one of the ways to signal to the market, “Come work with us because this is a place where you can work on interesting problems.”

Piotr Sarna: Definitely. You can, it could be even very materialistic as in “Come work with us because we have 100,000 GPUs and we happen to have written a blog post on how to put them in a single data center.” So it is boasting, but usually in a positive way. It's like something I really enjoy reading.

Glauber Costa: A little bit of humble bragging never killed anybody, right? So just, yeah.

Piotr Sarna: Oh, yeah, definitely. I mean, it's still very nice that they shared whatever they did, because usually it's also interesting from a technical perspective. If it's not, then people will qualify it as a form of marketing bullshit and ignore it because readers are quite smart.

Pattern 4: Lessons Learned

Glauber Costa: And the next one I think is the, you know, I actually have the book in front of me, is the “Lessons learned” pattern, right? So I guess this one is like I screwed up and what we learned from it.

Piotr Sarna: This is usually about a personal experience. That doesn't mean it needs to be personal. It can be personal experience while working at your company, of course. It’s kind of maybe similar to the bug hunt, but there doesn't necessarily have to be a bug or a mystery or anything like that. It might be just as easy or hard as explaining an interesting issue or project that you've worked on. The main point of those articles is that you had some problems that you needed to overcome while working on something, migrating the database or implementing something from scratch and you would like to share your problems so that when other people try to work on a similar thing, can just learn from your mistakes without making the mistakes first. So it's like, yeah, this one is very much about sharing your genuine experience so that other people can learn from it without, you know, not the hard way, just like you did. That's the main point of those articles. Or, it can be a postmortem of when a company needed to deal with some crash or downtime and they needed to fix something fast. And while doing that, they reached some conclusion that if they had done something else first, they wouldn’t have ended up with a problem like this. 

Other Blog Post Patterns

Glauber Costa: We're getting close to the end. What is the last pattern that you would like to highlight from the book?

Piotr Sarna: There are two more patterns. The first is "Thoughts on Trends" - it's a bonus pattern that you can only use after you've established credibility. If you just write your thoughts on something, there's a high chance people will ignore it because they don't know who you are. It's more likely that your blog post will trend if you're actually known for having opinions in that area. It's best to first write posts in your niche, build your reputation, and then it’s more likely that your thoughts on hot topics become more interesting to people. 

Glauber Costa: It's the final stage - the black belt of writing. So you first need to earn respect. Obviously, there are people who have strong opinions, but that doesn't mean they're right or well-supported opinions.

Piotr Sarna: Well-supported articles are the best. If they're not supported, they're usually just rants. But if somebody is famous and writes anything, it's going to land on the front page.

The last pattern is "Non-markety product perspectives" - how to present something you want to sell as a company or individual, but wrapped in educational content rather than just marketing gibberish.

There's also "Benchmarks and Test Results," which is obvious but tricky. There is a way to write benchmarks that aren't fake, contrary to what some people think.

Glauber Costa: Benchmarks are challenging. At Scylla, benchmarking was a central part of our strategy. And it sometimes took weeks to write a good benchmark, you really want to make sure the methodology is sound. But it doesn't matter how much effort you put in - everybody’s going to assume you're faking it because there's so much fakery out there. The moment people see anything suspicious, they assume vendor bias. It’s a very challenging thing to write about

Piotr Sarna: We call this feature of the pattern "guilty until proven innocent." That's how it works with benchmarks unless they're independent. There's a subcategory where an independent individual compares products - those are usually considered fair and not nitpicked. If you're comparing your own product against something else, people will accuse you of bias. But if you compare two versions of your own product, it's usually assumed to be quite fair.

Glauber Costa: Can you really be proven innocent? There's always a class of people who will never believe you.

Piotr Sarna: Exactly. It's tricky because you're going to be accused by the whole internet of making results work in your favor.

Surviving the Spotlight

Glauber Costa: How does it feel to be accused by the whole internet? The more attention you have, the more negative attention you receive, and it doesn’t seem to be linear. The more people see something trending, the more they want to pull you down.. As an extreme introvert, how do you deal with all the criticism?

Piotr Sarna: I think it works the same way for most people. After a few posts get attention and negative feedback, you just don't bother looking at comments. Like our colleague Pekka Enberg suggests - he recommends that you don't even open the comment section. I sometimes do because there's occasionally constructive criticism, but usually it's posts from people who only read the title. I don't deal with it because I inherently don't really care about criticism that isn't constructive. It truly doesn't bother me.

Glauber Costa: You’ve done a lot of public speaking as well. One thing follows the other…as you start writing more, you get more invitations to speak. What's scarier - writing or public speaking, especially for someone with your personality?

Piotr Sarna: I'm absolutely fine with online conferences. In-person conferences -- I haven’t been to one for ages now. I would probably still be a bit nervous, mostly because I can't have helper scripts on my screen that nobody can see, just in case I get stuck. The trick with drinking water is great - if you get stuck, just drink some water. It looks natural and nobody cares.

I remember the first ScyllaDB Summit where I had a presentation. I actually failed to notice I was scheduled because your email asking me to do it landed in Spam. And when I didn't respond, you assumed I agreed. Then I saw myself in the agenda and thought "What?" I was super nervous and even printed out my whole transcript.

But during the Q&A, which is usually the scariest part for those of us with stage fright, I realized that most of the audience doesn't care at all and after five minutes they're looking at their phones. Those who do care ask genuine questions out of interest, not to trick you. It's fine to say you don't know and follow up later. After that, I realized it wasn't super scary at all.

Glauber Costa: Things are scary until you’re brave enough and you do them. The second time is easier, the third time even easier. A lot of stage fright comes from novelty and fear of the unknown.

Piotr Sarna: Absolutely. It becomes routine. I'm out of this particular routine because I’m not that into traveling, but if I signed up for something, I wouldn't be particularly nervous.

Glauber Costa: Sarna, it’s been a tremendous pleasure to talk to you today. Where can people find the book and your work?

Piotr Sarna: Everything about the book, and more, can be found at writethat.blog. That's where we continue cataloging interesting blog posts into patterns, and there's a link to the book. I encourage everyone to read it because it's not just about patterns. It’s also really condensed knowledge on working with drafts, structuring posts, and writing well in English. Cynthia wrote most of that part, and I learned a lot from her chapters.

Glauber Costa: Your native language is Polish, right? Writing the amount and quality you do in your non-native language is impressive –even with help. Don’t discount yourself.

Piotr Sarna: You just need to play lots of video games in English when you're young. For non-native English speakers, who are the majority of blog post authors, it’s important to realize that nobody cares if you make typos or have incorrect grammar. If somebody nitpicks your grammar, that means the technical part was spotless - which means your blog was amazing.