Live data from Hacker News

The Missing Semester of Your CS Education – Revised for 2026

missing.csail.mit.edu

41–50 of 139 posts

Re: The Missing Semester of Your CS Education – Revised for 2026

#41
post #27

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"` 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…

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.

Re: The Missing Semester of Your CS Education – Revised for 2026

#42
post #27

Earlier 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. 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 band…

To put it into your metaphor: I am not advocating against the existence of bandsaws. I would just rather have bandsaws that do not cut off your fingers if you do not read a book about them first and make it difficult to sew the fingers back on, while requiring arcane incantations to do their work.

There are of course power tools with obnoxious protections that make them difficult to use, but since we are dealing with software here, we are not bound by the laws of physics. I believe that we can create a better tool that is both powerful and easy to use.

Re: The Missing Semester of Your CS Education – Revised for 2026

#43
post #24

Earlier quoted context omitted.

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.

> majority (statistically) work on yet another SaaS that is a CRUD that has been solved millions of times already. Not necessarily going to be true by the time current first year students graduate, given that solved problems are most exposed to AI acceleration.

Why wound it change?

Re: The Missing Semester of Your CS Education – Revised for 2026

#44
post #24

Earlier quoted context omitted.

> majority (statistically) work on yet another SaaS that is a CRUD that has been solved millions of times already. Not necessarily going to be true by the time current first year students graduate, given that solved problems are most exposed to AI acceleration.

Why wound it change?

Because the companies doing these will either not employ as many people as they do now or will cease to exist altogether since their customers will not need their services

Re: The Missing Semester of Your CS Education – Revised for 2026

#46
post #27

Earlier 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…

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?

Re: The Missing Semester of Your CS Education – Revised for 2026

#47
post #27

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"` 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.

I would say that is a reasonable criticism of git ... but I've seen the same thing in svn, perforce, cvs, and rcs. Different variations of the same issue of people not caring about the version history.

Since it's been a problem since the dawn of version control, it is either something that is part of all version control being a tool's fault that has been carried with it since doing ci, or it is something that people aren't caring about.

I feel this is more akin to a lack of comments in code and poor style choices and blaming the text editor for not making it easier to comment code.

Re: The Missing Semester of Your CS Education – Revised for 2026

#48

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"` an…

Your workflow makes sense for FOSS projects, where the commit is the unit of work. In my experience, on most professional teams, the PR is the unit of work. PRs trigger CI/CD pipelines. PRs map to tickets. The meaningful commit goes with the squash merge to the shared dev/main branch.

There are cases where I've staged commits this way for a PR, to make it more reviewable. I'd usually rather split them off into separate PRs, but when that would create a pipeline of three MRs that are meaningless on their own, then rewriting history for a single MR makes sense. I generally consider my feature branch's commit history to be for me, not for you. Going back and rewriting history is a chore that shouldn't be necessary if I did a decent enough job with the PR description and task decomposition. Those commits are getting squashed anyway. Along with all the "fix MR comments" commits on top of it.

It wouldn't bother me to adopt your workflow if it fits your team and its tools and processes. I'd just say, consider that your way isn't the only correct way of doing things. Your preferences are valid, but so are others'. The only thing that really bothers me is absolutism. "My way or the highway."

Your writing here reminded me of a particularly unpleasant coworker I had in the past. I quickly browsed your comment history to make sure you're not him... Excessive rigidity is not an endearing quality.

All that being said, I have also been constantly annoyed by people with too many YoE who can't be bothered to spend an hour or three to learn the basics of how the Git tree is structured, and what merge vs rebase does. They rely too heavily on their GUI crutches and can't fix anything once it goes sideways. Even when you lead them to water, sending them reading material and offering to answer questions after, they refuse to drink. Willful ignorance is far more irritating than stubbornness. I don't expect them to be able to remember what bisect vs cherry-pick does. Claude will spit out the subcommands for them if they can describe what they need in English. But they can't do that if they have no understanding of the underlying data structures...

Re: The Missing Semester of Your CS Education – Revised for 2026

#50
maybe would be interesting to include a lecture on how to interact with the open source community and successfully contribute to an open source project while respecting maintainer time and energy (and other unwritten rules of (n)etiquette).

edit: already in the "beyond the code" section... cool!

Post reply on HN