Anthony Sottile // @asottile

OPENING QUOTE: I actually think communication is the hardest part of open source. It can be really difficult to recognize that, "Hey, there's a person on the other side of the computer." I think if I could snap my fingers and fix one thing about myself and one thing about other people, is that everyone would just instantly get better at communication.”

Brian: That’s Anthony Sotille, currently software engineer at Stripe but also maintainer of many Python projects you’ve heard of, and this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Neha: And I’m nerdneha aka Neha Batra.

Brian: Every episode, Neha and I welcome a maintainer or open source developer into our studio to explore the impact their work is making on the world around them. 

Neha: In this episode, we speak with Anthony who—a tinkerer as a kid—got himself into programming when he was in grade school and wanted to automate some things. Fast forward to today, where he has become one of the most active users on GitHub, maintaining dozens of projects and juggling what seems to be a mindblowing number of initiatives. In this conversation, we speak about his early forays into programming, how he found himself teaching a course at his college, and why he thinks communication is so important in open source.

Let’s start by hearing about the first time Anthony wrote code.

Anthony: So, my first computer interaction, or at least the first time that I wrote code--because I had been tinkering with computers for much longer before then. The first time I wrote code was to cheat on math homework almost 20 years ago. I had a TI-83 calculator which had a TI-BASIC, very simple programming language. And I was sick of typing in the quadratic formula over and over and over. And so, I wrote a little bit of TI-BASIC and it was kind of a cool way to automate a tedious task, but use code to make my life easier. And in addition to that, my friends didn't have fancy calculators and they were like, "Well, I want this program too." So, I ported the TI-BASIC to Visual Basic Macros that you could stick into a Microsoft Word document and then I was able to distribute that Word document on floppy disks and basically share code.

And so, it was also a cool way to demonstrate that I can put in a little bit of effort and then share that with the community to have a broader impact. So, that was kind of my first experience with openly sharing code. I think I've stuck to that pretty well since then.

Neha: That's definitely the first time I've heard that the quadratic formula has launched someone into their interest in being able to share code. I kind of love it.

Anthony: Yeah, it's great.

Brian: Yeah. It's ripe with team Java “feels,” in like passing around the quadratic formula in the dark market, or the dark web, which I don't know if it got that far.

Anthony: Oh yeah, the teacher did not appreciate it.

Neha: Anthony’s love for coding and computers started in childhood but only grew from there. Over the years, he built a cohort of friends that he would code with. He found himself drawn to finding ways to make tasks in his life, and for those around him, more efficient.

Anthony: We had like all these crazy business ideas that we're going to try and build for stuff that we wanted to do. Mostly web apps. Things like, forms as a service was one example that we had built out like a way to have user-submittable forms. Looking back at some of the code, it was pretty bad and it had a lot of flaws, but it was an interesting idea. And maybe a little bit ahead of its time. Google Forms came and eventually replaced it. The other category of things were just convenient stuff for what I needed personally.

So, like another example is I had to do a bunch of chores as a kid and one of them that I would trade off with my brother was taking the dogs out. We switched off every other week and I was not the best at remembering to do that in a timely manner. So, I had my dad record a couple of sound bites like, "Anthony, it's time to take the dogs out.” “Anthony, it's time to take the dogs in." And I built a little Windows Forms Tray app so that it would tick down a timer and a little bubble would pop up and tell me to do my chores. And so, it was like a nice little chore reminder. But basically automating things that made my life easier.

Brian: That's awesome.

Anthony: Yeah. So, the next place that I was after school was I worked at Yelp for a total of five years. I started as a JavaScript developer, believe it or not, and primarily worked on front-end for the first amount of time that I was there. Well, it was hard for me to get my job done as a front-end developer because I had to wait for back-end developers to build the APIs in order for me to build my front-end on top of that. And so, I decided to just cut out the middleman and become a full stack developer. That way, I could unblock myself for building front ends by just building my own back ends. As I grew as a full stack developer, I then realized that I was getting blocked by infrastructure problems and went through the CTO at the time and was like, "Hey, if we continue at this development pace without investing in infrastructure, web frameworks, developer tooling, that sort of stuff, we're going to have a hard time scaling Yelp as we grow from 115 to 600 or to 1,000 engineers."

And the CTO is like, "Yeah, that sounds like a good idea. I'll give you a charter to try and build a team and we'll see where it goes after a few quarters and figure it out from there." We built a team called WebCore. The original idea was to make developers productive in the monolithic repository at Yelp and build them developer tools and other stuff around there. And that was where I really found my passion for infrastructure and developer tooling. Like I really liked being able to write a small amount of code that accelerates people a lot.

Brian: Anthony graduated from college in the era of the most popular JavaScript library at the time, JQuery. While he made the transition to Python, JQuery still holds a special place for him. 

Anthony: I still like jQuery even though it's  fallen out of fashion with programmers.

Neha: It still has its roots in a lot of what we do. So you can see those little remnants as well.

Anthony: For sure. For sure. Yeah. And a lot of what has shaped web standards has come from ideas that originated in jQuery. I miss jQuery.

Brian: It's nice to see folks can learn from previous experiences because some projects, they just sort of ignore history and try to rewrite things from the ground up. But we see this in so many different frameworks and languages. It's so much easier when folks can borrow from each other because then you have like... You made the jump from JavaScript to... Well, actually I'm making assumptions. Did you make the JavaScript to Python to do full stack?

Anthony: Yeah.

Brian: Okay. So, how was that transition from going from JavaScript to Python?

Anthony: It was fairly straightforward. I had worked in a lot of similar... I mean, most dynamic languages are fairly the same. It's just like, understand this syntax and how it applies to this syntax. But I'd also done a lot of stuff with VB, C#, C++ and those sorts of languages translate a little bit nicer to Python. And so, it was pretty easy for me to pick up. That said, I think a lot of my success in Python was because of my atmosphere and the peers that were there that educated me about language features and were useful tools and code review--or useful people. People aren't tools. I don't want to say that. 

Brian: Resources.

Anthony: Useful assets. Resources. There we go. Resources and code review to educate me about best practices and help me understand how to do things more efficiently and how to do things in a "Pythonic manner." Python was pretty easy to pick up.

Neha: Python was also one of my gateways too. I found it to be the first language that I was working in that almost was writing how I thought. And so, it ended up being one of the fastest ones that I could pick up as well.

Brian: My intro is Ruby. So, I'm not sure if that is a contentious point for these Pythonistas here. But yeah, yeah. My intro is Ruby, but also around the same year, 2013.

Neha: That’s an impressive run, and to see how it was nearly all self-driven is pretty inspiring. We glossed over this, but Anthony also took the reins on his college education. He started as a biochemistry major, thinking he wanted to be a doctor but within two years realized that computer science resonated with him more. So in his junior year he pivoted, crammed all that he needed for his degree into his last two years of college and graduated with a computer science degree. Biochemistry to computer science seems quite the leap, what initiated that change?

Anthony: This is actually a bit of an unfortunate story. So, when I started in school, they had you go through educational counselors and they tell you, "Okay. Well, take these classes, don't take these classes," et cetera. And unfortunately, my counselor when I talked to her about classes, she was like, "Oh, don't take the computer science course. It's really hard. You're going to burn out and fail at school." And I didn't know any better so I trusted her instinct and didn't take the course my freshman year and oddly enough... Well, we'll get to that in a minute. So, I started in biochemistry. I was really into organic chemistry in high school. My mother is a pharmacist. So, that’s kind of some natural tendencies towards that direction from there. I was into biology and it was fine. 

But partway through my second year, I was sitting in a class when the professor was lecturing from his own textbook, that he forced us all to purchase at the steep price of $400 a pop on his own proprietary research and expecting us to memorize that for his exam that would be specifically about his research at the end of the quarter. And I was just like, "Ah, I'm good at memorizing, but I just don't care." And so, I walked out and I went to a different counselor and was like, "Hey, I'm going to switch majors. I want to do computers. I'm employed. I'm pretty sure I can handle this course. Let's get into that next semester."

And, I took the course the next semester and after the first lecture, I had some questions for the lecturer. I walked up and talked to Mary Lou and she was like, "You don't seem to belong here. Your questions are not quite what we're looking for in this intro to programming course." So, I essentially coast through the course, but Mary Lou reached out to me at the end of that course and was like, "Hey, you seem like a type of person that knows a lot of this stuff, is really passionate about education. I saw you helping out at office hours and that sort of stuff. Would you like to step up and teach this course next semester?"

Neha: Wow!

Anthony: And so, I was like, "Yeah, let's do it!" And actually teaching was one of my favorite things in school because it was a great way to spread knowledge, but watching so many people just get that light bulb moment where they get programming and they're like, "Oh, this is awesome. I can make the computer do what I want to do." Just watching that turn on in people was great. I really love that. But yeah, that's kind of how I ended up in CS.

Brian: So, this is your second year in college when you decided to take these CS courses and then started teaching?

Anthony: Yep.

Brian: Okay. This is an amazing, amazing story, but also super awesome.

Anthony: Yeah. I took the course and then immediately taught it afterwards.

Brian: You might as well just start your own bootcamp at this point. You figured out the entire model.

Neha: Teaching can be so wonderful and it makes sense that it resonated with Anthony. I too have loved teaching and sharing knowledge but it can be hard to find those opportunities. Anthony missed that and wanted to find ways to teach again. Somehow, that led to more time to work on open source.

Anthony: For a while, I didn't really have many opportunities to be in a teaching capacity. Some of them were teaching, giving talks at work or spending time on documentation or educating people through code review and peer review and that sort of stuff. But that only has a limited scope in your impact. You're generally only impacting the people at your company or the people on your team or that sort of thing. And so, I got some opportunities to expand outwards from that through live-streaming and through YouTube content. And live-streaming for me actually started not really as a way for education, but it has sort of morphed a little bit into that. And it kind of comes as a side effect of that. I started live-streaming as a way for me to set aside structured time to work on open source.

Basically give myself time to, "Okay, I'm going to work on this project this weekend. I want to make sure I get this particular ticket done and get this deliverable by this point. I'm just going to block off my four hours, press go live and if people watch me, cool," whatever. But over time, live streaming changed from being that structured time to being more about community building and educating people that are watching, getting other people excited about programming and producing educational content at the same time. One of the most common things that I do on my stream and one of the most common questions I ask on my stream is like, "How do I get into programming? How do I get into open source?" And I love answering both of those questions, but repeatedly answering questions on stream can get tedious. And so I started collecting common questions and building YouTube content on it that I now have, I think it's over 340 videos that are similar. I have a question about programming and I answer the question about programming. And that's kind of been scratching my itch for teaching recently.

Brian: Which--I want to put out--how I found you was from Twitch first. I saw your channel and I sat and watched, probably around March or April 2020. And one thing that struck me too as well and it makes sense now that you mentioned your teaching background is like you'll be working on a problem and a question comes through and you'll stop the problem and then answer the question. So, it's like, for example, I don't know, strings in Python. Then you'll just go down and like run down the list of like, "Here's a string of Python. Here's how to do these other things. Here's some things you probably didn't know about." And then go back to working, which is very familiar. Like the engineer on a team, there's always that one engineer who loves teaching weird things about Git, or like the nuanced stuff. And that's the sort of feeling I get when I watch you stream.

Anthony: Yeah. If for me if I get five lines of code done in an hour, that is a major accomplishment because usually I'm spending 50% to 60% of my time not really distracted, but not working on what I set out to do. But yeah, that's the fun of it. Showing people weird things about Python and answering people's questions. I find that really fun.

Brian: Yeah. And to go back to the Twitch thing too as well, you were early on Twitch and live coding. Twitch is known to be a place, formerly just in TV where you just sort of stream whatever. And then it turned into only game streaming. And I know distinctively like in 2018, I actually started live streaming code. I wasn't very consistent but I did it for the same reasons that you had, I want a structured time to solve a problem. Doesn’t matter if people watch it. I fell off pretty quickly because I ended up having a kid. So, I went off on parental leave and then I just never got back into it until recently. But can you tell us more about the ecosystem of live streaming on Twitch? What it was back when you started and what it's kind of grown into now?

Anthony: Yeah. So, I also started late 2018, mid-2018. And back then there was an unofficial category called programming and it didn't have the icons that Twitch sets up. It wasn't in search. You kind of had to know that you were looking for the programming category. There was probably about, I want to say like 20 or 30 of us that would stream in there. You knew pretty, well not everyone's stream, but you knew most of the people that streamed in your same time zone. I would get five to 15 concurrent viewers. So basically zero, but it was a nice small community. We chatted and you built your stuff there. Those were the 100 or 150 lines of code per hour days. But I also talked to a bunch of my peers at the same time. I was like, "Hey, I'm doing this live coding thing on Twitch. It's kind of fun. You might want to try it out." And actually built up a couple of other friends who also streamed on Twitch and they invited their friends and we kind of built out this larger live coding community.

And the category grew and Twitch eventually merged it with the science category, which was popular at the time with streams like feeding ducks and growing marijuana-

Brian: Still is.

Anthony: ...and other interesting activities. And so for the longest time, the programming streamers, the game programming streamers and the software development streamers as well as ducks and weed, were all lumped into the science and tech category, which recently has been split out into its own category. And so the programming category has been revived. It's now called software and game development, it's largely remained the same over the entire period, but it has grown a lot. I think the biggest inflection point where it started taking off more was during the pandemic when people had much more time to consume online media, they weren't going out. So they were tuned into YouTube and Twitch and other social media and I for better or worse had a lot more free time during the pandemic because I was laid off from my job at Lyft and used that free time to stream and spend more time with the community.

And my channel exploded. I was probably about 20 or 30 concurrents before pre-pandemic and over the pandemic, I was averaging like 70 to 100. I was invited to the Twitch Partner Program, so I have a nice little check mark next to my name now and it's continued to grow since then. I average like 120 to 150 concurrents now. I'm still growing, but now that I have a real job, I don't get to stream as often and so, the growth has slowed a little bit there.

Brian: It makes a lot of sense that Anthony’s Twitch channel would grow during the pandemic. But he’s not just known for his live-streaming and teaching. He’s also been remarkably prolific as an open source programmer. 

Anthony: Well, the first project that I made was in late 2013, early 2014, somewhere around there. It was written during a hackathon at Yelp, the project is called Git-code-debt. The idea behind it was to track patterns in code bases over time and sort of do graph-driven development for burning down technical debt. We used it at Yelp to track things like one of the five deprecated ORMs or particular code patterns that we knew were problematic or unsafe and create a metric for them, track them on a graph and then use that to drive your goals for your team for that quarter. It didn't really get much use outside of Yelp as far as I know, but it was kind of my first experience with public GitHub and shipping code that other people can check out and look at. The first major important project that I still spend a lot of time on, it was pre-commit actually.

Pre-commit is a linter and code formatter tool that supports installing tools in a bunch of different programming languages. It happens to be written in Python but you have a tool in JavaScript or Ruby or Go or Rust or any of the other supported languages. It knows how to install those and run those against tools in your repository. The original code for it was written in college for group projects where I wanted to enforce style constraints on my partners that didn't have the same enthusiasm about style. And so, I built a bit of automated tooling that would enforce that on Git Hooks and Yelp. When I joined Yelp, Yelp had a lot of the same problems that we had in our group projects in that it was hard to have a consistent style.

We had linting tools in place, but they were optional. They were difficult to install. Every time we tried to add a new one, we had a fight with the systems team because they didn't want to install Ruby and they didn't want us to install these global tools and manage them for us. So, to me, it was kind of a way to install all those tools, make sure they're consistent versions and installed them all in user space so that the system team doesn't get mad.

So, I kind of took a lot of the ideas from my college group project thing and baked it all together and shipped it out as an open source project. And at the time I didn't realize just how popular this project would get. I kind of had an idea that like, "Yeah, this solves an important problem that Yelp was having." And yeah, it solved a problem that I was having, but the community response was kind of insane. A lot of people picked up this project and were like, "Oh, where's this been all my life? Why have I been doing this manually or not at all before this or why did I have this 3,000 line bash script that was doing the same management, but poorly." And so it's kind of grown from there.

And a lot of the stuff that I've built since then has kind of been built out from that. So, I'm working on pre-commit. I interface with a lot of linters and code formatters. I now maintain a good percentage of them in the Python community. And I work with a lot of the others as well. I've written a bunch of my own. By building that and building in open source, you work with the same open source tooling that everyone else is using. So you're using pytest for Python or tox to do build automation. And as I worked with those tools, you tend to find bugs. And so you'd go fix those bugs and people notice that you end up fixing a lot of bugs and they say, "Oh, well, if you like this project and you clearly understand enough of the code base to make a contribution, why don't you start maintaining it?"

And so, I collected more than a few maintainer’s bits by doing that. And I'm now a core developer on quite a few of those projects. So, like I'm a core developer on pytest and on tox and like a whole bunch of other linters. The other way that I've taken up maintainership in open source is kind of the ugly, unfortunate side of open source where maintainers, they have real lives, they have jobs, they have kids, they have hobbies, et cetera. And they don't always have time for open source. And some of them get burned down in open source. In those cases, many projects are left unmaintained or even if they're really important in the ecosystem or in the language space, like they don't have a maintainer. And in a lot of those cases I've offered to take up maintainership there.

So, two examples of that are the deadsnakes project which back ports and forward ports Python versions to Ubuntu LTS releases. The maintainer of that was no longer using Python and so they had no use for maintaining all of that infrastructure and I did. So, I offered to take up maintainership there. Another example is Flake8 where a maintainer had a bit of a falling out with open source in general and was frustrated with people being disrespectful in issue trackers and that sort of thing. Like was spread way too thin because they were so impactful in the Python community. And I offered to takemaintainership there so that he could focus on other things in his life.

Neha: That's a lot of projects to maintain and to oversee. Not only is it hard to manage one's time under those circumstances but Anthony has to balance that out with his job. That’s the condition of many maintainers, they work on their projects because they love them but they need a day job to take care of the bills. Anthony would love to dedicate himself to his own projects and he has something he’s working on that he could potentially dedicate more time to, should he get the support he needs.

Anthony: I have built a GitHub app recently based around pre-commit. So pre-commit being a linter and code formatter framework, it naturally translates to a CI system, which also runs linters and code formatters. And so, I built a purpose-built CI system that's based around that. And its kind of killer feature is that if your pull request is not formatted properly and you have formatters set up properly, the app will automatically fix your pull request for you, often changing a red PR to a green PR. Which is pretty cool.

The other aspect of it is your configuration file that specifies those linters and code formatters has versions as we talked about before and it also makes sure that those get periodically updated or that they are always getting the newest best practices for the tools you're using. And my hope is that companies pick that up and use the paid features of that to make that a sustainable project for me.

Brian: Okay. I'm happy to chat about that offline to see if we can get more eyes on that, but I'm seeing a very strong pattern in the JavaScript world where folks build open source things, get adoption or "product market fit," and then build a product or get VC funded. Actually, I don't know if you know this, but YC recently took a batch at the beginning of the pandemic and they're on the third batch at this point of only open source projects.

Anthony: Oh, that's cool.

Brian: And the whole goal was like, you go through the batch and you build a product that gets VC funded. And I think a lot of maintainers have to figure out, "Should I continue to work on this thing? Can I donate this to a foundation or can I get my job to pay for it?" I think it's actually a fork in the road for a lot of folks. And yeah, I appreciate you talking through the current situation with us. 

Anthony: Yeah, for sure.

Neha: I think also, you were talking about... So, you have all these projects that you've created, all these projects that you've kind of inherited as well. And so not only just the maintenance of that, its owned cost and I'd imagine that if you could get sponsored and be able to work on this full-time, you could even create things that you haven't been able to do yet. Is there a project that you have in mind that you haven't created yet that you would like to?

Anthony: Oh, I have a bunch of projects. The current one that is actually kind of a bit of a meme in my Twitch chat is I've been meaning to write a coverage service. There's a few out there and they're passable, but the idea really sprung up recently when Codecov had their breach. And there haven't been any decent replacements that are performant and have the baseline set of features that anyone would really want. And I have some ideas about how to build one and how I could go about doing that, but I don't have the time to do it. And I already spend too much time on funny personal projects. Like I wrote my own text editor for example. I think I wondered if I could build a text editor and the answer is yes, but it's a really hard thing to do. But yeah, I think there's other opportunities for building stuff that would be broadly useful to the community that just don't really exist yet. And, infinite ideas to make those sorts of things happen.

Brian: So Anthony clearly has a lot of projects on his plate, and he has this really engaged Twitch community. I’d imagine he gets a lot of contributors from there.

Anthony: Yeah. And that's actually really cool because I will often review a lot of pull requests directly on stream. And so people will see, and sometimes they'll see their own code being reviewed, sometimes they will see how someone like me would read other code and approach things. But yeah, I try and work as much in the open as possible. And a lot of people that have either found me through Twitch or found me through GitHub, end up bleeding through to both of the communities. And I try and take advantage of that a little bit. So, like my Discord community for my Twitch also has sections for the major projects that I maintain. And so, there's a lot of cross-pollination between those two groups and yeah, I think building in the open is really cool and it gives people that direct contact interaction that they might not get from the issue comment box, or essentially faceless interaction with an issue tracker or pull request.

Neha: Since you work with a lot of people who are early on in their open source career, do you have any advice for people who are interested in getting started, something that you've kind of learned along the way that you wish someone had told you?

Anthony: Yes. And actually, I don't mean to plug a video, but I actually released a video two days ago on my YouTube channel and the video is titled, The Most Important Skill I’ve Learned for Software Engineering. And in the video, I go through a framework for asking questions in submitting bug reports. It's basically a way to break down any issue that you're running into, into I think it's six steps, but the last two are optional. It's essentially like, "What was I trying to do? What did I do? What happens? What did I expect to happen?" Or like the bare minimum to getting a good bug report. And I think a lot of people fail one or more of those things. And if everyone asked better questions and made better bug reports like that, I think open source would be a lot more productive--and closed source. Any sort of customer support relation would be a better experience with those things.

Then the fifth and sixth step are about minimizing your reproduction and finding time debugging the problem, which often eliminates the entire need for asking a question in the first place. But I think that is by far the most important skill that I've gained by working on open source. But yeah, if more people did that, my life would be so much easier and their lives would be easier as well. 

As for getting started on open source, I think the biggest hurdle that people get stuck with a lot is they're intimidated by starting with open source. And it's not that hard. The easiest advice that I give is go to an issue tracker, search for easy or beginner-friendly or documentation is another way that first-time contributors can get involved, but find something that sounds interesting. If it doesn't have enough information to solve it, ask the maintainer, they're usually happy to help you figure out how to solve a problem especially if you're going to help them out as a contributor. And you're going to get your first pull request out there. The first one's the hardest one. It gets easier after that.

Neha: I think what I love about that is of course, in order to contribute to open source, if you're going to dive really deep into like opening up a pull request or anything, there's obviously a technical component of it, but a lot of what you said was around communication and how we ask questions and how we phrase things and how we share enough so that it's more of a help me, help you sort of situation. And is that something that you're noticing across the board with respect to how crucial communication comes into play?

Anthony: Yeah. And I actually think communication is the hardest part of open source. It can be really difficult to recognize that, "Hey, there's a person on the other side of the computer." And they may be frustrated with you or the technology, but they're just human and getting past the communication boundaries and difficulties is a hard problem. And programmers aren't necessarily the best at communication and so, it can be often difficult working past that. But yeah, I think if I could snap my fingers and fix one thing about myself and one thing about other people, is that everyone would just instantly get better at communication and it would be way better.

Neha: It’s clear that communication in open source is a major thing that Anthony thinks about. Improving communication can go in so many different directions though. I was curious what were some of the ways that he streamlines communication to make it more seamless for contributors and maintainers.

Anthony: I think there's a lot of stuff that can be done with issue templates and actually the new issue forums from GitHub, I tried them out recently and they're really nice. I set one up on the repository that gets the most issues by far of all the projects that I work on and the issue quality has gone up significantly. One of the two memes in my Twitch channel is that like, if I were to make T-shirts, one of them would say, "I Can’t See Your Screen." And the other one says, "It’s Not Working. It’s Not a Bug Report." And I haven't needed to ask people to actually show me their output in a while, which is really great. But yeah, getting higher quality issues and higher quality communication goes a really, really long way.

Neha: I'm curious about the other side. You were talking about how it's important when you're writing issues or opening pull requests or anything to remember that there are humans on the other side. As a recipient of maybe some of the... Not so great messages and the really great messages, how do you cope? How do you do it?

Anthony: Well, I get pretty low-quality stuff pretty often. My current method of coping is to try and laugh it off as much as possible, usually by sarcastically tweeting about it. And "Hey, Twitch chat, look at this issue that I got today." Some of them are pretty funny. Like there's another stream meme, which is: Good code changed like a ghost! Which is, someone came to my issue tracker and just vented some frustration about... They set up a code formatter and then the code formatter changed their code. Actually, the last bit is, "Good code changed like a ghost. Garbage. Why don't you say you have time to do something else? Doing this boring pointless thing just like some stupid writer who doesn't change Shakespeare and thinks he's doing a good job." 

It's just like I get stuff like this all the time where people are understandably frustrated with whatever they've set up and approaching this in a different way with a more level head--it's better for both of us. They would potentially get some feedback from me that's not just close and move on because I don't really have time to deal with negativity. And I'd much rather focus on somebody who's a positive member of the community than somebody who's out here to be rude. But yeah, I mostly cope by laughing.

Neha: Yeah. I have this new post-it that I wrote on Monday on my laptop, which is, have fun with it. So-

Anthony: That's nice.

Neha: ... I'm definitely reminding myself of the same thing.

Anthony: That's great.

Brian: It was great to speak with Anthony Sotille and have him on the ReadME Podcast. To learn more about Anthony, go to his Twitch account, twitch.tv/anthonywritescode.

I am Brian Douglas, aka bdougie.

Neha: And I am Neha Batra aka nerdneha. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all. 

Brian:  It’s been great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and the teams whose contributions move the world forward every day. Visit github.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Blue Dot Sessions. 

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!