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.
“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.