A CS course in real life

There are two common characteristics of college industry hires:

1. Idealism. If we all use the cool object-oriented concepts I just learned and implemented my 4-week class project with, none of these bugs I've seen would exist, everything would just work.
2. Naivete. Everything I write is a plugin, from-scratch module, right?

The root cause is that school is in a bubble. At best, a student will write 10k lines in a senior project course, all from scratch, using libraries that were developed with general purpose in mind, with great documentation available. They are never forced to see how big big systems really end up being implemented; they are allowed to think that everything can be a cleanly divided observer-observable, facades and polymorphic wonderland. Big software grows, changes direction, and has deadlines which tend to prevent major re-architectures. Adding to it requires debugging, reading through code, ignoring outdated comments, and not breaking any existing functionality. These experiences are impossible to get in the sterile environment of a new project which takes a few months to implement.

(I have no idea if this already exists, and I'll skip live/google searching)

Schools should offer a software engineering course whose focus is implementing a change to an existing large codebase. Start with a basic linux distribution and invent a new UI feature. Install firefox and make it leak less memory. Explore the code, make it better, maybe even get it checked in. Get to do something people can use in a class you get credit for. Step outside the world of toy projects. Have more perspective when you interview. Have interesting questions to ask. Get a totally different experience.

Even if a student is going to grad school, they will likely need similar skills. They have to work with existing projects, modify them to perform new experiments, fix problems, etc. Most have no idea how to approach this beast and burn a lot of time getting the hang of it.

What is the value of good design?

Writing code is not just engineering, it's also art. From early in our education we're taught about flexible and extensible design, patterns, good coding practice, imagining how our simple little codebase will one day become a dominant application, or perhaps a giraffe, and how we should be ready for the changes leading to that end. We strive for the perfect expression of this planning in code.

And yet, industrial software is riddled with crap. Code that handles the 3 cases we happened to care about. Code that makes special exceptions for particular fringe cases. Code that is so hard to follow that no one dares touch it for fear of completely breaking it. Were the authors of this code bad at what they do? Sometimes, yes. But, more fundamentally ....

I can't sell well-architected code for more money, the user just cares that their scenario works. It [usually] takes more thought (and time and cost) to write good code. The extensibility gained may never be used. The edge cases the bad code misses may not even be exposable. And yet, and yet, I know that writing the code well will benefit me later, will allow me to plug in cool features easily, will minimize bugs.

What's the right balance?

I think this could be the basis of a new religion.