I work at an engineering company that does a mix of software development (done by software engineers) and research/prototyping work (done by non software engineers -- we call them systems engineers). It is pretty common for these two groups to interact as some prototypes turn into deliverable systems.
Most of our software engineers use Git backed by a local Gitlab server.
However most code produced by systems engineers (Electrical Engineering, Mathematics, or Physics backgrounds) is not version controlled which causes a lot of headaches for me (and probably them too, even if they don't realize it).
I have taken it on myself to put together an introduction to version control with Git during an upcoming lunch and learn session.
My question is how do I best motivate the concept of version control for these non software engineers? What are the most obvious advantages that would convince them that learning Git is worthwhile when working with code collaboratively?
Top comments (6)
They probably already have some problems or pain points that git would solve for them. I would encourage you to quickly interview them and ask for their pain points.
I would expect these to be:
For the presentation, I would show them one of your projects on Gitlab. Show them how it looks, and how it visualizes changes, histories, and issues.
Then I would let them maybe download a very simple example project, let them make changes, commit them, and try it out in a hands-on matter.
There is no better way to learn than seeing something visually and trying it out yourself.
Yeah, git was designed to solve the exact problems they are probably facing. I agree with this approach and the others mentioned in the thread.
Thank you for the input! I like the idea of getting their hands dirty, I think that will help them get a feel for how it works. Also focusing on their issues will be a great angle to the presentation.
Your post was in Jan, so how did it go?
Teresa listed the key point. The next step would be to question if they're real... how do you know those are real? Have you actually seen examples where those non-engineers wanted to, say, undo changes, or have different people work on the same thing, and so on?
Sometimes even providing examples may not be enough, because those people have probably figured out a way to work around those problems. The question then becomes: why is version control a better solution than whatever else they currently use to manage that issue?
Ask them about their pain points when working collaboratively, especially when sharing code or text that incrementally changes. I'm almost certain that while sharing their experiences they'll come up with a reason on their own.
I've introduced the concept before as a security feature first. Because git will keep a history of your project, you can always revert, even if you mess up.
Try to keep the workshop itself pretty easy. Start off with how to use git for a single user (git add, commit, push). Then talk about how git handles multiple users (branches, merges). This would also be a good chance to ingrain some best practices into them, such as branches named after issue numbers. I would finally finish off with the fork/pull request workflow. (But only if that's something that could be common in your codebase.)
I'd be happy to talk to you more about this or share some ideas for the presentation if you want to get in contact with me directly!
Thanks for the reply! I'll definitely talk to the engineers and try to show how Git can solve their problems.