As someone who spends time programming, I of course find myself in conversations with people who aren’t as familiar with it. It doesn’t happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.
- I’m sure many of you have had similar experiences. So, I thought it would be interesting to ask.
Which leads to the other old saying, “computers do what you tell them to do, not what you want them to do”.
As long as you don’t let it turn around and let the computer dictate how you think.
I think it was Dijkstra that complained in one of his essays about naming uni departments “Computer Science” rather than “Comput_ing_ Science”. He said it’s a symptom of a dangerous slope where we build our work as programmers around specific computer features or even specific computers instead of using them as tools that can enable our mind to ask and verify more and more interesting questions.
The scholastic discipline deserves that kind of nuance and Dijkstra was one of the greatest.
The practical discipline requires you build your work around specific computers. Much of the hard earned domain knowledge I’ve earned as a staff software engineer would be useless if I changed the specific computer it’s built around - Android OS. An android phone has very specific APIs, code patterns and requirements. Being ARM even it’s underlying architecture is fundamentally different from the majority of computers (for now. We’ll see how much the M1 arm style arch becomes the standard for anyone other than Mac).
If you took a web dev with 10YOE and dropped them into my Android code base and said “ok, write” they should get the structure and basics but I would expect them to make mistakes common to a beginner in Android, just as if I was stuck in a web dev environment and told to write I would make mistakes common to a junior web dev.
It’s all very well and good to learn the core of CS: the structures used and why they work. Classic algorithms and when they’re appropriate. Big O and algorithmic complexity.
But work in the practical field will always require domain knowledge around specific computer features or even specific computers.
I think Dijkstra’s point was specifically about uni programs. A CS curriculum is supposed to make you train your mind for the theory of computation not for using specific computers (or specific programming languages).
Later during your career you will of course inevitably get bogged down into specific platforms, as you’ve rightly noted. And that’s normal because CS needs practical applications, we can’t all do research and “pure” science.
But I think it’s still important to keep it in mind even when you’re 10 or 20 or 30 years into your career and deeply entrenched into this and that technology. You have to always think “what am I doing this for” and “where is this piece of tech going”, because IT keeps changing and entire sections of it get discarded periodically and if you don’t ask those questions you risk getting caught in a dead-end.
He has a rant where he’s calling software engineers basically idiots who don’t know what they’re doing, saying the need for unit tests is a proof of failure. The rest of the rant is just as nonsensical, basically waving away all problems as trivial exercises left to the mentally challenged practitioner.
I have not read anything from/about him besides this piece, but he reeks of that all too common, insufferable, academic condescendance.
He does have a point about the theoretical aspect being often overlooked, but I generally don’t think his opinion on education is worth more than anyone else’s.
Article in question: https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
Sounds about right for an academic computer scientist, they are usually terrible software engineers.
At least that’s what I saw from the terrible coding practices my brother learned during his CS degree (and what I’ve seen from basically every other recent CS grad entering the workforce that didn’t do extensive side projects and self teaching) that I had to spend years unlearning him afterwards when we worked together on a startup idea writing lots of code.