How 30 Days of Commits Managed to Piss Me Off Rather Than Excite Me
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Recently, I had it in my head to participate in the new trend of filling up your Github contributions graph. After seeing five different articles on HackerNews and hundreds of search results on the topic, I decided that it was time for me to join in on the fun.
The premise behind the entire activity is the same as any “30 day sprint”. From NaNoWriMo to diets, doing something for 30 days, every day, will enrich your life and give you experience that you can’t get elsewhere, at least that’s the idea. On top of that, it helps build up a positive habit.
I believed it, especially since I subscribe to the entire monthly goals ideology. I’ve written books, done article sprints, and even shorter coding sprints. But never 30 days of coding.
The double award came from the fact that not only will you learn, but you get that green contributions swag on your profile. The profile that tells everyone, “I live to code”. It’s a form of tracking that let’s everyone know you’re dedicated. Similar to exercise social networks where you can see the past workouts and get points awarded.
But after about six days of doing it, I encountered a slew of maddening problems. First, let me explain that the “double award” is actually like a badge of honor, that you’ve done what you’ve promised. A proof of commitment.
So, that’s how I got myself in a situation where I decided to abandon the entire ordeal. And you’re welcome to correct me if I’m wrong.
It promotes bad branching habits
One issue is that Github marks your contributions in a specific
manner (at least publicly). A contribution is an opened issue, pull
request, or a commit on a default branch. The problem with this is that
most default branches are
master which means that this entire process promotes committing straight on master.
I rarely commit on master (outside of releases and prototypes). My
entire theory is that you can prototype on master but once you gain some
usage and some weight behind your code, it’s time to start branching.
For example, my Tseczka wp theme has a main release
master branch and an
branch which currently contains v3.0 code. Once that’s done, I’ll merge
it down but as it’s one of my major coding efforts, it’s where I commit
most of my code. Yet, it doesn’t count.
My Tseczka CSS framework is the same deal. It’s on bower, I regularly use it to prototype so I can’t just throw random code in there, it needs to be properly released. Thus, contributions outside of master don’t count.
I could go on and on but this is the crux of the problem. The spring encourages me to either branch improperly or focus on prototypical projects. It also doesn’t make sense from a public perspective to switch default branches whenever you branch out, just to “make it count”.
On top of that, open source work doesn’t count either! Opening up the PR will count, the comments on the PR will count and merging of the PR will count but none of the commits will count toward your goal. The reasoning behind it is that commits on a branch have not only the restriction of being on the default branch but also on the original repo. And since you can’t commit straight on someone else’s master repo (and it’d be a bad idea on an open source project anyways).
There’s no back-logging
Let’s say then, that a month later, I merge down my
overhaul-sprint branch. That counts as a contribution but a month worth of commits now visible on
are not backlogged into the contributions page. Meaning that any branch
work whatsoever is “useless” in terms of filling up those neat green
What’s annoying as well is that sometimes, when I work late, or just forget, I don’t do the regular
to check my code back into the repo. These contributions will disappear
as well and while they may count for today, they won’t for the day the
commits were actually authored.
It encourages bad life habits
I believe it’s a bad habit to give one hobby full power over your life, especially if that “hobby” is also already “work” and it discourages exploring life otherwise.
One of the
streakers mentioned that they abandoned a different hobby in order to pursue the
That to me seems backward. I can appreciate working on personal
projects daily but code is not life, it’s just another part of it.
Especially since this person ended up extending his streak for another
Plus, that kind of commitment is sure to cause a burnout. I’d say that variety of hobbies and a variety of activities encourage a person to think more clearly rather than blindly delving into the depths of 24/7 code.
Breaking the streak discourages much more than is worth
I’m hoping that someone will make a neat app to properly document contributions and contributions streak, that’d be awesome. But until then, seeing a week long streak go to hell because:
A. I forgot to push a commit
B. Did a great deal of work on a branch rather than on master
C. Worked on an open source project that’s not mine
is discouraging. I always feel like I’m in that
Rock - Hard Place.
So what now?
I’m abandoning the streak badge and just doing what I always do. Work on projects as I go. Doing a little bit every day, and taking advantage of that. I definitely won’t sacrifice weekends for this nor will I sacrifice good git habits.