> A lot of the reason people complain college is useless is that it doesn't teach you things that can only be taught with actual experience in industry.
Indeed this is true for many things such as the examples you give.
Although actually I did take a college class that did simulate the clueless pointy-haired boss.
The class was in our senior year, and we had to form small teams and design and implement a software product according to a customer's requirements.
Us undergrads did the coding, and the teams were run by graduate student "managers". The professor was the "CEO" and had final say.
The undergrads did all the work, but the graduate student said this: "My grade depends on me running the meetings. So you till me what we are meeting about, and I will then repeat your words and thus earn my grade by leading the meeting". Part of the customer requirements was that our application be distributed across a network. We were aware of CORBA, but choose to use a simpler, cheaper, more appropriate RPC system. The professor insisted that we use a full-blown Borland CORBA product, so that she would have an excuse to buy it for her research team and bill it as a classroom expense. Sounds like something right out of Dilbert if you ask me.
I still think there are a lot of useful things that could be taught in school, but aren't. What programmers need is experience writing programs. Not just theoretical knowledge of how to find the big-O of an algorithm, but how to actually design and implement a substantial amount of code. A lot of what it takes to create software is tedious, obnoxious practical stuff like figuring out compiler flags, selecting appropriate libraries, learning how to use those libraries, and figuring out unintended interactions between components that lead to bugs. Programming assignments in school are usually of the form "Here is a framework where everything is architected and coded except for one algorithm, go code that algorithm". This is fine for teaching the algorithm, but it misses out on all those other things I just mentioned.
When I was a TA for a graphics class, a big part of my job was handing out the programming assignments. I was given a fair amount of leeway, but I roughly stuck with what was done the previous year. An early assignment was to write a polygon rasterizer. We had a framework that allowed the students to just write the rasterizer and nothing else; they were given code to take input from the mouse to describe the vertices, and an output framework in the form of a setpixel function. The framework displayed the pixels as large blocks so you could see gaps between polygons that should have been adjacent (in case your implementation was flawed), and used color to indicate overlap (in case your implementation was flawed).
I thought this made the task too easy, so later when it was time to write a raytracer, I just gave them a set of requirements and suggested they use libPNG to write their output. Everybody succeeded in making a raytracer, and they learned how to think through the task of setting up the whole program. A more traditional approach would have just asked them to write ray-object intersection code, losing sight of the big picture.