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.
