We chat with Jared Bhatti and Zachary Sarah Corleissen, two technical writers with deep experience at major tech companies and open source projects, about their approach to documentation and the new book they helped co-author, Doc For Devs. We go deep on the best ways to annotate a codebase for future generations and how to localize explainer content so that it works for teams across multiple regions and languages.
Docs for Devs: An Engineer’s Field Guide to Technical Writing can be found here.
Jared worked as a technical writer at Google for more than 14 years and recently transitioned to Waymo, the self-driving car company spun out under the Alphabet umbrella. You can find him on Twitter and LinkedIn.
Zachary has been a technical writer at GitHub and the Linux Foundation, and now works as a staff technical writer at Stripe. You can find all her online accounts at her website.
Interested in exploring approaches for collaboration and knowledge management on engineering teams? Why not try a tool developers already turn to regularly? Check out Stack Overflow for Teams, used by Microsoft, Bloomberg, and many others.
Tired of security bottlenecks? Today’s episode is sponsored by Snyk, a developer security platform that automatically scans your code, dependencies, containers, and cloud configs — finding and fixing vulnerabilities in real time, from the tools and workflows you already use. Create your free account at snyk.co/stackoverflow.
Jared Bhatti You want to have the best practices for software engineering baked into all of the examples that you're giving, because you don't want to give a simplistic example of, “Here's how you contribute code,” but then forget, “Okay, well here's how you evaluate the code to make sure it doesn't pose a danger to people.” So that's really important. You have to think through the entire journey of your user and that's going to lead to the best outcome.
[intro music plays]
Ben Popper Hey, everybody. Listen up. Are you tired of security bottlenecks? Well, Snyk is a developer security platform that automatically scans your code, dependencies, containers, and cloud configs, finding and fixing vulnerabilities in real time from the tools and workflows you already use. Create your free account at snyk.co/stackoverflow. So if you're listening, head on over, support the podcast. Let 'em know we sent you.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my colleague and collaborator, Ryan Donovan, who edits our blog. Hey, Ryan.
Ryan Donovan Hey, Ben. How are you doing today?
BP I'm good. So Ryan, you have been a technical writer for a decade and a half, and these days you edit a lot of developers and writers who write about code. When you think about documentation, what's the first thing that comes to mind?
RD I think good documentation is kind of invisible. Bad documentation gets talked about more unfortunately.
BP Sounds like security.
RD Yeah, yeah. I mean, you hear about documentation when people can't find answers. And I think in some way Stack Overflow benefits from bad documentation because we have all the other answers.
BP True. We are the backup documentation for everybody. So without further ado, I'd like to say hello to our two guests. They have been working on a book all about documentation for developers, by developers. Zach, Jared, welcome to the podcast.
JB Hey. Thanks for having us.
Zachary Sarah Corleissen Yeah, it's nice to be here.
BP So Jared, let's start with you. Just for our listeners, tell them quickly who you are, what it is you do these days, and then if you don't mind, a little bit about how you got into the world of software and docs.
JB Sure. My name is Jared Bhatti. I'm a Technical Writer at Waymo and I lead the docs team on autonomous vehicle documentation. I am a software engineer by training, but I was working in several small startups that were doing not so great, like you do in the early-2000’s. I had done a lot of freelance writing. I also had a minor in English composition and deep interest in the written word. I posted my resume on Craigslist and was looking for another startup job when a recruiter contacted me and said, “I think you'd be a great fit as a Technical Writer at Google.” And at the time I'm like, “I don't think I've ever worked as a technical writer, but I've done all of your job requirements for a technical writer, so tell me more.” And that was 15 years ago and I've been at Google, or Waymo, since, and it's been a wild ride and I've loved it. It's the perfect intersection of technology and writing and communication. And I love to teach so it is a perfect fit for me. That's how I ended up here. Zach, do you want to talk a little bit about how you ended up here?
ZSC Sure. So I'm Zachary Sarah Corleissen. Currently I am a Technical Writer for Stripe where I work on the next iteration of Stripe’s API landscape. And I became a technical writer mostly because I graduated from college with a degree in English and a whole bunch of coursework in computer science and I had no idea how to combine any of that. And one of my aunts was a technical writer at Los Alamos National Laboratories and she said, “You should be a technical writer.” And I said, “What's a technical writer?” And that's how you get the dinosaurs in a tarpit. You just take one step and the next thing you know. But no, it's been really lovely. I have worked also at a handful of startups that served some amorphous and poorly defined need in the early-2000’s and have worked at GitHub, at Rackspace, and most recently at the Linux Foundation where I worked in the Cloud Native Computing Foundation Kubernetes documentation. And I love this profession. It is, like Jared says, the perfect intersection of so many powerful things. And it's the intersectionality of the profession that I think keeps me involved, keeps me vital, and makes me excited about the future of what it is that we do.
RD I will say, at my last job when I was going to build out their API documentation, I asked developers what was the best documentation and they said Stripe. So kudos to that.
BP This might be the first time we have three English majors on the call. I haven't found a good use for my dance degree yet, but maybe once we make the pivot to video that will come in handy. So we got a little bit of your background and I kind of want to let Ryan drive because this is his area of expertise. But I'll set us up with a general question. The book that y'all are working on, what was the genesis of that? How did you get this group together and what was the impetus for putting it down on paper?
JB Zach and I worked extensively on Kubernetes documentation for many, many years. We were both SIG Docs chairs and led a lot of the open source documentation contribution and processes there to really scale Kubernetes. And we had kicked around this idea of a book for a while on documentation and how do we teach developers documentation because so much of what we were doing was going to conferences, leading documentation sprints, really sharing our knowledge. And it seemed like there was a thirst for this, for other projects that were at this point where they were code complete and wanted to scale and documentation was how they could do it. And as we were teaching we encountered a number of just similar questions from people of how do we get started, what do we focus on, how do we write? And a lot of anxiety from developers of, “I don't know how to begin writing, and I don't know how to evaluate what is good or bad writing, and I don't know what's going to engage with my users.” So Zach and I were kicking around different ideas for this book and we started putting together a proposal and we realized that we needed a larger group of writers. I have a very Google-centric view, which is not how the world should work, although Google sometimes thinks that that's the case. And we had lots of feedback from the Linux Foundation that Zach was deeply embedded with and working for at the time. But we realized that we had a huge community to draw from from our own professional communities and from Write the Docs, which is an amazing documentation group that focuses on software documentation. So we took advantage of that community and a lot of just amazing talent came to the surface to co-author the book with us.
ZSC To this day I'm still shocked by the number of people who said yes when we asked them. The original list of folks that Jared and I invited to collaborate with us was obviously Jared and myself, and then we sent invitations to five other people and three of them said yes. So I don't know that it was necessarily that we set out to have as large a group as possible, it's just that we worked with the people who said yes, and that ended up being a really effective combination. It might be a little too early to talk about this but one of the struggles that we faced with the book was convincing a publisher that five co-authors was not the kiss of death for getting a manuscript over the finish line. As it turns out, I can't imagine having done this book any other way. That was one of the most powerful collaborations of my career. The book would not be what it is without the people who were involved in it. I mean, obviously, but it really was an effective and powerful collaboration. I don't think we ever had a big fight over anything. We had occasional differences of opinion, but at no point did we have any sort of dramatics.
RD Jared, I know you come from a computer science development background. Zach, do you also come from that background or did you get started in English?
ZSC I got started in English and honestly, I used to feel a great deal of imposter syndrome over being ‘less technical’ than other writers and developers in my field. But over time I've really learned to embrace it as an asset, because it puts me in a position where I'm able to ask powerful questions on behalf of other people who may or may not have the same substrate of knowledge underpinning their developer practice.
RD I always feel like that ignorance can be a strength. I say, “I'm the first dumb user you're going to get so I'm going to ask all the dumb questions.” I think the interesting thing for me is that computer science and English are often diametrically opposed skills, and you come from different ends of the spectrum. How did you bridge that gap?
JB I don't think they're diametrically opposed. I think we're trying to solve problems with different tools. I think that is really what we're trying to do. When I write code, I am trying to address a problem a user has. And when I write documentation, I'm also trying to address a problem the user has. So I'm just trying to meet people's needs but I have different sets of tools that I use to do it. And I think that's how Zach and I really worked together, especially when starting the Kubernetes documentation, because a lot of it was, “What do our users actually need?” Kubernetes is a massive, complicated project to wrap your mind around and there's a lot of really specific technical jargon that you need to understand before you start using it, and how do we give people this bedrock of knowledge that they can then build on top of, whether it's code or it’s content? And this was an initial struggle with the project because a lot of initial engineers had a very engineering-focused approach with, “We would like to create tools that then just generate the documentation.” And I'm like, “Does this actually serve our users? Is this what they want? Is this what they're expecting to read?” And I think the engineers who were proposing this just didn't have a fundamental understanding of how content works as a tool, so I had to break this down for them, like, “This is how humans gain knowledge. Let's focus on using this tool first, and then we can focus on automation down the road.” So these work together.
BP Did you start with a cave painting? No, I'm just kidding.
JB It was all interpretive dance.
BP Yeah, exactly. Now I see where my skills can come in handy. I had a conversation with our co-founder Joel Spolsky when I started, because I was trying to understand his perspective on the value of Stack Overflow for Teams, which is like a private instance of Stack Overflow inside a company. A lot of that is essentially serving a function like documentation. And he used a very sort of utilitarian metaphor, which is, imagine that you are the new superintendent of a building and somebody's complaining about their pipes being out. You have to go find a blueprint hopefully that somebody left before you that will explain how things work, why, and where you should go to fix this. Zach, to your earlier point about imposter syndrome, which obviously I have all the time as an English major on a software podcast, thinking about codebases that are at large companies that might last 10 or 20 or 30 years, and new people who are coming in who might not be proficient in the same languages or be working even on the same OS environment, you want them to be able to have a layman's explanation, maybe alongside a technical one, so that they can get a grasp for this stuff and then proceed to unpack how they should work on it.
ZSC Like Jared said, content is the first experience that people have of a project. The Read Me, the documentation, is the first place that people go to learn how to do a thing. And it is powerful to be able to work in analogies that don't do violence to the technical nature of the material, but also speak to the humanity of the people who are there to learn and to read and to increase their own capacity to accomplish whatever task they're trying to do. When we talk about open source communities, one of the metaphors that Jared and I use is the care and upkeep of a garden. We talk about cultivation, we talk about borders, we talk about weeding for some of the less glamorous aspects of an open source community. But just to return to the imposter syndrome and starting from an English place, a language place rather than a software place, like Jared, I don't think that there's a lot of difference between the two. I think it's just a differently strict set of grammar, and that these things don't exist for their own right. You don't write software to exist for its own sake. You don't write documentation to exist for its own sake. These things exist in order to accomplish tasks or solve problems.
RD Your book is developers writ9ing for developers, right? That's the end goal. How do you get a developer to write for another developer and have them convey the information?
ZSC Well, I think it doesn't require a lot of convincing, honestly. I think that the same urge that motivates a developer to write code in the first place, they're there to solve a problem. And if they are sharing that code out in the world, it's because they care about other developers solving problems as well. And so that same impulse to help and to share is just a differently strict grammar by which that sharing happens.
RD One of the things I've run into with developers writing for other developers is that they often have an expert blindness, in that they are so good at something that they can't get the beginner mind. Have you run into that? And how do you teach that beginner's mind?
JB Knowing that there's a problem is always the first step. I think identifying the fact that you have a curse of knowledge and then sort of looking for ways to break outside of that. And I think it's normal. We're all taught through academic writing or through writing in school to promote the projects that we've built and to sort of talk about them and the decisions that we've made and our own expertise, but that's not how our users want to interact with what we've built. So I think there's two approaches. One is empathy, of just understanding your user. Think about them, think about what they need, what they're coming to your project and what for, and what problems that they have that they want you to solve. And I think that's really useful for a lot of people. And I think another approach is writing style. There's a tendency for people to write in the ‘we’, like, “We made this decision with Kubernetes to create this construct called pods.” And like, “We made this decision because of blank,” and it's like, write it to your user. Write with ‘you’. Like, “You can use this feature to do blank. It solves your problem by doing…” That's how you can solve that and sort of work around it. Once you start writing to your users it becomes a lot clearer to them what value they're getting out of your content.
ZSC Right, it's very much an applied exercise in empathy. The purpose that you're not writing for yourself, you're writing for someone else, and what does that person need? If you want to write, for example, like a record of the history of Kubernetes, that's very different from, “How do I get started?” And you wouldn't put all of that history as a prerequisite to getting started. So like Jared said, writing style genre, and just a sense of what it is that the people who are going to read what you write actually need and actually want to do.
JB I mean, actually at my current role at Waymo, my goal is to share the curse of knowledge with as many people as possible, because I'm an internal writer. Like, “We're building a new ML model for our autonomous driver. Here's all the decisions that we made and the historical background between all those decisions and all the tradeoffs that we did. And as a new engineer working on this ML model, here's all the things you should know.” I'm trying to get information out of engineer's heads and get it into all these new hires that we have and get that to scale. But when I worked on Kubernetes it was, “How can I reduce the complexity of this product into a way that you can understand and immediately apply and use?” So that empathy piece becomes really useful.
BP I had a question, Jared, which is specific to Waymo. I don't know if you can answer it, but when writing documentation there, do you have to consider things like ethics and governance? You're dealing with vehicles that are moving people, there may be government agencies that are very interested in how the cars work. There may be people who are writing ML models who want to make sure that they're equitable or ethical. Is that stuff a consideration in documentation or is that like a higher order kind of thing?
JB I think that's a consideration across the board. It's definitely something that we thought about within Kubernetes and something that Zach's thought about extensively at the Linux Foundation. When it comes to writing content, most of my content is internal, so it's focused on other engineers learning how to contribute to the ML model, and like how the cars perceive the world. But something we do think deeply about is safety and privacy and security, not only of the people in the car but the world outside the car and like, how do we think about pedestrians, how do we think about cyclists, how do we think about other drivers? And that whole conversation between the car and the road and all the other users of the road and of the environment is something that we think about really deeply in addition to the privacy of people's data, how are we maintaining the safety and security of the data that we have? So this is something that needs to be baked into the documentation, because you want to have the best practices for software engineering baked into all of the examples that you're giving, because you don't want to give a simplistic example of, “Here's how you contribute code,” but then forget, “Okay, well here's how you evaluate the code to make sure it doesn't pose a danger to people.” So that's really important. You have to think through the entire journey of your user and that's going to lead to the best outcome. It's a very sort of company-centric view. In an open source project, this is something that Zach can speak to much better than I, you also have to think about the contributor side of things of what's going to bring in an inclusive and diverse set of contributors who are going to feel comfortable and included in the conversations around the future development of a project. Zach, did you want to chat about that?
ZSC Yes. First I want to just echo back that ethics and ethical thinking is at the heart of technical documentation. And the specific application of ethics for Waymo's product cases is, I mean, obviously the ethics of autonomous vehicles are not going to be universally applicable necessarily, but I think that over the next year, I think that ethics are going to be very front and center in discussions about documentation as professional practice, just because it is critically important for documentation to be reliable and build trust. Those things are at the heart. They need to be almost an unconscious presumption of documentation and unfortunately, I feel like there are a lot of competing interests to keep that trust from being automatic. There’s sort of the nature of culture and technology. I know that's a very big can of highly-packed worms to open right now. But just to say, I think that ethical practice of documentation is going to be a very conscious discussion in the coming year. But specifically for open source communities, yes, I think that some of the first documentation that open source communities need to provide for themselves are things like codes of conduct, setting clear boundaries, setting expectations, setting the basic rules for what is this space appropriate for and what do we do when that space is not held in a way that we agreed to collectively? How do we maintain ourselves first and foremost? So yeah, I think that there's a really large ethical space around bringing contributors into an open source project in a way that builds trust, that is truthful, that creates reliability and creates safety. And these things aren't automatic, we have to be very conscious and very intentional with how we communicate our expectations. I think we need to acknowledge that some boundaries are aspirational rather than necessarily inherently descriptive of where a community is at the moment, and it's good to acknowledge that, to say, “We're not there yet but this is where we're going.” If I could sum that all up I would say good documentation tells the truth and builds trust, builds safety.
RD It's interesting you talk about almost like documenting the community itself. How much of that is community driven and how much of that is top-down?
ZSC So I will say this is one of Jared's great strengths and one of the reasons why I treasure working with him. When it comes to documenting the community itself, it's very easy to lose sight of priority, to think that because I'm spending energy documenting this community that this is what really matters. And of course with a software project, what really matters is helping other people use it. And how this would surface in conversations with Jared and myself is that I would propose some piece of either like CI/CD, or some piece of automation to put into the stack, and Jared would come back with, “That's a tire fire. Why do you need to automate a tire fire?” And keeping the focus on the quality of the user experience, making sure that we're not burning cycles endlessly introspecting, and that we're keeping focus on what matters. Jared, did you want to talk a little bit more about your experience of that side of priority?
JB Yeah, I just think it's useful to always have very clear contributor guidelines and clear contributor process. And I think there's a desire to overcomplicate things and I think just avoid that at all costs. Just keep it as simple as possible, because every minor bit of friction is a barrier to entry for people who want to be involved. And studies have shown that those barriers are far more impactful on minority groups in the community, so it's important to keep things simple and keep things documented. We had an amazing community manager named Paris Pittman who really helped facilitate a ton of conversations between the folks developing the roadmap and architecture of Kubernetes and the plans going forward for that project, and the people working on releases, and the people who were documenting. And we all came together and said, “This is our release process. This is how we want to work together. And when we conflict, this is how we're going to make decisions, because we're not always all going to agree, and we don't need to have that but we should all at least understand and respect the decisions that we make as a group.” She was amazing at facilitating that conversation and getting us to agreement and then documenting it. And then we've basically run every single release based on that decision that we made nearly five years ago. So once you get it right it's not a thing that you constantly have to go back to and rewrite and work on. If you can get it right, it lasts.
BP The first question to kind of getting to this idea we've been talking about, about how to be inclusive and ensure that everyone who comes to this documentation in the future can understand it and contribute to it as needed, do you do a bit of cultural sort of anthropology as you're figuring out the teams you're working with? Which is to say, do you go talk to them and understand what language they use, what metaphors they use, what story points they use, and then try to mirror some of that back to them in the documentation? Or do you have your own style that you've developed, your own approach that you feel is best across the spectrum of people for communicating knowledge in documentation.
JB I feel like the answer is yes to everything that you've asked. So yes, we do some anthropology and we look at who's doing the talking and who's doing the listening, and seeing what's resonating, what's not, what's working, how do we communicate? And I think when it comes to language, and how people speak, and the words that they use, I think there's a really important value for accessibility of are we using words that everyone agrees with and that make sense to them and carry the same meaning? Because it's very easy to overload words, and naming is super hard in tech. I know we can all think of really bad examples of poorly-named products and poorly named features. And this is something that not only from a feature standpoint, but just from, how do we talk to other people about what we're building and why it's useful for them, it's important that that resonates with them and that they understand. We also document things in a style guide. So I know the Linux Foundation has a style guide. Alphabet has a style guide. There's many other companies that have great style guides that I refer people to. Having a consistent language and agreements around how that language is used is really important. When we internationalize things and translate things for other audiences, that introduces a whole other layer of complexity and things like metaphors become very difficult. So there's just a push towards language simplicity, like how concise and simple can the language be and still convey the same amount of meaning? And for anyone that's written, you know how difficult that is. So that's one of the core skills that we bring to the table. But Zach, I know that you developed so much of the translation pipeline for the Linux Foundation and their documentation so I'm really curious about your point of view on this.
ZSC So Ben, to return to your original question, I like that phrase– cultural anthropology. Yeah, so that is a good practice for documentation, to use the words that your audience uses. So yes, it's not quite forensic, but getting to know people, listening to the words that they use, listening to the language that the community uses to describe itself to, to describe technology in the various components they're in, and to reflect that back in documentation. At the same time, because of the requirements for internationalization, language needs to be as easily localizable as possible, so it means that colloquial understandings become like an anti-pattern in documentation. Don't use things that don't really translate outside of a language or outside of a culture. And the thing is that they're sneaky. Even that word, sneaky, does that localize well or not? It really depends. I think a best practice is to write in a way that shows that there is a human speaking to you and that that voice can adapt to be as local as needed for a community to hear its own voice speaking. So it's a bit of a balancing act.
BP Yeah. I think the thing you both said which I hadn't really considered is the global aspect and the internationalization. My question came from talking with Maggie Appleton on the podcast recently, and she was talking about her approach to UX design, saying that it was helpful to go onto a certain subreddit and figure out how people described something before trying to build it for them. But a lot of what you said rings true, which is that trying to do it in a way that maybe has a bit of a narrative and metaphor and therefore is easier to grasp in one domain makes it much more difficult at the scale that a Stripe or a Waymo is at. All right, I want to throw it to Ryan to see if he has any final questions before we head to the outro.
RD I was just going to say, I love me some idioms and metaphors and that's deadly for cross-cultural communication. On top of the anthropology, how much of your job is archaeology? I feel like the primary sources for documentation for me were always using the product and then talking to experts, but sometimes that doesn't give you everything. So where else do you turn for answers?
JB I never thought about it as archaeology, I always thought about it as like detective work, but maybe that's just my bias for the sorts of books I like to read. I just think that the human element of technical writing is huge. And I think there is definitely an archaeological component of like, “I'm documenting a library and it hasn't been updated in a couple months. What were all the code changes and what's changed compared to what's documented and let me look through that.” So there is an archaeological piece there, but it's also going out to people and asking the right questions and building rapport and having relationships with a lot of people. I rarely write code anymore but the fact that I can sit down and just say like, “Just speak geek to me. Just word vomit on me all of your thoughts about this particular feature and I will take it and write it for our users in a way that makes a ton of sense to them and I'll let you review it, but I'm going to sit down and ask you all the questions that I think you're going to want to talk about as a software developer. I'm going to take that information and translate it.” I think there's a really powerful skill there. And I find that people with journalism backgrounds or research backgrounds tend to excel really well in technical writing because they're okay with asking those questions, especially if those questions are uncomfortable. Sometimes people build a feature and you're like, “Who's going to use this?” And the person's like, “I don't know. I just thought it was really neat to build this feature.” And that’s useful to know. Maybe somebody will use it, but I would write that very differently than something that there are thousands of users who need to have this feature right now.
BP Asterisks for a possible developer application in the future. I gotcha.
ZSC I think that the difference between archaeology and detective work is the degree to which the subject is past tense.
JB “How old is the skeleton?”
ZSC Yeah, basically. There's actually a really good example in Kubernetes documentation of the kind of forensic near-term archaeology let's call it that goes into technical writing. So, for cluster DNS inheritance, basically the short version of cluster DNS inheritance is that you can set nodes of a cluster. You can indicate whether those nodes should inherit the cluster DNS policy when those nodes are spun up, and there is a value called ‘default’ for whether or not a node should inherit DNS policy from the cluster. There is a value called ‘default’. The default value is not ‘default’, and finding out why that was the case and which SIG, special interest group in Kubernetes, like which particular set of developers maintains this feature, is it SIG node? Is it SIG Cluster? Is it SIG API machinery? Who owns this and how do we deal with it? How did it come to be that this was the case? And if you look at the documentation for cluster DNS policy, all of that archaeology is summed up I think in a callout that's two sentences long that says, “The value of ‘default’ is not the default value.” But that's the kind of eight hours of forensic work that goes into a two-line sentence. And whenever I have to explain why is technical writing valuable, that's only two sentences, why did it take you eight hours to do it? It's because of all of the forensic archaeology that goes into that kind of knowledge.
JB And that's also where good relationship building is important, because then you get a bunch of user feedback that's like, “This doesn't make any sense to me.” And you look at it and I'm like, “I'm a rational person, this also doesn't make sense to me. Maybe I need to surface this to the developers who wrote it and say this doesn't make any sense. Like, I understand why historically this happened, but you should change this.” So there's a lot of feedback cycles that we sort of facilitate as writers. It is a conversation that we're constantly having between our users and the engineers who wrote the code to begin with, and it's not just a one-way bullhorn that we're shouting our features out to folks.
ZSC Yeah, and that's one of the real values of technical writing and one of the reasons I think why we won't be automated out of a job anytime soon is because we sit in that intermediate space where we are advocating on behalf of users, we're also in direct conversation with the developers and we have a chance to help affect the decision making upstream to keep things like that from happening again, or the patterns that produce that, having a chance to disrupt those and make a better user experience. I mean, the best documentation is the kind you don't have to write. And being able to improve the user interaction before it ever comes to the phase where it needs to be documented, that's a value that technical writers add.
JB Right. One day you'll be able to delete that line that says the default value is not ‘default’, because the product is better. That's why you won’t have to write that.
[music plays]
BP All right, everybody. It is that time in the show. I'm going to shout out the winner of a lifeboat badge, someone who came on Stack Overflow and saved a question from the dustbin of history. Thanks today to Martijn Pieters, how to forward-declare/prototype a function in Python. Awarded just eight hours ago, so we appreciate that. This question is almost eight years old and it's been viewed 30,000 times, so really helping out. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions, podcast@stackoverflow.com. We'll shout you out on the show. And if you like what you heard, leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find me on Twitter @RThorDonovan. And if you have a great idea for a blog post that you want to write for us, please email me at pitches@stackoverflow.com.
JB I'm Jared Bhatti, Technical Writer at Alphabet, and co-author of Docs for Developers: an Engineer’s Field Guide to Technical Writing, which you can find at docsfordevelopers.com. And you're welcome to follow me for tech writing tips and general tech writing chats @JaredBhatti on Twitter.
ZSC And I'm Zachary Sarah Corleissen. I am a Technical Writer at Stripe. Docsfordevelopers.com. If you want to follow me on Twitter, I really can't recommend it, but if you do for whatever reason want to follow me on Twitter, that's @Zachorsarah at Twitter.
BP All right. Follow at your own risk people, you heard it. All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]