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
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
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
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."