Think about just how rare talent is. In fact, you could define talent as "rare skills." A lot of people think they’re talented but few of us actually are. By the data, most of us are "average." Of course, there are talented programmers out there. What do they look like? Let’s start by defining what they’re not.
A talented programmer isn’t necessarily famous, rich, popular, or the hot shot at some organization. Don’t get me wrong, some of these people may be talented, yet their talent isn’t defined by their fame or fortune, but instead their results.
Think of a famous athlete. He or she is producing results. Maybe that means the most points in a football game or the most rebounds in a basketball game. Maybe that means the most championships. However you define it, professional athletes produce results. For programmers, results are just as important.
Now let’s say you’re interviewing potential programmers and you want to find someone who’s really talented. The lazy way to evaluate a candidate is to look at their resume, check some references, and see how much their current employer is paying them. A better way to find talented programmers is to find people who can produce results.
What do "results" mean in regards to programming? One consistent trait that I’ve found in talented programmers is that they know how to structure things. Code itself is structured information. Talented coders want that structure to be as close to perfection as possible.
Mediocre coders simply care that the program works. At first, any working program seems like "results," but poorly coded software is a poor result. And we don’t want just any results, but instead, top-notch results.
Whenever I interview programmers, I give them a small piece of Java code. They are given five minutes to analyze the code, then they have to tell me what’s wrong with it and how they’d improve it. Very quickly, we find out who’s talented and who’s mediocre.
Talented programmers immediately home in on the structural problems, some obvious, some a bit more nuanced. They don’t care if the program works or not. Instead, they look at the unstructured chaos and literally can’t stand what they see. They have to bring organization to the chaos, anything less is unacceptable.
This is what a talented programmer looks like. A mediocre programmer, on the other hand, doesn’t mind the chaos. Hell, they’ll probably embrace it because that code is probably the type of code they’re used to seeing and writing. Who cares if the class name is "parser" and there are "save" and "get" methods? So what if the methods are not "get" and "set," but suddenly "get" and "save"?
A little bit of chaos is okay, right? So long as the program runs, right? Wrong. Poorly coded programs and uncontrolled chaos will lead to headaches down the line. That might mean bugs in the software or random crashes. That might mean future programmers struggling to understand how the software was written. Or it could mean something else altogether.
Talented programmers know this and that’s why they will focus on getting the structure right first. Sadly, finding a truly talented programmer often feels like catching lightning in a bottle. Don’t get me wrong, I know plenty of talented developers, but I’ve met many, many more mediocre developers. That’s because it’s what the market demands, or at least accepts.
Companies want to push out software as quickly as possible while paying their programmers as little as they can. Lazy programmers don’t really care about much except collecting their paycheck. If they can cash checks with mediocre, chaotic code, they’ll do so. Overused and misused frameworks and poor project management skills ensure that mediocrity will continue to not only exist, but thrive.
On the rare occasion that a talented programmer emerges on a mediocre team, he or she will often be treated like a pariah, or at least an oddity. Mediocre programmers will roll their eyes at all of the talk of "structure," "discipline," and "consistency." Why bother with all of that?
Don’t think you’re a talented programmer? Maybe you’re not, but by adding structure and discipline to your coding, you can start to develop talent. It may not happen overnight, and maybe you’ll never be the Lebron James of the programming world. But you can improve.
Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.
I read your article with much interest as i'm in the business of scaling teams and products but i'm not too concerned over the latter as my experience demonstrates (clearly to me, at least) that once we "fixed" the team problem - they would largely take care of the product. It is clear to me that this issue you discussed here is actually a far more complex one which has been debated on separate occasions on many platforms other than ACM; in truth, its a practical problem that stems from a philosophical one.
And i'm in agreement with you that talented developers do focus on the structure and more importantly the semantics behind the structure as they know the maintainability of the code outweighs whatever short term benefits a less structured (some might think "optimized code") could bring and let us not forget that "process is only as good as it is executed, faithfully". The timeless adage "Premature optimization is the root of all evil" is a good leverage to beg the developers to see reason which is a battle engineering managers do not win all the time.
I applaud your call that all of us can improve and for the sake of our software - we must improve to create a clearer (even simpler) structure which will benefit posterity.