You might expect this post to discredit ill-defined hiring criteria like smart or assertive. While that is also a tech hiring scourge that I hate, this post is not about that.
This post is a case against applauding intelligence in a software engineer.*
*And actually maybe anyone, but I’ll stick to what I know.
We do this constantly. “Oh, she’s so smart,” the beaming manager will say of a direct report. We refer to engineers as “whiz kids” and “geniuses.” Candidates with privileged Ivy League pedigrees get preferential treatment. Candidates without such privilege scramble to code “smart” into their credentials with other phrases like “fast learner” or “intellectual.”
So your engineer is super smart?
Okay. I don’t care.
I mean, I care, but not because I’m happy for you. I’m worried that you’ll give your engineer responsibilities, based on their logical prowess, that put your team at risk.
Let’s consider a few scenarios.
1. Why do you want a smart engineer? Maybe you want one because you would like them to produce high-quality code. Their extra brain-wrinkles, you think, will help them make connections that turn the code into a pillar of architectural brilliance.
Look, here’s the thing about brain-wrinkles. They make connections even when there aren’t really connections to be made. Super-smart developers will not realize this because they think the reason they see the connection and others don’t isn’t that they made it up and it isn’t there—it’s that everyone else is just too intellectually inhibited to see it. So they blaze forward and refactor on the assumption that they’ve discovered a pattern that does not exist. Now we have this one awkwardly polymorphic object that represents three different concepts, and we start subclassing methods with no-ops to get around it. Or we have to hit a service to get the titles of our menu items because some genius thought this made more sense than putting the titles in the html. Or there’s some kind of arcane hash acrobatics happening because Captain Brilliant wanted to loop through fourteen keys and values more efficiently. None of these are made up scenarios. I have seen all three of them with my eyeballs.
We refer to these mistakes as clever code—which is a pejorative term. Alternatively, we call them over-engineered. Every programmer makes these mistakes, and it’s fine, but each one makes the code harder to maintain. So the problem arises when engineers routinely fail to consider the possibility that their predictions for how code will scale are wrong. To consider that possibility, and to consult other programmers’ opinions on it, requires humility.
The smarter the programmer, the less likely they are to be humble, because they’re often right, and confirmation bias has convinced them that they’re right even more often than they are.
2. Why do you want a smart engineer? Maybe you want one because you would like them to learn fast. You have a lot of tech stacks, or you’re doing something hard, and you need them to ramp up quickly.
Canonically defined intelligence does sort of correlate with learning speed, but only if the person puts in the effort to learn. Sometimes, for a smart person, that effort is minimal because they find the subject easy. Computers, by contrast, are hard.
Computers are hard because their evolution depends on the admirable, herculean efforts of a staggering number of fallible human beings, all over the world, coordinating their efforts very poorly.* So programming doesn’t make sense. The systems don’t all work the same way. Drawing connections between two theoretically similar things often doesn’t work.
*That’s right. Somewhere under the hood of every computer game you have ever loved is a highly questionable hackjob that looks like the bits and bytes equivalent of duct tape and popsicle sticks. This is true all the way down to the internet itself, so don’t get the idea that you’re somehow safe from this hackery.
The thing about learning hard things is that, no matter how smart you are, you are going to have to work at it. It takes time and effort—in a word, it takes discipline.
The smarter the programmer, the less likely they are to be disciplined. Maybe it’s because they could skate by in school on their smarts, so they never learned to grind. They are less likely than others, in my experience, to repeatedly do something they’re bad at until they get better. It’s draining to look at your task list, say ‘I don’t feel like it,’ then pick up your knapsack and go do it anyway. It’s much easier to blame the tool, whine and complain, get defensive, or drag the team towards solutions that you’re good at and familiar with, regardless of their relative fitness for the problem at hand. I have only ever seen this behavior in programmers who are very hung up on their own intelligence.
3. Why do you want a smart engineer? Maybe you want one because you would like them to teach others. They know the most, so they have all the skills that you want to transfer to the rest of your team.
The thing is, in order for your genius hire to teach anyone anything, other people have to enjoy learning from that person. That person has to know how to explain things well, and that person has to treat people who know less than they do with enough respect that their potential mentees don’t feel humiliated asking them for help.
For some reason a lot of intelligent people (and this is not just software engineers) get some sick joy out of failing to comprehend why a concept would be difficult for someone else to understand. They get so much joy out of it, in fact, that sometimes they pretend not to comprehend it, even when they do, in fact, remember a time when they found that concept challenging. And they vocalize this failure to comprehend to the person having trouble. Newsflash geniuses: “I don’t get why this is so hard” is a great way to guarantee that the person you’re talking to never ever ever ever comes to you with a question again.
Even if a teacher-to-be does not do that exact thing, said teacher still needs to know how to connect with someone, understand their perspective, and exercise patience. In a word, it takes empathy.
The smarter the programmer, the less likely they are to be empathetic. I think this is because smarts, canonically defined, refers to a specific type of logical intelligence; it excludes emotional intelligence. As kids grow up, school tells them—especially the super-smart kids—that smartness, meaning logical intelligence, is the most valuable quality in a person. So, combine that with the aversion to doing things they’re bad at, and super-smarts often gravitate to logic-smart activities. As adults, they have underdeveloped emotional understanding. This makes them unfit to teach as is.
The Upshot
In each of these cases, we see reasons for wanting a smart developer. In each case, intelligence is not specifically a detriment. However, intelligence is not sufficient to get the job done well. Instead, there must also be some other quality in the person—and in each case, it happens to be a quality that we find less and less as IQ rises.*
*Yes, IQ is a flawed and incomplete metric for intelligence. It does, however, measure some of the extremely narrow subset of qualities that we’re characterizing ‘smart’ to mean for the purposes of this discussion.
So what do we do?
Rather than using “smart” as a seal of approval on software engineers, we evaluate and praise them on other skills like humility, discipline, and empathy. What’s lovely about all of these skills is that they, unlike raw smarts, can be taught, learned, practiced, and improved. When we focus our teams on optimizing themselves for these skills, rather than smarts, they learn behaviors that help the team learn and improve. Compare that to what happens when folks try to optimize on smartness: we get defensiveness, aversion to admitting failure, or denigrating comments toward folks who don’t understand something.*
*Also, annoying intellectual pissing contests in the kitchen about wine/beer, trivia, or the vague and distorted scraps of what the competitors remember from their philosophy studies back in undergrad.
By selecting for these necessary qualities in new hires, we also see the talent pool differently than we saw it while we were selecting for intelligence via shitty privilege-proxies. Suddenly, we realize that it doesn’t take an advanced mathematics degree or a knack for Socratic argument to do the engineering job stunningly well. We start to see the candidates that the smarts-focused tech conglomerates are missing. These are the ones that, when given a chance, will show them all. They’ll ask the right questions. You’ll build the right things, for the right people. And you’ll have a ball at work. Wouldn’t that be fantastic?
If you liked this piece, you might also like:
This rubric for evaluating employees on their contributions to an inclusive culture
This six-part series on giving and receiving feedback, OR, if you’re busy,
This 20 minute talk on the subject (complete with a slide that everybody finds hilarious)