I’m not sure exactly when the stereotype of the brilliant programmer switched from nerd to role model. But places like the Q&A platform Quora often publish wistful queries like How does one become a great coder? Or What things do you do to become the best programmer?
Brilliant programmers are a rare species. That doesn’t mean that you shouldn’t aspire to be one, especially when you first start a coding career. Or, if you’re a project manager, you try to hire the smartest programmers you can find. But it does mean you should be aware that a focus on the highest levels of programming talent, without consideration of other skills, can be shortsighted and even lead to problems for your organization.
What Does a Brilliant Programmer Look Like?
She or he is not hard to identify. They’re the person who produces code effortlessly. This person’s analytical mind allows them to discuss the logic behind a program, both in depth and at a high level. They have a strong grasp of your product’s architecture, yet also understands granular level details. This is the person on your team who loves to learn new languages. This programmer brings a manual home to study on the weekend. This person takes online courses outside personal areas of expertise or has several programming irons in the fire – all just for fun. In short, you have a valuable team member. So what’s the problem?
Downside 1: Code Does Not Solve Everything
Years ago I did a walkthrough of an intricate subroutine a coworker had written. Its purpose was to identify the first four characters of a surname within a long string of variable data. This was old school programming. In fact, he wrote it in assembly language. It was brilliant code and isolated the surname from the noise close to 100% of the time.
Months before, while working at a different company, I had the same assignment. My solution (as a grade-B programmer, on a good day) was to call the government agency that produced the specs to get a few more details. It turned out the field was optional. I didn’t have to write a line of code.
Here’s the takeaway: it’s not important to have avoided coding something that one time. But it is important to solve the business problem at hand, instead of spending time writing unnecessary subroutines. You need to move on to the next project. Unfortunately, brilliant programmers love problems like this and the challenge of crafting a solution that consistently returns the correct result. Faced with an interesting logic problem, many times the first thing they will do is crack open an editor and start coding. Perhaps they should instead make a phone call or talk to a subject matter expert.
Perfectionism can be a part of this personality, too. You see this lots of time when assigning this type of programmer a simple program change. Often she or he will completely overhaul good code because it doesn’t meet their high standards. At best, that’s a waste of time. Often, it complicates the code for the next programmer tasked with maintaining it.
Downside 2: You Can’t Keep the Talent
Decades ago, programming talent was heavily recruited. Now, platforms like Github and LinkedIn mean that developers are even more visible for poachers. A good programmer having a bad day only need pick up the phone to get access to dozens of companies hiring for their skill set.
This employee is likely the highest paid person in your organization. They should be – they are worth it. So what’s the downside? This personality is always looking for the next big thing. Unfortunately, your application no longer resembles that. Your A-Team of programmers is great for a new product. But they get bored easily. After the initial launch, the details of fixes and phase two deliverables won’t hold their interest.
Downside 3: Brilliant Can Mean Arrogant
Perhaps someone with only casual familiarity with your application lectured you on how it works. Or you sat through a meeting with two developers who argued over the intricacies of a technology that has no bearing on the business at hand. It’s likely that brilliant programmer dismissed or even ridiculed a request for a program change from an end user. And they did it with no attempt to understand the underlying problem. IT staff and application end users consider these typical experiences with arrogant programmers.
It’s easy for brilliant developers to become arrogant. They have a great deal of power in forming the end user experience of an application, perhaps for tens of thousands (or more) users. They have a direct view into an application’s functionality and data that is unavailable to its users. What’s more, they probably don’t receive the credit due to them for keeping it running every day. These responsibilities mean that they sometimes assume the role of gatekeeper. This makes it difficult when users ask for changes.
I’d be remiss if I didn’t point out that this is an advantage of Izenda’s self-service analytics. We give users the ability to explore their data and create their own reports and dashboards, without having to go back to a developer to ask for changes. They don’t have to wait for reports, and developers don’t have to cope with report requests.
Switch from Stars to Hubs
Instead of focusing on the star developer at the top of the hierarchy, organizations should perhaps focus more on the value that other employees offer. Programmer B, say, is a solid worker, but not a star by any means. He lacks all the attributes of a brilliant programmer. He consults with experts before coding, and he willingly plods along on not particularly exciting code. He even respects the opinions of his peers. Because of this, he is actually preferred as a team member over a more brilliant coder. There’s some interesting research to back this up.
Employees like this resemble a hub connecting different teams, improving relationships and expediting processes. This adds a value that organizations enjoy often without being aware of the fact.
What About That Brilliant Programmer?
Meanwhile, you’ve still got that brilliant programmer on your team. But you’re not sure how you can keep him. Or you are that person, looking for your next challenge. Here are a few modest proposals:
- Task them with mentoring your those developers for whom coding is just a job.
- Move them into management. The rule “those who can’t program, manage programmers” doesn’t apply here, because they are never simply brilliant at coding. They also tend to be gifted in other ways, like writing, teaching or managing.
Don’t expect them to jump at either opportunity – management is not as fun as programming. Instead, appeal to the big picture – the impact they can have as a manager in determining your product’s roadmap.
“Over the years I’ve seen how little ability you have as a programmer, no matter how good you are, at making a difference or changing things that are broken,” wrote Andrew Wulf in a blog post that should be required reading for new programmers. “I simply didn’t realize how little room you have to advance as just a programmer.”
Finally, insist that your brilliant programmer always provides thorough program documentation and regular code walkthroughs with other team members. Make sure you have a plan in the eventuality that they leave, because eventually, they will.