Why You Need To Hire Great Developers

52 Replies

The difference between a bad developer and an average developer is small, but the difference between an average developer and a great developer is enormous. It’s an ocean of difference. A great developer is 20x more valuable than an average developer, easily, and so it’s critical to hire one great developer, instead of 20 average developers.

A recent coworker of mine once worded it this way:

“You have entropy creators and entropy reducers”.

Both groups will add value (at 20x differential), but the rate at which entropy is added to the system needs to be as low as possible, otherwise the entropy reducers won’t ever get past just removing entropy from the system, in the form of bugs, poor code design, etc.

Great developers know about this ocean of difference, and so they tend to gather at organizations that have a reputation for hiring great developers. Average or bad developers demoralize the great ones, because they can’t keep up with the entropy. A line from Pirates of Silicon Valley captured this well:

“What we do is like opening doors every day, you open the wrong one, all sorts of bad things will come in. You have to be careful which door you open.”

If you let a bad developer in the door, you’ll sap the productivity of the great developers because they will just spend a ton of time cleaning up the messes. And maybe the bad developer is just a really nice person, so you can’t just get rid of them without causing a stir. Nothing good comes this mistake, and the negative impact can’t be understated.

We’re Awful At Distinguishing Great Developers

Software engineering has no qualification standards, and the people who need developers are very poor at identifying/recognizing what a great developer is. The result of this is that there are legions of terrible developers. Our industry is packed with developers who have no business even being in the industry. It’s common to find resumes overflowing with acronyms and claims about their knowledge, which more often than not are extremely exaggerated or just outright falsehoods.

If after you interview a candidate you find that you aren’t completely sure about them, don’t hire them. If you can’t tell if they are good or not, don’t hire them. If 2 out of 6 people on the interview loop are either ‘no’ or ‘maybe’, don’t hire them. The consequence of letting a bad developer in the door is far greater than maybe missing a good one.

In a future blog post I’ll discuss techniques to use when figuring out whether to hire someone.

  • Asdfs

    good

  • ic

    That’s actually a self-contradictory statement you’re making here– you say that a really great developer is 20x better than an average one, but the price of having a bad developer in your door is worst than not having a potentially really good developer. Plus, if everyone only hired experienced, really-good developers, then no one would be able to become one eventually. I think most companies nowadays have forgotten about training and nurturing talent can be much more potent (see General Electric and the executives it produces up until 20 years ago).

    • http://benlakey.com/ Ben Lakey

      Fine points.

      While I find the notion of training and nurturing to be one of good intent, I think it applies for some fields but not always for software development.

      Being a great developer involves a great deal of curiosity, self teaching, and initiative. This is necessary because the pace at which change occurs in our field means that by the time on the job training is seen as necessary, it’s too late in the technology cycle. If the developer isn’t actively seeking these things out to keep himself/herself ahead of the curve, then by definition they are not a great developer.

      This isn’t a blanket statement however; I have known one developer who educated himself on the job and is now a great developer. It takes a very special person indeed to do this, and is very much the exception.

      I’d encourage you to read the following article for more information. It seems to strike a balance between our points of view.

      http://www.economist.com/blogs/babbage/2012/06/super-star-programmers

    • Albert

      Was thinking along the same lines, how do you become experienced if you don’ get a chance to gain any?

      • http://benlakey.com/ Ben Lakey

        Being a great developer has little to do with experience; It’s a type of person who has the passion and curiosity to seek out greatness before it becomes necessary for an employer to drag them along with training.

    • Gordy

      In my experience great problem solvers become great developers.

      Hiring someone for the long haul is not so cut and dry as just hiring a “great developer”. You may find someone just out of University who has a great aptitude and will become a great developer.

      • http://benlakey.com/ Ben Lakey

        I’d argue that we’re actually saying the same thing, and that the difficulty comes in identifying who those individuals are.

  • Hn

    This post itself is much like the point your making: it does more harm than good. Great developers start off as crappy developers. No one is born slinging code.

    Instead of arrogant, self important posts like these, we need more posts encouraging positive growth. Please follow the hn thread for the full commentary:

    • Reese Currie

      I must disagree. Great developers start off being good. When I say this, I must point out that my definition of a “crappy” developer is one whose solutions are more complex than the problem they’re trying to solve, and a good developer solves problems in such a way that is as simple as possible (but no simpler, as Einstein said). Being “crappy” has nothing to do with what libraries you know or don’t know, or how much you may know about the languages you use. It has everything to do with being unable to effectively solve problems.

      • http://benlakey.com/ Ben Lakey

        Agree wholeheartedly with Reese. It’s about problem solving ability, and a lot of that is determined by the individual and whether they are hungry and passionate for knowledge, and have a penchant for simplicity.

      • Th

        +100. I’m tired of idiots with MVP/MCSD diploma who shake the air with acronyms instead of just SOLVING THE TASK. They blah-blah about dependency injection, SOLID principles, containers and GoF, but in reality they are not able to create even simple database application with extensibility with entities! That’s ridiculous…
        MVC sucks, WCF sucks, Workflow sucks, but they still continue to push this cr@p into our heads!

    • Dan Sutton

      I also disagree. Great developers start out great: all they need at that point is to get used to programming. It’s built into a person: you can either do it or you can’t, and any great developer can detect the trait in another person, even if that person’s never seen a computer, within seconds.

      Strange observation: it appears that programming is a native, inbuilt talent… so that implies that we, as a species, have evolved the talent… on the understanding that at some point, computers would be around so that we could make use of it.

      • Dude

        While I agree with your comment on the whole, you may want to read a bit into what evolution is and how it works (hint, not as you imply).

        • Dan Sutton

          I know. I was being facetious. Perhaps it was too subtle…

  • Tyler Wanlass

    Hey Ben – great post. I’ve personally witnessed this while employed at previous orgs and it’s not just engineering talent either. If from top down the culture isn’t to hire folks smarter than you you’ll inevitably be ok hiring folks that are ‘good enough’. At the end of the day as you noted, A players will eventually move on.

  • http://twitter.com/eikonne Eb

    Really curious to read your criteria for a “great developer”. Different situations call for different levels of competence. Not everyone wants to be great but that doesn’t mean they want to be mediocre also.

    • Dan Sutton

      I don’t think it has much to do with what you want to be: it has more to do with what you are (and have always been). Just as you can’t teach someone to have perfect pitch, you can’t teach them to program, either: you can show them the language, the rules, the syntax, and examples… but the thing which really distinguishes a great developer from the herd is that ability to go nuts and perform unfollowable maneuvers of lateral thinking. That’s a facility which can’t be taught: it’s rooted deep into the basic thought structures of an individual’s personality.

  • William Payne

    What is the difference between a great developer and a merely average developer? Well, whatever posts like these might insinuate, it is not an intrinsic characteristic.

    I have been both.

    At times, I have tackled projects like a man possessed, obsessing over details every waking moment, walking into work first thing in the morning with a list of changes already fully formed in my head, unable to stop working, even if I wanted to (which I did not). Another time, another workplace, a different industry, somehow nothing “clicks”. A certain level of enjoyment is still there, and a certain level of competence, but the obsession is gone, and my behavior reactive, rather than proactive; I contribute to the project, but am not the engine powering the project forwards.

    What is the difference between the two? How can one job evoke passion, and the other mere acceptance? What does it take for a job and a project to “click”, so that you spend most of your time in a state of “flow”, of effortless concentration, and “passionate productivity”.

    I strongly suspect that the factors will differ from individual to individual. For me, the subject matter, my relationship with my colleagues, the length of my commute, the workplace environment and the home environment; all of these have an impact.

    Engineering a great team is much harder than simply hiring the right people. 10Xers are not just individuals, they are moments in time; unique combinations of personality, environment and circumstance. Geography matters; the workplace environment matters, where and how the developers live matters.

    Of course, who the developers are matters also, as does the alignment of their passions with your organization’s objective.

  • Guest

    If average developer work with great developer there are major chances for average to learn and become great. Not to hire but sees the capability if he has to become good/great developer

  • http://www.codemein.net/ CEA (codemein.net)

    I do not agree with you. It definitly depends what employers need. Beside that a good average developer will become the great developer next to great ones. So employers give less money but good results they get.
    But the harmony have to be well organized like (junior + midior) or (midior + senior)

    • Dan Sutton

      You’re obviously wrong. Had you hired a great developer, for example, he’d probably have written you a spell checker by now.

  • Mark

    What a pile of festering crap. 20x? Really? Where did you get that number from? Thin air is my guess. There is no objective way to decide who is a great and not so great developer. It can change with time and project and by the people you are judged against in the team you happen to be in at any given time. And you might be awful at distinguishing great developers because you’re a self-obsessed and talent-less twat but some of us have gotten reasonable enough at it not to keep hiring morons. Keep your mouth shut and let people think you’re a fool; open it and let them know you are a fool.

  • John

    Seriously? You think by deleting my post that makes you right? You’re not right: you can’t just pluck a number out of thin air and not expect to be lambasted for it. Still, I suppose you’ll delete this as well – your ego must be terribly fragile if it can’t take any criticism.

  • Bhargav

    Stupid post! Doesn’t make sense…

  • Dave_mm0

    It’s a shame there are no qualification standards

    • Dan Sutton

      I agree… but how do you measure the ability to think laterally, and, more importantly, if you’re hiring someone to do this because you can’t, then you have no frame of reference for recognizing it. However, I think this guy might have some ideas (if you haven’t read his books on lateral thinking, then I’d recommend them most highly): http://en.wikipedia.org/wiki/Edward_de_Bono

  • zozotw

    this is a very wasted discussion…i wasted 4 minutes reading it

  • Wuffinlaw

    This is great post!!! Some key factors for entropy reducers in your related post, “What Makes a Good Software Developer?”, are 1) “…be passionate about writing reusable and highly-maintainable code” 2) “Be an encapsulation and loose-coupling ninja.”, 3) “K.I.S.S”, 4) “DRY…Refactor, refactor, refactor.”, and 5) “Strong typing is your friend.”. Another key factor is “Don’t make a mess just to meet a monolithic schedule.”, however, I think this is an organization or culture driven factor rather than an individual factor. Some of the previous comments seem to imply that good software developers write code fast. Wrong, wrong, wrong. Although writing code fast is an important factor, without the other factors listed above, such developers are “entropy creators”.

  • Sam Carleton

    Ben, I wanted to say thank you for the thought provoking blog. I was going to reply here until I realized that the thoughts your blog created took me in a slightly different direction. Thus I opted to blog about it: http://j.mp/MRpZ4b

    Again, thank you, and Peace!

  • Fabien Bouleau

    A bit like defining the difference between a mere programmer and an engineer.

    • Dan Sutton

      There’s no such thing as a mere programmer. However, there’s definitely such a thing as a mere engineer. Here’s why: in order to be able to write *anything*, a programmer must learn *everything*. I mean everything. You have to understand the systems for which you’re programming, and to solve any problem you have to be able to understand all things. Mentally, programmers are at the top of the food chain: programming, if approached correctly, represents the pinnacle of human thought. Actually implementing an algorithm as a runnable program is the dog-work: it involves making compromises to the system and actually returning to the real world… but 90% of programming is done in the mind, before one ever sits near a computer, and for a mind to be able to do that properly, especially with large systems, requires a facility for thought which is unparalleled in any other discipline.

      • Cmcfau

        ” programming, if approached correctly, represents the pinnacle of human thought”

        This is utterly ridiculous.

        • Dan Sutton

          So is your name. And fairly obviously, you’re not a great programmer, which is why my comment represents the casting of pearls before swine in your case.

          • Exolon

            That’s convenient isn’t it – you construct your argument such that if someone disagrees with you, they are “fairly obviously” not a great programmer, and therefore their opinions may be ignored.

            I’ve been hooked on programming since first being exposed to it on my Commodore 64, at nine or ten years of age. Not only is it an amazingly fulfilling practice, it’s also amazingly useful in almost any domain you can think of, which is one reason I believe everybody should learn how to do it.

            But I also think your statement that programming represents the pinnacle of human thought is quite ridiculous. Although it certainly requires a combination of both logic and creative, abstract thinking, it is by no means the most difficult thing you can do. If it is, then you’re doing it wrong.

            Further: “90% of programming is done in the mind, before one ever sits near a computer, and for a mind to be able to do that properly, especially with large systems, requires a facility for thought which is unparalleled in any other discipline.”

            Absolutely not. If your approach to writing any problem is to construct 90% of the solution in your head before even touching a computer, then you are definitely doing it wrong. Throw out that old book which recommends big design up front. Explore problems with the computer and break it down. Trying to construct a complete solution in your head in one pass is not going to work outside of toy problems.

            If anything, this ability to interactively explore problems and solutions, and to decompose your solutions into modular pieces is what differentiates programming from many other mentally taxing disciplines.

          • Dan Sutton

            Yes. Some of us can do all that breaking down of problems into smaller problems and exploring what happens in our heads, with enterprise-level systems, without touching the computer. At that point, it becomes the pinnacle of human thought.

          • Exolon

            “Yes. Some of us can do all that breaking down of problems into smaller problems and exploring what happens in our heads, with enterprise-level systems, without touching the computer. At that point, it becomes the pinnacle of human thought.”

            I worry about anybody who believes they can do this competently.

            In the same way that I worry about anybody who claims they can drive across the country at night at high speed with no headlamps, no seatbelts, and no brakes on their car.

            That kind of inflated “rockstar” self-appraisal is dangerous and smacks of the Dunning-Kruger effect.

          • Dan Sutton

            Oh, ye of little faith…

  • Jerome Berryhill

    So, what kind of developer are you, Ben? The kind that makes everyone around him a little more productive? Or the kind that blames his problems on “entropy” produced by his colleagues?

  • http://www.intelligiblebabble.com/ Leland Richardson

    As many negative comments as this post is receiving, I think the author is still right. Bad, average, and even good developers are commonplace, and most of the development world is run by those three groups. That being said, “great” developers can be game changers and if you aren’t a large corporation, your success may hinge on whether or not you have any.

    In my eyes though, being a “great” developer, however, is rarely about experience or even technical ability. It’s about personality, ambition, and intelligence.

  • Dan Sutton

    I agree wholeheartedly with this post. I’d also wish to point out that the way to determine whether a candidate is a great developer is to get another great developer to do the interview. The great ones can tell each other in seconds: it’s like vampires…

  • Dburt

    I would extend this concept to the QA team as well. Organizations frequently think they can pay bottom dollar for QA people because they are considered just monkeys to push some buttons. A bad QA person can add a lot of entropy your organization and make things miserable for even the best developer. I think a good QA person also adds 20x value over a poor QA person.

    • Dan Sutton

      Agreed. My arse has been saved many times by a competent QA person. Programmers should never perform final testing on their own code…

  • Guest

    Good code comes from experience, Experience comes from writing bad code. – Mark Twain (1835 – 1910) Something like that.

  • http://viracct.blogspot.com/ Anuja K

    That’s why I prefer judging a candidate based on aptitude test and not merely on the buzz-words he talks about! There are hundreds of thousands of mediocre developers in the industry.

  • Golden Lari

    Isn’t that contradictory to your own post of June 24, with the conclusion:
    One gifted ‘hero’ programmer is not as important as having an entire team of average-to-good developers who can work together.

  • F F

    Pointless article when there is no objective measure of what makes a “bad”, “average”, “good” or “great” developer.

  • swampwiz

    This is probably one of the big reasons why there are so many employers claim that there is a skill shortage while at the same time there is widespread unemployment in the programming field. Employers are as picky as a princess looking for Prince Charming, and put out reqs for a new developer looking for that great developer, making every supplicating applicant go through an enormous array of tests of both skills, personality & “team chemistry” – and not even considering the poor bloke who happens to be unemployed, since it can’t be fathomed that one of the great developers could ever be unemployed!

  • Nospam

    This concept of good developers or bad developers is why software is designed badly. A developers should be doing nothing other than following blueprints. A ninja designer who can provide detailed design for a product from design to documentation to support and maintenance while making a profit is what counts.

    It is not about this immature attitude that so many developers have I.e. I know more than you.

  • LevelPlayer

    I do find this post quite arrogant and after 20 years in software I have to say I’ve had it up to here with the arrogance in our field in general. This attitude of exclusivity and “I’m better than you because I know and you don’t”, doesn’t do our field any benefit other than to perpetuate the stereotype that software developers are special (we’re not) and that we are a persnickety crew prone to bouts of prima donnaism.

    A blog post telling people what not to do is spending time and energy and our attention (I read this all the way through) on the negative, instead I would have preferred reading about YOUR challenges in becoming a better dev. Perhaps your blog usually focuses on your experiences on a personal level but the headline of this particular post grabbed my, and I”m sure others, attention.

    All too often, I find that we speak in the general and try to make our experience into corollaries that others should obey as a prescription, and that’s not always so effective for the speaker or for the listener.

    We all have our experiences and training and, if someone isn’t performing to expectation, it’s usually because of the confluence of external factors with the employee’s internal struggles [work and non-work related].

    That doesn’t make them a bad programmer. It makes the situation not an ideal one for apple magic to happen. If we took you and put you in the wrong environment, made you feel like less of an artist and more like a cog in the machine, I’d imagine that god forbid, you might exhibit some of the traits you ascribe here to ‘bad developers’

    In other words, have more empathy for those that you think you’re better than, because inevitably, on your way down, perhaps they will repay you with the same kindness.

    • Exolon

      Totally agreed. I also take strong exception to the idea that great programmers are born and not made – that one’s ability as a programmer is a fundamental aptitude or talent which cannot be altered.

      It’s a rather distasteful view which is for some reason popular in our western world: even in school we tend to say things like “well I’m not good at math, so I’ll do an arts degree instead” or “I like playing the piano but it’s so hard, therefore I’m not good at it… I should study social sciences instead”.
      In contrast, students in China, for example, will tell you “I can achieve whatever I want, if I just try hard enough”.

      This habit we have of surrendering to destiny and doing whatever we feel we have “natural” talent at… it’s the same erroneous and defeatist thinking which produces the argument that you don’t “become” a great programmer – that it’s already been decided by fate’s hand alone.
      Not only is this a depressing attitude, it also makes you powerless to improve, since you believe that it’s simply not possible and therefore there’s no point trying.

      A more realistic and practical proposition: hire the best programmers you can find and don’t worry if they’re “great” or not. Then pair up programmers with different levels of ability and watch both of them improve.
      And don’t think of yourself as a “great programmer”. You’re just a programmer, hopefully on a never-ending journey to be a better one.

  • Th

    The first criteria about stupid developers is their proud of acronyms like “MVC”, “IoC”, “SOLID”, etc. Immediately kick their ass and find another person!

  • h1580245

    So, “We’re awful at distinguishing great developers” but “We should only hire great developers?” I don’t think I’d hire a developer who thinks this way.