5. People Interaction
Yup. People skills matter. Programming seems like a great job for asocial people. It's actually the shittiest job imaginable if you have weak people skills, because you get staffed with the crappy maintenance projects that have no upside. (Programming probably has the most variance of any job category; the best projects are a lot of fun, and the worst grind your mind to sawdust and produce nothing.) If no one likes you, no one trusts you, and you'll never get projects where your technical intelligence really matters.
I understand the hate that technical people have for "office politics" but the only approach that works is to adapt. To figure that shit out so you can laugh (silently) at the suckers who don't get it instead of being one of them.
4. Writing Matters
Yes, yes, yes. It really does. My personal opinion is that you're no better a programmer than you are a teacher. We're drowning in technical assets. Most assets are of abysmal quality because the people generating them never took the time to communicate what was being done, how and why, but too little code is not a problem for the software world. We have too much. Too much code and far too much unmanaged complexity.
People who are unwilling or incapable of teaching others how to use the technical assets they've created should not be programmers IMO. That's your job. To solve problems and to teach people how to use those solutions.
3. Software is Never Done
Further reading: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...
Sadly, this is more a consequence of big-program enterprise methodologies. In small-program shops, software can be "done". It can actually be finished. The overarching project continues to expand, but this shouldn't be accomplished by shoving more kLoC into a working program and diverting it away from the original vision.
Large, ambitious projects should be structured as systems and given the respect that a system deserves (such as attention to fault tolerance and communication protocol). There's no excuse for most of these large single-program monoliths that ultimately (Conway's Law) become artifacts of parochial corporate politics rather than elegant, minimalistically simple solutions to mathematical and computational problems.
I'm a fan of the Unix philosophy and small-program methodology. Solve a problem. Do it well. Move on. Come back to it if you need to solve another problem. Not unless. I don't like the big-program methodology, under the guise of "object-oriented programming", that seems to have won in the contemporary Java-shop culture.
2. Few Clever Algorithms
Sad but true. The managers' job is to take cleverness out of our jobs, not because they're assholes or don't trust us (usually not the case) but because if our work relied on our cleverness or creativity, then they wouldn't be doing their jobs, which is to deliver business value reliably. We tend to like the high-expectancy, high-variance, fun and creative work, but there isn't much tolerance for this in the industrial world, which would rather produce the low-expectancy "sure thing". The problem is that Big Software actually isn't "reliable"; it's just that the legacy costs are paid out later after all the decision-makers have had a couple of promotions and are far away from the wreckage.
1. Complexity from Aggregation
Yes. This is exactly why I hate big-program methodologies. They inject so much unplanned, unexpected complexity into everything. People should aim for 500 lines of really clean, usable code instead of 20,000 lines of garbage that barely solves the problem and for which no one really knows what it does.