Great to see a chapter on version control. It is such a shame that almost no CS program teaches proper version control. VCSs and the commit history can be such a tremendously valuable tool when used correctly.
git bisect/blame/revert/rebase/… become so much less useful when VC is treated as a chore and afterthought, and basically amounts to: “Feature is done, my work is complete, just do `git commit -am "changes"` and be done with it.”. And don’t get me started on commit messages.
It is shameful that for a large part of the industry, this is the norm. It is shameful that for a lot of professional, who call themselves software architects or reliability engineers and such fancy titles, still have essentially no idea what they are doing with git, and their response when git add/commit/push/pull don’t work is to shrug, and just delete and re-clone the repo.
Version control should be treated with care and attention to detail. It pays for itself 100 times over.
If your commit history is maintained and tells a story, it is a joy to review your PR. If you just `git commit -am "try fix"` 26 times over, and all that is left in the end is a ball of mud, it is horrible.
I have heard of each of those tools but I've never really used them for real.
Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.
This feels harsh. Engineers have an endless list of other things to learn that are arguably more important, and it isn’t always worth understanding all the weird edge cases that almost never pop up (to say nothing of Git’s hostile, labyrinthine UX that one would have to deal with).
It's absolutely worth taking the time to learn `jj`, for example, but `jj`'s ideas build on top of `git`'s ideas. If you don't know why it's important that commits reference their parents, for example, that's limiting your knowledge of how VCS works in important ways.
A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
If most people are not using a tool properly, it is not their fault; it is the tool's fault.
Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good.
- The interface is unintuitive.
- Jargon is everywhere.
- Feature discoverability is bad.
- Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it.
Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design.
I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.
If somebody can get a lot done with a tool, then it's a good tool. And a lot of tools can't both enable people to get things done and avoid being misused. They have to pick one.
> If most people are not using a tool properly, it is not their fault; it is the tool's fault.
This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training.
A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...
Very true, though it has improved a over the years. Most people haven't noticed because when git has introduced newer simpler commands it hasn't deprecated the old ones. You can now use it like this, but most people don't know it:
Instead of the old workflow using checkout with a bunch of different flags.
I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now
It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals". JIT learning is a good way to acquire capabilities with real-world application, but there is not JIT pull that forces people to learn about bisect, git objects, git logging, etc. These things can only be learnt either through setting off time to read documentation or by being taught through a course.
I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
I think most people learn git through the particular processes that are established at their workplace, as every company uses git or VCS in general differently somehow.
I'm glad to see there is a "Beyond the Code" section that discusses comments. Here's what I typically told my students in Intro to Programming"
Good comments lend insight into the code. Reading the code itself tells you the what. Comments should explain the why. Comments like "i+=1; /* Increment i */" are of little value. However comments such as "We increment i mid loop so that we can peek ahead at the next value for a possible swap" are more useful.
Use a narrative voice when writing comments, like you are explaining the code to your grandparent. This make digestion easier.
Remember, code spends most of its life, and most of its expense, in the maintenance phase. The easier you make your code to understand, the less it will cost and the longer it will live.
One of my large enterprise clients currently requires all tech staff to complete 18h (yes, eighteen hours!) of "agile training", in addition to speed-running 14 separate mandatory online courses.
This time would be much better spent watching these 9h of lectures.
I'd include sed and awk, because these tools are ubiquitous and can accomplish in a few readable lines what people write long programs to handle in other languages, seemingly because they are unaware of sed and awk, don't know how to use them, or are required for some reason to do it in the project language.
In fact, generally teaching people to select the right tool for the job is a good skill to prevent them from using golden hammers.
I don't think students in 2026 need any encouragement to use LLMs, but sure, it would be strange if the LLM companies didn't give away student plans cheaply.
I don't see the lock in effect (such as learning a language, or a complex software product) with LLMs yet that would drive student based marketing efforts.
> In particular, we’re curious to hear the community’s take on our inclusion of AI-related topics
I think this is fine and if anything you should give it more space. It doesn't replace foundational understanding, but the course is explicitly about "practical" aspects, we can assume said foundational understanding is developed in other courses.
Something like "build your own agent" would be a great intuition pump. The model is doing the heavy lifting and a basic harness is a couple hundred lines of simple code. It could fit in a single lecture and it would be very high signal in my opinion.
In some way this could be the most important course.
You don't appreciate it when you're studying, because obviously it sounds a bit soft. But when you're learning how something works, often the thing that stops you isn't the fundamentals, which you know what are, it's the little frustrations like not knowing how to commit or pull code, or not knowing how to navigate the terminal.
I would focus more on being able to follow the development of new and existing foundational technologies, rather than focusing on, say agentic coding. That one really sticks out as a trendy topic that doesn't really deserve to be included.
Not an entire semester, but I'm really glad my uni had a semester long core CS course on exactly this. Still one of the most useful courses I've ever taken, I refer my notes from that class even now.
I have a bit of unsolicited feedback (in this terms): the basic IT skills, not CS or CE, but IT, that everyone needs but most don't realize, including techies who often stay in their bubble and don't truly understand the classic desktop model despite having the skills to do so, are a bit different IMVHO:
- first of all, you need to know how to manage your own digital information. Even though it's taken for granted that a CS/CE freshman knows this, well, in my experience, that's usually not the case also for many PhD... Information management isn't just a taxonomy of files and dirs; it's also about evaluating, for example, what happens if the software you use for your notes is discontinued, or if your photo gallery disappears, and so on, and acting accordingly knowing your SPOFs and how to mitigate them;
- then you need to know how to write, in the broadest sense, which includes mathematical notation, generating graphs, "freehand" drawing like simple CAD, and formatting your work for various purposes and media, whether it's emails, theses, reports, or general messages. This is where teaching LaTeX, org-mode, R/Quarto, etc comes in. It's not "advanced" is the very basic. Before learning to program and no, Office suites are not an answer, they are monsters from a past era, made to makes untrained human with little culture to use a computer for basic stuff instead of typewriters, a student is not that;
- you need to know how to crunch numbers. Basic statistics are useful, but they're largely stuck in another era. You need to know how to do math on a computer, symbolic computation, whether it's Maxima or SymPy, doesn't really matter, and statistical processing basis. For instance, knowing Polars/Plotly/* at a minimum level are basic skills a freshman should have at a software/operational level, because they should be working in these environments from day one, given that these are the epistemological tools of the present, not paper anymore.
Then you also need to manage code, but in the broadest sense. A dSCM is also for managing your own notes and documents, not just software, and you need to know how to share these with others, whether it's Radicle or Forgejo or patches vua mail doesn't really matter, but this family of software needs to be introduced and used at least at a basic level. A DynDNS services should be also given so anyone could try to self-host the services they want.
Knowing how to communicate is an essential skill, and it's not about using Gmail or Zoom... it's about learning how to self-host basic communication services. It doesn't really matter if it's XMPP, Matrix, or Nostr, but the concept must be clear, and understanding the distributed and decentralized options we have today is vital. A student needs to learn how to stand on their own two feet, not on someone else's servers.
These are basic IT skills that aren't "advanced" at all, despite what many people think, or "sysadmin-level" and so on; they're simply what a freshman should have as someone who loves knowledge and wants to get their hands dirty.
Lol, does any of this matter anymore with AI coding? It was hard to get people to care about this sort of thing before ai coding, now its impossible. People in a few years will be coding without even knowing what unix is.
Yes. Agents are good at solving densely represented (embarrassingly solved) problems, and a surprising and disturbing number of problems we have are, at least at the decomposed level, well represented. They can even compose them in new ways. But for the same reason they would be unable to derive general relativity, they cannot use insight to reformulate problems. I base this statement on my experience trying to get them to implement Flying Edges, a parallel isosurface extraction algorithm. It’s a reformulation of marching cubes, a serial algorithm that works over voxels, that works over edges instead. If they’re not shown known good code, models will try and implement marching cubes superficially shaped like flying edges.
You are still necessary to push the frontier forward. Though, given the way some models will catch themselves making a conceptual error and correct in real time, we should be nervous.
I've had the same experience. I do a lot of automation of two engineering software packages through python and java APIs which are not terribly well documented and existing discussion of them on the greater web is practically nonexistent.
They are completely, 100% useless, no matter what I do. Add on another layer of abstraction like "give me a function to calculate <engineering value>" and they get even worse. I had a small amount of luck getting it to refactor some really terrible code I wrote while under the gun, but they made tons of errors I had to go back and fix. Luckily I had a pretty comprehensive test suite by that point and finding the mistakes wasn't too hard.
(I've tried all of the "just point them at the documentation" replies I'm sure are coming. It doesn't help)
Depends on whether one wants to be a software engineer or a mere LLM operator.
To be fair to the parent poster, many people do seem to aspire only to be LLM operators, who will be a dime-a-dozen commodities accorded even less respect and pay than the average developer is today.
Most “cs” students don’t work in aviation, majority (statistically) work on yet another SaaS that is a CRUD that has been solved millions of times already.
If you regard a CS degree as vocational training to "code" then perhaps not - but I don't think that's really how people should be regarding a CS degree?
Computer science and coding are as related as physics and writing. If your thesis is the LLM can replace all of science then you have more faith in them than I do. If anything the LLM accelerates computer science and frees it from the perception that it is coding.
git bisect/blame/revert/rebase/… become so much less useful when VC is treated as a chore and afterthought, and basically amounts to: “Feature is done, my work is complete, just do `git commit -am "changes"` and be done with it.”. And don’t get me started on commit messages.
It is shameful that for a large part of the industry, this is the norm. It is shameful that for a lot of professional, who call themselves software architects or reliability engineers and such fancy titles, still have essentially no idea what they are doing with git, and their response when git add/commit/push/pull don’t work is to shrug, and just delete and re-clone the repo.
Version control should be treated with care and attention to detail. It pays for itself 100 times over.
If your commit history is maintained and tells a story, it is a joy to review your PR. If you just `git commit -am "try fix"` 26 times over, and all that is left in the end is a ball of mud, it is horrible.
Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.
Meanwhile enterprise teams are often like - who cares, let's auto-squash all commits into one.
A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good.
- The interface is unintuitive.
- Jargon is everywhere.
- Feature discoverability is bad.
- Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it.
Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design.
I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.
If somebody can get a lot done with a tool, then it's a good tool. And a lot of tools can't both enable people to get things done and avoid being misused. They have to pick one.
This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training.
A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...
git switch some-branch # edit files git restore file2 # undo changes to file2 git stage file1 git commit
Instead of the old workflow using checkout with a bunch of different flags.
I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now
I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
This time would be much better spent watching these 9h of lectures.
In fact, generally teaching people to select the right tool for the job is a good skill to prevent them from using golden hammers.
I think this is fine and if anything you should give it more space. It doesn't replace foundational understanding, but the course is explicitly about "practical" aspects, we can assume said foundational understanding is developed in other courses.
Something like "build your own agent" would be a great intuition pump. The model is doing the heavy lifting and a basic harness is a couple hundred lines of simple code. It could fit in a single lecture and it would be very high signal in my opinion.
You don't appreciate it when you're studying, because obviously it sounds a bit soft. But when you're learning how something works, often the thing that stops you isn't the fundamentals, which you know what are, it's the little frustrations like not knowing how to commit or pull code, or not knowing how to navigate the terminal.
- first of all, you need to know how to manage your own digital information. Even though it's taken for granted that a CS/CE freshman knows this, well, in my experience, that's usually not the case also for many PhD... Information management isn't just a taxonomy of files and dirs; it's also about evaluating, for example, what happens if the software you use for your notes is discontinued, or if your photo gallery disappears, and so on, and acting accordingly knowing your SPOFs and how to mitigate them;
- then you need to know how to write, in the broadest sense, which includes mathematical notation, generating graphs, "freehand" drawing like simple CAD, and formatting your work for various purposes and media, whether it's emails, theses, reports, or general messages. This is where teaching LaTeX, org-mode, R/Quarto, etc comes in. It's not "advanced" is the very basic. Before learning to program and no, Office suites are not an answer, they are monsters from a past era, made to makes untrained human with little culture to use a computer for basic stuff instead of typewriters, a student is not that;
- you need to know how to crunch numbers. Basic statistics are useful, but they're largely stuck in another era. You need to know how to do math on a computer, symbolic computation, whether it's Maxima or SymPy, doesn't really matter, and statistical processing basis. For instance, knowing Polars/Plotly/* at a minimum level are basic skills a freshman should have at a software/operational level, because they should be working in these environments from day one, given that these are the epistemological tools of the present, not paper anymore.
Then you also need to manage code, but in the broadest sense. A dSCM is also for managing your own notes and documents, not just software, and you need to know how to share these with others, whether it's Radicle or Forgejo or patches vua mail doesn't really matter, but this family of software needs to be introduced and used at least at a basic level. A DynDNS services should be also given so anyone could try to self-host the services they want.
Knowing how to communicate is an essential skill, and it's not about using Gmail or Zoom... it's about learning how to self-host basic communication services. It doesn't really matter if it's XMPP, Matrix, or Nostr, but the concept must be clear, and understanding the distributed and decentralized options we have today is vital. A student needs to learn how to stand on their own two feet, not on someone else's servers.
These are basic IT skills that aren't "advanced" at all, despite what many people think, or "sysadmin-level" and so on; they're simply what a freshman should have as someone who loves knowledge and wants to get their hands dirty.
You are still necessary to push the frontier forward. Though, given the way some models will catch themselves making a conceptual error and correct in real time, we should be nervous.
They are completely, 100% useless, no matter what I do. Add on another layer of abstraction like "give me a function to calculate <engineering value>" and they get even worse. I had a small amount of luck getting it to refactor some really terrible code I wrote while under the gun, but they made tons of errors I had to go back and fix. Luckily I had a pretty comprehensive test suite by that point and finding the mistakes wasn't too hard.
(I've tried all of the "just point them at the documentation" replies I'm sure are coming. It doesn't help)
To be fair to the parent poster, many people do seem to aspire only to be LLM operators, who will be a dime-a-dozen commodities accorded even less respect and pay than the average developer is today.
Not necessarily going to be true by the time current first year students graduate, given that solved problems are most exposed to AI acceleration.