Oh very very true. They start becoming more useful for group projects.
We taught what what needed, but students (in learning to be self resourceful) will often google things, try tutorials, read on stack overflow, etc... and sometimes get themselves turned around. Git is a big piece of software to understand completely I guess, and even if you only show someone a small bit, they are likely to get confused at some point when they are trying to go deeper.
As an interesting and certainly unintentional thing, we discovered at one point that the words git uses to describe commands are often daunting to students. Commit and blame in particular. At one point we found many students weren't making enough commits, or sometimes none and were reluctant to turn in their homework. Through meeting in some 1:1's, we discovered that some of the students felt that if their work wasn't perfect, they didn't want to "commit" to it and that the word held too much power seemingly- they thought maybe there was something deeper to it.
This probably sounds silly, but when teaching people who are new to programming there are all sorts of preconceived notions that can really hold people back, and this was one of them.
That doesn't sound silly at all. In fact what sounds silly is taking techniques designed for large professional software projects and applying them to things that aren't anything of the sort.
It reminds me of the problem with teaching Java as a first language – you must start with `public class Foo` in a file called `Foo.java`, containing a method declared as `public static void main(String[] args)`, which means you must either explain tons of concepts (what "class" means, what "public" means, what "static" means, etc.) long before you can motivate any of them, which makes everything seem complicated and hard, or hand-wave them away as incantations that you'll learn about in due time, which makes programming seem magical and mysterious.
None of which is to say that Java isn't a great language for doing professional work, just that it isn't great to start with. Git seems quite similar to me.
On the other hand, I get that it is valuable to teach techniques that will actually be useful to students in their professional life, even if they are clumsy in a non-professional setting. There's a real tension here.
Apropos of nothing else I wrote: I've always enjoyed seeing people alias `blame` as `praise` or something similarly positive (although `annotate` is the built-in neutral option, which is also pretty good).
You're 100% right across the board. The tension between 'real job skills' and 'things that are good for the sake of learning' are very difficult to balance in a program where an overwhelming majority of students are looking for jobs immediately after the program. This was something I thought about every single day.
Yeah, it makes me feel like a curmudgeon, or like a job-protectionist, but I think it's a shame that so much of the "learn to code" movement is focused on training for professional software jobs, rather than on learning how programming works so that it can be used as a base tool, more akin to writing or arithmetic. Teaching all these professional techniques up front seems to me like training people for statistics or accounting jobs before they've taken middle school math.
That focus comes largely from the students. They want/need a job asap. Unlike a college freshman who has 4+ years to learn, and has set aside that space in their lives, it isn't uncommon for a student leaving these programs to be down to their last 30-60 days of savings after this program and need a job immediately.
Anything you teach them that is simply theoretical, you have to fight them to get them interested in. This isn't to say I didn't do it. I taught students basic C, binary conversion, arduino, basic electronics, game programming, noSQL databases, computer science, etc... in various classes. But there was always a group of students who wanted nothing outside of what they would need on the job, immediately.
We taught what what needed, but students (in learning to be self resourceful) will often google things, try tutorials, read on stack overflow, etc... and sometimes get themselves turned around. Git is a big piece of software to understand completely I guess, and even if you only show someone a small bit, they are likely to get confused at some point when they are trying to go deeper.
As an interesting and certainly unintentional thing, we discovered at one point that the words git uses to describe commands are often daunting to students. Commit and blame in particular. At one point we found many students weren't making enough commits, or sometimes none and were reluctant to turn in their homework. Through meeting in some 1:1's, we discovered that some of the students felt that if their work wasn't perfect, they didn't want to "commit" to it and that the word held too much power seemingly- they thought maybe there was something deeper to it.
This probably sounds silly, but when teaching people who are new to programming there are all sorts of preconceived notions that can really hold people back, and this was one of them.