Parenthetically, I might add that, when I took undergrad courses on compiler design and operating system design, it was quite clear that the main topic of study was “techniques for the systematic design of non-trivial software artefacts”. The specific applications were merely example “carriers” for technique, like études for music students. I find it hard to see how to transmit this ability to students without using detailed specific examples. (However, this was in the mid-eighties… evidently things have changed in CS education since then.)

Most of the software that I have been involved with here works almost all the time, is used (a lot) by many people, and improves the quality of their lives, at least from there own perspective. The characteristic of this software that distinguishes it from Dijkstra’s products is that the software is created, enhanced and maintained by teams of people. Some of them write lines of code, while others maintain wikis, manage bug-tracking databases, run tests, design interfaces and so on. Certainly that subset who actually churn out lines of C needed a lot of training. The courses we taught as part of our undergradaute program were fine for this training. On the other hand, I would say that the grades we gave were a very poor predictor of programmer quality. The only exception is that those few people who consistently attained As in evry course they ever took were likely to be successful programmers.

But there is a lot more to a successful software product than lines of code. And I see little evidence that these factors can be taught at a University or any other institute. Rather, they are a pool of much individual experience and talent.