Here’s what’s in store for this episode:

• 00:00 - The hosts discuss how to impress and win over the heart of a developer in your life. 

• 02:30 - First Commit: How India built the PARAM 8000 supercomputer. 

• 06:07 - The Interview: Peter Strömberg and Brandon Ringe, the co-maintainers of Calva, discuss the benefits of sharing responsibility for open source maintainership. 

• 18:18 - #AskRMP: We learn from Jana Iris about best practices for community building from scratch. 

• 21:15 - Feature Release: The ReadME Project’s Klint Finley shares what we can learn from vintage computing.

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• Building super fans through genuine human connections by Jana Iris

• Agical, Peter Strömberg’s employer and open source sponsor

• The modern web’s underrated powerhouse by Klint Finley

• Enterprise code migration with developer happiness in mind by Prince Shekhar Valluri (LinkedIn)

• Move past incident response to reliability by Will Larson

Special thanks to Jana Iris for sharing her thoughts on getting started with OSS community building. Also, thank you to Peter Strömberg and Brandon Ringe for providing their insight on collaborative maintainership and how building together can benefit the community.

---

Martin: Now, what the heck's that in the background of your picture? I can see there's a massive switch. How many ports are on that thing?

Neha: Oh, I forgot that that was still out there. Yeah, this weekend we were switching out our switches. My closet was overheating. We switched at our switch for something smaller. You know, sometimes you got to upgrade, so that’s what we did this weekend.

Martin: You got to switch it up.

Neha: I got to switch it up. Oh, that was good. This is The ReadME Podcast, a show dedicated to the topics, trends, stories, and culture in and around the developer community on GitHub. I'm Neha Batra, and I lead GitHub's core productivity team.

Martin: And I'm Martin Woodward from the GitHub developer relations team. Wait a second, Neha. Core productivity team? That's a bit new, isn't it?

Neha: It is, yes. I got the chance to move from the communities team to core productivity, which I think kind of makes sense if you think about it. I get to work on some of the core pieces of GitHub that maintainers use on a daily basis, like pull requests, et cetera. It's really exciting.

Martin: Nice.

Neha: But enough about me. Martin, something that I've been thinking a lot about lately is actually impressions.

Martin: Is that because we are getting tons of listeners on the show? Thanks, everybody.

Neha: I love that, that little shout out to our listeners, but I'm not talking about page impressions, I'm talking about the impressions we make on other people on an individual basis. With Valentine's Day coming and all, I've been thinking about how we make impressions on each other based on the work that we do. So here, I got one for you, right? As a developer, if you wanted to impress me, you should include tests in your pull request.

Martin: Oh, I get it, I get it. Let's see. Well, if you want to impress me, how about sponsor the maintainers you depend on? That would definitely impress me. Or how about this? If you got issues, include a stack trace.

Neha: Yes. If you want to impress me, write a README that includes how to contribute back to your repo. 

Martin: That’s actually really good, by the way. 

Neha: And speaking of contributors, we have some great ones on the show today. So today, we're going to hear from Jana Iris on how to find a mentor. Klint Finley is back, this time talking about vintage computing. And, in the spirit of great partnership, we're going to look at the ins and outs of co-maintainership with Calva co-maintainers, Peter Strömberg and Brandon Ringe.

Martin: Hey, Neha, if you really want to impress me, first, you have to be ready to commit.

Neha: Ooh, bravo. Bravo.

Audio: (singing)

Neha: Today, we're heading back to the 1980s and to the other side of the globe from where I work and pretty far from Martin as well. At the time, India was in search of a supercomputer for a fairly specific purpose, to research weather patterns. 

Audio: (storm soundscape)

It's a large country—seventh biggest in the world by land size—and at the time, it had between 600 and 800 million in population. So, the Indian government had a pretty large need to predict weather and protect its people.

Martin: In the past, India often looked to either Europe or the US when looking for advanced technology, and in this particular case, they asked for help from the US to allow them to buy a Cray supercomputer. It was super cray, Neha.

Neha: Super cray.

Martin: I know, I've actually been looking for a Cray on eBay forever. It hasn't happened quite yet. I don't know if you've seen it. It's one of the coolest-looking supercomputers ever made. It's that circular one, and it even had bench seating on the outside of it. It's really, really cool.

Audio: This is the Cray-1. It’s been called the fastest computer on Earth, a masterpiece of engineering, and the world’s most expensive loveseat.

Martin: Anyway, while US leadership could have helped, they feared the supercomputer in question, a Cray, could also be used for more nefarious purposes, to help develop missiles and nuclear weapons, that sort of thing. So, request denied.

Neha: Yeah. Instead, the US offered a less advanced computer. Necessity is often the mother of invention, so India decided to instead make its own supercomputer—one actually powerful enough for its needs.

Martin: The Center for Development of Advanced Computing, or C-DAC, was born in 1987, and it was a major turning point for technology and everybody else in the country.

Neha: The prime minister at the time appointed Vijay Bhatkar to head the project, and the PM, Rajiv Gandhi, famously asked him three questions. One: Can we do it? Two: How long will it take? And three: What's the price tag going to be?

Martin: And despite never having actually seen a supercomputer himself, he knew that they could do it, and cheaper and faster than trying to buy a Cray from the United States.

Neha: And just three years later, his prediction came true as India unveiled a supercomputer, the PARAM 8000, much to the surprise of the rest of the world.

Audio: In 1991, India shocked the world and unveiled its first indigenous supercomputer, known as PARAM 8000.

Martin: It was the second-fastest supercomputer in existence in 1991. It was 28 times more powerful than the computer they'd originally been trying to buy for the United States for that same $10 million price tag, and it offered something special to the world, because it was efficient and inexpensive. It also brought down the price of the US-created Cray, making supercomputers more accessible to everybody. Buyers from countries like Germany and the UK also appreciated the relatively low price tag of the PARAM 8000, just $350,000.

Neha: Bhatkar continued his work developing a series of PARAM computers after that initial breakthrough. And for those of you who don't know, the word param means “supreme” in Sanskrit.

Martin, working on this podcast with you is super fun and collaborative.

Martin: Where's this going?

Neha: Well, I've been thinking about today's interview, and in some ways, don't you think that we are co-maintainers of this podcast?

Martin: Yeah, sure. Okay, go. Where's this going?

Neha: What I'm hearing is that you agree, which is awesome, because we actually have two other co-maintainers here with us on the show today. We have Peter Strömberg. And Brandon Ringe. 

Neha: Peter and Brandon are the co-maintainers of Calva, a VS Code extension for Clojure and ClojureScript development, and they're here to talk to us about the good, the bad, and the ugly of co-maintainership, what they've learned along the way, and what lessons they can share about collaboration in general. I'm super excited about this, so I'm glad to have you here.

Peter Strömberg: Super happy to be here.

Brandon Ringe: Thank you for having us.

Martin: I think probably it's worth us talking about, first of all, what is Clojure, and what is ClojureScript? Why would I want to use this as a language?

Brandon: Clojure is a functional programming language. It's a Lisp dialect. It allows developers to write more reliable code and to do more with less, really. That's what attracted me to the language.

Martin: What about you, Peter? What got you into Clojure in the first place?

Peter: I was at a startup, and we had a green field, and the devs brought in Clojure. And I wasn't the programmer then, I was a product owner. But then, I saw how they worked very interactively with the product, and they had it jacked in to the application they were developing, and they were asking the application stuff, and they were telling the application to do new stuff, and that got me totally hooked.

Neha: I've got to say, having your first interaction with Clojure inspiring you to go back to development, I feel like is probably the strongest testimonial I've ever heard ever. The fact that the team itself was very collaborative and this was a language that you could collaborate with… expand a little bit more about what is collaborative about Clojure for someone who's hearing this for the first time.

Peter: You're right. That team was like mob development. It's amazing to do it in that kind of pair programming setting, because everyone can contribute to the conversation you are having with application, and see it respond differently to what you throw at it. Certainly, it's made more fun in the collaborative environment.

Neha: The two of you work on Calva together. How did that part come together?

Peter: Key here is that, almost from the start, I had decided that Calva was a team effort, so I really was looking for having a team. I guess all contributors have been potential team members, and when Brandon was contributing and we were interacting, I thought, “I would like to work more with Brandon.” So then, I just asked him if he would want to be part of the team, and he accepted, and that's where we are.

Brandon: Yeah, it felt amazing. I was honored that he asked me to come on, because I wanted to work in open source, and that was kind of why I was starting to contribute more. I’d finally found something that I could contribute to and then turn around and use it the next day in whatever I was doing, hobby or work-wise.

Neha: Peter, what are some of the biggest hurdles that you've seen with co-maintainership and collaboration more broadly?

Peter: It took me quite a while before I found Brandon, but I had other people joining the team. For me, what was the hard part was the continuity. That was what I was after, really. If something changes in my life so I need to drop Calva, then I know that Brandon is there and can continue it. 

At one point, I had a really, really large set of contributions from a team member who joined. It was amazing stuff that was added to Calva, but he just left and dropped it before it was finished. So that was the toughest moment. Moment? It was a long time, actually, to learn it enough to be able to maintain it, to dare ship it. I don't know if I really learned something from it, because I would do it again the same way. But you need to be aware, extra aware, when a lot of stuff comes at the same time. Almost drowned me, so...

Neha: Yeah, that sounds like quite the emotional rollercoaster, right?

Peter: Yeah. Hey, it's just very emotional. Still emotional for me, actually.

Martin: Well, to your credit, Peter, it takes a special kind of person to share something that they've invested so much of themselves into, and something that is so personal to them, to open yourself up and to sharing direction of it. It's fine to say that you want the help, but actually giving over some of that control as well, that's the harder bit. 

Any other tips, either of you, Peter or Brandon, in terms of how you actually run the project day to day? You know what I mean? Like getting flooded with notifications and coordinating who's doing what.

Brandon: I definitely use GitHub's notification system very frequently to manage how I prioritize things with Calva. For example, I'll first filter by anything I was mentioned in to make sure I'm being responsive when people are asking me for help or my input on something. And then I'll move down to participating, so I'll filter by anything I'm participating in. And then from there, I usually go and I look at what issues were created or PRs created where no one else has responded yet, because I don't want to leave people hanging for too long. We try to get to people within a few days to a week, max, and a lot of times, it's pretty quick.

Peter: When it comes to tools, I mean, we have GitHub, CircleCI, and Slack, and that serves us great. I think what is important for us has been... I picked this up in Pragmatic Programmer many, many years ago. They had an item about design for concurrency, and it was partly about how you design software to run concurrent, but it was also about how you run your project in a concurrent way so people don't lock each other up. You try to see all the time where you are creating dependencies that are just imaginary. You can remove them and keep people not blocked on each other. So, I think to value concurrency is important, and certainly to value it higher than you value control. Control is fine, but with concurrency, it's more important, I think, for us.

We release often. Ship it out as quickly as possible, and that's one thing we can do to not block things, because we are almost at the trunk all the time. And also, with pull requests, we don't require that they are reviewed before they are merged. Certainly, when it comes to team members, it's an open source project. People have lots of stuff to do, so it can take days before someone comes in with something. And people have mostly the sense to know when they need to wait for feedback and when they can go forward. Then we do post-feedback. That is one thing you can do to not block each other. It also means that you will ship regressions at that point. I usually say that we move fast and we fix things, so that's also a thing about not being blocked on risks.

Neha: What I'm hearing from you is there's a trade-off. In order to unblock people, in order to give people the chance to move forward, you're giving people more autonomy. And in order to handle the risks that come out of that, you have to be able to react quickly when it doesn't go well. So it's almost like you're providing a safety net for people to move faster and for people to feel entrusted to be able to do the right thing.

Peter: Exactly. And it's important when recruiting a team member. That's one thing that I noticed with Brandon, that he would contribute things, and then he would stay and fix anything and continue to refine it and all that. So it's important that the team knows that the users are impacted. 

Neha: I'm curious also, I think we've kind of been talking around this, but as an open source project, how do you specifically tailor the workflow to make things easier both technically and culturally? In order to resolve disagreements, for example.

Brandon: Our CI workflow helps a lot with making sure PRs are good to be merged and making it easy for us to do these frequent releases like Peter's talked about. And also, just making sure that the way to contribute is defined step-by-step for any newcomer who might even be new to developing a VS Code extension, new to TypeScript, or new to Clojure. That really makes it a lot more likely that people are going to contribute.

Peter: And also, we try to make it very, very clear where Calva is going, what is important for the Calva project, so people who see the project and interact with it, they can feel if it's for them. Maybe they want to use it, but maybe they don't actually agree with the decisions we have made around it. So, if that's super clear, then they can save time by not trying to engage more. But at the same time, the other side of that coin is that people that really like your vision, where you're going with this, they are attracted to it, so you're really attracting the right people. I think that's also very important in... We let people free, they can do whatever they want, and we know that it will contribute to Calva in a good way.

Martin: Yeah, definitely. I talk a lot about a contribution funnel and how you can do that, and having good CI processes that are reproducible is critical to that, for sure. 

Peter, as you started the Calva project, if you could start over, is there any one thing that you could change?

Peter: I think it has been so much fun and so rewarding that I wouldn't dare change a thing about the project. I mean, it has been the most rewarding thing I have ever done. Brandon mentioned our CI pipeline, which wasn't stellar for very long, but you really need to feel where it hurt you to know what you should do to fix it. And at some point, Brandon couldn't stand it, and then he fixed it, and it has been amazing since. I think that also goes to this contribution thing. If you open up to contributors, they come with very different mindsets and stuff like that. If you would do this alone, if I had this closed source or some other like that, it wouldn't have been anything. I think if Calva would have been developed in that manner, it would very quickly been just made irrelevant by the open source project.

Martin: Fantastic. Well, Peter Strömberg and Brandon Ringe, thank you very much for joining us here today. And if you want to check out their work, over to the Calva project and download it in the Visual Studio Code Marketplace. Thank you very much for joining us.

Brandon: Thank you.

Peter: Thanks for having us.

Neha: Now for Ask RMP, where we grab a listener question from you and get an expert to give us their advice. This month, Jonas from Melbourne asks, I have a great project in mind that I plan to open source; where do I start with building a community around it from the ground up?

For answers, we went to Jana Iris, an investor at TQ Ventures and builder of developer communities. Here’s her advice.

Jana Iris: There are many ways to build community. I think what's nice about the early days is you don't have to think about scale, so you can really focus on building really deep relationships with those early engaged people, and really get to know them: their name, their pain points. The more of a relationship you build, the more likely they're to stay engaged.

And with community building, especially in the early days, the first pillars you may think about are education and knowledge-sharing. So, when you open source a project, making sure you have great documentation, it’s clear what the project does, and then the second pillar is knowledge-sharing, just making it really easy for folks to talk about the project, share, talk about it in talks they give, in blogs. Those are kind of key things, education and knowledge-sharing, that you think about in the early days.

What I find is: People open source a project and expect it to take off right away. It takes a while to build community. It takes a while for people to discover your project. And so, really early on, it's important to speak at meetups, speak at conferences, blog, respond on Hacker News, be really active on social, talk about the project in different areas. The more you engage with the early users and start building the community, the more the project will take off.

When you open source a project, there are a few key things to think about. I always find that developers sometimes think a great project sells itself, but it's important to think about messaging and story and branding as well. So when you open source a project, making it really clear what the tool, the project, does, and then telling a story. Like, how does it benefit? What are the purposes? Having some branding that uou don't have to spend a lot of money on it, especially if you're a solo developer. Just having a little bit of engaging branding, and then just great documentation—and those things can go a long way from the beginning.

Neha: Do you have a burning question about open source software development or GitHub? Share it on social using the hashtag #AskRMP, that's A-S-K-R-M-P, and it may be answered in our next episode.

Martin: Neha, everybody remembers their first computer, right? Mine was a VIC-20 I seem to remember playing with when I was a kid. I was jealous about all these sort of people with Sinclair Spectrums and things. What about you? Do you remember what your first computer was?

Neha: I absolutely do not. I was a baby. I wasn't a baby. I was probably five or something like that. So, I remember a box. I remember that the font was yellow.

Martin: Yellow?

Neha: Like a gold-ish yellow, and that's about it. And I remember that my dad would bring home new games every week or something from the university, but I had no idea. I have no idea. What about you, Klint? Do you remember your first machine?

Klint Finley: I do, yeah. It was a Commodore 64, and I played Sesame Street on it. There was actually a mat that rolled out over the keyboard so that I didn't have to really type, just mash a section of the keyboard to respond to stuff.

Martin: Wow. There we go.

Neha: Okay. So, I guess it's just me that doesn't remember. Well, that's cool.

Martin: Well, if you haven't guessed already, we've got our special guest back on with us again, Klint Finley. He's senior editor at The ReadME Project, and this week we're going to talk about vintage. Klint, you did a really good article about vintage computing and why it's having a resurgence again, so it's good to have you back.

Klint: Yeah, it's good to be back.

Neha: So it's probably a little self-explanatory, but before you dive in, can you actually tell us what you mean by vintage computing?

Klint: Sure, yeah. I mean, maybe retro computing would be a better term for it, but vintage computing was already kind of in use, so I went with that. In the context of the article, what I'm really talking about is just any sort of computing product, whether that's hardware or software or service, that's basically been discontinued by its original maker. 

Yeah, what really got me interested in this was... The last time I was on, I was talking about Game Boys and older video game platforms that people are still making games for even though they've long been discontinued. I wanted to kind of zoom out and look at other platforms that people are keeping alive, and I saw that open source has really enabled communities to keep these things going long after their expiration date. And I found that just really fascinating.

The Apple Newton was discontinued, I think, in 1998, and there's still an active community around that. Even more extreme, the Commodore 64 people have developed little hardware widgets that are open source that can connect it to Wi-Fi, so you can get on the internet on this kind of ancient hardware, and it's called FujiNet. It's available for a lot of different vintage computing platforms. It's a whole thriving set of communities working on these things.

Martin: Actually, a buddy of mine, Scott Hanselman, did a demo a couple of weeks ago where he connected his Commodore 64, his real Commodore 64 that he'd actually built from chips with solder and stuff, and then using FujiNet and things and connecting it to Copilot and ChatGPT as well, so you can get this amazing cloud AI stuff hooked into this Commodore 64. It was built for ages ago. 

So, why is this cool again? Why is retro cool? Is it just because these kids are all out there looking at their retro devices and thinking analog's cool, like they are with their tape recorders and everything? Is it just for hobbyists and for Generation Z, or is there actually some functionality here, too?

Klint: Yeah. Well, I mean, obviously nostalgia is a big part of it. There's a lot of people who want to revisit platforms from their youth, or like you said, younger people who want to have some experiences that they weren't around for in computing. But there's also elements of functionality there. This guy Morgan, who's one of the first people I talked to who helps maintain some of the Apple Newton communities, he started using a Newton back in the mid-aughts when it was already discontinued and the big thing were PalmPilots, but he found that the Newton... he hadn't actually owned one in the '90s, but he found he could get one used, and the functionality for it better fit his needs.

One of the big things is instead of the type of flash memory that was common at the time that would basically lose all your data every time the device turned off, and you would have to resync your data with your desktop to get it all back, there was permanent memory on the... I think a solid state drive, essentially, on the Apple Newton, so he could have that memory all the time. And it had expansion ports, so he was able to actually get Wi-Fi on his Newton, which even a lot of PalmPilots at the time you couldn't do. It was just actually a more functional, more useful device for him than the other things that were around at the time. I think what really draws a lot of people into this is that it helps them better understand computing.

Neha: I was thinking about it, and there is this new obsession with the old also that's coming back into fashion, like '90s fashion is coming back, but it sounds like this is a lot more functional. I'd imagine it's kind of like forensic science, right? There's a bit of a benefit for people to understand these building blocks of previous technologies so that we can better understand the machines that we use today. Right?

Klint: Right, right. Yeah. A lot of these were simpler machines compared to today's really complex systems where there's multiple different processors, and no one can really fully understand everything that's going on in a modern smartphone or laptop, where a Game Boy or a Newton were kind of just at the end of the period where people could really look at the computer architecture and understand the entire system. Somebody I talked to actually studied Game Boy architecture in his computer architecture class at university, because it was a way to really just understand a full system, and actually a more fun way, probably, to explore some of that.

And then, you can see it on the software side as well. Gopher is a communications protocol that predates the web, and people did a lot of similar things with it, kind of linking sites together and sharing text and things like that, but it's also a lot simpler protocol than the modern HTTP protocol that has encryption layers and web sockets and things like that, where Gopher is so simple that it's a lot easier for somebody to just jump in and learn it and start to really understand the basics of computer networking.

And then, that simplicity also is really valuable for a lot of developers to learn how to better develop modern applications. Chris Maltby, who designed the open source Game Boy tool GB Studio, talked about how trying to produce Game Boy games and the confines of that system where you have really simple graphics, simple sound, a small surface area to work with, but then they still have to be fun games and engaging games, taught him a lot about developing software, building products that are engaging without going overboard with complexity.

Martin: Yeah, I actually built my first site in Gopher just before I built my first website. So yeah, it was called was some sort of page, “My college at university,” I seem to remember. In fact, some of those old pages I did on the early web are still around. The oldest page I had that's still live, it dates from sort of '94-ish, I think, maybe '95, and it was like a simulation of a galaxy collapsing in on itself, and the university I went to still has that live, that website. It says on it, “Warning, this page has an animated .gif, which might not work in some older browsers.” That’s how old it was. 

But that archiving side’s important as well, isn’t it? The Internet Archive, they've just started archiving sort of old PalmPilot programs and things like that, you mentioned that earlier. Why do you think this archiving side, this preservation side, is important as well?

Klint: Yeah, well, if you think about it, computing has really become a big part of culture, and preserving that in the same way we try to preserve anything else, newspapers, books, paintings… it’s something that's just so much a part of the fabric of life that it should be preserved so that people can study it and refer back to it. 

Yet, one of the more fascinating things in preservation right now is trying to preserve these interactive services that start with the internet and bulletin board systems and things like AOL and Prodigy and CompuServe that sort of predated the modern web and internet experience. That actually creates this huge challenge, as you can imagine, where you don't have access to the servers, you don't have... For the interaction, there's a side to it that even if somebody had access to it, how do you get it to run? How do you get it to actually work in the modern era?

That’s actually one of the coolest projects I saw, was Prodigy Reloaded. They're actually working on building a functional kind of drop-in replacement for a Prodigy server that you can connect to with a real Prodigy client running in DOSBox or another virtual machine, essentially, or probably on an older computer, if you actually have DOS installed on it, and then connect up to something that is a real live server that's interactive and can respond to the client and essentially simulate the experience of using Prodigy, which is a really interesting service in that they really pioneered a lot of things from advertising to e-commerce to booking travel online in a user-friendly way.

You could do some of that stuff already with CompuServe, but it was all text-based and a little bit challenging, whereas Prodigy really helped bring the whole notion of a user-friendly online service experience to the masses. People haven’t forgotten about it, but you can’t easily just see what it was actually like until now with Prodigy Reloaded. Though, going back to Gopher, that’s actually a little bit simpler, because there’s actually Gopher sites that still exist, and you can download a Gopher client and log into some of these services and check them out, and it’s kind of a fun way to experience what the early internet was like.

Martin: I’ll have to go see if that website’s still up, or that Gopher site’s still up that I helped do. I’ll go and check it out.

Neha: Klint, I really want to thank you for sharing all of this, I've always been so obsessed with going faster and doing more and saying, “Why would you want to relive that old stuff and see what it was like back in the day when we could do so much more now?” But I’m starting to come around to it. I’m understanding that it really is important to go back to our roots.

And we've kind of hit that time where there is... It’s going to be more and more common to relive what it was like back in the day in museums and stuff like that, where as far as I know, there’s probably only a few computing museums today, and that’s going to become more and more commonplace. So this, to me, is that first big realization that we’ve hit it, that computing is here to stay, it’s part of our history, and now when we go back and understand how we got here, there is a lot to learn, and there are already people who are beginning that appreciation and making that easier for the rest of us. So, thanks for that.

Martin: It’s kind of why the archive’s important too, isn’t it, I guess, Neha?

Neha: Yeah.

Martin: That’s what’s in the archive, and before we put that segment in the archive, Klint, why don’t you give us a preview of what’s coming up for you in the future?

Klint: This month, we have my feature on the evolution of Cascading Style Sheets or CSS. CSS is the other part of the front-end stack, along with HTML and JavaScript. CSS has really come a long way over the years, but it just doesn’t really get the sort of attention that JavaScript gets, so we wanted to change that. 

Then, we have a guide from LinkedIn on how they moved from a monolithic repository to thousands of smaller Git repositories. It covers how to handle a migration of this scale while also prioritizing developer happiness. 

And Will Larson discusses how organizations can move beyond incident response towards reliability engineering and prevent incidents before they happen. 

As always, you can find all of this and more at github.com/readme.

Neha: That’s it for this episode of The ReadME Podcast. Thanks so much to this month’s guests, Peter Strömberg, Brandon Ringe, Jana Iris, and Klint Finley. And thanks to you for listening. Join us each month for a new episode, and, if you’re a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate, and review, or drop us a note at thereadmeproject@github.com. You can find links to all the stories and articles mentioned in the episode at github.com/readme, and while you're there, subscribe to our monthly newsletter.

Credits: GitHub’s The ReadME Podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were reported by senior editors Klint Finley and Mike Melanson. Audio production and editing by Reasonable Volume. Original theme music composed by Xander Singh. Executive producers for the ReadME Project and the ReadME podcast are Rob Mapp, Melissa Biser, and Virginia Bryant. Our staff includes Stephanie Moorehead, Kevin Sundstrom, and Grace Beatty. Please visit github.com/readme for more community-driven articles and stories. Join us again next month, and let’s build from here.

Neha: There are two difficult problems in computer science, naming things, cache invalidation, and off-by-one errors.

Martin: Hey. That’s actually quite good.