In my heart, I’ll always consider myself a professional software developer. I began writing code at the ripe old age of 12. While I don’t write code on a daily basis anymore – the sin of being ‘management’ – I still write code at night to keep my skills fresh and to ensure that I can sit in a room with my development team and understand the conversation and hopefully add value. While at one time, I considered myself an expert in the languages I used (don’t ask, they are all now ancient). I realize now that I can still write good code – but because I don’t do it day in day out, I don’t kid myself in thinking that I’m the whiz kid anymore. I’m not. I’ve got team members that are extremely talented and I’ll give them praise any chance I get.
So what makes a great developer?
Over the years I’ve watched a lot of developers come and go in the shops where I’ve worked. Some of these folks couldn’t code if their life depended on it and didn’t last long. Others made it look effortless – producing code that was simple, easy to read and just seemed to work. So what made these developers different, what did they do different than everyone else?
Patience
Some programmers get their assignment and without asking any questions start pounding out the code. They’ll quickly listen to what is needed or skim the requirements and get to work. They’re dismissive of further explanation, and are quick to say that they know what the users want better than the users of the system.
The best programmers take their time. They actually read thru both the requirements documentation and the technical designs if they exist, or they’ll spend time interviewing the user to understand what the true problem is and what issue is being solved. They are not only concerned about what it is that is wanted, but they take time to understand what isn’t wanted or needed in the solution. These developers think not only about the specific assignment but want to understand how it fits into the whole puzzle. Are there parts of the system that operate ahead of their piece – what do those parts of the system do to the data before it gets into the code that they are writing? Are there parts of the system that will need the output of the code that they are writing? How do they ensure that the data is validated before it leaves their code and is handed off to code written by another team member?
Lifelong Learner
Coasters – they drive me nuts! These are the folks that think they know everything and that they are better than everyone else on the team. They scoff at junior developers and will tell them that there is nothing that they can learn from such a junior team member. The Coasters are forgetting that anyone can be a teacher.
On the other hand, I love lifelong learners. These are the developers that are constantly pushing themselves to learn new technology, understand how to use the language they are developing in more efficiently. They are constantly reviewing everyone’s code and are not afraid to take a chunk of code, walk over to the person that wrote it and ask them to walk them thru the code so that they understand what is happening. They aren’t afraid when someone critiques their code and in fact actively pass their code around to others on the team to be examined. When you run into them in the breakroom or walking thru the office, they will begin telling you about the new scripting language they are playing with or some new solution/tool/framework that might make the team more efficient. Give these folks room to play – they will make your team better and find unique solutions to some of the toughest problems you have.
Commitment to Excellence
We know these folks – the developers that quickly write their code and then throw it over the wall for someone else to test. They’re not concerned about what happens downstream – heck, they’re not even concerned about what happens within the code they just wrote. They spend more time fixing their code than they spent quickly writing the code – in this instance, speed does not win the race.
Flip that around now. The best programmers take their code personally! They view their code as a direct reflection on themselves. The best programmers will actually create their battle plan prior to writing any code – understanding exactly how they will test what is being created or modified to ensure that it works within the complete workflow. Reviewing all of the incoming data, understanding what they should and shouldn’t expect. Reviewing all of the output and integration points and understanding how the data can be manipulated and what are false values or boundaries of the data. They will write small chunks of code or use scripts to test the code they are creating/modifying. They are not only implementing unit testing, but are thinking through integration and regression testing along the way and then executing prior to handing off the code.
Passion
Look, if you don’t like your job – find something else to do. We know these folks, they slouch in, plop down, ignore their fellow team members, don’t offer to help others, won’t bring new ideas to the table, won’t participate in meetings – team or otherwise and won’t do anything but exactly what they're told. Are you kidding me!
Now, show me someone who is passionate about what it is they do! Yeah, that’s the ticket! I love these folks – they live and breathe to be the best coders out there! They’ll call themselves a geek – and view it as a sign of honor! They aren’t afraid to tackle the most complex parts of a project. They find a way to practice their skillset – just like the best musicians. If they’re given a particularly difficult task, they’ll try 2 or 3 different solutions to find the one that works best. They are disappointed in themselves when they miss a deadline or someone finds a bug in their code – but they are the first to step up and take critique. They view critique as a lesson along the way, will actually listen to it and attempt to learn from that criticism. They will throw themselves at new technology when asked – and in a lot of instances without being asked – so that they can become more efficient. You’re hired!
Self Sufficient
There are days I’ve pulled my hair out because someone will tell me that they hit a wall and couldn’t get any further. When I ask them what the issue is, they tell me they’re waiting on answers to clarify some problem in the code or with the requirements/design. When I ask them what they’ve done to solve the problem, I get a blank stare after they tell me they sent an email out 2 days ago. Really, you couldn’t find it in yourself to stand up, walk to the other side of the building and get an answer? Ugh – do I really look like I want to play baby sitter!
Now the best programmers are bull dogs! They hit an issue and they are tracking down the best way to get the answer. Sometimes that is tracking down someone internally, sometimes that is looking on the net to find a solution to a particular programming problem, and sometimes that is asking a team mate sitting a few seats away. They are not afraid to ask questions and understand that communication can be used to solve issues! If the issue is big enough, they don’t hesitate to escalate the issue – but usually have a couple of different options to resolve the problem.
Wrap Up
These have not been presented in any particular order, but they do represent the traits that I see in the best developers. They are traits I attempted to show when my main role was to sling code every day and that I hope I still possess in the role that I currently play.
What are the traits that you see within the best developers you have on your team? Let’s keep the conversation going!
If you'd like more information on my background: LinkedIn Profile
