There’s lots of choices that go into programming. From small things like naming a variable or a function to large things like which viable solution to choose to a large problem. For an empathy driven developer, thinking about the maintenance and integration experience will carry a lot of weight when evaluating options. You ask yourself a lot of questions like:

• Is it possible for someone to leverage this code without having to understand the inner workings?
• Does the code place a lot of responsibility on the invoking code’s author to call things in a particular order? In a particular state? With a particular combination of parameters?
• Is it easy for a future maintainer to understand the impact of changing a given variable?
• Is it easy for a consumer of your function to reason about its state change and result?
• Can you map what your code does to a metaphor or model that’s easy to explain and reason about?

It’s front of mind whether you’re putting an unreasonable cognitive burden on a future programmer to confidently invoke or modify your code. You empathize with the developer who won’t have your contextual and contemporaneous information. This person won’t be steeped in the code like you are and they won’t have the conversations with the product manager, UX designer, client, etc… fresh in their mind. It matters to you that this person succeeds because of your decisions and not despite them.

It’s worth pointing out that asking these questions and having these concerns aren’t enough by themselves. It’s still important to learn and develop the skills necessary to answer and address them. I find myself applying Domain Driven Development practices and the SOLID principles among other best practices. The point is that empathy driven development motivates me to seek out these solutions and continuously evaluate their success at producing code that others enjoy working in or with.