I’ve had the good fortune to work in a bunch of different software positions over the past 2 years. And along the way, I met a bunch of amazing people who have taught me basically everything I know.

Some of them had an incredible ability to describe their architecture in excruciating detail. Some of them were curve busters that could fix the most obscure bug I stumbled across. But also, they would all take the time to walk me through the code, component by component, glossing over the irrelevant parts, and focusing on details that mattered. They would patiently pair with me on bugs that I spent all morning banging my head against. And I’m sure they were suppressing their laughter when they politely answered all of my trivial questions (here’s how to exit vim if you were wondering btw).

As someone who had very little programming experience going into university, I never really thought about software engineering apart from the usual stereotypes. So perhaps it’s not surprising that back when I first started out, if you asked me what skills I thought were needed to do well, I would only be half right at best. Here’s what I’ve learned since then.

But first, a question.

When someone asks you what are the common attributes of a software developer, what comes into your mind?

• Logical?
• Analytical?
• Structured?
• A quick thinker?

Sure, all that. They’re useful skills in solving complex problems and implementing elegant solutions.

Here’s the thing, does this also mean that being a better developer requires being more logical, more analytical, and more structured?

The answer seems intuitive. You need to write structured code for a computer to compile. But if the only objective was to write code that a computer can understand, what’s stopping us from writing it like this?

Photo by Markus Spiske on Unsplash

The answer is simple, we’re also writing code for the next person to understand and maintain. That’s why we organize code into classes. That’s why we name our variables and functions descriptively. That’s why we establish software patterns to build a shared mental model of thought. Of course, the compiler couldn’t care less.

So, how do we decide what patterns to enforce, what variations we’ll make to fit our needs, and how we’ll organize and communicate it so that our code stays maintainable and avoids becoming spaghetti?

Well, we need to consider how other developers use our system. We need to imagine how they’ll approach our codebase when they need to make changes. We need to leverage our own experiences and understand the common mistakes that people make when facing code, they’ve never touched before. We need to think about what kind of cues can be used to ensure that people keep our code clean moving forward.

From a different perspective, when you get a code review, what percentage of that review is focused on making your code correct? What percentage of that review is focused on making your code more readable, maintainable, and adherent to everything around it? If you’re not in the habit of pushing code that literally doesn’t work (I would hope not), it’s almost always the latter.

So, what skills do developers use when they’re trying to decide?

A little bit of logic, structure, and technical background sure, but not a particularly abundant amount if you’re willing to dedicate some time to read up and hone your skills. What’s most important is thinking about your fellow developers who are working alongside you — in other words, it’s about having empathy.

Empathy? Sounds like design.

Yes and no. It’s great if developers have that same level of empathy for their users and can relate the impact of their work to building a better end experience. It’s also (understandably) not something that is front of mind when you’re automating testing pipelines or defining new schemas.

It is important however, that developers are thinking about their fellow contributors, and it’s something that good developers practise on a day to day basis. It comes up when your coworker walks you through a tricky part of the codebase, and explains exactly what you’re looking for because they too have been confused by the same little hack. It comes up when you’re deciding whether to add a comment to that slightly ambiguous line, or maybe just drop a little note in the pull request. Being empathetic helps developers communicate their code to the rest of the team, and since software is such a team sport, building and fostering that collective understanding makes all the difference.

So why does it matter if we’re (sort of) doing it already?

I can’t count the number of times I’ve heard phrases like:

“I don’t think I’m qualified [for this position] because I’m not very technical”

“It’s exciting, but I’m just nervous because I’m not very logical or smart”

“It’s hard because I’m not a very good coder”

It’s great for people who are already in software to implicitly understand that empathy and communication are as vitally important as good problem-solving skills. It’s not great when people are discouraged from exploring a potentially rewarding opportunity, simply because they equate being a good developer to solving a LeetCode hard in a breeze.

Again, it does take an average level of logical thinking (a level that most STEM majors ought to have by simply studying in their field). It does take a persistence to learn and a determination to overcome challenges. But what we tend to miss in our conventional way of thinking is that beyond a certain level, you don’t need to have exceptional reasoning and analytical thinking to excel in most roles; there are other less visibly portrayed skills that are just as important. You won’t win any IOI medals, but fortunately, that’s not what it means to be a good developer.