"textbook perfect code" ...
... is rarely found in textbooks, from my experience.
Why is that so ? Because textbook code is, by virtue of its objective - teaching coding - too simple and too small for the issues associated with paid-for / commercial software development to pop up. It avoids covering issues encountered in developing software not strictly associated with the technical act of coding itself.
Amongst those, in no particular order:
Teamwork - the absolute necessity to either work with other programmers or work with project managers, business requirements, your boss and her/his budget - is usually absent from textbooks. If no framework for this exists in the software project at all, it'll end up with interesting "warts" - think of massive code diffs in series of subsequent commits for no other reason than two developers having set their IDE's to "auto-indent" with different rules. Or imagine the odd little key component in an otherwise-pure-Java project pulling in Jython plus a bunch of 50 python modules including a few binary components written in C++, because one developer got away with writing a 50-line piece in Python using those modules since that was so much simpler and faster than the 500 lines it'd have taken in Java. Think about the "write to spec" warts that occur because specs and tests are done first for "validate known-to-be-valid input only", the code is written that way, and half a year someone using it is terribly surprised about the security holes blown into it by obviously-invalid input ... never spec'ed, never tested, never requested ... and no two-way communication anywhere between requirements mgmt, technical architects, project managers, testers and coders. And where in a textbook have you ever seen an example covered so big that you _couldn't_ implement it on your own in a month (Knuth's level 3.5+ exercises notwithstanding) ?
Complexity - textbooks often are extremely brief on this one, and C.Hoare's "The Emperor's old clothes" is quoted nowhere near as often as it should be. Abstraction, Encapsulation, Specialization, Generalization and other "layering" patterns are often covered extensively from the "how to do it" perspective but warnings about the dangers of extensive layering, respectively guidelines on "good usage" (do you really need to subclass if all you want is to have an object instance that differs from the default-constructed one in a single property ?), or, to put it differently, "when not to use it", are often absent. The coverage of interfacing with pre-existing libraries is often scant. As a consequence, have bunch of new interface layers here, a new generalization there counteracted by an additional specialization elsewhere, and have multiple sequences of conversions resulting a chinese whisper chain of data transfers. Every layer on its own might be a great, well-written, perfectly documented and admired piece of code ... but the combination screams at you just as much as the result on the floor of a night drinking great wine after a michelin-starred ten course meal.
Libraries - face it, you're not going to write everything from scratch. But which Java programmer knows even a third of the Java 7 classes by name ? Which C++ programmer can use a third of Boost without the manual ? Which C/UNIX programmer knows how to use a third of Linux syscalls ? And that's only _standard_ libraries. Not to talk about the vast worlds of things like Perl or Python's component archives. Effective programming often means effective research into what existing library already-in-use-elsewhere in the project will provide the functionality that you've been considering reimplementing from scratch. Which book teaches this ?
Legacy - textbooks like to advertise the latest-and-greatest; of course it's a necessary of work life to keep your skills up, and to follow changes and enhancements in the technologies touching your area of expertise, but even more so is it important to develop "code archaeology skills". That is, go backward in time and check out what was considered good practice in 1990, what was cutting edge in 1995, which code patterns and styles were considered best in 2000. Go to the library and read a book on J2EE from 2002 as well as the newest one on Java 7, then grab a 1992 and 2012 Stroupstrup. Read and compare the Documentation/ subdirectory of the Linux kernel sources in the 2.2 and 3.4 versions. Much of this reading will trigger "duh" moments of the same sort that you'll inevitably encounter when you start to look at existing code. Nonetheless, textbooks (or, even more so, lessons/lectures) that emphasize how mistakes are identified, rectified and avoided in future projects are barely existant, else F.Brooks "mythical man month" wouldn't still be so popular more than 40 years after it was written.
Evolution - coding, and I object to adherents of "software design" here - is never intelligently designed. In the beginning, it's created, and from that point on it evolves. It grows warts, protrusions, cancers that are hindering its adaptibility to the tasks it's set to just as much as new nimble limbs and telepathic powers to help it. A wart for one usecase can be the essential sixth finger for another. Code Veterinary can be a dirty job, and the experience of humility involved with dragging the newborn out past the cr*p of the parent is not something you're prepared for by reading about it, because books don't smell. Often enough there'll be the revolting ethical challenge of becoming a Code Frankenstein as well - when you'll stich a few dead protrusions dug out of a code graveyard by someone onto the already-mistreated beast. It's like textbooks that tell you about how to have fun making babies but not about how to change their nappies or how to deal with teenagers having a fit.
All of these one can learn to live with; none of these are necessarily perpetuated ad saeculum saeculorum.
Thing is, "textbook perfect" isn't the same as "beautiful" and that isn't the same as "best for the usecase". The grimy bit about software development is that a really beautiful solution can be built from frankensteinish code, and to develop the skills as well as the thick skin to be able to do this, no textbook I've seen will prepare you for.
(I still like coding, but sometimes I think I should'be become a vet)
Biting the hand that feeds IT
