I'd suggest adding software testing and QA, particularly with the rise in AI and agentic coding requiring better testing skills, but that would deserve an entire separate course all of its own.
The Missing Semester of Your CS Education – Revised for 2026
51–60 of 139 posts
Re: The Missing Semester of Your CS Education – Revised for 2026
#52Honestly shocked ethics aren't discussed more as the "missing semester," too many devs are completely fine working for truly evil companies.
Especially considering proper licensed engineers often due have to take engineering ethics courses as part of their program.
Re: The Missing Semester of Your CS Education – Revised for 2026
#53Earlier quoted context omitted.
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?
Most people treat higher education as a pass to good paying job and I think it's unrealistic to think otherwise.
> Most people treat higher education as a pass to good paying job and I think it's unrealistic to think otherwise.
Yes, and that's a problem. If the advent of coding agents leads to people that are only in it for the money staying away from higher education - good. Those people are the reason why higher education turned to shit anyway and maybe it will be a nice change when people go into higher ed out of curiosity and not because they smell money.
Re: The Missing Semester of Your CS Education – Revised for 2026
#54Great 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"` an…
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 your…
> If most people are not using a tool properly, it is not their fault; it is the tool's fault.
Replace tool with one of piano|guitar|etc and see your logic fall apart. Software tools like any other have a manual and require effort and time to learn.
Re: The Missing Semester of Your CS Education – Revised for 2026
#55Earlier quoted context omitted.
Git is badly designed, but your rule is also bad. 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 somebody can get a lot done with a tool, then it's a good tool. Does "getting it done with pliers" make them a good wrench?
If somebody has some technique that screw things with pliers that are much faster and reliable than a wrench, you not being able to replicate it doesn't invalidate that person's usage.
Now, until such a person exists, ridiculous counterexamples are still ridiculous.
Re: The Missing Semester of Your CS Education – Revised for 2026
#56Great 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"` an…
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).
What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.
Re: The Missing Semester of Your CS Education – Revised for 2026
#57Great 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"` an…
"Almost no CS program teaches proper version control"
This is just false. In the UK, you would learn version control in the first week, then submit all work through version control for the whole course.
I find it hard to believe that Americans just don't use version control at school. It doesn't make any sense.
Re: The Missing Semester of Your CS Education – Revised for 2026
#58Great 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"` an…
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…
>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"
I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use.
A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
Re: The Missing Semester of Your CS Education – Revised for 2026
#59Earlier quoted context omitted.
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 your…
> If most people are not using a tool properly, it is not their fault; it is the tool's fault. Replace tool with one of piano|guitar|etc and see your logic fall apart. Software tools like any other have a manual and require effort and time to learn.
modern instruments are actually improved designs of older instruments which were just that: badly-designed & hard to use
Re: The Missing Semester of Your CS Education – Revised for 2026
#60Earlier quoted context omitted.
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 your…
Right on. Git is good at what it does, but its CLI is too low-level. It feels more like an assembly language than an end-user language, and a haphazard one at that. There are wrappers that make it much more approachable. IntelliJ’s Git frontend, for example, is pretty nice.
Git is a cli software. If you find yourself repeating a set of commands, what you should do is abstract it using an alias or a script. And you will have you own nice interface.