I just finished How Not to Be Wrong: The Power of Mathematical Thinking by Jordan Ellenberg and one particular section made me think of tech. Ellenberg discusses a cultural phenomenon called the “genius cult” that convinces people that “it’s not worth doing mathematics unless you’re the best at mathematics” (Ellenberg, 412; emphasis in the original). He theorizes that the results of this phenomenon are detrimental to mathematics and the world.

Ellenberg admits that he is in the cult to a degree; reading his Wikipedia page makes you feel like you are reading the IMDB page for Good Will Hunting (https://en.wikipedia.org/wiki/Jordan_Ellenberg). Notwithstanding his educational experience (“So this is a Hahvahd bah, huh? I thought there’d be equations and shit on the wall.”), he recognizes the negative impact of this cult; as a professor, he has seen good math students drop out of the major because they saw others who were more advanced than them. He calls for us to “dump the stereotype that math is only worthwhile for kid geniuses” (Ellenberg, 413) so that there can be more math majors in medicine and politics.

Well. I majored in math and I wasn’t a child prodigy. In fact, I forgot what a median was the other day. But I also didn’t go to a super competitive school like Harvard. Occasionally, someone in my class would get a perfect score on a topology exam that I thought was impossible, but that kind of experience did not happen enough to dissuade me from majoring in math. Plus, I had nothing else to major in…

…because there was no way I was going to major in computer science. I thought that computer science was only for people who had been taking apart and putting back together electronics since they were 3. I thought computer science was only for boys who loved video games and hated writing essays. But at the same time, I hated writing essays, so I wasn’t about to switch to the arts.

I don’t regret majoring in math, but I also think there is a genius cult in computer science and software engineering. Ellenberg argues that not only does focusing on the cult of genius keep good contributors out of the field, it also undervalues hard work and collaboration. What appears to be large mathematical achievements are made up of incremental accomplishments by a community of hardworking individuals, so emphasizing individual genuis does not help mathematical developments.

Despite the perception otherwise, being an engineer isn’t always building a huge breakthrough app alone in your basement. It can be. But it usually isn’t. Usually, it’s “how can we improve this code slightly so it does X better?” or “what’s the best way to get Y really quickly?” or “Why isn’t A doing B?????? A is supposed to do B!!!!”

If one is joining a team with existing solutions, whether or not they call these solutions “legacy code” (it’s not legacy if you’re still using it, s’all I’m going to say…), one’s job will be largely incremental improvements with other hardworking individuals. Although there are times I undertake large projects that include a design session and a large deliverable, it’s broken up to incremental deliverables; I use existing solutions whenever I can, and I have never done a project in which I didn’t rely on my peers.

Engineering is not the work of individual rogue geniuses. It is creatively combining a Stack Overflow solution with your own knowledge, putting the results in 1 line of your teammates’ existing code, and pinging another colleague to see if they’ve figured out how to deploy it yet. It is grepping the repo for a similar solution and pattern matching it for your use case. So teams benefit from hardworking, tenacious individuals- not geniuses.

So how do we attract more of these kinds of teammates? We should try to break through the cult of genius. Some advice:

  • Don’t advertise in your job listing that you’re looking for a “coding genius”, “whiz kid”, or the equivalent. Focus on the skills used most often: communication, collaboration, and critical thinking.
  • Emphasize that seniority isn’t just a high score on a coding test. People should not be promoted and put on a pedestal solely for their coding skills. Can they help develop others? Can they ask the right questions about a project to save time and resources? Can they identify and eliminate redundancies?
  • Avoid pigeonholing engineers into the rogue genius stereotype. This can be a self-fulfilling prophecy. Emphasize the other positive traits that engineers display, and those traits will proliferate.
  • Encourage conversations about ROI. When someone completed a story by broadening the scope of existing code rather than writing code from scratch, discuss how that saves resources in the future. Every piece of code introduced is code that must be maintained by the team, no matter how “geniusly” it’s written.

Citations Ellenberg, Jordan. How Not to Be Wrong. Penguin Books, 2015.