Stop Demanding "Real-world" Application in Teaching Programming

Once more, a programmer calls for teaching "computer science" through doing "working piece of software that real people use." Hacker News discussion has been a bit critical, but people still seem to think that software engineering education somehow calls for such ideas. This has sicken me so many times that I have to say it here:

For the love of all that is elegant and maintainable, stop demanding real-world application in teaching programming. And I meant all programming teaching, regardless of theory or engineering.

Let's take a step back and think about insane demand for "real-world-ness." In sports, this would be equivalent of telling a kids to compete in Wimbledon to learn tennis; or join NFL to learn football (or FIFA for the other football); or join a gang to learn martial arts. How insane are those proposals! Or, it's like learning physics by building bridges across real rivers. Or learning biology through working in the farms. Or learning chemistry through building bombs. How stupid are these? (well, beside the farm thing; tipping cows actually sounds fun).

The only good analogy for this kind of obsession would be servicing jobs, such as mechanic or electricians. However, this analogy is also extremely flawed. For one, these tasks are physical, so the same exact situation has value for students to repeat over and over; programming, once it's done once, copy-n-paste will solve all subsequent instances (and that's how most real-world work is done). Furthermore, natures of these tasks are completely different from programming; a better analogy would involve engineering a car or electricity grid; oh, so we should train engineers by making them build cars, on day one. Good luck! Lastly, even training for servicing involves "scaled-down versions of real-world projects." After all, each exercise needs one true solutions. Real-world situations rarely offer such niceties.

Therefore, please please stop obsessing over "real-world" and "real people." It's a stupid ideas, a recipe for disasters!

How, you ask?

First, because it will surely lead the students to mistake the trees for the forest. Sure, there is a lot of drudgery in real-world programming, bug fixes and all that. However, those are not, and should never be, the crux of a programmers' tasks. Instead, a programmer's true calling, and the focus of her work and attention, lies in designing and engineering, in the creation of a beautiful object that has not existed. Sure, Zeus has to arrange for Athena to be bathed and dressed and armed, but he must first will her into existence. The willing is programmers' pleasure; the bathing, dressing, and arming are its costs. Why, for the love of all goodness, do we want to torture students with drudgery?

Second, the point of education is to clarify concepts and techniques. This is precisely why school projects are not real. They are engineered to illustrate the concepts. This is why every single physics book contains phrases like "assume that there is no friction." By removing hairy details, the instructors demonstrate the concepts to their students. Once the students have understood the concepts and techniques, their applications are but trivial matters. Thus, it makes no sense to start out with hairy details. At best, it delays learning unnecessarily. At worst, it actively distracts the students and misleads them into a soul-crushing view of programming.

Lastly, starting with something so applicable runs the risk of locking students into a specific set of technologies. All projects need a few things: a programming language, a revision management system, an issue tracking system, and probably a build/test system. Each has at least several choices. Although these choices differ mostly at cosmetics level (think LISP vs Java), many of the differences have sparked religious wars over technologies. Thus, educators would do well to sidestep these thorny issues and focus on (as said above) concepts and techniques. If the students are instead thrown into the middle of a complicated situation (and all real world projects are complicated), they may over-invest in the particulars of that project. This easily leads to lock-in and closemindedness. Just look at the .NET-only or Java-only crowds. Their schools probably strive to equip them with a practical tools. These schools ends up scaring them off from other technologies.

Thus, let me repeat my plea again: please stop this stupid obsession over "real-world" in teaching programming. Please teaching programming as the wonderful, creative, and elegant art and science that it is. I committed to programming because of its beauty, because of the god-like feeling of conjuring up something out of nothing, because of the freedom and personality that it offers. I did not become a programmer to write a stupid "great bug report." I became one to avoid them. So, please, stop torturing people you are supposed to help.