I have been attending a lot of virtual cons recently, and a recurring theme had been the value of contributing to open-source projects. At the same time, “100 Days of Code” had been assaulting my Twitter feed. I am a sucker for gamification, and I’ve learned there are a lot of great ways to turn that into an asset. Still, hundred-day challenges have never been my thing. I have been casually attempting to earn the Fanatic badge on Stack Overflow for over six years.

Instead of one hundred days/hours of coding, how about one hundred pull requests on GitHub? No B.S. pull requests either. While I have no control over the timeframe in which any pull request is going to get a response, I’m talking about “mergable” pull requests. Without putting any limitations on its scale, each pull request must make a genuine contribution and conform to all project standards. Issuing one hundred PRs in a single day isn’t a challenge at all if quality is no issue. “Mergable” also means completing any extra actions required by the project, such as signing Contributor License Agreements. Fortunately, one hundred hours of pull requests did not become one hundred hours of CLAs.

One hundred pull requests in one hundred hours seemed like a reasonable plan. I’d get the satisfaction of challenging myself, I’d become an active contributor to open-source projects, and in the end, it might all be an experience to write about.

It turned out that one hundred mergeable commits in one hundred hours was not a reasonable challenge. With a little bit of Python scripting, it wasn’t a challenge at all. I used a script to pull the URLs for one thousand popular repos and search through each repo’s markdown files for common typos. I spent most of my free time for a few days looking through the generated reports and creating PRs and issues as appropriate. One hundred PRs in one hundred hours was a very casual level of difficulty, and I had been looking for a challenge. As Professor Hubert Farnsworth said, evolution has programmed the male brain to take anything anyone thinks is important and make it bigger. “One thousand PRs in ten days!”

Since the challenge centered on maintaining a given rate of productivity, one PR per hour, the less time a PR required the “better” it was. A repository with a single typo in the project README is better than a repository with many typos spread through dozens of documents. Outside the context of the challenge, the more errors a pull request corrects the greater a contribution it makes to the project. So far, I had resisted the urge to only fix a single error for each PR regardless of how many were present in the repo. If I really wanted to push some numbers up, it would be a necessary strategy.

The dangerous temptation inherent to gamification is the loss of the original intent. It was time to move away from questions of how best to sensationalize and started thinking about actual value. Big numbers are wonderful, but targeted, sustainable efforts are better than acute preoccupations.

That doesn’t mean I can’t still be do silly things in questionable ways for fun, profit, and elucidation. I’m losing the framework of a challenge, but I’m gaining the guidance of a plan. A brilliant plan than can be surmised in a single word: Over-engineering. I find a certain pleasure in intentionally over-engineering a project. I like it as a way of learning to use new technologies in new environments and in new combinations. It’s effective and after years of trial-and-error I’ve learned to find a comfortable sweet spot somewhere between “intensive learning exercise” and “impossibly convoluted nightmare.”

Find out how that works out in Part 2 of my first blog article. I’ll be replacing my simple Python script with a distributed application of Dockerized microservices using asynchronous task invocation and no less than three different database technologies. None of it is necessary, but it is very educational.