To be honest, I think a "team play" level is in there as well.
Working on your own software pet project, working on an open source project with other developers, and working in a corporate software environment are very different experiences. The rock-star programmer cliche still exists, but I think your average run of the mill programmer's success is more determined by how well he plays with others and balances his relationship with management and other forces of evil.
Also throw in a requirements level. A lot of people struggle with this early (and sometimes late) in their careers. It sounds simple, but figuring out what the customer wants (what they _actually_ want), and what you've agreed to provide, and what the program _actually_ needs to do (all three are often exclusive concepts) is a big deal. Sometimes the customer doesn't know what they want (but won't be happy until they get it). Sometimes the customer thinks they want the wrong thing, and won't be happy if you deliver it to them. Requirements analysis is a specialization all it's own, but speaking the language is a huge asset if you go into "big software" (aerospace, medical, defence, etc).