[lacampbell]

Graduates from traditional programs often leave with next to no experience with testing, version control, team structure/process, newer languages, frameworks/3rd party packages, etc, and my experience in industry is that it's a role of the dice if your company, team, etc are interested in teaching you or waiting for you to learn.

It's a waste of time to teach industry tools at a university. It's much more valuable to be taught fundamentals. Know your fundamentals well and any new tech will be much easier to learn. It's long-term thinking - put in the investment to make sure you can change skillsets in the future.

All the things you mentioned tend to be ephemeral and change a lot within a few years. Look at the git monoculture that's sprung up in the last 5 years for example - 10 years ago it might have been reasonable to teach SVN.

[crusso]

And if you learned SVN, you would have had a solid base for understanding GIT. Would you expect students to learn source code control in the abstract or not at all?

You have to do programming assignments anyway. Why wouldn't you require students to learn and use the latest source code control tools while they're doing their development?

Teach students to write tests, use source code control, utilize continuous integration, etc.

Although the specific tools, languages, and approaches will evolve in the coming years - none of the above are going away soon.

[lacampbell]

Git is a very complicated piece of software. it's not intuitive, it has a famously poor CLI, and it takes time to learn.

Time spent making undergraduates use git is time that could be spent teaching them long-term, fundamental skills.

[crusso]

vi isn't very intuitive either, but there's no better way to learn something difficult than to learn it when you're young. I've been using vi professionally for 30 years thanks to my early GT classes. It's probably the single-most valuable skill that I learned there that I still use today.

[lacampbell]

I'm a vi(m) user, but I have to say - it's not a fundamental part of computing at all. It's just a very popular tool. A lot of people don't know how to use it and manage to make amazing things.

there's no better way to learn something difficult than to learn it when you're young

Hmm, define 'young'. I'm in my late 20s and I find it easier to learn new things more than ever - including things I failed to learn in my teens and early 20s. Maybe I'm just a late bloomer, and it took me a while to "learn how to learn". But maybe I'm still young in the eyes of someone who has been using vi for 30 years (:

[hackermailman]

If you know Graph theory then you know git, all that remains is just reading the man page for specific commands. Intro to Graphs/Graph Theory is generally in the curriculum at all university compsci departments

Testing ect is usually covered in all intro classes (assert libraries) or industry type testing like JUnit by a software engineering elective typically taught in Java

[lacampbell]

If you know Graph theory then you know git, all that remains is just reading the man page for specific commands.

Just because one of gits key abstractions is based on a kind of graph, I don't think it follows that knowing graph theory means you know git. I mean LISP is based on a graph structure as well but plenty of people find that confusing.

[sf_rob]

Exactly, we were checking in Java assignments in the form of a ZIP file in 2009 that we had validated with print statements. It wouldn't have been that much more work to structure the algorithm assignments in that class in a way more similar to industry workflows even if the workflows are an evolving target.