For the first 10+ years of my programming career I worked on my own code almost exclusively. Sometimes I’d read the code of others, but I rarely had to alter it.

For a couple of years I worked with another co-worker, but we paired regularly and the code we wrote was usually designed by both of us. So while it wasn’t totally my code, it was code I understood and agreed with.

In my new job I joined a team with a large number of pre-existing projects, which I now help maintain. This code is most definitely not mine, and working with it requires an ongoing attitude change on my part.

An approach I’ve tried a few times is to say, “I’ll just replace this other code with my code, then all will be well.” ‘Well’ is not how things have turned out, partially because the code has proved resistent to easy refactoring and partially because I approached the code from a place of arrogance - “Oh, this code isn’t mine and since mine is obviously superior I don’t need to understand what this code is doing, I just need to replace it.”

And, as I’ve found, if you try to replace code that you don’t fully understand, you are probably doomed to failure. I’ve found this out more than once, actually. Suggesting that maybe I’m not the best learner.

My lacking skill here, I think, is empathy. Empathy both with the programmers who wrote the code I now maintain and, weirdly, with the code itself. I don’t know exactly how one can empathize with code, but it’s the best term I have for the desire to investigate and understand the code’s purpose and meaning.

Empathy with the programmers is easier to explain than empathy with their code. I don’t know the circumstances that led to this code: what time pressures were faced, what knowledge the programmers had or hadn’t, what requirements had changed in the morning meeting, etc.

Sure, I can look at a huge method with nested if-loops and say, “This should change.” But I think something I need to work on is not saying, “This was done badly and only my solution to it is right.”

---