The trap of overcommit-ment

Overcommiting?

You must watch the sunrise atleast once a day
- Phil Dunphy

If you are mildly interested in making a contribution and are enthusiastic to a certain extent, the open source community recieves you with open arms and a box of chocolates.

When you pick up your first project, you start using fancy expressions to describe your work, create page long descriptions to your pull requests and create issues supported by customized screenshots. It is a good thing. Maybe the best of things. But unlike what Andy Dufresne said in the Shawshank Redemption , this habbit dies very soon. As it dies another one creeps up to takes it place.

Overcommit is very different from overcommitment. Though adding the over suffix, only helps in very recherché situations. When you see lots of green on your github homepage, you are overjoyed to see how you have progressed, but it is more often than not, what data scientists call, grunt and misleading. The github green is pretty easy to fool (probably why github removed the streak attribute, since it was costly to calculate as well).

Overcommiting begins when a fowl in the community sees an opportuinity to shine and commits every small change. Thus a small sub-routine costs 200 commits, 199 of which were uncompilable.

Something like the delusion of god, is the delusion of work progress after overcommitment. But a lot of developers were saddened by GitHub’s sudden, unilateral decision to remove code streaks. Jed Watson, who had a 1,000+ day streak of open source contributions as of Thursday, wrote a touching article about how his streak had followed him through many life milestones, such as the launch of KeystoneJS and the birth of his daughter. And Jed wasn’t alone. Many other famous open source contributors prided themselves on their consistent coding, as reflected in their long-running streaks. Look at how beatiful it looks :

Do’s and Don’ts

Thank you for reading! Happy commiting !

Tags