You seem to be starting too abstract. Analogs help and so does starting from a point where the students can experiment and get feedback on their mistakes from their own code, not from abstract concepts. These are lessons I learned when we designed and taught a 8 week coding course for Graduate students who had never touched code before. Feedback for us as teachers was instant. (Analogs. Analogs. Analogs.) Imagine learning about structural engineering - would you rather start by prototyping bridges with different materials and seeing how different structural designs hold up better, or would you prefer to be lectured about conflicting philosophies on proper road arrangement, materials and tensile strength first.
Analog example I used (explain like they're five): Front end, backend, middleware, databases are like a Macy's animated window display. HTML is choice and order of the mannequins in the window. CSS are the colors and positioning. Javascript is the string that makes visible characters move. Middleware (Python, Go, Java) are the sales clerks grabbing goods from the warehouse (database), serving customers, and updating the window panes.
The course did a lecture on HTML/CSS first day, Javascript second, dug in deeper by debugging a snakes game in JS, Git on day 3 (failed for same reasons you mentioned), Ruby on Rails (immediate productivity was key), Wordpress installation, then PHP deeper dive, etc. One student said "I can't believe I paid someone $20k to build me a Wordpress site that I can now set up and customize myself after a few days."
Always start with immediate productivity for non CS students - let them sink teeth into the ideal outcome, then modify that ideal, then learn how to break and fix it, then dig deeper into why and how things work before going to best practices. If they don't know why something broke, they can always go back to figure out how it should work first.
If I was to do it again, I would teach Git with paper - have the class augment a paper tree with paper nodes or something else tangible. You can even have them write a collective story instead of code. The more abstract the topic, the simpler the analogs to get the largest subset of users to grasp it.
I have to strongly disagree with this approach to teaching git. I've been in software engineering for a decade now and have taught many entry level and experienced devs about git. If you start out with trees and other git internal concepts you're just going to lose them.
Have them create a directory, put some files in it, `git init`, add all their files and commit. Have them make some changes, add and commit again. Then ask them how their fellow devs would see their changes. This leads into the distributed nature of git and pushing to remote repos. Continue from there with more practical work and repeat.
I've seen it take devs months of working with git daily to start to understand some of the more advanced concepts so it needs to be practical up front.
If you've seen devs take months of working with git daily to start to understand some of the more advanced concepts, then maybe the problem is the current teaching method. They might learn the more advanced concepts a lot faster if they learn the concepts first.
You're assuming they want to learn. I've seen devs work with svn for years which is conceptually much simpler and they still don't know how branching and merging work, they'll do things like checkout each branch separately and copy files over rather than merge.
Edit - also a favourite interview question for anyone that claims to be familiar with svn is "what does the switch command do", a quick and easy filter to seperate those that know from those that claim to know.
I felt their attitude towards SVN was silly, so I decided I would make my change the right way. But when I went to merge, I got a bizzare error about a 'missing revprop' and it knocked the wind out of my sails.
I'm ashamed to admit it, but I ended up copying the files just like everyone else on that project for the brief stint I worked on it. :(
I disagree.The principal behind git is very simple but it can be tricky for people to understand it. Visual representation of a tool,which most of the time is only a handful of command line entries, can be useful.
Analog example I used (explain like they're five): Front end, backend, middleware, databases are like a Macy's animated window display. HTML is choice and order of the mannequins in the window. CSS are the colors and positioning. Javascript is the string that makes visible characters move. Middleware (Python, Go, Java) are the sales clerks grabbing goods from the warehouse (database), serving customers, and updating the window panes.
The course did a lecture on HTML/CSS first day, Javascript second, dug in deeper by debugging a snakes game in JS, Git on day 3 (failed for same reasons you mentioned), Ruby on Rails (immediate productivity was key), Wordpress installation, then PHP deeper dive, etc. One student said "I can't believe I paid someone $20k to build me a Wordpress site that I can now set up and customize myself after a few days."
Always start with immediate productivity for non CS students - let them sink teeth into the ideal outcome, then modify that ideal, then learn how to break and fix it, then dig deeper into why and how things work before going to best practices. If they don't know why something broke, they can always go back to figure out how it should work first.