Since finishing my dissertation, I decided to gather some metrics across the related repositories. Pulling the raw number of commits with (roughly) this:

find . -name .git
    | xargs -I {} git --git-dir={} log
                      --all
                      --author=$(whoami)
                      --pretty=format:"%H"
    | sort | uniq | wc -l

I realized that I’d crossed the 10,000 commit threshold right before graduating. Which seemed appropriate.

While the Gladwellian 10,000 hours heuristic (debatable as it may be) for mastering a craft fits as a general cross-discipline measure, I’d conjecture 10,000 commits is a more fitting measure for software engineers. It’s difficult to imagine reaching 10,000 commits without having gone through a full software lifecycle, probably more than once. And counting commits instead of hours has the advantage of each being a visible, presumably atomic, and (lightly) documented bit of work, where the prerequisite (actually using/understanding version control) is a good indicator of investment in the craft. For those of us who may have exceeded 10,000 hours tinkering with “programming” before finishing high school, having a goal that requires the discipline to document your progress may be more helpful than 10,000 unstructured or undocumented hours of hacking.

Particularly when completing a CS Ph.D., commits to research software, open source patches, version controlled manuscripts, research notebooks, etc.—when taken together—are rarely going to number much less than 10,000 if you’ve truly produced enough work to graduate. Similarly, though I’ve not stayed in a junior software developer role long enough to be promoted, crossing the 10,000 threshold sounds more than ample evidence of outgrowing the role.

When a software project hits 10,000 commits—no matter how ugly it might be—it’s easy to imagine it being fleshed-out and mature. I’d like to think engineers might be too.