For me, the best way to learn is to build something you can personally benefit from. That forces you to learn the technology necessary to make it work. I adopted this approach with one of the first programming projects I did as a kid. My brother and I had a silly problem: one of our chores was taking our dogs out every couple hours, but we were both bad at remembering—with very messy consequences.
I wrote a small timer application and got my dad to record two audio snippets, calling us each out by name and reminding us to take the dogs out, and let them back in a few minutes later. To build that, I had to research and learn about threading, scheduling, and how to make a tray application and Windows Forms app. It was a good learning experience, and one that culminated in something personally beneficial.
When I started working on open source in 2012, it was an opportunity to create things that would not only benefit me, but also my peers. A handful of those early projects were never useful to anyone else, but a few got picked up and grew. Now I maintain about 70-80 open source projects.
I’ve found my way to maintaining OSS projects in a number of different ways. The first was by creating a project that became popular. Those are the ones I’m most excited about—the ones I create by learning and doing. Another is through making positive contributions on a project and being asked to join as a maintainer. Finally, I’ve inherited projects from maintainers who have burnt out or otherwise opted to step away. When this happens to a project that I use heavily and am invested in, I volunteer to take over.
Putting pre-commit out in the open
The project I’m most passionate about is pre-commit, which originated in closed source—but only because I didn’t know what open source was yet. It’s a linter and code formatter that was written in Python but also manages Git Hooks, and installs tools in different programming languages, including JavaScript go, Ruby Rust, and Docker.
pre-commit started as a way for me to enforce style on group project partners in college. I felt much more passionate about code quality than my partners, so it was a way for me to programmatically fix cosmetic issues like white space and comment style. Because tabs over spaces. I actually wrote my own text editor.
I worked at Yelp for five years between 2012 and 2017, and we had our own version of a similar tool. Ours, however, was a 3,000-line bash script that was externally managed from the primary code base—and broke everyone’s development workflow every time we touched it. So I generalized pre-commit for Yelp, and figured we might as well release it as open source. I had written 95% of it in my free time, and, during a Yelp hackathon, we decided to make it more polished and professional.
We got some designer support and put together a documentation site for pre-commit. We also wrote about it on the Yelp engineering blog and, for better or worse, Twitter (as much as I hate the bird site, it seems to be the best way to spread the word on technology). After pre-commit was released, I realized how many other companies had exactly the same problem, and how well the tool could solve them. It quickly became my most popular project.
Assuming good intent and trying not to take things personally
Almost all of my projects are Python. I used to be a frontend developer, but I just don't have time to keep up with how quickly it changes.
If you’re using Python, you’re probably using flake8 a popular linter framework. I think it’s changed hands six or seven times at this point, with maintainers cycling in and out over the years. The most recent maintainer that I took over from, Ian Stapleton Cordasco (sigmavirus24), is similar to me in that they’re involved in basically every project and have a lot of influence on the tools they use. As a side effect of that, they’re very important in the Python community.
Unfortunately, the amount of non-programming work added up, and Ian lost his passion for the project. The other problem is that flake8 is set up as a wrapper around other tools. Everyone else’s bugs bubble up through the framework, and it attracts a lot of off-topic and unrelated commentary. Sometimes you’ll get individuals who are belligerent, aggressive, and rude. In a lot of ways, I experienced the same things and understand that end state where you just don’t have time for that kind of nonsense.
To combat these challenges, I have a few strategies. First off, assume best intent. Most people are coming from a place that has no ill intention toward you. I also try to nudge people in the right direction. I give them pointers, like, “If you would have approached this problem this way, or asked your question like so, it would have described it more accurately, and we could have played this out differently.”
Sometimes you just have to close the issue, move on, and try not to take it to heart. It’s hard to separate the software from the people, and I am really bad about taking things personally, but I try my best.
Discovering the challenges and rewards of OSS
Another project that’s equally important in the Python community is pytest. I’d been using pytest since 2013, and around early 2017, I left Yelp and started getting more passionate about open source. I took six months to see what it would be like to just focus on OSS. While it was ultimately unsustainable because it didn’t pay the bills, it was a fun six months.
During that period, I dug into some personal bugs, and pytest was the tool I used most. I frequently ran into edge cases and spent time solving my own problems and adding features. I took it upon myself to search through the bug tracker, learn more about the project, and understand the structure and how things fit together. In short, I kept finding opportunities to contribute—and eventually became a maintainer. In 2020, there were some shifts in the project’s direction and team of maintainers, which allowed us to standardize pytest’s governance strategy and make the project better.
I don’t want to be part of governance for more projects, because that’s where I feel personal responsibility to spend time on them. I’ve already hit that threshold where I can say I’m over that. I do think the community aspect is fun. You get to sit in someone else’s shoes, figure out their problem, then craft a solution to help them out. A lot of times, we’ll recognize an opportunity to improve the documentation and experience—not just for that person, but for everyone else down the line.
Pioneering a modern way to program
In 2018, I started streaming on Twitch, when the programming category was still small. There were 10 or 20 streamers who would draw audiences of five to ten people. For me, it was mostly an excuse to sit down and have structured time to work on open source. Since there was an audience to interact with, it made the experience better. When someone else is watching, they can give you hints and tips, or you can just chat about life. Similar platforms like YouTube streaming and Mixer didn’t even have a programming category, so Twitch was the only place for this kind of engagement.
Over the years, people started picking up on the idea, because in a way, live streams are really just about interpersonal contact. When I started, I would spend 90% of the stream actually coding and 10% with the community interacting. Now, it’s shifted more toward community interaction. The joke is that if you write 10 lines of code in an hour, you’re doing really well.
I’m good at continual context switching, but not every programming streamer takes the same approach. Some will ignore chat and spend most of their time writing code. It’s more of a performance than it is an interaction, and I don’t personally enjoy watching those.
I love to interact and show everyone what I’m working on. I explain the why, diagram things in real time, and tell stories. I also share a lot of my experiences about live streaming and programming, and encourage other people who are interested to go live and share their code. I think that aspect of streaming is really fun.
Teaching and learning with and from the community
My Twitch audience has varied skill sets, backgrounds, and knowledge. I get a lot of viewers who are programming for the first time and want to understand more. One of the most popular questions is how I got started and what they can do to get better at programming. Another is about college degrees, and if you need them to be successful in software engineering. My answer is usually no, but it does get your foot in the door. I have a formal degree, but was employed as a software engineer before I even started my formal education.
I was a TA in college for my introduction to programming class, and my favorite part was watching people’s faces light up when they understood what was happening. When they realized, “Oh, this is actually really cool. I can make the computer do what I want it to do,” it was amazing. I’m getting goosebumps now just talking about it. I absolutely love that part of education and teaching, which is why I was drawn to Twitch.
I take a lot of the content or questions I get and re-record them as educational YouTube videos. I think I have close to 300 now. I know people who have been inspired to start programming and improve their skills after watching my streams, which is so cool.
And that community education really goes both ways. The other day I was working on updating my YouTube descriptions using the YouTube API, and people in chat were so helpful, sharing different things I could try and how they fixed similar problems. Chat has been instrumental in helping me learn things; one time, one of my viewers helped me fix something that would have otherwise taken me another 12 to 18 hours.
Other than things that I write for myself, or patches and improvements, I’ve started to say no to maintainer offers, and have told myself that I shouldn’t pick up more projects. But two to three times a week, I intentionally set time aside for Twitch because I really enjoy it. The combination of two-way education, engagement, and programming is a constant source of inspiration, and goes back to the best way for me to learn by doing.
