Much like development is maintenance and a creative field, development is also communication. One of the hardest problems I’ve run into with programming isn’t the programming itself, it’s making sure I’m actually building the right thing and fully understand the requirements.
Just because it’s obvious to you that a feature should work a certain way doesn’t mean it isn’t equally obvious to someone else that it should work a different way. Not that I’ve ever gotten burned by that or anything ;) As overly simple as it sounds, it can be really helpful to talk your plan for building a feature over with the person who came up with the requirements and your team lead. Something as simple as having a quick chat about how you’re going to build a feature can uncover assumptions you’ve made that aren’t right or things you missed or even existing code you didn’t know about that could really help.
If you’re working directly with other developers on the same project, it’s possibly even more important to communicate with them. At the very least you need to figure out who does which piece and how your code will work together. If you can divide a project into nicely separated pieces with an interface or API between them that definitely makes things easier, but you still need to keep in touch. Interfaces can change as you build and discover what you actually need, parts of the project can be delayed, there are all kinds of things other people on your project might want to know about.
Even if you’re not on the same project, it’s still useful to communicate with your team. If nothing else, your team lead needs to know how your task is going so they can get ready to assign you more work or re-assign a task they were going to give you if you hit a snag.
Stubbornness is more important than intelligence or talent when you’re learning to code, but that doesn’t mean it’s useful all the time. Listening to other people’s ideas is just as important as refusing to give up. It’s tempting to stubbornly insist on doing things your way, but that’s only going to hurt your project and piss off your team. An idea being yours doesn’t mean it’s the best way to do it. Of course, another dev, even a more senior one, having an idea doesn’t magically make that one perfect either, that’s why it’s so important to talk things out. It’s nice when you get to implement your own ideas, but it’s best for your project if you implement the best ideas you have available, whether those came from you or from someone else on your team.
Whether or not you actually take their suggestions, it’s really important to listen to your team. Despite what you may have heard, software development involves surprisingly little coding in a basement far away from all human contact. Professional software development is fundamentally a team sport, very little of it is so small that a single person can build and maintain an application by themselves. Working with a team means you need to get along with them and listening to them is a big part of that. If you bother asking for anyone else’s opinion, you need to give it a fair shot and seriously consider implementing it. If your mind is already made up, do the polite thing and don’t waste people’s time by asking for opinions you’re not actually going to listen to.
The preceding rant is brought to you by the many horror stories I’ve read online about people who label their listening problems someone else’s communication problem. Listening is communication. Without it, no information gets shared.
Communication skills are at least as important as hard development skills if you want to make a living as a developer. If I had to choose just one, I’d say communication is more important. Someone who will listen to me and explain what they’re doing can learn to code or code better. There’s nothing you can do with someone who can’t communicate. That doesn’t mean you have to be perfect at it – I’m certainly not – just that you’ve got to try.
Arrogance is definitely a blocker – melreams.com
[…] First of all, software development is a team sport. Sure, side projects and prototypes can be built by individuals, but the vast, vast majority of business software is built by teams, which means that communication is everything. […]