My open source students are beginning Hacktoberfest this week and already the DMs are coming in with a familiar question:
"Is this issue big enough? Is this too simple?"
I understand the question, since I explicitly ask that students work in real open source projects, avoiding those repos that appear suddenly every October and vanish just as quickly in November. I want to see everyone working on valuable contributions to existing projects. But how big should a contribution be?
My answer: as small as possible, while providing value. Let me give you a few recent examples.
For the past month, our beloved blogging aggregator, Telescope, has been broken. I asked my current students to use our new Seneca SSO based Sign-Up flow and create an account. Later that same week, I was shocked to see that none of their blogs were showing up in the timeline. I decided to look at the database to see what was going on (maybe no one actually signed-up?), only to be met by a set of angry 400 errors on the database's REST API.
I filed an issue and not long after, Kevan appeared with a fix that changed a single line! The difference between me being able to properly administer the database and being locked out came down to updating 15 characters!
After shipping these 15 characters to production, I was now able to see what was happening in the database, and sure enough, the students had created accounts: the system just wasn't processing or showing their content for some reason.
Thankfully Roxanne appeared in the issue with some ideas and a willingness to turn her debugging prowess onto the problem. Her research uncovered an issue with how new users were being processed by the system.
Telescope has three categories of users:
- Those grandfathered into Telescope from the Planet CDOT Feed List wiki page
- Those who have created accounts via our SSO based Sign-Up flow
- Those who have graduated from 1. to 2.
All of our testing last year focused on people in category 3, namely, those who were listed in the wiki page, but also created accounts for themselves. In this case, we link the accounts in our backend, allowing an existing user to sign-up and re-take control of their account.
This fall, for the first time, all of our users are from category 2 (i.e., creating brand new accounts that don't exist in the wiki). It's a scenario that should work (in theory!) but clearly doesn't in practice. Our feed parser couldn't find a name for all the new users, so ignored their feeds.
The Telescope project is about to turn 3 years old this month (it started in Oct 2019, remember that world?). Since then, 229 contributors have written close to 25K lines of code. The code is mature, and the architecture takes time to learn and understand. I don't think any of the recent devs (myself included) knows all of it.
Getting involved with a medium-sized open source project like Telescope takes time. You have to figure out where a bug is coming from, try and get things running locally, test your hypothesis, discover that you're wrong and try again, talk to people about what you learned, and repeat that process for hours, days, or weeks without giving up. Often, like I've just shown you above, the actual fix is trivial, even obvious! But only once you've figured out what's going on in the first place.
Lots of big things get brought down by tiny forces (try stepping on a single piece of lego in the night as you fumble around a room in the dark). In the examples above, I showed you that 35 characters were all that it took to make 25K lines of code unusable.
Having a big impact isn't about writing a lot of complicated code. Rather, real programming is doing exactly what's needed to make a system work, and nothing more. If you can do it by changing a single line of code, you're a true master. If you can do it by removing a single line of code, you're a wizard.
My advice to all my students this October who are struggling with imposter syndrome and feeling like their tiny contributions won't amount to anything: be like Kevan and Roxanne.