Over a million developers have joined DZone.

How 30 Days of Commits Managed to Piss Me Off Rather Than Excite Me

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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 overhaul-sprint 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 master are not backlogged into the contributions page. Meaning that any branch work whatsoever is “useless” in terms of filling up those neat green squares.

What’s annoying as well is that sometimes, when I work late, or just forget, I don’t do the regular git push 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 streak. 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 several months.

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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Antonin Januska. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}