Rubenerd

Speaking of podcasts, I listened to another one a few weeks ago where version control was discussed. It could have been CoreInt, or ATP again. Anyway the hosts asked each other when they learned it, and concluded they had to pick it up on the job.

I assumed I’d formally learned it somewhere, but realised it came later than I expected:

• I did Software Design and Development and Information Processes and Technology for the HSC at the Australian International School in Singapore, which would have been a lot of abbreviations had I typed them as IPT as SDD for the HSC at the AIS. No version control.

• Then I did a stint of computer science at UniSA. No version control.

• Then when I went back to uni and became a biscuit at UTS to learn more of the information and business sides, we touched Subversion once, briefly, in a single subject.

The argument against learning VC is individual tools are constantly either in vogue or not, so it’s not valuable to teach a specific toolchain. I don’t buy that; there’s plenty you can learn about checking out code, branching, merging, and conflict resolution that would broadly apply to any reasonable tool. Most of the problem domain is people as well, so there are soft skills around collaboration that can be explored.

Checking out the NetBSD pkgsrc system with CVS was my first experience with VC, but my first commits were all with Subversion. I learned hg on my own time for personal projects, then reluctantly picked up Git long after the industry had spoken. One early company I worked at used Perforce, but I never touched it.

It was only when I started the last couple of jobs that I learned version control seriously, and I would still only classify my understanding as intermediate at best.