GitHub isn’t your CV, and GitHub commits don’t show your talent

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

January 12, 2015

I previously wrote about how GitHub isn’t your CV, and went on the even close my LinkedIn profile because of how little value it actually provided.

GitHub’s eye candy

Lately, I noticed people posting things like diagrams of burnout based on a dwindling number of commits to GItHub. Once again, it seems like GitHub likes to invent metrics and measures that seem to me little more than eye candy. Yet I fear managers and engineers using them as hiring metrics.

As my best example of such useless eye candy, I will point out myself. I am a self dubbed editor-at-large for Spring’s Getting Started Guides. The side effect is that if you go check out all the guides, you’ll find my name spread across almost all of them. I can probably claim 80%+ of the commits as well. It makes my GitHub profile look crazy with bursty rates of activity. For a full comparison, compare myself to my colleague Roy Clarkson. GitHub is showing that I have over 2600 commits for the pat year while Roy has 610. I fear that if Roy and I were somehow applying for the same position, someone might use that crazy metric to make a decision!

The truth is, Roy is a project leader for both Spring Mobile and Spring for Android. Roy has tackled countless problems, and being a one-man-band for two projects, has tackled an armada of issues with no one but himself. Passing on him due to a silly metric would be foolish.

The reason I have so many commits under my belt is that I wrote a tiny script that made it easy to roll the guides whenever a new version of Spring Boot comes out. It looks like this:

#!/usr/bin/env python

import os
import re
import sys

if len(sys.argv) < 2:
    print "Usage: %s " % sys.argv[0]

with open(sys.argv[1]) as input:
    with open(sys.argv[1] + ".new", "w") as output:
        content = input.readlines()

        for line in content:
            if "1.1.9.RELEASE" in line:
                output.write(re.sub("1.1.9.RELEASE", "1.1.10.RELEASE", line))

os.rename(sys.argv[1]+".new", sys.argv[1])

That 22-line app has saved me hours upon hours of effort and allowed our guides to stay up-to-date with the latest releases of Spring Boot. It’s the reason that when Phil tweets about a newly released version of Spring Boot, I usually tweet about the guides being updated within the hour. My teammates have come to assume my answer to a given problem is, “I can write a script for that.” And this app is nowhere to be found in my GitHub profile.

All code requires context to be properly evaluated

That is the kind of code and context I would carry into an interview. It shows that I know more than one language. I know that not everything is a Java application. It shows that I also understand the dividends paid in saving engineering time. And it shows that I understand the value of keeping documentation up-to-date.

The unfortunate side effect is that GitHub now shows me with MANY days of having bursts of over 50 commits. The thing is, if you were to hire me, there is no guarantee that I would be knocking out 50 commits on key software components. (Unless I write a script that starts doing document updates the same as I do now.)

Hiring others isn’t easy

I have actually hired people in the past. Long ago, when I received my first promotion, my manager explained that I had reached a level where interviewing candidates would be part of my annual evals. I took that on full steam. I interviewed dozens of people. I quickly learned that the one hidden question to ask yourself is, “would I want to work on the same project, side-by-side, with this person?” As can be expected, not everyone was perfect.

But nothing in a resume or any other publicly visible metric tipped me off about the best nor the worst people that worked directly for me. One person took over the mission critical app I had led for years. He had new ideas I would never have thought up. Another was a copy-and-paste developer that couldn’t seem to learn new lessons. He didn’t last six months. There was no way to know this short of actually working with them for a few months.

People, please don’t pick pre-fabricated metrics and eye candy as your criteria to hire and fire. Use real talent and judgment. And be ready to ask yourself, if this person doesn’t work out, what will be your course of action?


Submit a Comment

Your email address will not be published. Required fields are marked *