I have talked to aspiring engineers about professional skills they will need that not taught in school. Some of them are technically taught in school, although they are taught poorly. Version control systems are a great example of this.
While getting the basics for fetching code, creating branches, and committing code is nice, that is not the education you need with version control software. I will use Git for our example today, although it could just as easily have been one of many different flavors of version control. Perforce comes to mind as a version control system that video game developers use because it manages large repos of game assets nicely.
The things you need to learn about version control are more related to merging code and how to deal with a repo that four or more people are actively working on, sometimes even editing the same file. This is not what you get to do in school unless you are working on some kind of capstone project. A week-long project with two or three developers does not get to the level of excruciating pain and suffering that results from four or more people actively working in tandem on a codebase. You seldom get projects with enough people, and you are not working on a project for long enough for the pain to really be felt.
It raises the question: “What is the reasonable expectation for source control proficiency for a new employee without any experience?”
The answer is: “Git proficiency is not a reasonable expectation.”
There is a moment of cognitive dissonance when a new employee asks for help with a git merge. “Hey,” You might be tempted to say, “Didn’t you submit your code sample from a git repo?” While that is a perfectly reasonable knee-jerk reaction, it is not really a good one. Merging code into a large project on a team is not the same as “one person writes a small piece of code and uploads it in a controlled environment with no one else touching it.” It is not in the same ballpark and probably not even in the same league.
You are left with two options.
The first is to buy one of them there goofy mugs with all of the Git commands written on it and to have them hunker down and “git gud.” Maybe this works here and there. I do not know if it scales well. If you want to try that, you have the Amazon Affiliate Link to buy it. I will thank you for them tasty Bezos nickels if you buy one.
The second option is to have them look at using nicely written GUI tools to do their Git management.
I am a fan of the second option. I have used Sourcetree to great effect with new engineers, technical artists, and other team members to solve Git issues. Sourcetree is reasonably good and it is free. It is also a Gateway product to Bitbucket and Atlassian products. Consider yourself warned.
Other people use Smartgit, a fine alternative. It just costs the monies.
Visual tools like this are a reasonably good and fast way to teach new hires to triage repo issues effectively.
In the long term, is this a skill you will need to be a successful senior software engineer or architect? Possibly. Some people get quite good at using visual tools to manage the repos for their whole organization. Some people need to go to the command line, possibly out of personal choice.
The point I want to make is that this is not an urgent skill to learn right out of the gate. If you do need it, maybe, in several years, you will have time to learn it. There are enough important things to learn as a freshly employed software engineer that this one is worth punting down the field a little.
Thank you for coming to my TED talk!
