It’s not mentioned in the article, but I also think that learning how to debug and observe the behavior of C programs is useful given the limited ability to catch issues at compile time and high likelihood of code weaknesses and errors in C. Learning not just a traditional debugger like gdb or lldb, but also at least being introduced to tools like perf, strace, and ideally more powerful things like dtrace or bpftrace would be very helpful.
In my own Masters program we had a class on software systems which heavily featured both practical coverage of C and lots about debugging and observability. One of the most aggressively _useful_ classes I’ve taken.
This sounds like a class that was sorely missing in my CS education; looking back at what I was taught versus what skills have been useful in the industry, my university courses always seemed to treat debugging, profiling, etc as irrelevant details. Taking time to improve my understanding of them has paid off quite well in my career, I think.
Years ago, I was a teaching assistant at my alma mater's introductory programming course, which taught C. While debugging was not officially part of the curriculum, we made sure to offer a written, step-by-step tutorial with screenshots for people on how to do debugging using our officially-suggested development environment (which was Borland C by the way). We would explicitly mention the importance of debugging when introducing the first homework assignment, and refer students to the tutorial.
Yes, the poor way this is taught is one of the reasons why so many people are stuck in the stone age of printf debugging.
Already in the mid-1990s it was possible to use C debuggers as poor man's REPL, have tracepoints, scripting debugging sessions, visualize data structures, track down memory leaks and corruption.
In my own Masters program we had a class on software systems which heavily featured both practical coverage of C and lots about debugging and observability. One of the most aggressively _useful_ classes I’ve taken.