In my last post about Empathy Driven Development, I described how it influences decision making at a day-to-day level in coding and design choices. But being an empathy driven developer also says a lot about how you define success in your career and what internally motivates you.

Writing about motivation theory, Frederick Herzberg describes the difference between the two factors that influence how you feel about your job: hygiene factors and motivation factors. The former are only capable of making us unhappy with work – bad compensation, low job stability, onerous company policies. Fix all these and at most you won’t hate your job. The latter is where we derive career satisfaction – interesting work, increased decision making and influence, personal growth, etc.

Being an empathy driven developer doesn’t mean that you’re somehow above hygiene factors – you still care about being paid fairly and having healthy work environment. Instead it’s about finding more fulfillment in improving others lives in both big and small ways compared to commanding a large amount of respect from your peers, a lofty but deserved title, or an impressive GitHub account.

Empathy driven developers are user-focused

I’ve never been a fan of the phrase “customer driven”. It invokes a sterile and transactional relationship between me and the user. I get that it is the intention of the term – someone has paid for a good or service and the company will prioritize over everything the law allows for – but its always rung hollow to me. As an empathy driven developer, I find it more motivating to view customers as human beings struggling with a problem rather than a revenue stream.

I worked a service desk job while I was in college and I enjoyed it more than I had any right to, being the bookish introvert that I am. People could be grumpy and rude, but largely I’d find customers to be pleasant and grateful when I helped them out. The immediacy of that feedback loop felt great – I’d apply my knowledge to make someone else’s life easier and they’d express happiness and relief. It was proof of a job well done and that I adding value to someone’s life. I believe that this visceral response is what motivates an empathy driven developer.

Early in my software career, I worked on a product that had something like a six month release cycle. That’s a painfully long turnaround for a client waiting on a feature or a bug fix. Mercifully, we had a patch process for delivering fixes to higher priority bugs, but the definition of what met the bar for “higher priority” was squishy. I remember fighting to get a particular bug fix into a patch. It wasn’t in a critical path nor was it going to take down the system. Instead, it was an obnoxious usability issue that forced extra clicks for a lot of users. It was a dumb bug with a quick fix, but I couldn’t convince management to include it in the patch. These poor users were going to have to deal with the frustration of extra clicks every day for next six months.

I understood at the time why I couldn’t persuade the managers – any change to production was seen as a risk and they’d been burned one too many times by the confident promises of well-intentioned engineers – but it still didn’t sit well with me. There had to be a way to avoid putting all your eggs in a single six month basket and no longer be terrified of even the smallest change. A way for an empathic engineer to tighten their feedback loop with users and be motivated by the impact of their changes. In the years since that patch I’ve picked up many techniques and designs to do just that.

The rise in microservices has corresponded with several other practices – continuous integration and continuous deployment, observability, micro-frontends, APIs, and infrastructure as code. These all can combine to enable rapid and safe changes to a system in isolated ways. As an empathy driven engineer, you’ll never want to leave these practices once you’ve experienced them. They empower you to do the work you value and automate the parts you don’t.

Empathy driven developers are mentors and teachers

It shouldn’t be surprising that empathy driven developers enjoy being teachers and mentors. You feel another engineer’s frustration with a problem and the sense of helplessness as they spin their wheels and get nowhere. You equally feel their elation when they have both the solution and the knowledge to solve it themselves in the future. Seeing another engineer become more empowered and confident in their craft and capabilities is incredibly motivating because you know that feeling.

And yet, there were times in my career I felt myself recoil from questions. I would reflexively feel my stomach sink when asked a question like, “Hey have you ever seen this error before?” and see an all too familiar message in an enraged red font. It wasn’t that I didn’t have an answer, it’s that I didn’t enjoy giving the answer. “Maybe I’m not cut out to be a mentor…” I’d say to myself. Clearly I don’t always enjoy it.

I’d wrestle with this contradiction for a while, but eventually I figured out what distinguished the times when I enjoyed being helping someone find an answer and when I didn’t. I love teaching people about tools, techniques, paradigms, libraries, and generally things that I felt improved me and my craft – effectively, concepts that can be reapplied. The inverse is true when fielding questions that are one-off in nature, things like a random error message or troubleshooting one-time setup steps on a local environment. There’s just no lesson for someone in what is effectively a trivia question – just the required tribal knowledge. I don’t get frustrated that someone asks this type of question; I get frustrated that they have to.

In summary

For empathy driven developers to derive a sense of fulfillment from their career, they need to find or create a work environment where they can focus on helping users and teaching co-workers. They need to seek out places with practices like CI/CD and IaC. They need to work somewhere that minimizes tribal knowledge.