We’ve updated the course based on our personal experiences as well as major changes in the field (e.g., the proliferation of AI-powered developer tools) over the past several years. The 2026 course includes revised versions of four lectures from the previous course, and it adds five entirely new lectures:
- Development Environment and Tools
- Packaging and Shipping Code
- Agentic Coding
- Beyond the Code (soft skills)
- Code Quality
We’d love to hear any feedback from the HN community to improve the current or future iterations of the course. In particular, we’re curious to hear the community’s take on our inclusion of AI-related topics (e.g., dedicating an entire class to the topic of agentic coding; though we tried to counterbalance it with plenty of disclaimers, and a dedicated section on AI etiquette in Beyond the Code).
--Anish, Jon, and Jose
That’s why it’s important to write comments as if to your grandparents. For the feelings of accountability that it engenders.
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.
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.
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.
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...
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.
I know that that is the old syntax but holy hell, that's insane. Why couldn't it always have been git branch --create|delete|delete-remote? It could have but Linus doesn't care about your feelings or small brain. :)
There are wrappers that make it much more approachable. IntelliJ’s Git frontend, for example, is pretty nice.
Instead, the complexity of your mental model should scale with the complexity of the thing you’re trying to do. Writing a “hello world” in Java does not require a mental model of all of the powerful things Java can do.
We want CS 101 students to use version control but for a lot of them it will also be their first time using a CLI and a programming and also the underlying CS concept.
For professional work, people can and do learn complex interfaces and jargon, if it is advantageous.
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 believe git is architecturally sound and well designed, but the command line syntax can be overly confusing and opaque.
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.
A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.
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'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.
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.
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...
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.
Exactly. But that is sadly the state of things.
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.
These would have been very useful to me back when I was in the university.
Later I got my own IBM 386 and installed Linux on it and started to program in Perl …
I am a big fan of Jon’s YouTube videos on Rust and I started to use Rust in non conventional ways.
I am going to follow this lecture series and “port” them to rustdoc and see how it goes.
Another rabbit hole to fall down, it is going to be fun.
101
- Bash for Beginners (https://tldp.org/LDP/Bash-Beginners-Guide/html/)
- Bash Tutorial (https://www.w3schools.com/bash/)
201
- Bash Programming (https://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html)
- Advanced Bash Scripting Guide (https://tldp.org/LDP/abs/html/)
301
- The Bash Manual (https://www.gnu.org/software/bash/manual/bash.html) (https://man7.org/linux/man-pages/man1/bash.1.html)
- ShellCheck (https://www.shellcheck.net/)
for i in $(ls /bin/* /usr/bin/* /sbin/* /usr/sbin/* | sed -E 's?.*/??g' | sort -u) ; do
echo "command: $i"
whatis "$(basename "$i")" | cat
echo ""
done | tee command-descriptions.log
find /bin/ /usr/bin/ /sbin/ /usr/sbin/ -executable -type f -exec whatis "$(basename {})" \; | sort -u > commands.txtI 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.
Things are so much easier. No need to a massive amount of plugins and configs, mostly works out of the box.
I'm still using bash out of habit, though. My one nod to modern tooling is using fzf for shell history search...
I agree that these shells are better than bash, etc. But some bash knowledge is probably a must, given its ubiquity. You're not always going to have the option to install fish.
(Sadly, most of my jobs, including my current one, require tcsh).
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.
Research is great, but if wre trying to train people to make real things, there's a whole different set of skills where you only need a thin vineer of CS training and a deeper understanding of software maintenance.
Thanks!
- 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.
edit: already in the "beyond the code" section... cool!
I'd ask chatgpt if the AI bubble will pop any time soon but it will probably tell me something unrelated and/or completely incorrect and I would just have to go find the answer on Google anyway. Maybe I should ask chatgpt if any of these AI companies will ever manage to make it out of the red.
https://missing.csail.mit.edu/2026/code-quality/
Although it's specifically code quality, not software quality, I feel so much is missing. Of course there is no space to explain it in detail, but they could at least list/mention things like complexity, maintainability, modularity etc.
I do think your point is valid. The trend in the industry is putting emphasis on cosmetic qualities (format, workflow, testing), producing huge amount of metadata that consumes huge amount of human and machine energy for the peace of mind.
Complexity, maintainability, modularity have more to do with thinking about the problems at proper abstraction levels.
It seems we ended up spending more time on tools like writers spending more time on sharpening pencils or playing with fonts than writing something meaningful.
A low quality software can have beautiful code just like a low quality book has beautiful fonts.
Two decades of Git: A conversation with creator Linus Torvalds
https://www.youtube.com/watch?v=sCr_gb8rdEI
I was surprised that he only spent four months on it as a maintainer. What a great piece of work by a great software developer.
Want my feedback? Delete the AI bullshit and go back to teaching programmers how to learn and understand what they are building.
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.