Accepting the code of others
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."
Written by Ian Whitney
Related protips
3 Responses
I couldn't agree more. I especially like how you point out the empathy part of things. I rarely if ever think about the code that I am trying to understand in terms of what time pressures or whatever circumstances the programmers were in at the time. I'll have to make a note to have this more in mind when I'm at work. Thanks for the post man.
I agree too, but there are solutions! First of all, ask someone for the reason of some implementation choices or why something seems wired (if there is still someone to answer that!).
Most of the time you'll have an answer like this one: "yes we were in a hard ruch with a customer and nobody changed it after". Just answer "ok" and go ahead in such cases.
But sometimes, you'll have a question to your question, "why is this newcomers asking me this strange question?!" and then you can discuss and share some experience (if any) and point of view and then improve the overall quality of the code AND the team (or your own if they were totally right)! which is good!
Accept wrong choices, discuss them when you have opened mind interlocutors and listen constructive answers are my best advices around such situation.
Great note! Thanks for sharing. It reminds me of this thought by Pete Warden:
"Over the years I’ve developed tremendous respect for the depth of subtle requirements that have been baked into legacy applications through countless undocumented changes. When I was younger my first instinct was always to rewrite them, but after discovering by painful experience that the complexity of the old software almost always reflected the poorly-articulated complexity of the users needs, I learned to love shims like these." (http://petewarden.com/2013/10/22/five-short-links-54)
