The trap of overcommit-ment

Overcommiting?

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

Avoid making a commit when your code is uncompilable, but don't make commits everytime your code is. For example, banks use a similar mechanism to rollback to the last commit if a transaction is not succesful. Thus each commit must count.

Try making commit messages short, yet keep them sweet. People generally rely on the messages that fit in the github window

Never judge your progress by the number of commits you make. Even the number of lines you write is a better parameter than that and it is probably the second most misleading one. The best parameter is a mentor.