I agree with many of the things she presents, but I’d also like to point out what other thing computer science students don’t learn in school that’s important, but often overlooked: Domain knowledge.
It’s not the same as listening to your customer, because your customer and/or user has one perspective on domain knowledge, and it might not be deep nor broad. The customer might have just started the job last week and is trying to tell you how to write software to assist him with a job that he doesn’t know how to do himself.
Can you write computer software without domain knowledge? Yes. Heck, my whole schtick is that I don’t need a lot of domain knowledge when testing an application because software fails in predictable places because it’s software, irrespective of industry.
But I do pick up some domain knowledge from a little research to help supplement my understanding of how the user will use the software and to try to predict some patterns of behavior that real users will attempt when confronted with this strange piece of programming during the workday.
I’m not keeping it very secret, am I? Because I want the developers to pay attention to it, too. And project managers. And client engagement vice presidents. Try to glean a little about the problems the software is trying to solve instead of just solutions presented to you to code. Because where your assumptions and their assumptions differ, danger lies.