In 2003 Andy Hertzfeld – a key developer for the original Macintosh – was growing frustrated with an open source project called Chandler. At first Hertzfeld was intrigued when Mitch Kapor, of Lotus Notes 1-2-3 fame, approached him about building software to help people organize their lives.
The excitement didn’t last. Maybe it was the endless lack of focus on what to build. Maybe it was the constant change of requirements. Whatever the reasons one thing was clear. Early versions of Chandler were unstable and the changing features left users equally puzzled.
But it wasn’t just the absence of focus. The more Andy thought about it the more he realized the project was missing a passionate technical leader. No one was pushing the project forward. He states in the book Dreaming in Code, which was written to document the creation of Chandler, “To make a great program, there’s got to be at least one person at the center who is breathing life into it in a ferocious way. And that was lacking.”
More than anyone else Andy saw the problem. There was no Mitch Kapor for Lotus 1-2-3, no Mark Zuckerberg for Facebook, no Bill Gates for Altair Basic, and no James Gosling for Java. What Chandler had in vision it lacked in technical passion.
Although there is no doubt there must be a passionate technical leader, equally important is the supporting cast. Great developers not only have technical competence but a passion for software. Of all the traits exhibited by developers, there are three I look for. They are curiosity, tenacity, and embarrassment (CTE). Great ones have all three.
Curiosity
Nothing frustrated Thomas Edison. He created the first light bulb not with fancy equations but by endless experimentation. If Edison were a software developer he would have been an excellent debugger.
If the light bulb had problems software development has more. Just like what separated Edison from other inventors, when a program is misbehaving there are two reactions developers have. A great developer reacts with curiosity, bad ones with frustration. When a problem is solved a great developer thinks to themselves “how interesting” while the bad one feels resentment at the time spent.
No skill will stop a developer from becoming great more than this. If you want to invent the light bulb you have to be curious.
Tenacity
It only takes a couple hours in the morning observing how developers begin their day to spot the productive because there are two kinds of developers: ones that come ready to work and those that don’t.
There are other clues beyond the morning. Having been in technical leadership roles, nothing is a better indication of tenacity than having a developer knock out quality tasks and then ask for more. Never have I found a saying so true: “If you want something done give it to the busiest person.”
Embarrassment
Here is a decisive experiment. Next time a feature has bugs reported on it, observe how the developer reacts. Do they shrug off the issues with excuses or do they react with embarrassment followed by quick action?
No amount of psychology or crafty interview questions will reveal whether a developer has pride in their work faster than seeing how they react to mistakes. An embarrassed developer is a quality developer.
Subscribe