A new developer joined our tech team this week, and I’ve often seen how it takes some time for new recruits to get the hang of a new development environment. I thought it’d be a good idea to sit down with him and give him some pointers so that he can move in the right direction.
If you have read the The 7 Habits of Highly Effective People you will see some similarities in these tips. That is one of the books that have influenced me the most, even though I read it back in college, and to this day I still remember and apply those rules.
Here are the 7 tips I gave our new developer. I think these are good for any developer at any stage, so I thought it’d be great to share them.
Listen
I think this is the most important, if not the most important one of all. We, developers, are famously trigger happy and are always eager to start coding without spending too much time in “boring” specs. In our mind we are always coding even when we’re being told important business rules. We also tend to be a step ahead thinking we have figured everything out.
Don’t. It’s important to really listen when we’re in that specs meeting or when we’re talking to a fellow developer. Put your mind in pause mode and really try to understand what you’re being told, and don’t interrupt every 30 seconds with “Yeah, I know”. There’s a big chance you might not know.
Don’t try to impress
There’s an inherent competitiveness in all of us developers. We’re always trying to show off our knowledge in the dark corners of our computer languages or how we solved the most challenging coding problem. The problem is that this can become an issue with communication. It’s fine to do a “I told you” dance every now and then, but be on the lookout if you’re always minimizing your team member’s opinions.
It can also become an issue if you’re doing this with your supervisor. Most likely he’s already heard that “clever” solution you’re showing off with and in most cases it’s not an original approach that you just came up with.
This doesn’t mean you shouldn’t offer ideas when the setting is right (i.e. a brainstorming session) or when you’re asked for any thoughts on how to approach a problem.
Be proactive
There’s nothing worse than a developer who finishes his assignment and then just starts to surf the web for the rest of the day, pretending he’s busy, or goes to his IM window to chat with friends. A developer should always be ahead of what’s next and prepare himself for the upcoming tasks. For example, if you know you’ll be working with MongoDB in an upcoming project, make time to start learning it ahead of time.
It’s also very important is to check the workload of the rest of the team. If one of your fellow developers is banging his head on the wall with work and you’re done with your project, be sure to offer your help. He might not take it, but he will be grateful for it. And in a future occasion, he might help you when the tables turn.
Sharpen your skills constantly
The cool thing about software development is that there’s always new stuff to learn. Don’t become one of many developers I’ve known over the years that fall into a “maintenance” cycle and do the same repetitive tasks over and over. You might not feel it, but you’re being left behind. Subscribe to development blogs, join social networks and buy books on languages that you work with or that you hear other people praising. Catching up after years of not being up to speed is painful and might mean losing a cool opportunity in a new position.
Don’t assume, ask
This is related to the first rule. When you get the full explanation of what the project entails, make sure you understand everything correctly. Don’t skim the emails or functional specs and never assume you understand something you’re not clear on. Always raise the flag when you’re not 100% sure of any piece of the project. It’s always better to ask early before coding than when you’re 100,000 lines in.
Be a perfectionist
Don’t settle for poor code. It doesn’t matter that you’re pressed for time. Always write code you’re proud of, and make sure you improve it as time goes by. Think that this code might be seen by your supervisor or by a coworker and that you could potentially share with a prospective future employer.
Beat deadlines
It’s not enough that you meet deadlines. It’s up to you to set a date that you’re comfortable you’ll be able to deliver. That doesn’t mean sandbagging it or doubling the time. Make some buffer for Q/A and unexpected issues, but set and communicate a deadline and then beat it every time.
If you follow these tips, I am sure you’ll become and continue to be a great developer for time to come.
What about you? Do you have other tips to become a great developer?
