Most of Your Time At Work Will Not Be Coding
…at least, not in the traditional, hands-on-keyboard sense. This is one of the things that a lot of CompSci graduates don't realize when they head out into the workforce. When I look back at all my jobs and put on my PHB's hat, I would say that I spend less than 25% of time coding. Another 25% of the time is reading code, yak-shaving or searching for solutions. The rest of the time is spent talking with people; this is a skill that neither CompSci, nor most university courses teach. These numbers always fluctuate (some days, I put my head down and code almost 100%), but it says a lot about how much "coding" I do. Also note that I wrote "talking with people", not "talking to people" because there is a big difference.
Real-Life Example
I was writing an AJAX call to display maintenance messages on a website when the corporate website is down (something like: "We are currently upgrading our systems, your experience on this may be degraded temporarily as a result"). Making the call was easy, but I couldn't get my negative tests to work. Why? People someone decided that it was okay to return HTTP 200 OK even for instances when the remote system encountered an error. In effect, it is saying "I successfully received your request, but processing your request failed in my system." I spent the next couple days (yes, days) arranging the appropriate people together to make them understand why returning success messages on errors isn't going to work.
Getting people to agree with you take negotiation skills. You can't simply send an email, make a phone call, or talk in a meeting about how someone is wrong and you are right. I've seen people do this and it goes over quite badly. So badly in fact that the developer (who was actually correct) ended up losing the argument and had to implement the incorrect design. The skill of "taking to people" is really the art of negotiation. That's the common denominator in interviews, first dates, and just about every client meeting. Very few people teach negotiation skills, outside of sales seminars, but it's a skill that pays dividends in just about every aspect of your life.
Oh, and what about getting the developers to change the return code on the AJAX call? I lost. Some battles aren't yours to win. I had to write a workaround and put another penny into the pile of technical debt.
A Word About Jargon
Once you enter the business world you are going to encounter A LOT of jargon. Learn them and their hidden meanings. Once you do, that world becomes a lot less scary and you can converse more easily with others. There's nothing wrong in asking "what does that mean?" when someone uses a piece of jargon that you've never heard of (or in a way that is new to you). As always, Google is your friend here. Here's some definitions of just a few that I used in this post.
PHB or Pointy-haired boss: He's the archetype of a manager from Dilbert comics that is non-technical, knows little about the work you do, but controls everything in your job.
Yak-shaving: In order to do A, I need to do B. But to do B, I need to do C. And so on it goes until you realize that your time estimate for doing A is now used up on other things.
Negative test: a test designed to ensure that the system handles failure appropriately. For example, does an error message display correct if I make a call to a remote server that is offline?
Technical debt: bad design decisions that you'll eventually have to fix in the future, as it makes the codebase more complex than it need be.