If you’re in the software industry, you’re likely familiar with the Stack Overflow Annual Developer Survey. This year’s results were released this past week. For the second consecutive year, “version control” was not reported. The last year it was reported (2018), git was the by-far dominant tool in the space. It has likely only gained more marketshare in the last two years, which is why it did not make the report. In this sense, it is unique–engineers disagree about seemingly everything except for git.

NOTE: The 2021 survey reintroduced surveying for VCS in an “other” category–95% of all professional developers indicated that they use Git.

Version control is an everyday practice for all software development. It enables multiple people to work on the same codebase, well-organized and well-documented code, rapid debugging, and versioning. In short, version control is a huge productivity enabler. But its utility goes beyond enabling productivity–it is, in my opinion, the best indicator of software talent. An engineer’s familiarity with git and their ability to use git to solve various problems are great ways to estimate experience and problem-solving ability respectively. Better yet, nearly all engineers have been exposed to it at one time or another. For that reason, it should be tested in all technical interviews–when was the last time you were asked to use git in a technical interview? Yeah, didn’t think so.

Git-centric questions cover just about everything you might want to know about a software engineer’s skillset–their understanding of internet protocols like HTTP and SSH, distributed processing, theoretical computer science in the form of Git’s internals, their attention to detail and familiarity with their most-used tool, etc…. While different software calls for different programming languages, frameworks, hardware, etc. the vast majority of software is now controlled using Git. In some cases, Git also serves as a fundamental tool for the operations of software deployment.

Git use in its own right can make or break a software team–when, not if, a critical bug makes it to production, bisecting through a log of "testing" commits, each of which does not build, is a silly place to be. By making the debugging process better, by having a clean commit to roll back to, by interviewing for VCS compentence…maybe–just maybe–you could have prevented the bug in the first place. At worst, you would have released it and fixed it months ago.