Empathy is the most undervalued skill in software engineering

Ask most engineers what makes a good software engineer and you’ll get a list of technologies. Knows Kubernetes, can write performant SQL, understands distributed systems. Maybe “good communicator” if they’re feeling generous. None of that is wrong, but it misses the point entirely.

The most important skill for a software engineer is empathy, and I don’t mean the feel-good HR training kind. I mean the practical ability to understand why you’re building what you’re building, who it’s for, who’s paying for it, and why they might stop paying for it. Without that understanding, you’re just generating code and hoping it lands.

Building for nothing is no fun

Early in my career I worked at a company where engineers sat in a corner and built features from a spec. We’d get a ticket, build it, push it, move on. Nobody ever showed us how the product worked for actual users, and when I once asked a product manager if I could watch a demo of a feature I’d built, the response was genuine confusion. “Why?” That moment stuck with me, because it showed just how completely disconnected we were from the people actually using what we built.

Seeing how a product works for a user is essential to building it well. If you don’t understand how someone actually uses your software, you’re guessing at tradeoffs and edge cases, and while you might guess correctly sometimes, you’ll never consistently make good decisions. You won’t even notice when you’re solving the wrong problem. That’s the difference between a developer who writes code and an engineer who builds products.

What empathy actually means

When I say empathy I don’t mean “be nice to people.” I mean developing the ability to model the world from someone else’s perspective, and concretely that means asking yourself a set of questions that most engineers skip:

• About your user: What are they trying to do? What’s their context? Are they in a rush, are they technical, and what happens when your system fails for them at the worst possible moment?
• About your client: Why are they paying for this, and what would make them stop?
• About your team: Who’s going to maintain this code in two years when you’re on a different project?
• About the business: What’s the revenue model, where’s the company going in three years, and will your architecture survive that journey? If you’re building a startup MVP with enterprise patterns, something is misaligned (and if you’re building an enterprise system with startup shortcuts, something is on fire).

Most engineering decisions are tradeoffs, and you can’t make good tradeoffs without understanding these perspectives. Technical skill tells you what’s possible; empathy tells you what’s worth doing. I’ve seen teams build perfectly engineered solutions to the wrong problem, and the root cause was always the same: nobody stopped to ask these questions before writing the first line of code.

The gap in our industry

We hire for technical skills and hope the rest follows, which sometimes works with engineers who’ve been through enough projects to develop that understanding on their own. Most of the time it doesn’t, and we end up with teams that can build anything but aren’t sure what they should build. The default then becomes building whatever’s in the spec, which is how you end up with technically sound software that nobody actually wants to use.

I’ve worked with brilliant engineers who built technically impressive systems that nobody wanted. Beautiful code, great test coverage, zero users. I’ve also worked with mediocre coders who understood the problem so well that their simple solutions outperformed everything else. The second group ships better products consistently, because they spend less time building the wrong thing and more time on what actually matters to users.

This doesn’t mean technical skills are irrelevant, of course they matter. But I’ve seen far more projects fail because nobody understood the problem than because someone picked the wrong database. We optimize for the wrong failure mode.

Domain modelling as applied empathy

One concrete area where this shows up is domain modelling. Properly modelling your domain requires you to deeply understand the business you’re building for: the entities, the relationships, the rules, and more importantly, the exceptions to the rules that nobody tells you about until you get them wrong. This is a skill that requires specific attention and care, and it’s chronically undervalued because it doesn’t feel like “real work.”

Engineers rush through domain modelling to get to writing code, which is a bit like rushing through the foundation to get to the roof. Get it wrong and every feature will fight you. I’ve seen teams spend weeks refactoring because their model didn’t account for how the business actually worked, and that’s not a technical failure; nobody took the time to understand the domain deeply enough before starting.

What this means in practice

The engineers I want on my team can write code, sure, but more importantly they can talk to a user and identify what they actually need (not just what they say they need), look at a feature request and ask “but why?” until they understand the underlying problem, and consider maintenance, operations, and team changes when making architectural decisions. They’re also willing to kill features that don’t serve users, even if those features are technically interesting to build.

The goal is figuring out what works, not minimizing technical debt or writing the cleanest code. And you can’t figure out what works if you never leave your IDE.