[HN Gopher] The Missing Semester of Your CS Education - Revised ...
___________________________________________________________________
The Missing Semester of Your CS Education - Revised for 2026
We returned to MIT last month to teach a revised version of Missing
Semester, six years after the original debut (which has been
extensively discussed on HN, in
https://news.ycombinator.com/item?id=22226380 and
https://news.ycombinator.com/item?id=34934216). 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
Author : anishathalye
Score : 364 points
Date : 2026-02-23 16:02 UTC (1 days ago)
(HTM) web link (missing.csail.mit.edu)
(TXT) w3m dump (missing.csail.mit.edu)
| badc0ffee wrote:
| At first, the purple links had me convinced that I'd already
| clicked on them.
| Hendrikto wrote:
| 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.
| TonyStr wrote:
| 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.
| Anonyneko wrote:
| 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.
| stackghost wrote:
| >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.
| skydhash wrote:
| I see this enough that I don't bother ranting about it.
| There's the free "Pro Git" (on the git homepage) that will
| teach you most of what you"ll need in a lifetime. But you
| tell people about rebase and the reflog and their eyes glaze
| over.
| npinsker wrote:
| 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).
| gcr wrote:
| 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
| HelloNurse wrote:
| 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.
| 9dev wrote:
| That's akin to saying the most important thing for an
| author is to use a word professor correctly.
| irishcoffee wrote:
| I'd argue its like saying its important for an author to
| write an entire book using ed.
| xml wrote:
| 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.
| krupan wrote:
| 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:
|
| 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
| cameronh90 wrote:
| > 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...
| fragmede wrote:
| Then again, the number of shop teachers missing a finger
| would give anybody pause. Blame is secondary to the fact
| that you just _lost your fucking finger_. Thankfully, git
| 's sharp edges won't permanently physically maim you,
| though guts sharp edges resulting in you committing API
| keys GitHub can still hurt you, just in your wallet but at
| least you didn't lose a finger.
| WillAdams wrote:
| Contrast with:
|
| https://old.reddit.com/r/todayilearned/comments/158lp0m/c
| omm...
|
| >My high school shop teacher, before he let any of us
| near the machines or power tools, told us horror stories
| about students who lost fingers and eyes by being
| careless with them. For the entirety of that semester,
| nobody got so much as a chipped fingernail.
|
| which is a better match for my experience --- the best
| advice I ever got was from my high school shop teacher:
|
| >Before turning on the power switch, count to ten under
| your breath on all your fingers while visualizing all the
| forces involved and all the ways the operation could go
| wrong, then remind yourself that you want to be able to
| repeat that count after turning the power off.
|
| I don't think Sawstop would have a business model if all
| tablesaw injuries were tried by a jury of such shop
| teachers (heard him scream at the kid who removed a guard
| through hearing protection all the way on the other side
| of the shop around a corner while operating a lathe while
| making a heavy interrupted roughing cut w/ a chisel I
| really should have paused to sharpen --- the student was
| banned from ever entering the shop again).
| xml wrote:
| 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.
| irishcoffee wrote:
| We did! Mercurial!
| dpc050505 wrote:
| Contemporary bandsaws used by people who take workplace
| safety seriously have emergency brakes for just that reason
| (countless trained operators also lost fingers). Improving
| tools is something we've been doing since our ancestors
| first held a branch. If we satisfied ourselves with good
| enough we'd live much different lives.
| marcosdumay wrote:
| 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.
| owlstuffing wrote:
| > 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?
| marcosdumay wrote:
| 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.
| owlstuffing wrote:
| 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.
| skydhash wrote:
| 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.
| esafak wrote:
| That's a cop out. Not every CLI sucks so bad it needs a
| wrapper.
| everybodyknows wrote:
| My git experience got a lot better after I built scripts
| and customized the git config files to fully exploit:
| git-log --graph --reflog git-commit --amend
| git-cherry-pick
|
| Also, becoming fluent with creation of and switching
| between local, short-lived branches.
|
| With the above in order, I found I could subset the git
| state model:
|
| * temporary branches rather than the "stash"
|
| * commit tentative work to HEAD; amend, discard or set
| aside in a temporary branches rather than as later
| discoveries require
|
| * side-step the index/cache/staging_area for most
| operations -- transfer directly between work tree and
| HEAD commit
| shagie wrote:
| > 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.
| zer00eyz wrote:
| > problem since the dawn of version control ... a tool's
| fault ... or it is something that people aren't caring
| about.
|
| At the start of my career I ended up in a UI position. Old
| school usability on the back side of a 2 way mirror.
|
| The tool has lots of shortcomings: images, documents that
| aren't text, working with parts of repositories... These
| aren't issues faced by the kernel (where emailing patches
| is the order of the day). And these shortcomings have lead
| to other tools emerging and being popular, like
| artifactory, journaling file systems, and various DAM's.
|
| Technology on the whole keeps stacking turtles rather than
| going back to first principles and fixing core issues. Auth
| (DAP, LDAP, and every modern auth solution). Security (so
| many layers, tied back to auth). Containers and
| virtualization (as a means of installing software...).
| Versioning is just one among this number. We keep stacking
| turtles in the hope that another layer of abstraction will
| solve the problem, but we're just hiding it.
|
| One of the few places where we (as an industry) have gone
| back and "ripped off the bandaid" is Systemd... It's a vast
| improvement but I would not call it user friendly.
|
| Usability remains a red headed step child, its the last
| bastion of "wont fix: works for me" being an acceptable
| answer.
| netdevphoenix wrote:
| > 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.
| Throaway1982 wrote:
| modern instruments are actually improved designs of older
| instruments which were just that: badly-designed & hard to
| use
| tovej wrote:
| Modern instruments are still difficult to use unless you
| spend time learning how to. Just like git.
| Throaway1982 wrote:
| No they're easy to use. They're hard to master. Git is
| hard to figure out how to even upload to.
| tovej wrote:
| Git is much easier to master than the piano. I played
| piano for years and can only just play two-handed
| melodies if they aren't well-aligned.
|
| I've read a few blog posts and half a book on git, and I
| don't remember the last time I had issues with it.
|
| I also don't recall a junior ever having trouble
| uploading files with git. Unless they're in an
| interactive rebase, which wouldn't happen your first time
| trying out git.
| gglitch wrote:
| I see the point and I wouldn't want to belabor the
| metaphor, but I really feel like guitar is actually
| extremely difficult to even get started with. Between the
| awkward stretching of the fingers, how difficult/painful
| it is to hold down strings hard enough (and close enough
| to the fret) to get a clean, clear note, and how hard it
| is to hold those strings down in such a way that your
| fingers don't brush against other strings, I'd say guitar
| is crazy hard to start. I'm saying this as someone who
| has been playing and enjoying guitar for decades.
| Beginners have a rough time of it for awhile.
| mcmcmc wrote:
| [delayed]
| intended wrote:
| For UI/UX arguments on professional grade software, I present
| the Bloomberg terminal. A fever dream in shades of orange,
| black and blue.
|
| For professional work, people can and do learn complex
| interfaces and jargon, if it is advantageous.
| 1718627440 wrote:
| The hardest thing to get people to, is to think of a
| evolution of their codebase as opposed to just a single state
| with a sophisticated backup system. Writing proper commit
| messages and diffs follows from that. The actual Git commands
| are then incidentally.
| krupan wrote:
| So much this. Once you get beyond the very basics, git is a
| code editing tool as much as your editor/ide is
| sigbottle wrote:
| 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.
| oytis wrote:
| My rite of passage towards git kung-fu was committing to
| Linux kernel. It's brutal there, you have to have your
| history really clean.
|
| Meanwhile enterprise teams are often like - who cares, let's
| auto-squash all commits into one.
| sh34r wrote:
| 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...
| Stevvo wrote:
| "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.
| barnacs wrote:
| I don't think using git should necessarily be taught as a part
| of a CS education. Any self respecting engineer will be capable
| and have the curiosity and motivation to dig into it on their
| own. CS should give them the prereqs to do so, such as hashing,
| graphs, trees, etc.
| AnimalMuppet wrote:
| Version control isn't the only thing like that (though it might
| be the most important). They ought to have some familiarity
| with the idea of a bug database, for example. A requirements
| database (a software engineer could go through their entire
| career without having to ever touch one, but they should be
| familiar with the idea).
| esafak wrote:
| This might be a good time to teach jujitsu, before they're too
| invested in git.
| zerkten wrote:
| A big part of the problem is being permitted to teach this
| stuff. As a UK CS grad from the early-2000s, my observation was
| that academic staff recognized the need for these skills. They
| weren't permitted to teach it due to time available and the
| view that it wasn't academic. Thankfully, my university's CS
| department offered courses in these kinds of topics taught by
| the support staff (read: sysadmins). These courses existed to
| help other departments with skills but were open to students.
|
| 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.
| qsort wrote:
| > 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.
| ILoveHorses wrote:
| 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.
| lordnacho wrote:
| 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.
| pards wrote:
| 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.
| andersmurphy wrote:
| Is this going to be like when Sun paid universities to use/teach
| Java? Just with Anthropic and LLMs?
| dmurray wrote:
| 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.
| Cerium wrote:
| 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.
| jayd16 wrote:
| That means you need more marketing. Coke isn't popular
| because of lock in.
| blks wrote:
| Recent changes in Claude Code show the tendency of locking
| in.
| mono442 wrote:
| Is there even a point learning CS now with the rapid progress of
| agentic coding? It seems like a complete waste of money and time.
| arethuza wrote:
| 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?
| mono442 wrote:
| Most people treat higher education as a pass to good paying
| job and I think it's unrealistic to think otherwise.
| arethuza wrote:
| Is that "pass" still worth it though? NB I have no idea -
| ~40 years since I did a CS degree!
| plastic-enjoyer wrote:
| > 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.
| zelphirkalt wrote:
| On one hand I agree, since I see way too many
| dispassionate people working in this profession, on the
| other hand this requires businesses to understand, that a
| software developer is more than a code monkey. I am not
| sure we are heading there. Currently, it seems more like
| many non-IT people think that their monkey imitations are
| the same that software developers have been doing for
| years and that they now don't need any good developers
| any longer. For some CRUD businesses this might even be
| true.
| ModernMech wrote:
| 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.
| projektfu wrote:
| Is there any point in teaching aviation engineering when an LLM
| could probably generate something that looks reasonable from a
| corpus existing work?
| wiseowise wrote:
| 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.
| oytis wrote:
| > 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.
| wiseowise wrote:
| Why wound it change?
| oytis wrote:
| 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
| srpablo wrote:
| I think it's a bit like `rails generate`, where it
| massively speeds up getting a CRUD webapp 0 to 1, but
| once you get to GitHub or Shopify size, you need a lot
| more than that to add a new data model.
|
| AIs are pushing many things forward, but due to training
| sets and context windows, I think meaningfully adding to
| actually valuable apps, at least as we currently write
| them (the kind with many DBs/caches/message queues,
| services) will take a fair bit longer.
| zjp wrote:
| 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.
| operation_moose wrote:
| 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)
| ThrowawayR2 wrote:
| 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.
| kkfx wrote:
| 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.
| projektfu wrote:
| 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.
| NoNameHaveI wrote:
| 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.
| dec0dedab0de wrote:
| I prefer comments like "I'm sorry about this, I know it's ugly
| but I'm in a rush and it's the quickest way to get it working"
| stronglikedan wrote:
| As long as there's a "TODO" tag in the comment to easily
| search for, then I prefer those comments as well.
| tovej wrote:
| 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.
| nautilus12 wrote:
| 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.
| ludicrousdispla wrote:
| Personal hygiene is worth a mention.
| shimman wrote:
| Honestly shocked ethics aren't discussed more as the "missing
| semester," too many devs are completely fine working for truly
| evil companies.
| wps wrote:
| Especially considering proper licensed engineers often due have
| to take engineering ethics courses as part of their program.
| bruce343434 wrote:
| Is a moral compass something you can teach someone in a short
| course if they have been lacking it so far in their entire
| lives?
| anishathalye wrote:
| MIT already has an excellent class on Ethics for Engineers:
| https://e4e.mit.edu/
| shimman wrote:
| Clearly failing the students seeing how they still work for
| evil companies.
| Arun2009 wrote:
| Just wondering - do you include information on interviewing,
| salary negotiation, communication with management, leading teams,
| and maybe topics on career progression?
|
| These would have been very useful to me back when I was in the
| university.
| Jonhoo wrote:
| Not at the moment, but it's a good idea for the next iteration
| of the class!
| a-dub wrote:
| 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!
| ThrowawayR2 wrote:
| 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.
| tovej wrote:
| I would hope any CS/Software engineering education would
| already include QA. Both a testing course and a general
| software quality course.
| DGAP wrote:
| This is great but irrelevant in the age of ai.
| snowhale wrote:
| the fundamentals in here (shell, git, debugging, profiling) are
| more relevant with AI, not less -- AI autocomplete is pretty
| bad at suggesting the right git bisect or strace invocation if
| you can't tell it what to look for. knowing what tools exist is
| still on you.
| 0xbadcafebee wrote:
| If you want to master the shell (it will save years of your
| life), follow these guides. I _highly recommend_ reading the
| entire BASH manual, it will answer every question you 'll ever
| have, or at least give you a hint about it, as well as expose you
| to all the hidden knowledge (some call it "gotchas") you'll wish
| you knew later. 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/)
|
| To find every Unix-y program and get a 1-line description of it
| (and referenced programs/functions), run: 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
|
| View 'command-descriptions.log' with _less command-
| descriptions.log_ , use arrow-keys and page up/down to navigate,
| and type 'q' to exit. To find out more about a program like
| _df(1)_ , run _man 1 df_.
| e12e wrote:
| I think looking at some of the documentation for oils (nee oil
| sh) and ysh - as well as [looking at using] these two projects
| [in place of bash] - is also a good idea today:
|
| https://oils.pub/
| zahlman wrote:
| I think I would do it more like: find /bin/
| /usr/bin/ /sbin/ /usr/sbin/ -executable -type f -exec whatis
| "$(basename {})" \; | sort -u > commands.txt
| stevetron wrote:
| How about including a course in touch-typing that emphasizes the
| computer keyboard rather than the typewrite keyboard?
| caillou wrote:
| In terms of shell, I moved to the fish shell 5 years ago.
|
| Things are so much easier. No need to a massive amount of plugins
| and configs, mostly works out of the box.
| BeetleB wrote:
| xonsh user for 8 years here :-)
|
| 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).
| e12e wrote:
| Fish is probably a good idea for an interactive shell. Osh/ysh
| might be a good idea for scripting:
|
| https://oils.pub/
|
| I'm still using bash out of habit, though. My one nod to modern
| tooling is using fzf for shell history search...
| ghc wrote:
| That's actually brilliant! Most of my classes only taught what
| tools were needed to accomplish coursework, not generally useful
| tools. Even our OS class focused on the workings of the kernel,
| not the Unix philosophy and how it influenced what tools were
| included, and how to use them. Then again, 20 years ago the year
| of the linux desktop was much farther away than it is today...
| cratermoon wrote:
| I didn't even have to look to know that they'd added a section on
| AI sloperators.
|
| Want my feedback? Delete the AI bullshit and go back to teaching
| programmers how to learn and understand what they are building.
| ontouchstart wrote:
| When I was a Physics Ph.D. student in NYU in the late nineties, I
| took a course called UNIX tools in the CS department. It was a
| hands on course where the instructor did live REPL in the
| terminal and we watched him showing us all the tricks. I got
| hooked with UNIX since then. Got myself a dialup terminal in my
| tiny apartment in east village and dial in to the workstation on
| campus. The latency is so bad that I can't only see the feedback
| after a few keystrokes. That was when I trained my vi muscle
| memory. (EMacs was out of the question.)
|
| 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.
|
| https://ontouchstart.github.io/rabbit-holes/missing/
| __mharrison__ wrote:
| Huge blindspot, especially with all the AI coding going on now...
| Testing
| whateveracct wrote:
| Purdue CompE has long had a 1 credit hour course that is just
| this. Lots of bash and git and then a little Python and Tkinter
| at the end. Other courses them assumed we had this knowledge -
| the 300-level ASIC class had us submit assignments by pushing to
| a remote, for instance. Definitely one of the most useful credit
| hours I had.
| blks wrote:
| I would omit agentic "coding" all together.
| dvfjsdhgfv wrote:
| As it's hosted on CSAIL, I was somewhat disappointed by the code
| quality section:
|
| 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.
| ontouchstart wrote:
| I am not at lecture 9 yet. I would love to follow their journey
| at human pace just like I did 30 years ago.
|
| 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.
| ontouchstart wrote:
| I watched this YouTube video
|
| 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.
| vibecodingfraud wrote:
| To watch
___________________________________________________________________
(page generated 2026-02-24 23:00 UTC)