Published Sep 19, 2021
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:
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.