Hmm, not a bad list of five
Personally, given my experience of academia, my number 1 would be writing readable code.
Design Patterns is something I've become very very wary of. Far too often it's learn the patterns by rote and then use them in some sort of shake and bake strategy. Architectural cookie cutting as it were.
As well as learning the basic patterns, as least as much emphasis should be on recognition.
If you look at your list and my addition of readable code, and our discipline in he business world, there's an over-arching concept all the way through them, and it's this that's missing from academia.
Change is a given.
Today's question isn't yesterday's, or tomorrows. It has changed, it will change. Anything that makes change harder to manage or implement is bad.
There is a similar lack in the business based approach to software design as well.
It's subtle but Change Management and Change Control are not the same thing.
One copes by enabling, the other generally by denying.
