The Number One Trait of a Great Developer

Note: Our very own Tammer Saleh recently wrote a blog post about hiring for judgement. With his permission, we’re reposting it here.

Maybe the best programmers aren’t those who spectacularly solve crazy problems, but those who don’t create them, which is much more silent. – Lena Herrmann

When I look around at other companies hiring Ruby on Rails developers, I see them focusing on three major traits: Super-smart; Large community following; Deep Ruby knowledge. They’re all wrong. While these are great aspects in moderation, they all miss the number one quality of a fantastic developer: Judgement.

###A story about Jack and Dianne Jack is a Rockstar. Jack talks about all the latest trends at all the coolest conferences around the world. Jack makes a point of starting each project with at least three new technologies. When asked to produce an internet-based backend for letting kitchen devices synchronize their list of recipes, Jack went to town. The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.

Dianne is a good developer. Dianne started as a Unix Admin, and moved into Ruby two years ago. When asked to produce the same system, she immediately started asking questions:

“How many devices do we expect to have?” “Well, we hope to sell 500 in 12 months.” “How often will they need to report in?” “Roughly once an hour.” “How reliable is the network?” “It’ll use WiFi, so fairly reliable.”

Dianne wrote a RESTful API endpoint in Sinatra with a MySQL DB. PostgreSQL would have been better, but she “knew mysql.”

Will Dianne’s solution scale to 10k users? No, but it doesn’t need to. Dianne’s solution is simple, easy to understand, and highly maintainable. Dianne knew it wasn’t the most elegant solution, but she also knew that anything much more complex would be beyond her current skills. ###It’s all about trust When given what has the oportunity to be a “fun problem,” developers without judgement tend to run to their cave to craft the most elegant solution possible. They have a natural desire to over design the solution either in terms of flexibility, speed, feature scope, or simply to get a chance to play with their new pet technology. They need to be constantly checked on to make sure they aren’t half way down a rabbit hole.

What’s worse is that they won’t know when they’re out of their depth, so they’ll leave code bombs littered throughout your project. Clever little bits of code just waiting for the unwary teammate to trip over. ###Hire for Judgement I leave the team to decide if a candidate is smart and fits our culture, but I take responsibility for figuring out if he has good judgement. To do so, I take him out for a beer, and I ask a couple of leading questions:

1. What’s your least favorite part of Ruby and the Ruby on Rails framework, and why?
2. Tell me about the last time you used an interesting bit of technology, and what you learned from it.

These questions are great for getting a coder to talk passionately about where they’ve been burned and where they had their mind blown. You learn a lot about who they really are and where they’re coming from. Which do they fear most: magic or cut-n-paste? Have they fallen in love with NoSQL stores? Have they learned when not to use them? Have they learned the hells inherent in multi-threaded code? Are they more comfortable in a Kingdom of Nouns, programming functionally, or juggling a bunch of hashes, and why?

Listen to the why’s, and not the what’s, and you’ll hear judgement.