The importance of character in software engineering

Software engineers care a lot about being smart and knowledgeable. Conversations about how to become a better software engineer often center around learning more facts: programming language syntax, design patterns, details of how particular technologies work, and so on. It’s also undeniable that having a strong working memory is really useful, if only so you can fit more of a codebase in your head. However, there’s a whole other dimension to being a strong software engineer that doesn’t get talked about as much: character.

What do I mean by character? I mean the kind of person you are: the quality of your internal self. For want of a better word, your “virtue” or “moral fiber”. In my experience, people with good character are dramatically more effective software engineers.

There are approximately one million books about learning software engineering skills and approximately zero books about software engineering character. It’s a bit unfashionable today to talk about character, for some reason. Maybe because it’s harder to quantify, or because it feels too personal. But it’s still important. I have worked with very, very smart engineers who were held back by their character.

Emotional regulation

One of the points I make a lot on this blog is that managing your own emotions is a core part of being a software engineer. Many engineers avoid work that needs doing because they’re afraid. If they instead actively sought out work that scared them, they’d have much greater impact - no need to write better code or learn new technical skills. Being a good debugger is all about developing a strong tolerance to confusion. And every single project has a period where it feels like it’s going to be a disaster. You have to power through that to ship anything.

Whatever “good character” is, the ability to manage your emotions instead of being ruled by them is a key part of it. That idea goes all the way back to Plato, who thought that a virtuous person’s reason should guide their passions like a human driving a chariot. Many people now think it’s more complicated than that (e.g. the distinction between reason and passions is itself a bit fuzzy), but the general point is still pretty uncontroversial. Being unable to regulate your emotions as a software engineer harms each PR you put up.

Keeping a cool head in a crisis

Keeping a cool head in a crisis is another underrated skill for software engineers. There are lots of minor crises in the normal course of a software engineering project: customer issues, bugs, unforeseen setbacks, new requirements, and so on. None of these are particularly serious, on the grand scale, but they’re serious enough to serve as tests of character.

You can fail these tests in a small way or in a big way. Failing in a small way looks like getting visibly stressed out. We’ve all worked with engineers who didn’t handle the pressure well and took it out on their colleagues: being snippy in meetings and code reviews, difficult to have conversations with, and in general not being a steady hand on the wheel.

Failing in a big way looks like total panic. Either completely shutting down and not communicating with anyone, or the opposite: spraying panicked messages across Slack channels. Either way, it worries the hell out of the managers, who typically step in and impose some form of order. Often they do so by bringing in some other engineer who they know can keep their nerve in a chaotic situation - an engineer of better character.

Knowledge can be too much power

Competent software engineers are in a position of real power in any tech company they’re in, regardless of the formal reporting structure. That’s because they’re the ones who can directly make changes to the product, and - perhaps more importantly - the ones who can definitively answer questions about the way the product works. This is not a lot of power, but it’s definitely some power. Unfortunately, it’s enough power to go to many software engineers’ heads.

If you want to be effective as a software engineer, you have to work with many other people who do not have your technical context. It is very important to resist the urge to lord your extra knowledge over them. I have seen so many software engineers brush off genuine questions about the product as stupid questions, or to airily dismiss some genuine concern with a one-line technical answer that they know the person they’re talking to will not understand.

This arrogance is a weakness of character. It’s a weakness that makes you a weaker software engineer, because you need non-technical (or less technical) people on-side in order to do anything useful in an organization. In fact, they have plenty of knowledge that you do not have - they’re just usually virtuous enough not to rub it in your face.

Why are software engineers often arrogant?

Why is arrogance so common among software engineers? It’s because software engineers typically get hired for their technical skill, so other values - like strength of character - sometimes get neglected or deliberately traded-off. For more human-centric roles, interviewers are directly trying to identify and screen out arrogance.

You can also survive in a software engineering role with poor character. You won’t be anywhere near as effective, but you’ll still be able to put out some useful work and keep your job if you’re technically skilled. That’s much less true for product managers, managers and other roles¹.

Summary

Plenty of books and blogs will tell you how to develop your functional programming skills or teach you algorithms. But if you’re already pretty good at that stuff, you might be better off trying to become a more virtuous human being: more in control of your emotions, more able to hold your nerve in times of crisis, and humbler about the institutional power your technical knowledge grants you.