Software Application Engineer at Workday
San Rafael, California
No matter how good of a coder you are, you will be working on a team. If you can't communicate to your team what your working on, when it will be done, and what you need from them, you will not go very far in the industry.
I have 2 examples for you.
Lets say you're working for a project at school. You need to make an app. You split it up into different areas. You're in charge of the web user interface (UI), with others taking the back end, the database, the iOS client, etc. You go spend the month making a beautiful UI. Now its the week that the project is due. You come together with your team to put the pieces together and, oh no! You're expecting JSON but the back end developer is sending you XML. You expected that the data sets would be small, but the database developer is sending you sets of 1000 instances. The UI table you made can't handle it and now looks terrible. Plus your iOS developer is using a web view, but didn't tell you that it doesn't support the particular JS library your using. You all try your best but can't re-code it all by deadline, and have to turn in a crappy-looking, half-functioning project. (This sort of thing happens all the time at school).
The lesson here as much as you think you can plan it ahead of time and do work individually, it is way more efficient to meet frequently, let each other know your progress, and let each other know when you run into problems and need to change course.
Another example. You have a real job now. Your product manager (PM) gives you a task to do. It seems straight forward, so you tell her that you'll have it done by the end of the week. You go into the code that your going to improve. Turns out it was made by a developer on another team. Your not using your communication skills, so you try to read and interpret the code yourself, instead of just asking the other developer about it. It takes you 3 days to interpret and test the code that's already there. The last day of the week, your finally coding a solution. The PM comes to check on you, and you say "I ran into some problems, I need another week". The PM says you can't have another week, I told the customer they'd have it today! She makes an exception and tells the customer it'll be out next week. Next week you finish the code, turn it in. It goes to a Quality Assurer (QA). They start testing it, and it turns out there was a test case you didn't think of. You could have talked to the QA and made sure you were covering the test cases as you went... but you didn't. They send the code back because its buggy. Its Friday again. PM comes over. You don't have the code. You tell her you'll definitely have it by next week. So it's next week, everything's working, you covered all the test cases. Oh no! Its broken again, what happened!? Some one pushed something that broke it! They didn't know you were working on something that used that code. Who pushed the code? You find out. Instead of talking to them and seeing what they were trying to accomplish, you go into their code and fix it. You push your code. QA and PM are happy. In a meeting the next week, everyone is going crazy because a big new feature was released (not yours) and its broken because someone not on that team modified it. The company is losing money and reputation. They trace it back to you. You're fired over this.
This is a lesson I've had to learn myself at my job. If I run into a problem now, I tell someone. I ask for help. I let people know things might be late. I reach out to other teams to make sure my code won't effect them. And I document my code so that when others need to work with it, it is easy for them. This is what makes me a good software engineer, and not just a good coder. Companies are aware of this, and most won't higher someone without good communication skills.