That Brilliant Programmer May Not Be Your Most Valuable

By December 29, 2016For Product Managers

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

Follow Izenda on social media for the latest on technology and business intelligence:


  • Except hubs are more often than not just as arrogant, and rigid in their own opinions… It’s not brilliance that makes people arrogant, quite the contrary.
    That being said, an exceptional programmer often codes in a way that few understand, so even though the original pattern may be great, once they leave it’s chaos. So there is something to say indeed about valuing your middle class.

  • SeattleC++ says:

    Yes, yes, oh yes! Motivating the whole team to do their best work is far more powerful than spending time searching the world for unicorn 10x programmers.

  • Mark says:

    What is brilliant? I would say your definition is off. The task you mentioned has prebuilt solutions in most libraries that include searching with REGEX etc. Sounds like they took the “I know how to do it this way” approach.

    To me brilliant is the person who can pick up new code and understand the backing architecture, figure out how that solves a business problem and being able to bring that forward as well as solutions others may not see.. I didn’t see any of that in the person you setup as “brilliant”. IMHO those people are worth 3-4 developers. In general they will save time, know when to ask questions and challenge the preconceived notions. Without that presence you usually have overbearing business who doesn’t understand development and asks that they do things and expect the “letter to be kept” which is why a lot of companies suffer the “time to market” failures.

    One person who actually does understand the industry and what is needed and challenges the preexisting notions can save projects double digit percentage gains in time.

  • Kelly says:

    Many good points in this article, but I’d think carefully about trying to turn a brilliant programmer into a manager. First: go read (or at least look up) The Peter Principle. Second: I know many brilliant programmers who would vehemently resist and revolt against being made into a manager. They LIVE to CODE, and often don’t want to have to deal with people.

  • Thabo says:

    I Live to code and the downside in that is that I’m sooooo bad with words….. what does that make me?

  • Thabo says:

    Not that I disagree with the “solve business problems, rather than write unnecessary code”… 1hr to solve a single problem may not seem much, but having to solve 20 problems(x 1hr) is way too long than spending 5hrs to write the code that would seem unnecessary then take 20mins/problem to solve the remaining 19 problems…… that should spare you 7to8hrs you almost wasted code less solve more.

  • Mat says:

    If I have a brilliant developer who doesn’t play well with others then I’ll simply give them an area of the system, or project, that is really challenging on a technical level. I’ll let them run with it with minimal supervision because I’ll know the problem will keep them focused. I won’t necessarily constrain their creativity. I’ll also expect their work, brilliant though it may be, can’t be simply dropped into production. That’s fine, because they’ve cracked the technical challenge (that’s why you have them on your team) but then I’ll arrange for that work to be handed over to another type of developer for integration into the wider project or product. At that point they are free to move on to the next challenge whether it be on my team or with another team. A lot of the time the brilliant developer is a contractor anyway and it would make sense to release them once the hand-over is complete. Sometimes documentation is a problem for the brilliant developer. That’s fine, technical authoring is a whole other skill that someone else might be better suited to writing.

    In my experience developer’s tend towards introversion and are not so strong in interpersonal skills as say manager’s or sales-people. It always strikes me as ironic that we would expect these types of people to play well in teams or even interview well. Seriously, when you encounter a ‘brilliant’ developer that may or may not be somewhere on the autism/Asperger scale don’t even try to manipulate them to become better team players.

  • Marshall A Hill says:

    @Kelly, agreed. More often than not, the attributes or aptitude that makes and individual a brilliant coder can be in stark contrast to someone I would want to follow or want to promote as a leader. What makes a person arrogant also tends to be wrapped up in insecurity and people with high levels of insecurity usually in my opinion make for poor leaders. Maybe a carrot approach for these individuals to gain skills in other areas with the reward being more control over things like architecture or mentoring and things that could facilitate them to more leadership positions. I would never just take a coder and make them in charge of anything, especially if means putting them in control of people. When I hire developers, especially more senior developers, I want to see that they have gained in some business domain and are more adept at interacting with people in other parts of an organization. If I hire just a coder then I am more apt to have to micromanage them. I want capable doers not incapable followers. If we see that software development is an exercise in solving business problems and less to do with the latest shiniest language or framework, then it follows that the brilliant coding part of the job is the less important than other skill sets, such as critical thinking, requirements elicitation, being able to talk at a level that a business person would able to follow…and of course this is all just my opinion, take it as such lol.

Leave a Reply