A few of my recent topics here have been on what legacy code is, and possible ways to stop writing new code that turns into legacy code as soon as you push it to master. I think one of the best ways to avoid this is to write code with empathy.
If you are unfamiliar with empathy, it is basically the ability to perceive feelings and emotions. Especially the feelings of others. Some people are really good at this, and do it naturally; really hurting when other people hurt, crying when others cry, etc. Men typically find it harder to be empathetic, probably because we are naturally less atuned to our own emotions than women are to begin with. For you Next Generation Trekkies out there, think of Deanna Troi.
When writing code, we are typically just focused on the requirements at hand. We have a box to check, and we are just focused on checking that box. We are focused on making the test turn green. We rarely pause to think of what other people may think of the code, unless we happen to be in the habit of pair-programming to begin with. Because we don’t think about this, we don’t consider what somebody will say, think, or feel when they see this code at a later date. We don’t have empathy with them.
If we did pause every once in a while to consider that hypothetical future person coming in to look at our code, who is likely already in a foul mood because they were pulled off of whatever their more interesting project was to fix some bug in this crappy system, will be thinking and feeling when they stumble across this chunk of code. Will they curse it for being unclear? Will they be happy to find that it is supported by unit tests? Will they be mad that they have to trudge through a set of comments that is basically a dissertation on why you happened to choose Apache’s common utils rather than Guava?
Perhaps one of the reasons older code gets such a bad reputation is because software development has been skewed towards a male dominance, and so we never even thought to consider writing code while thinking of a potential mythical future reader of said code. But we can learn, and learn to write better software that won’t be a drain to come across in the future, for ourselves, or anybody else.