Debugging. I don’t mean “how to use gdb/lldb/etc.” but the general art of figuring what is going wrong and how to solve it. Especially with respect to race conditions.
Quality control.
Especially in a professional setting "If you've clicked around a bunch and it still works, it's fine" is not a sufficient way to test code, which doesn't even have tests.
The same goes for code, if nobody looked over it, it's basically experimental.
I'm going to be a dipshit contrarian and say "everyone has 90 things they'd like added to the *core* of CS and if we listen to a hundredth of the proposals the degree would be unworkably huge".
Regular expressions, but when you say "not enough people seem to know" I'm thinking pretty much any researchers who use textual databases and computers as part of their work.
Event loops are used everywhere but there are few formal introductions. And most c++ async presentations never demos how to work with one. Ville made a presentation on sender receiver in qt at least. But it's only at 300 views on YT.
Comments
Especially in a professional setting "If you've clicked around a bunch and it still works, it's fine" is not a sufficient way to test code, which doesn't even have tests.
The same goes for code, if nobody looked over it, it's basically experimental.
I'm going to be a dipshit contrarian and say "everyone has 90 things they'd like added to the *core* of CS and if we listen to a hundredth of the proposals the degree would be unworkably huge".
Some parts could clearly be taught better, ofc.
Floating point is almost never correct, but it's as close as you can get in a finite representation.
Row major vs collumn major isn't just an aesthetic choice, it has massive implications across your applications
Tabs > spaces
linked lists/recursions are mostly a waste of time, until suddenly there's no way out of it
It's often easier to recompute something than to wait for it to arrive from disk/storage