Today, I had a conversation with a small company that doesn’t use version control.
It’s hard to remember what it was like before version control. I know I did get started in a world without it. When I started in embedded development, we didn’t have version control.
Before there was version control, I made versioned backups of my entire working directory.
Yikes. Dark ages.
Then our development team moved everything into SourceSafe, as I recall. This was before Microsoft bought it out and turned it into Visual SourceSafe (which I also came back to later). And then we moved to CVS.
I also used Aegis for a bit, developed by the late Peter Miller. It introduced to me the concepts of feature branches and a working baseline on which the tests always pass.
I also used Peter Miller’s cook (an alternative to make), or at least played with it, for building a large, complex project made up of multiple subprojects. Today, of course, we have magic build systems that just seem to do the right thing and can be invoked from our CI/CD process.
After CVS, we all migrated to Subversion for a short time.
I’ve also used ClearCase and Perforce, both of which are incredibly powerful but both of which left me asking, “Why?” With regard to the former, I worked at a company that had a ClearCase department and ClearQuest department, alongside Release and other DevOps (in the days before we called them “DevOps”). You needed to send an email to the ClearCase team in order to create a release tag. (I swear I’m not making this up.) And they were typically very prompt about handling such requests. The level of administrative overhead for this system was so great, I still don’t know what net benefit it bought over other, less powerful alternatives.
Git came on the scene, and I became overwhelmingly confused. Git was a simple tool powerful enough to blow your foot clean off. Yet somehow there was always someone in the organization who could sew the foot back on again, good as new. Then a colleague sent me a link to Michael Schwern’s talk, “Git for Ages 4 and Up,” and suddenly it all made perfect sense. It’s fascinating how paradigms matter.
Now I version my resume using Git. Git is such a low bar that I just go to it directly. I don’t have my resume on GitHub, mind you; I just have a .git subdirectory in my resume directory. It’s not just the one resume file, either. I have a functional and chronological resume and different resumes for different sectors, plus a subdirectory with resumes for certain specific employers. I also have a Makefile that formats all the LibreOffice files as PDF (invoking LibreOffice with appropriate command-line switches), which I can then send to recruiters or employers. So it has a number of the qualities of a software-development project.
I did a one-day project for an employment test yesterday, and it occurs to me how much my basic process and architecture skills have matured over the years. I used an IDE, wrote unit tests, checked my code into Git at each stage, and pushed to GitHub. Then I added issue tickets for features that I thought ought to be added. I stopped just short of CI/CD, but I have used CI/CD for similarly small toy projects because it is really easy to set up.
Part of what’s different is that the tools have gotten way better over the past 30 years. What used to be difficult and expensive is now a cheap (or free) download with step-by-step instructions that kick off automated scripts to do all the complicated stuff.
But another part of what’s different is that my personal process has matured. I’ve become more experienced. It feels natural to use version control. In the same way that I now naturally think in terms of requirements, abstractions, and architecture—rather than syntax and other programming language details—I also naturally write unit tests. That feels comfortable, safe.
May all your bars turn from red to green.
Tim
