Ep. 38 Writing for Developers With Piotr Sarna

Ep. 38 | Writing for Developers With Piotr Sarna ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fd3t3ozftmdmh3i.cloudfront.net%2Fstaging%2Fpodcast_uploaded_nologo%2F43243169%2F43243169-1746559462989-16d13287f57d8.jpg&w=512&h=512) ## Document Notes > [!note]+ Document Notes > tags: [technical-writing, developer-communication, book-club] > author: Overcommitted Podcast > source: YouTube > reference: https://www.youtube.com/watch?v=glwOSF424XQ > date created: 2024-12-19 10:30 > > # 🏷️ Title: Ep. 38 | Writing for Developers with Piotr Sarna >  ## 🧰 Action Inbox - [H1] Start writing book chapters as extended blog posts — reduces intimidation factor #writing - [H2] Use AI for editing/review, not content creation — maintain authentic voice #ai-tools - [H3] Advocate for writing culture on engineering teams — improves documentation and recruitment #team-culture ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Writing for Developers Book](https://writingfordevelopers.substack.com/) - [Write That Blog](https://writethatblog.substack.com/) - [Overcommitted Podcast Discord](https://discord.gg/overcommitted) ## 📝 Summary - Piotr Sarna discusses co-authoring "Writing for Developers" with Cynthia Dunlop - The book focuses on engaging technical blog posts rather than documentation - Co-authoring makes writing easier by splitting workload and providing editing support - Three key characteristics: intriguing topic, distinctive educational core, smooth delivery - Writing culture improves team communication and company recruitment ## 📖 Main Content The conversation explores how technical writing extends beyond documentation to include engaging storytelling for developers. Sarna emphasizes that co-authoring reduces the intimidation factor of book writing by treating each chapter as an extended blog post. The book identifies specific patterns in successful developer blog posts and provides ongoing examples through Write That Blog. Key insights include using AI as an editing tool rather than content generator, and building writing culture within engineering teams to improve both internal communication and external recruitment. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/glwOSF424XQ?t=0) — Introduction and Guest Background - Key idea: Piotr Sarna co-authored "Writing for Developers" focusing on blog posts, not documentation - Evidence: "We specifically didn't want to describe how to write engaging documentation because it's boring" #### ⏱️ [02:30](https://youtu.be/glwOSF424XQ?t=150) — Learning VHDL and Logic Gates - Key idea: Sarna studies hardware fundamentals unrelated to his distributed systems work - Evidence: "I keep coming back to learning logic gates and VHDL to understand how systems actually work" #### ⏱️ [04:15](https://youtu.be/glwOSF424XQ?t=255) — Co-Author Collaboration Origin - Key idea: Authors met through work at ScyllaDB, never met in person during book writing - Evidence: "We actually didn't meet in person ever since that's a fun fact" #### ⏱️ [06:45](https://youtu.be/glwOSF424XQ?t=405) — Previous Database Book Success - Key idea: First book was open source and gained popularity in their niche - Evidence: "The book is open source and available for free online. It had quite a few views" #### ⏱️ [08:20](https://youtu.be/glwOSF424XQ?t=500) — Co-Authoring Is Easier Than Solo Writing - Key idea: Collaboration reduces workload and provides professional editing support - Evidence: "Co-authoring is substantially easier for a start, especially with Cynthia as a skilled ghost writer" #### ⏱️ [10:30](https://youtu.be/glwOSF424XQ?t=630) — Chapters as Extended Blog Posts - Key idea: Breaking books into chapters makes writing less intimidating - Evidence: "Each chapter is kind of like an extended blog post. You probably already wrote enough to comprise a whole book" #### ⏱️ [12:10](https://youtu.be/glwOSF424XQ?t=730) — Write That Blog Origin and Purpose - Key idea: Blog provides up-to-date examples of patterns described in the book - Evidence: "We wanted something that is up to date all the time as a natural continuation of the book" #### ⏱️ [15:00](https://youtu.be/glwOSF424XQ?t=900) — Filling the Developer Writing Gap - Key idea: Most writing resources for developers only covered documentation, not engaging content - Evidence: "99% of books that talk about writing for developers just mention documentation which is boring" #### ⏱️ [18:45](https://youtu.be/glwOSF424XQ?t=1125) — Three Key Characteristics of Good Posts - Key idea: Successful developer writing has intriguing topic, distinctive educational core, smooth delivery - Evidence: "Cynthia came up with three characteristics: intriguing topic, distinctive educational core and smooth delivery" #### ⏱️ [21:30](https://youtu.be/glwOSF424XQ?t=1290) — Tiger Beetle Database Example - Key idea: Best technical writing goes above and beyond with interactive elements - Evidence: "They implemented a browser game just to make their blog post cooler which worked obviously" #### ⏱️ [25:20](https://youtu.be/glwOSF424XQ?t=1520) — Reading Strategy for the Book - Key idea: Book can be read out of order, patterns section is self-contained - Evidence: "Don't feel inclined to read from chapter one, we wrote this book totally out of order" #### ⏱️ [28:15](https://youtu.be/glwOSF424XQ?t=1695) — Writing Culture in Engineering Teams - Key idea: Technical blogging proves understanding and creates better documentation - Evidence: "If everyone keeps writing technical blog posts, it's clear that you understand what you implemented" #### ⏱️ [31:40](https://youtu.be/glwOSF424XQ?t=1900) — Starting Writing Culture - Key idea: Begin by writing something, then ask to publish officially on company blog - Evidence: "Write something up front then start asking around if it could get published officially" #### ⏱️ [35:50](https://youtu.be/glwOSF424XQ?t=2150) — Cringe Writing Examples and AI Usage - Key idea: Use AI for editing and review, but don't let it create content - Evidence: "By all means use AI to review your blog post but do not let it actually create content" ## 📚 References - [Writing for Developers Book Repository](https://github.com/writing-for-developers) - [Write That Blog Substack](https://writethatblog.substack.com/) - [Overcommitted Podcast Community](https://discord.gg/overcommitted) - [ScyllaDB Technical Blog](https://www.scylladb.com/tech-talk/) ## 🗣️ Paraphrase - Technical writing for developers should focus on engaging storytelling and educational content rather than just documentation - Co-authoring books becomes manageable when treated as writing several extended blog posts with editorial support - Successful developer writing combines intriguing topics with distinctive educational value and smooth delivery ## 📰 Newsletter **Level Up Your Technical Writing Skills** The latest Overcommitted podcast features Piotr Sarna discussing his book "Writing for Developers" - a fresh take on technical communication that goes beyond documentation. Key takeaways include treating book chapters like extended blog posts to reduce intimidation, using AI for editing rather than content creation, and building writing culture within engineering teams. The book identifies patterns in successful developer blog posts and emphasizes storytelling elements that make technical content engaging. Perfect for developers looking to improve their communication skills and increase their visibility within organizations. **Resources:** [Writing for Developers](https://writingfordevelopers.substack.com/), [Write That Blog](https://writethatblog.substack.com/), [Overcommitted Community](https://discord.gg/overcommitted) ## ✅ Action Items #### DevRel - Create pattern-based content templates: develop reusable structures for technical blog posts based on successful examples - Educational workshops: run sessions on technical storytelling and narrative structure for developer audiences - Developer experience: improve technical documentation by incorporating storytelling elements and engaging examples #### Community - Book club coordination: facilitate reading groups using Discord and Blue Sky for multiple communication preferences - Writing mentorship: pair experienced technical writers with developers beginning their writing journey - Content sharing: create spaces for developers to share and get feedback on their technical writing #### WordPress - Documentation: apply storytelling patterns to make WordPress documentation more engaging and educational - Community: encourage technical writing culture within WordPress contributor teams - Training: develop writing workshops specifically for WordPress developers and contributors ## 🧪 Hypotheses - Co-authored technical books have higher completion rates and better quality than solo-authored ones - Engineering teams with strong writing cultures have better internal communication and external recruitment - Technical blog posts following specific patterns receive more engagement than unstructured posts - Interactive elements in technical writing significantly increase reader engagement and comprehension ### 📊 Methodology - Survey technical writers on collaboration vs solo writing experiences and completion rates - Analyze engagement metrics across technical blog posts categorized by identified patterns - Compare hiring metrics between companies with and without technical blogging cultures ### ❓ Questions - How can technical writing patterns be adapted for different programming languages and frameworks? - What role should AI play in technical writing education and skill development? - How can remote teams best foster collaborative writing practices? ### 🔮 Future Research - Analysis of successful technical blog post patterns across different developer communities - Impact of technical writing skills on career advancement in software engineering - Effectiveness of various AI tools for technical writing assistance vs content creation ### 💡 Implications - Practice: Developers should view technical writing as an extension of their programming skills - Education: Writing education for developers should focus on patterns and storytelling rather than just documentation - Policy: Engineering teams should consider technical blogging as part of professional development - Community: Technical writing can serve as both internal communication tool and external recruitment strategy ### 🧠 Learning Styles Assessment Reading level estimate: 10-12 (Advanced technical vocabulary balanced with conversational tone) #### 👀 Visual learners - Present: Podcast format limits visual elements, relies on verbal descriptions - Improve: Companion materials with blog post pattern diagrams, writing structure visuals #### 🔊 Aural learners - Present: Full audio discussion with multiple voices and conversational format - Improve: Chapter-by-chapter audio summaries, guided listening questions #### 🗣️ Verbal learners - Present: Rich examples, analogies (chapters as extended blog posts), clear definitions - Improve: Glossary of technical writing terms, comparison frameworks #### 🧩 Kinesthetic learners - Present: Book club activities mentioned, hands-on writing practice encouraged - Improve: Writing exercises, pattern identification worksheets, collaborative editing tasks #### 🧠 Logical learners - Present: Clear pattern-based structure, systematic approach to technical writing - Improve: Decision trees for pattern selection, metrics for measuring writing success #### 🧑‍🤝‍🧑 Social learners - Present: Book club format, Discord community, collaborative writing emphasis - Improve: Peer review protocols, writing partnership guidelines #### 🧘‍♀️ Solitary learners - Present: Book reading can be individual, personal reflection on writing examples - Improve: Self-assessment checklists, individual writing challenges #### 🌿 Naturalistic learners - Present: Organic pattern recognition in existing blog posts - Improve: Content ecosystem thinking, writing as part of developer environment ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Audio-first format naturally accessible to screen readers - Improve: Transcript with proper heading structure, linked timestamps #### Keyboard navigation - Present: Standard podcast controls work with keyboard navigation - Improve: Enhanced web player with clear focus indicators #### Contrast and readability - Present: Audio content eliminates visual contrast issues - Improve: High-contrast transcript design, readable typography #### Text resizing and reflow - Present: N/A for audio content - Improve: Responsive transcript layout supporting zoom to 200% #### Media and captions - Present: Full transcript available - Improve: Structured transcript with speaker identification, downloadable formats #### Forms and interactions - Present: Simple podcast interface - Improve: Accessible community signup, clear form labels ### 🌍 DEIB Assessment #### Cultural breadth - Present: International perspective with Polish author, global remote work discussion - Improve: More diverse examples from different cultural contexts in technical writing #### Inclusive language - Present: Gender-neutral terms used throughout, technical jargon explained - Improve: Plain language alternatives for complex concepts #### Neurodiversity support - Present: Conversational pace allows processing time, multiple communication channels mentioned - Improve: Content warnings for rapid topic changes, structured summaries #### Representation - Present: Mix of male and female hosts, international guest - Improve: More diverse examples in writing patterns, varied cultural perspectives #### Psychological safety - Present: Supportive discussion of "cringe" writing examples, learning-focused tone - Improve: Explicit encouragement for beginners, normalize writing mistakes ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear argument that co-authoring reduces individual workload (supported by evidence) - Inductive strength: Pattern identification based on multiple blog post examples - Causal reasoning: Writing culture leads to better team communication (needs more evidence) - Analogical strength: Chapters as extended blog posts (effective simplification) #### Fallacies - Survivorship bias: Examples focus on successful blog posts without analyzing failures - Anecdotal evidence: Heavy reliance on personal experience without broader data #### Tone of voice - Overall tone: Conversational and encouraging, balances expertise with accessibility ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on critics or alternative approaches - Reverse victim/offender: Not applicable to this content - Emotional cues and rhetoric: Positive, encouraging tone throughout ## 🎯 Conclusion Technical writing for developers extends far beyond documentation to include engaging, educational content that builds both individual careers and team cultures. The key insight is making writing approachable through patterns, collaboration, and treating each piece as an extended blog post rather than an intimidating large project. Organizations that foster technical writing cultures see benefits in both internal communication and external recruitment. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Co-authoring reduces writing intimidation through workload distribution > [!quote] [Ep. 38 | Writing for Developers with Piotr Sarna](https://www.youtube.com/watch?v=glwOSF424XQ) by [[Overcommitted Podcast]] via [[YouTube]]. Published 2024-12-19. Accessed 2024-12-19. > "Co-authoring is substantially easier for a start, especially with Cynthia as a skilled ghost writer." Collaboration provides editorial support and reduces individual burden for large writing projects. [view highlight](https://youtu.be/glwOSF424XQ?t=500#H1) #writing #collaboration ID:rw_001 ### [H2] Technical writing patterns enable consistent quality content creation > [!quote] [Ep. 38 | Writing for Developers with Piotr Sarna](https://www.youtube.com/watch?v=glwOSF424XQ) > "It's really amazing how the initial list of patterns applies to any new blogs that happen every month." Identifying structural patterns in successful content creates reusable frameworks for future writing. [view highlight](https://youtu.be/glwOSF424XQ?t=730#H2) #patterns #content-strategy ID:rw_002 --- ## Full Transcript [00:00] Welcome to the Overcommitted Podcast, [00:02] your weekly dose of real engineering [00:04] conversations. I'm your host this week, [00:06] Britney, joined by Hey, I'm Bethany. And [00:09] I'm Erica. The three of us met while [00:10] working on a team together at GitHub and [00:12] realized we all are obsessed with [00:14] getting better at what we do. We decided [00:16] to start this podcast to share what [00:17] we've learned. Be talking about [00:19] everything from leveling up your [00:20] technical skills to navigating your [00:22] professional development. All with the [00:24] goal of creating a community where [00:25] engineers can learn and connect. Today [00:28] we are joined by Sarna joining us from [00:31] Poland, one of the authors of the book [00:33] writing for developers and that is what [00:35] we are going to talk about today and I'm [00:37] so excited about it. Thank you so much [00:39] for joining us. [00:40] >> Thanks and hi. So my name is P, but feel [00:42] free to call me Sar because that's way [00:43] easier to pronounce for everyone. I [00:45] program distributed assistance for a [00:47] living, but I also got into writing [00:49] first blog post and then books. So here [00:52] I am. [00:52] >> That's awesome. to kick us off. What is [00:54] one thing you're currently building or [00:56] obsessed with learning right now? [00:58] >> I keep coming back to learning that what [01:02] would be the name of it like logic gates [01:04] and stuff. So, VHDL and very lock so [01:08] to the roots of uh how all those system [01:11] actually works. through a year or so I [01:14] come back to learning all the [01:16] fundamentals and I hope that in a few a [01:18] few months maybe I'll learn enough to [01:20] just uh order my own system on chip like [01:23] the first one. So this is like totally [01:26] unrelated to my day job but something [01:29] I'm kind of passionate about. [01:31] >> It's awesome. Doing things that are [01:32] completely unrelated to my day job is [01:34] one of my favorite things to learn about [01:36] as well. Sometimes that's sometimes [01:37] that's nice. So, we also there was a [01:39] co-author for the book writing for [01:41] developers, Cynthia Dunlop, who was not [01:43] able to join us. She uh got impacted by [01:45] the post AWS flu that it seems like it [01:48] went around to everybody that went to [01:50] reinvent. Um, but I know you both [01:51] co-authored the book together. I'm [01:53] curious, how did you two meet and decide [01:55] to tackle this project together? [01:58] >> We've we actually didn't uh meet in [02:00] person ever since that's you know, fun [02:03] fact. We've always only seen Syn mostly [02:05] through Riverside of all places. We [02:09] worked at Sil for a time and uh the [02:14] story started with a previous book of [02:16] ours which was about databases and the [02:18] way it started was as follows. I was [02:20] approached by uh Appress the publisher. [02:24] They wanted to actually they wanted to [02:27] find an author to write a book [02:28] specifically about CADB. I kind of [02:31] didn't want to do it. So I forwarded [02:33] them to the marketing department of CIA [02:35] DB and we figured out that maybe I will [02:38] first of all co-author a book with four [02:40] people total and then make it a general [02:42] book about databases because a book [02:44] about CLB will be out of date the moment [02:47] it's released and maybe if we just cover [02:49] some fundamentals of performance and [02:51] other aspects of databases it will have [02:53] better shelf life let's say and that was [02:55] a nice well I would call it a success it [02:58] was uh the book is open source and [03:00] available for for free online. It had [03:03] quite a few views. Uh so yeah, I was [03:06] happy to see it getting popular enough [03:08] in our niche. And then by this time I [03:11] was already kind of hooked on writing [03:14] books and when Cynthia approached me [03:16] about writing another one, I just read [03:18] on the spot and this time we approached [03:20] a few publishers. Ultimately we decided [03:23] on Ming and yeah and then we wrote this [03:26] one. It was totally unrelated to the [03:28] previous database one, but it was I [03:30] think it was even funnier to write. [03:32] >> Yeah, somewhat related in the in the [03:34] developer realm, but very different [03:36] topic for sure. [03:37] >> Yeah, [03:37] >> writing a book seems like it it's [03:39] probably really hard. And then [03:41] co-writing is probably another whole [03:42] layer of extra things on top of that. [03:45] Um, what was a collaboration process [03:46] like writing a book with another person? [03:48] >> I'd like to strongly disagree that that [03:52] co-authoring is harder. It's actually [03:53] way easier if you cater with Cynthia. [03:57] That's [03:59] that's the secret sauce. Uh Cynthia is [04:02] first of all a skilled ghost writer and [04:04] also a writer. So she kind of took all [04:08] the burden of pre-editing everything off [04:11] me. I could just spill out barely [04:13] coherent sentences and she would just [04:15] form them to beautiful English sentences [04:18] that we could then pass to the publisher [04:20] for review. So uh it's way easier first [04:24] of all because of that. Uh and second of [04:26] all writing a book like a whole book [04:29] might be might be a little tough because [04:31] it's it might take a year or three. If [04:34] you write 1/4th of a book it's a couple [04:37] of months. So it's like you can see the [04:39] end of it. So it's actually especially [04:42] in with the first database book we [04:44] actually everyone was responsible for a [04:45] few chapters. So all I had to do was [04:47] like [04:49] write three chapters if I remember [04:51] correctly maybe four and each chapter is [04:54] kind of like an extended blog post. So [04:56] just that and then you have a book. So [04:58] uh I would say that uh co-authoring is [05:01] substantially easier for a start [05:04] especially to the point that I would [05:06] never actually selftor without uh [05:09] without co-author and without sa [05:11] specifically I suppose. [05:13] >> Yeah that makes sense. I feel like maybe [05:15] it's also one of those things where like [05:16] the idea of writing a book seems very [05:18] intimidating because it's a whole a [05:21] whole book, but does it feel a little [05:23] bit less intimidating now that you've [05:24] done a couple of them? [05:25] >> It would still feel a little bit [05:27] intimidating for me to read the whole [05:29] book, but yeah, I mean a half, not so [05:32] much. It would just be yet another book. [05:34] And if you think of every single chapter [05:36] as an extended blog post, then it's [05:38] yeah, you probably already wrote enough [05:41] of those to comprise for a whole book. [05:44] So you just do it in a row and then get [05:47] everything reviewed and published. [05:48] >> That makes sense. I like the idea of [05:50] looking at it as an extended blog post. [05:52] That does seem a lot less terrifying [05:54] than writing a book. And if I understand [05:56] correctly, you both run Write That Blog [05:59] as well. Can you tell me a little bit [06:00] about what that is and what it's all [06:03] about? [06:05] >> It started as a as a promo for the book [06:08] itself. We wanted to have a place where [06:11] we would continue giving examples of the [06:14] patterns of blog posts that we that we [06:17] described in the book that are up to [06:19] date monthly. The book is structured in [06:21] a way that a huge part of it is a couple [06:23] of patterns that we that we just kept [06:26] seeing everywhere. If you browse hacker [06:28] news, I can pretty much assign patterns [06:32] as as you see them right now cuz it's [06:34] like muscle memory at this point. So, uh [06:36] since uh we already for every for every [06:39] one of those pattern chapters, we had [06:42] some examples but those would eventually [06:45] get out of date and we wanted something [06:46] that is up to date all the time. So, we [06:48] just started this monthly this section [06:50] of blog posts and we just post them [06:52] there. That's pretty much it. It's like [06:54] a natural continuation of the book. [06:56] Nice. Is there anything that you've [06:58] learned since the book was written from [07:00] that write that blog? Like is there any [07:02] like new insights you've gained that [07:04] didn't make it into the book since [07:06] you've been running that? [07:07] >> I think there's one pattern that we [07:09] didn't capture well, which is somebody [07:12] describing how something totally [07:15] unrelated to their work works. So it's [07:17] usually I do assign it a pattern because [07:19] we only have so many of them to pick [07:22] from, but I'm usually undecided about [07:24] this one. So maybe I should consider [07:26] adding like an appendix to the to the [07:29] book describing one more one more of [07:31] those. But otherwise, no, it's really [07:34] really amazing how the initial list of [07:36] patterns applies to any any new blogs [07:39] that that happen every month. [07:41] >> That's really awesome. I love that you [07:43] all are continuing on with your thesis [07:45] of the book and to continuing to provide [07:48] examples for folks to um to look [07:50] towards. So that's really cool. shifting [07:52] into maybe the book specifically. So as [07:56] as we know the book is called writing [07:58] for developers and I'm curious from your [08:01] experience what gap were you trying to [08:03] fill in the existing landscape for [08:05] writing resources? Was it just lacking [08:07] in general or was it lacking [08:09] specifically for developers and what are [08:11] your thoughts on that? So before our [08:13] book was released, we did some research [08:15] if there's anything that really covered [08:17] exactly the same topic. And [08:19] unfortunately [08:21] 99% of books that talk about writing for [08:24] developers just mention documentation [08:26] which is boring from the start and we [08:28] specifically didn't want to describe how [08:31] radical engaging documentation because [08:33] it's an instead we wanted to share how [08:37] to how we think engaging blog posts can [08:40] be can be written and there was just to [08:41] the best of our knowledge there wasn't a [08:43] thing that described it specifically for [08:45] technical people because technical blog [08:47] posts are well there's some uh [08:53] some [08:55] some things with good writing in general [08:58] but they need they also have some [08:59] specific things like they should be [09:01] there should be an educational aspect to [09:05] them which isn't really necessary for [09:07] pros but on the other hand there are [09:09] some things from writing good pros that [09:12] also apply to blog posts so yeah we just [09:14] wanted to fill the niche because as far [09:16] as we knew there there are lots of very [09:19] nice blog posts out there so you can [09:20] learn by example but nobody to the best [09:23] of our knowledge at least combined in a [09:25] book. [09:25] >> That definitely makes sense. I was [09:27] really struck by the concept of the book [09:29] because I feel like it's such a fresh [09:31] take on writing for developers and it's [09:32] something that I feel like I've been [09:35] trying to hone in on for a while with [09:37] this element of storytelling for [09:40] developers like being able to craft a [09:42] narrative but focusing on technology as [09:45] well. So that's really cool. I'm curious [09:47] for those developers who maybe think, [09:50] "Oh, I'm just writing documentation and [09:52] I don't know if this book is for me." [09:54] How would you respond to that? Are there [09:55] any concrete ways that devs can apply [09:58] what's in the book to their day-to-day [09:59] even if they might not blog or is this [10:01] really pushing towards the blogging use [10:03] case? [10:04] >> We have a whole section of the first [10:06] chapter which is called why you write. [10:09] So probably an extended answer to this [10:12] question. Uh and it also covers a huge [10:16] list of excuses why not to write. One of [10:18] it is kind of could be summarized as I [10:20] only write documentation. Well, [10:22] documentation is usually about something [10:25] potentially interesting that was [10:26] implemented before. So you can also [10:29] twist it into an interesting blog post [10:31] instead of just talking about the [10:33] details. And this is just just one of [10:36] those of those excuses. There's a whole [10:37] list and we we dealt with each one uh [10:41] with in in in one of the first chapters [10:43] and even yeah I think it was even [10:44] chapter one just to get everybody [10:46] started. [10:47] >> Man definitely mind readading that is [10:49] really cool that you all tackled that [10:52] already. I'm excited to dive in and and [10:54] read more about that. something that you [10:56] also might mention in the first part of [10:57] your book, but is there three things [11:01] that you're hoping that folks take away [11:04] from this book or if they were to only [11:06] remember three things they remember XYZ? [11:09] Uh is there anything about this book or [11:10] is this just generally uh supposed to be [11:12] a reference or what are what are your [11:14] thoughts on that? [11:15] >> I think Syn came up with three [11:17] characteristics of a post that everybody [11:19] should remember so we can just quote [11:21] that. It was an intriguing topic. [11:23] distinctive educational core and smooth [11:25] delivery and they are all described in [11:27] the book. But it is a good resource even [11:30] if you just want to look at a few [11:31] examples to get you started and because [11:34] usually it's easier if you see a block [11:37] structured in a similar way that you [11:39] would like something expressed or maybe [11:40] you just like the style of someone and [11:42] you want to publish something in a [11:44] similar style. and going through the [11:46] examples and seeing what were the good [11:48] parts of of some specific blogs and what [11:51] have been improved might just inspire [11:53] you as well. [11:54] >> Very cool. I'm excited because I made [11:57] sure to get the physical copy to [11:59] annotate a lot with this book because I [12:01] feel like there's going to be a lot of [12:02] takeaways from it. So, very very [12:04] exciting. Is there any piece of writing [12:07] either from you or someone else that you [12:10] think every developer should read? just [12:12] like a good example of what developer [12:15] writing looks like. It [12:16] >> might be a little unfertile is just one [12:19] because we we tried to pick those [12:22] examples per pattern and they are all [12:24] something that we we consider really [12:27] good. The one that I will keep [12:29] remembering forever was one from tiger [12:32] beetle database because they went ahead [12:35] and implemented which run in browser [12:38] just to make their blog post cooler [12:41] which worked obviously. So yeah that's [12:45] that's the kind of initiative I would [12:46] always support and it was also very [12:49] educational and technical and so on. So [12:51] then that's something I definitely [12:52] remember but all of the examples are [12:54] quite quite distinctive and very nice. [12:56] So, we are actually kicking off a book [12:59] club for writing for developers with the [13:02] overcommitted community. And we learned [13:04] a lot from our first book club and we're [13:06] going a little faster this time. We're [13:08] reading two chapters a week and using [13:10] multiple platforms. We're using Discord [13:12] and Blue Sky. And we're also doing some [13:14] sync meetings, video call to try to make [13:16] it more accessible for people with [13:19] different schedules and communication [13:20] preferences. So, have you been a part of [13:23] any book clubs in the past, remote book [13:26] clubs that have done things really well [13:28] that we can maybe steal from? [13:30] >> We were featured in Phil Ethon's book [13:32] club with the same with the same book. [13:34] Although that one was mostly a [13:39] emailless discussion on the one hand it [13:41] was quite easy to take part in because [13:44] you just reply to an email but then yeah [13:46] there there weren't any as far as I know [13:48] there were the sync meetings or anything [13:50] like it so there's not much to share [13:53] because that one that one was text only [13:55] >> cool yeah we're really excited to have [13:58] those um live discussions and sort of [14:01] have both the opportunity to participate [14:05] through writing which is good practice [14:07] practicing what we learn and also the [14:09] the discussions um [14:12] to involve [14:13] >> well if you would like to make this [14:15] particular club more practical then you [14:17] can just gently force people to also try [14:20] writing something along with the book [14:22] and just publish it because yeah it's [14:25] doesn't take much to just publish [14:27] something worst case nobody notices it [14:29] but it happens to every other blog post [14:33] >> well that's good uh good advice to keep [14:35] in mind um for anyone who might be [14:38] participating and learning for anyone [14:40] who's starting the book. What would you [14:44] suggest as sort of a mindset of going [14:46] in? Yeah, [14:47] >> you could copy the author's mindset. So [14:50] the first one was that we wrote this [14:52] book totally out of order. So don't feel [14:55] inclined to read from chapter I mean [14:58] starting from chapter one is probably a [14:59] good idea. We did write that one first [15:01] but uh then it was really a random [15:03] choice of what we felt like writing. So [15:07] readers are encouraged to just read what [15:09] they feel like reading. So in particular [15:11] there is no order of patterns that we [15:14] feel to read at all. But also if you [15:16] would like to just read the end intro [15:18] and then skip straight to patterns [15:20] because you you can't resist just seeing [15:23] what they are just go ahead and then you [15:25] can catch up on all the other advice [15:27] that is in the books. Don't be too [15:29] strict with uh with the order. Every uh [15:33] chapter with patterns has a few blog [15:36] post examples and there are also links [15:38] to them. If you own a paperback copy [15:40] then you also have a repository that has [15:43] all the links. So you can just follow [15:44] and actually see them because we [15:46] couldn't reli reliably for instance [15:49] include this web browser game inside a [15:52] paper book. So I just need to go ahead [15:54] and see it yourself. We'll um include [15:57] that in the show notes as well with a [15:59] link to the book. And that's good to [16:00] know about the book being not [16:03] necessarily in a strict order. And it [16:05] sounds like it's really centered around [16:07] these patterns, the sort of content [16:10] patterns that you identified. So that's [16:13] a good place to start and focus if [16:15] people are looking to focus on one area. [16:17] Awesome. Um, so beyond individual skill [16:21] building or personal brand building, [16:24] what role do you see writing culture [16:26] playing in engineering teams and [16:29] organizations? Um, presumably a lot of [16:31] our listeners are working developers, so [16:35] they're looking to apply this content to [16:38] their work. Um, so how how do you see [16:42] that applying to day-to-day and how can [16:44] developers advocate for good writing [16:47] practices on their teams? [16:48] >> So I was fortunate enough to join Sid [16:51] which already had a very healthy writing [16:54] culture. It was maybe a little too [16:56] healthy because I was kind of forced to [16:58] write but I grew to enjoy it like really [17:01] enjoy it. not stop from syndrome. enjoy [17:03] it and uh it does make the whole [17:06] engineering culture also quite healthy [17:08] because if everyone keeps writing [17:10] technical blog posts that are that are [17:13] just published for everyone to read then [17:15] it's first of all clear that you also [17:19] understand what you implemented which is [17:21] quite important and then those blog [17:23] posts uh usually serve for a better way [17:26] of actually documenting the interesting [17:28] parts of what happens inside the company [17:31] uh because nobody reads documentation [17:33] end to end and if there's an and there's [17:36] a nice interesting blog post with some [17:39] surprising conclusions that everybody [17:40] would actually write it. Those posts [17:43] actually also will lure people in cuz if [17:47] the company has an engaging blog, there [17:49] are some [17:51] corporations that have very good blog, [17:54] very good technical blogs like [17:55] Cloudflare or Netflix or others and uh [17:58] they just make people want to join the [18:00] team that also writes those kinds of [18:02] posts. And as for starting the culture, [18:06] if it isn't there, I think it's worth [18:08] trying just to first of all write [18:11] something up front and then start asking [18:13] around if it could get published [18:15] officially as as a company blog because [18:17] it's there isn't usually a reason to say [18:19] no unless there are some trade secrets [18:21] in the blog post which you should just [18:23] remove. But otherwise, it's probably [18:25] best to just write something then ask [18:27] and worst case you can just publish it [18:29] on your personal blog if if it doesn't [18:31] work out. I feel like especially in so [18:34] many companies that are mostly remote um [18:36] like GitHub or like you know a ton of [18:38] companies now writing is really the one [18:41] thing that is surfaced you know like [18:43] across different teams and it's one [18:45] thing like if you're like trying to [18:46] improve visibility in the organization [18:48] it's like very very important I feel [18:50] like to be able to write and write well [18:52] and tell a narrative that other people [18:53] can pick up. So it's definitely I think [18:55] one of the best skills for developers to [18:58] invest in in my opinion. Excellent. This [19:00] has been great and I'm so excited to [19:02] kick off the book club. I think we're [19:04] going to start with chapters one and two [19:06] when this by the time this episode kicks [19:08] off and we're going to have a we have a [19:10] Discord community already that folks can [19:12] join if they're interested in being in [19:14] it where we'll have some synchronous [19:16] discussions like Erica said and then [19:18] we'll also you know just have a space [19:20] not only to talk about the book but to [19:22] share your writing if you're listening [19:24] and you're like hey I wrote a thing and [19:26] I want other people to see it then [19:27] that's a great spot to do that. So, we [19:29] always wrap up our podcast with a fun [19:32] segment, and this one, I don't know if [19:34] it's actually going to be that fun or [19:36] not, but this is what I came up with. [19:38] Um, we'll do a round robin, so we all [19:40] get to, you know, admit a little bit of [19:42] something here, but the question I came [19:44] up with was, what's the most [19:46] cringe-worthy piece of writing you've [19:49] produced in your career? Um, something [19:51] that makes you like look back and laugh [19:53] at now. Um, feel like this could also [19:56] just be like code you've written because [19:58] I feel like that is very something that [20:00] a lot of developers can identify with. [20:03] It doesn't necessarily have to be [20:04] writing. I feel like anything that I've [20:05] written beyond the last like 3 weeks is [20:08] usually something I'm like, who wrote [20:09] that? Oh, it's me. Great. So, I'll start [20:11] and we'll go around. I think that one of [20:13] the most cringeworthy things blog posts [20:15] that I've written is I have one blog [20:17] post that I keep around just as like a [20:20] uh a lesson learned where it was when I [20:22] first learned about AI and I was like oh [20:25] man I'm going to copy this thing into [20:27] chat GPT and see what it says and it [20:29] produced something from like what I had [20:31] written that I was like man this is very [20:33] obviously AI generated and not great but [20:35] I'm going to save it because I think [20:37] it's hilarious and nobody's going to [20:38] read that one and now it's on my blog [20:40] but it's the Boise code camp 2024 post. [20:44] It is very clearly um [20:47] a lot of AI flowery uh content that I'll [20:52] share. It's yeah I feel like there's a [20:54] learning curve with AI things where [20:55] people are like I'm going to do [20:56] everything with it and like oh okay no [20:58] never mind I can do some things with it. [21:00] The only like very cringeworthy piece of [21:02] it is it had really good SEO. When I [21:05] looked up Boise Code Camp like that last [21:06] year, I was like, it's on the front page [21:08] of Google for for that, which is when I [21:11] was like, "Oh man, that's not great." [21:13] But yeah, that is mine. Bethany, would [21:15] you like to go next? [21:16] >> Yeah. So, how many M dashes were in that [21:18] list of [21:19] >> It's probably all M dashes like a string [21:22] of dashes. That's funny. [21:24] >> Yeah. I was having trouble thinking [21:26] about this because I'm like I probably [21:27] haven't posted anything that I thought [21:29] was cringe. But I my mind went to [21:32] anything I've ever like tweeted or [21:34] posted on Blue Sky I just feel is [21:36] automatically cringe. I am terrible with [21:39] short form content or distilling my [21:42] thoughts into a short set of characters. [21:44] So I've definitely posted some cringy [21:46] things and just like deleted it [21:48] immediately because I was like what am I [21:50] saying? I think recently I posted on [21:52] Blue Sky. I was like, I don't trust [21:55] something that's marketed as viral. And [21:57] then I'm like, what am I saying? This is [21:59] the like most lukewarm take ever, so I [22:02] instantly deleted it. Um, but that was [22:05] the biggest thing I could think of. I [22:08] don't have a blog, so I haven't had any [22:10] experience with that, but maybe with [22:11] this book club, I'll finally get around [22:13] to doing that as that has been a goal of [22:15] mine for a while. So, very excited to to [22:18] have a blog and hopefully not post [22:20] cringy things. So Erica, why don't you [22:23] go? [22:23] >> Yeah, I also think that I have not [22:26] written externally enough. I write a [22:29] fair amount like internal to GitHub, but [22:32] I feel like I like pre-edit anything [22:35] external with the cringe factor. I did [22:38] like post I think like when I did my [22:41] boot camp, we all had to do some kind of [22:43] like blog post about our final project [22:45] or something and like I guess I would [22:47] say that but I don't think it's bad. I [22:50] think part of this is like we're [22:52] constantly learning and like when you [22:55] look back and you're like well that [22:57] that's so obvious like why would like [22:59] why would anyone write a blog post about [23:01] that because it's like HTML and CSS like [23:04] who cares. Um, but I think yeah, like [23:08] part of learning how to write is kind of [23:10] like getting over that hump and being [23:12] kind with yourself of like it's okay [23:14] that was past me and you know I don't [23:17] have to know everything to have [23:19] something worth reading and you know I [23:21] learned it at some point so maybe [23:22] somebody else needs to learn it too. [23:25] >> Um, Zarna did you want to share anything [23:27] if you have anything that you want to [23:28] admit? [23:29] >> Sure. Uh the most screened worth by far [23:31] would be my bachelor's thesis, but [23:33] that's not probably publicly available. [23:35] Hopefully isn't. But one actually public [23:38] one well one is screened on purpose. The [23:41] first chapters to the database book were [23:44] written by me and they were short [23:46] stories of database performers with [23:49] purposefully very forced humor that [23:52] wasn't very funny. And I I actually have [23:55] a hard time actually reading this [23:56] because it's just sad. But this is also [23:59] the chap this alo the chapter that [24:02] reportedly inspired Cynthia to reach out [24:03] to me to write another book. So I guess [24:06] it's good that I did. And as for AI [24:09] generated content, we also tackle it uh [24:11] in the book cuz our main advice is to by [24:14] all means use AI to GI and review your [24:18] blog post but do not let it actually [24:21] create content. We also provide some [24:24] examples of this generated content which [24:26] is especially I think it was generated [24:28] over a year ago. So uh the the models [24:32] did get a little better with writing [24:35] although not not that much but some of [24:37] those examples were very very hard to [24:40] read especially if AI tried humor again [24:43] that's the it just can't do this at all. [24:46] Yeah, I'm I'm willing to be an example [24:49] of of poorly poorly revised with AI [24:54] things. Um, yeah, I can definitely [24:56] overdo it and I think it's a really [24:58] great editing tool, at least as like a [25:00] first pass before, you know, to point [25:03] things out, but I've learned like, oh, [25:05] okay, I don't really like it actually [25:06] making changes. I just like it to [25:08] suggest changes to me and not actually [25:10] make changes to the thing that I write [25:11] because the changes it makes kind of [25:12] suck. Yeah. Cool. Well, that was fun and [25:15] a little bit therapeutic as well at the [25:17] same time. So, thank you all for [25:19] participating. With that, we're going to [25:21] wrap up. Thank you so much for joining [25:23] us. If folks want to find you on the [25:26] internet, where is a good spot to find [25:28] you? [25:28] >> You could start with this repository for [25:31] a book and you could probably find me [25:32] through there or you can just leave my [25:35] contact info somewhere so you can so you [25:37] can post it. I'm technically also on [25:40] Discord, but I'm a Discord boomer and I [25:43] just can't use it. It's It overwhelms me [25:45] with this flashy images and [25:47] notifications. So, I probably miss [25:49] whatever people approach me with in that [25:51] particular platform. So, yeah, I'm like [25:54] email is fine. [25:55] >> Awesome. Yes, I love the term Discord [25:58] Boomer. That's that is great. Excellent. [26:00] Well, uh with that, thank you so much [26:02] for tuning in to Overcommitted. If you [26:05] like what you hear, please do follow, [26:06] subscribe, or do whatever it is you're [26:08] supposed to do on the podcast app of [26:10] your choice. Check us out on Blue Sky. [26:12] Join us for Discord, particularly as [26:14] this book club kicks off, and share with [26:18] your friends. Until next week.  ## Highlights - **Remote Coauthors Became Repeat Collaborators** - Piotr Sarna and Cynthia Dunlop never met in person but co-authored books remotely. - Their first database book started as a ScyllaDB proposal and grew into a general performance guide. Transcript: Piotr Sarna Actually didn't meet in person ever. So that's a fun fact. We've always seen Cynthia mostly through Riverside, of all places. We worked at ScyllaDB for a time and the story started with a previous book of ours, which was about databases. And the way it started was as follows. I was approached by Appress, the publisher. They wanted to actually, they wanted to find an author to write a book specifically about ScyllaDB. I kind of didn't want to do it. So I forwarded them to the marketing department of ScyllaDB. And we figured out that maybe I will, first of all, co-author a book with four people total and then make it a general book about databases because a book about CILADP will be out of date The moment it's released. And maybe if we just cover some fundamentals of performance and other aspects of databases, it will have better shelf life, let's say. And that was a nice, well, I would call it a success. It was, the book is open source and available for free online. It had quite a few views. So, yeah, I was happy to see it getting popular enough in our niche. And then, this time I was already kind of hooked on writing books. And when Cynthia approached me about writing another one, I just read on the spot. And this time we approached a few publishers. Ultimately, we decided on mining and yeah, we wrote this one. ([Time 0:01:57](https://share.snipd.com/snip/4d80a037-47cc-4c4c-aa3f-cdca30d81fc4)) - **Write Books As Extended Blog Posts** - Co-authoring makes book-writing easier by sharing drafts and editing responsibilities. - Break a book into chapter-sized "extended blog posts" to make writing manageable. Transcript: Piotr Sarna Like to strongly disagree that's that co-authoring is harder it's actually way easier if you co-author with cynthia that's that's that's the secret sauce uh cynthia is first of all A skilled ghostwriter and also a writer. So she kind of took all the burden of pre-editing everything off me. I could just spill out barely coherent sentences and she would just form them to beautiful English sentences that we can then pass to the publisher for review. So it's way easier, first of all, because of that. And second of all, writing a book, like a whole book might be a little tough because it might take a year or three. If you write one fourth of a book, it's a couple of months. So you can see the end of it. So it's especially with the first database book, we actually, everyone was responsible for a few chapters. So all I had to do was like, write three chapters, if I remember correctly, maybe four. And each chapter is kind of like an extended book post. So just that, and then you have a book. ([Time 0:03:48](https://share.snipd.com/snip/499c356e-0af4-4c7f-93ca-abd740055d34)) - **Keep Examples Living Online** - Use WriteThat.blog to publish monthly pattern-based examples that stay current. - Keep live examples online because paper books can't include interactive demos. Transcript: Piotr Sarna Started as a promo for the book itself. We wanted to have a place where we would continue giving examples of the patterns of blog posts that we described in the book that are up to date monthly. The book is structured in a way that a huge part of it is a couple of patterns that we just kept seeing everywhere. If you browse Hacker News, I can pretty much assign patterns as I see them right now because it's like muscle memory at this point. So since we already, for every one of those pattern chapters, we had some examples, but those would eventually get out of date and we wanted something that is up to date all the time. So we just started this monthly section of blog posts and we just post them there. ([Time 0:06:05](https://share.snipd.com/snip/fc5fc110-d5ea-4fe2-9e8e-786e3883445b)) - **Developer Blogs Require An Educational Core** - Technical blog posts need an educational core in addition to good prose. - That dual requirement makes developer writing distinct from general creative writing. Transcript: Piotr Sarna So before our book course release, we did some research if there's anything that already covered exactly the same topic. And unfortunately, 99% of books that talk about writing for developers just mentioned documentation, which is boring from the start. And we specifically didn't want to describe how to write engaging documentation because it's in the morning. Instead, we wanted to share how we think engaging blog posts can be written. And that was just, to the best of our knowledge that there wasn't a thing that described it specifically for technical people because technical blog posts are well there's some some Some things with good writing in general but they also have some specific things that there should be there should be an educational aspect to them, which isn't really necessary for Prose. But on the other hand, there are some things from writing good prose that also apply to blog posts. ([Time 0:08:11](https://share.snipd.com/snip/9b989da7-267e-497a-b21b-32068187bb42)) - **Turn Docs Into Engaging Posts** - Turn documentation topics into interesting posts by highlighting why the work mattered. - Chapter one addresses common excuses and practical ways to start writing. Transcript: Piotr Sarna We have a whole section of the first chapter, which is called Why Write? So it's probably an extended answer to this question. And it also covers a huge list of excuses. Why not to write? One of it is kind of could be summarized as I only write documentation. Well, documentation is usually about something potentially interesting that was implemented before. So you can also twist it into an interesting blog post instead of just talking about the details. And this is just one of those excuses. There's a whole list and we dealt with each one in one of the first chapters. And even, yeah, I think it was even chapter one, just to get everybody started. ([Time 0:10:04](https://share.snipd.com/snip/91b9e7c8-0a0f-4a92-b4af-c3d0b8d15bf2)) - **Three Pillars Of A Memorable Post** - Great posts combine an intriguing topic, a distinctive voice, and a clear educational core. - Smooth delivery seals the reader experience and makes technical content accessible. Transcript: Piotr Sarna Think Cynthia came up with three characteristics of a post that everybody should remember. So I can just quote that. It was an intriguing topic, distinctive educational core and smooth delivery. And they are all described in the book, but it is a good resource, even if you just want to look at a few examples to get you started. ([Time 0:11:16](https://share.snipd.com/snip/70c03f11-af79-4b94-b4b8-71987f187b8f)) - **Interactive Demos Make Posts Stick** - Piotr remembers a TigerBeetle post that ran an interactive demo in the browser. - That extra effort made the blog both educational and memorable. Transcript: Piotr Sarna It might be a little unfair to just one because we tried to pick those examples per pattern and they are all something that we consider really good. The one that I will keep remembering forever was one from Tiger Beetle database. Because they went ahead and implemented a thing which ran in browser just to make their blog post cooler, which worked obviously. So that's the kind of initiative I would always support. And it was also very educational and technical and so on. So then that's something I definitely remember. But all of the examples are quite distinctive and very nice. ([Time 0:12:16](https://share.snipd.com/snip/5ecc1022-8410-4458-a50f-f6d285b44132)) - **Combine Reading With Publishing** - Make book clubs practical by forcing participants to write and publish alongside reading. - Publishing small pieces boosts learning and reduces fear of visibility. Transcript: Piotr Sarna We were featured in Phil Eaton's book club with the same book, although that one was mostly an email list discussion. On the one hand, it was quite easy to take part in because you just replied to an email. But then, yeah, there weren't, as far as I know, there weren't the sync meetings or anything like it. So there's not much to share because that one was text only. Erica Cool. Yeah, we're really excited to have those live discussions and sort of have both the opportunity to participate through writing, which is good practice, practicing what we learn and Also the discussions to involve. Piotr Sarna Well, if you would like to make this particular cloud more practical, then you can just gently force people to also try writing something along with the book and just publish it because It doesn't take much to just publish something. ([Time 0:13:30](https://share.snipd.com/snip/9e85ac0f-026e-433f-996f-0b7df1b2e7de)) - **Read The Book Nonlinearly** - Read chapters out of order; follow what interests you and jump to patterns. - Use the book's repo links to view examples that can't fit in the paperback. Transcript: Piotr Sarna You could copy the author's mindset. So the first one was that we wrote this book totally out of order. So don't feel inclined to read from chapter. I mean, starting from chapter one is probably a good idea. We did write that one first, but then it was really a random choice of what we felt like writing. So readers are encouraged to just read what they feel like reading. So in particular, there is no order of patterns that you need to read at all. But also if you would like to just read the end intro and then skip straight to patterns because you can't resist just seeing what they are, just go ahead and then you can catch up on all The other advice that is in the books. And don't be too strict with the order. Every chapter with patterns has a few blog post examples, and there are also links to them. If you own a paperback copy, then you also have a repository that has all the links. So you can just follow and actually see them because we couldn't reliably, for instance, include this web browser game inside a paper book. So you just need to go ahead and see it yourself. ([Time 0:14:47](https://share.snipd.com/snip/0eb59d08-426e-43f1-bed9-f74cbce0b18a)) - **Writing Culture Strengthens Engineering Teams** - A strong writing culture validates engineers' understanding and improves internal knowledge sharing. - Public technical blogs attract talent and surface a team's deep thinking. Transcript: Piotr Sarna So I was fortunate enough to join CIDADDB, which already had a very healthy writing culture. It was maybe a little too healthy because I was kind of forced to write, but I grew to enjoy it, like really enjoy it, not stop from syndrome, enjoy it. And it does make the whole engineering culture also quite healthy because if everyone keeps writing technical blog posts that are just published for everyone to read, then it's first Of all clear that you also understand what you implemented, which is quite important. And then those blog posts usually serve for a better way of actually documenting the interesting parts of what happens inside the company. Because nobody reads documentation end to end. And if there's a nice, interesting blog post with some surprising conclusions that everybody would actually write it. Those posts actually also lure people in because if the company has an engaging blog, there are some corporations that have very good blog, very good technical blogs, Cloudflare or Netflix or others. And they just make people want to join the team that also writes those kinds of posts. And as for starting the culture, if it isn't there, I think it's worth trying just to, first of all, write something up front and then start asking around if we could get published officially As a company blog, because there isn't usually a reason to say no unless there are some trade secrets in the blog post, which you should just remove. But otherwise, it's probably best to just write something, then ask. And the worst case, you can just publish it on your personal blog if it doesn't work out. ([Time 0:16:48](https://share.snipd.com/snip/dc3d8c3c-7f65-4098-ac8f-23ddd0e2805d)) - **Cringeworthy Early Writing Led To Opportunity** - Piotr found his bachelor's thesis and early book chapters cringeworthy, especially forced humor. - That early work still helped him meet Cynthia and start further projects. Transcript: Piotr Sarna Sure. The most screened work by far within my bachelor's thesis, but that's not probably publicly available. Hopefully isn't. But one actually public one, well, one is screened on purpose. The first chapters to the database book were written by me and they were short stories of database performers with purposefully very forced humor that wasn't very funny. And I actually have a hard time actually reading this because it's just sad. But this is also the chapter that reportedly inspired Cynthia to reach out to me to write another book. So I guess it's good that I did. And as for AI generated content, we also tackle it in the book because our main advice is to by all means use AI for GBIES and review your blog post, but do not let it actually create content. We also provide some examples of this generated content, which is especially, I think it was generated over a year ago. So the models did get a little better with writing, although not that much, but some of those examples were very, very hard to read, especially if AI tried humor. ([Time 0:23:29](https://share.snipd.com/snip/f577cd60-7367-467b-ab15-5a3716230829)) - **Use AI For Edits, Not For Writing** - Use AI as a brainstorming and editing tool but don't let it author posts. - Review AI suggestions carefully and keep human judgment central to voice. Transcript: Piotr Sarna Post, but do not let it actually create content. We also provide some examples of this generated content, which is especially, I think it was generated over a year ago. So the models did get a little better with writing, although not that much, but some of those examples were very, very hard to read, especially if AI tried humor. Again, that's the, you just can't do this at all. Brittany Ellich Yeah, I'm willing to be an example of poorly revised with AI things. Yeah, I can definitely overdo it. And I think it's a really great editing tool, at least as like a first pass before, you know, to point things out. But I've learned like, oh, okay, I don't really like it actually making changes. I just like it to suggest changes to me and not actually make changes to the thing that I write because the changes it makes kind of suck. ([Time 0:24:18](https://share.snipd.com/snip/5e3d8948-8644-4024-a3ea-a3401b7f4c0d))