Rock Star Programmers - 5 Traits I See As Winners

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

I Can't Find The Right People - Yeah Right!

I've had several discussions lately with different groups of people about hiring people.  I'm somewhat surprised at the attitudes of some of the decisions being made or expressed in these discussions.  Here are some of the comments I've heard:

1. We'll only hire people that have x years of experience.
2. We'll only hire people that can prove they have experience using xyz framework.
3. We'll only hire people that have a Bachelors degree,
4. We'll only hire people that have a Masters degree.
5. We'll only hire people that are experts in programming multiple languages.
6. We can't afford to hire newbies, it's too distracting.
7. We need programmers who also have experience as system admins?

Maybe we don't have a shortage of qualified applicants; maybe we're being too picky!  You want 7 years of experience, but you won't consider an applicant with 5 or 6 years of experience, really?  Someone can demonstrate that they know how to code and can discuss in detail their contributions to sophisticated development efforts – yet they don’t have a degree and you won’t hire them?  Your organization uses some hot off the press framework, or some framework that isn’t used by 90% of the developers breathing – yet you won’t hire a skilled programmer that has a track record of learning new languages frameworks and give them a few months to come up to speed?  You find a candidate that can develop is several languages – but is missing a key scripting language that your company uses, and you think that passing up this individual because you can’t afford to give them a little time to learn the scripting language – and this is a good idea?  You don’t want to hire new developers right out of college because you can’t afford to distract your staff – meantime, they’re working 70 hrs a week because nobody is there to handle the simple stuff or address the tickets being opened because of errors in the production environment, great choice!

As hiring managers, we’re supposed to be taking into consideration the long term needs and health of our teams.  I find these statements be short sighted at best.  Hiring inexperienced programmers into the organization provides several benefits that we need to be aware of and fight for:

1. They can take over the lower level complexity tasks that do nothing more than distract the more highly paid resources.
2. They can handle production problems that act as a distraction to the entire team.
• Side benefit – this forces these younger developers to learn the ins and outs of the systems that they are supporting so that they can transition into the development team at some point and take on more complex development tasks.

Part of the problem is we are relying on automated applicant tracking systems that filter out everything but an exact match with all of the keywords/buzzwords that we created for the job description.  These systems don’t allow us to find those gems that we can bring into the organization and grow into the next superstar.

How many times have you gone out and hired some superstar, just to have them leave 2 years later?  Sometimes these folks keep moving around because they know they can keep getting a bump in salary.

The real key is to understand the qualities of the people that currently work in your environment.  What makes them stay?  What makes them successful?  You then need to really hone your job descriptions to describe the type of people you want in the organization.  Then you need to adjust the applicant tracking system.  Stop filtering candidates out on skills and find ways to identify candidates based on the real traits you need in the organization.

If you’re a small company – do you really want to hire someone that has a track record of only working in large organizations and has a history of job hopping?  If you need developers that need to be able to meet with non-technical users – shouldn’t you be looking for a developer that has a track record showing that?

I’ll go further – sometimes you need to forget about finding someone with 5 years of experience and focus on finding an entry level programmer that displays a passion for learning, knows how to communicate, has local connections and will become the next rock star in your organization. 

Look at one point, none of us had experience.  Remember how excited we were when we got our first job?  Remember how we tore into any available documentation to learn?  Remember what we felt like when we moved our first code into production?  Someone, at some point, reached down, put their hand out and gave you a chance.  Now it’s your turn!


If you'd like more information on my background: LinkedIn Profile