My (former) expectations
When I started learning programming (which was about seven years ago, when I was in high school), I was mostly learning by myself. I was reading books and tutorials, solving some problems on a website, which in its nature was similiar to this. I wanted to solve problems by myself, to create apps. Life of a coder seemed like a very good choice for an introvert like myself, because I wouldn’t have to interact much with other people.
Confrontation with reality
After I got my first job, however, I needed to re-evaluate my thoughts. Working as a software developer, indeed includes long hours of coding. But, in order to develop maintainable software, you also need communication skills.
When developing real-life applications, you need to be able to brainstorm, to give out ideas, to provide insight. Those things are valuable in the planning and design phases. Also, you need to speak up if you have spotted a potential flaw, that haven’t been spotted by others. Keeping things to yourself is a bad idea – if you can spot a bug before the implementation, it is easier and cheaper to fix than fixing it after the implementation. If you keep things to yourself, such a chance could be missed.
Also, you need to signal if you haven’t completely understood the task you are given, so that you don’t get stuck or develop something not demanded. Misunderstandings are quite common with new employees – the “old guys” know both the system and the product owner, also the jargon of the project. There may be many things obvious to them, but not so obvious to you.
Depending on the company’s culture, project size and your experience, as a software developer you may be tasked with gathering more or less detailed business requirements. But you should not focus on the requirements themselves – what really matters is the job to be done for the client. You need to obtain and understand the client’s desired final outcome. And this comes with its own set of roadblocks – the client may not have it formulated clearly in his own head, because he has been using a legacy solution for years. On top of that, you, as a “technical person” have vastly different perspective than the client.
Other thing is, if you want to be successful as a programmer in the long run, you need to pass on knowledge. As I said earlier, keeping things is a bad idea. Known bugs, projects jargon, credentials to common services – those are things you unconsciously remember after being long enough in a project. But when a newcomer gets to your project (it does not matter if he is a senior or an intern in this case) – that person does not know that. You need to pass on this knowledge and also know how much you can pass on in one go to not overwhelm the newbie.
Working as a software developer involves quite some time of dealing with people. If you are considering or planning to work as one, be sure to focus not only on the coding itself, but also on talking with people. Also, don’t be afraid of sharing your thoughts and opinions – the environment you are in should be encouraging it anyway.