Hacker News new | ask | show | jobs
by alexeyza 3920 days ago
Thanks for sharing your experience!

In fact, the blog post doesn't include all the details, but some of the educators we interviewed were not from CS. You can see a table describing all the participants in our research paper (the link is provided at the end of the blog post).

Just like you, I believe it is completely possible to use this for non CS classes, and still gain all the benefits. However, like you said, there should be a basic understanding of Git.

1 comments

One of the hardest things to overcome (even in a programming class) is the why of doing things in Git. Many of the things we do seem arbitrary to students who are just learning. Why do you make multiple commits? Why use branches if you're the only one using it? Why make decent commit messages? I just want to turn in my work!

Many of git's capabilities seem esoteric to students, and for someone just starting indeed they are (students aren't managing a huge FOSS project, just their homework).

Maybe you don't need to do some of those things for assignments? They are all intended as aids in maintaining a long-running software project with many contributors, which is a very different use case than personal homework.
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.