Empathy for future developers

Chatting with some fellow developers over the Christmas period, the subject of the so-called “soft skills” came up and one of them made a very interesting observation - that those skills lead to better code as well as better collaboration.

Side note: I’ve come to hate the term “soft skills” because it somehow implies that those skills are easier to learn than the so-called “hard skills”. It’s my experience - both personally and observationally - that these skills are far harder to learn and execute well than the comparatively simple task of writing working code. This is not to say that writing code is actually easy - just that working with people is far harder (and, in some cases, far more rewarding) than working with code.

Empathy is the ability to understand someone else’s perspective on things - to picture yourself in their shoes and understand (at least partially) what it is like for them.

Understanding empathy within a team is relatively straightforward, but what about having empathy over time?

Production code has a temporal aspect that is sometimes ignored. For every piece of production code, there will be, sooner or later, some other developer who needs to read and understand it. Perhaps they’ll be fixing a bug or adding a feature. Or, maybe they need to understand what it does to copy the functionality elsewhere.

Empathy for that future developer - who might just be a future version of yourself - can be challenging because it’s a one-way street. This is very unlike the normal inter-personal situation where there is a feedback loop to drive self-correction.

So, what does this kind of empathy look like? Here are a few ideas.

Code needs to be readable. Write the code so that it’s easy to read, not easy to write. Make it as easy as possible for someone unfamiliar with the code to read through and understand what it does and what it works. Add comments to explain things that can’t be inferred from the code.

Code needs to be trustworthy. Names of types should reflect the semantics of the type. Names of methods should reflect what the method achieves. Names of fields and local variables should reflect what’s referenced. Names that are misleading or ambiguous should be avoided.

Code needs to have automated tests. Provide a safety net for that future developer so they can start to make changes confident that any unintended consequences of their changes will be picked up by the test suite. Make sure your tests are well structured and that test failures are easy to diagnose and fix. Run the tests as a part of your CI builds, and block any PR with failing tests.

Of course, this list is far from complete.

What would you add? How will you show empathy for the future developers charged with working on the code you’re writing today?