You read through the code. You read it again to make sure you understand what it’s doing. Your left eye starts twitching. You read the code a third time.
“WTF was wrong with the person who wrote this?”
I hate how often I react this way. It’s a quick default that’s hard to reset – immediate annoyance as if the developer or engineer responsible for writing whatever I’ve come across was scattering landmines.
It’s easy to shit on the people who came before you. They’re usually not around to defend themselves or provide context. It’s a common (but terrible) way to prop oneself up and display an illusion of competence. “Look how much I know, and they didn’t!”
It’s much harder to calm down, empathize, and think things through. An initial reaction of “WTF?!” is entirely valid (You’re gonna feel what you’re gonna feel.), but getting stuck on the frustration and not going further is unfair to your predecessors and causes you to miss out on learning.
How? vs. Why?
“How” a problem was solved/band-aided/kicked-down-the-road is usually the root of those frustrations, but the next step is thinking through the “Why” of the solution, which is often the source of useful information.
The code might be stupid, but there’s usually a reason. Maybe:
- Something stupid upstream brought its stupid with it. Alternatively, something stupid downstream needed more stupid.
- The dev/engineer was told to do it that way.
- The dev/engineer was getting pulled in 1000 different directions and needed to make a fast band-aid.
- The dev/engineer was doing the best they knew how.
- It’s actually not stupid. You just think you know more than you do.
That doesn’t rule out laziness or malice, but they’re much rarer and shouldn’t be the default assumption. When we run across goofy looking code and configs, we need to respect the constraints and context the person who wrote them faced.
Note: That the person might actually be an idiot is a real, intractable constraint. How would you have fixed that? Yelled “Be smarter!” at them?
Thinking through and learning the “whys” that caused the stupid will help you understand the context of the problem you’re currently facing. You’ll learn about not only technical pitfalls, but cultural ones as well. A lot of the stupid that shows up in code has nothing to do with the technical competence of the person who wrote it and everything to do with their manager or the company at large.
Grace and placing blame
How many times has the past version of you done something stupid that harmed future you? How many times have you looked at something you made a year ago and thought “What was I thinking?”
Like any skill, if you’re not embarrassed by some of the code and configs you’ve written in the past you’re 1.) an egotistical monster, and 2.) not getting better. Knowing that, allow some grace for yourself and the people who came before you.
When DevOps practitioners talk about establishing culture, one of the big elements they discuss is creating trust by not focusing on placing blame. That idea doesn’t just apply to your immediate co-workers. It applies to those in the past as well. Trashing prior devs/engineers can have the same effect as trashing the people you currently work with, it just adds a caveat to the way the team thinks about trust.
“Well, they’re not trying to throw me under the bus right now, but…”
I can’t say I’ve mastered this skill yet. Sometimes, in moments of frustration, I flat out suck at it. But I’m trying and that’s kind of the crux to all this. Everyone is trying, no one has arrived, and the more we empathize with the unknown constraints of those who came before us, the better off we’ll be.
Top comments (17)
My mantra is always "the person that did this did it with the best skills, resources, and knowledge they had at the time". I'll try to improve it with the skills, resources, and knowledge I have now.
Still works if that person was me.
resources being tech stack reqs, info, and time they had to get it done?
Yep! You can include "authority to demand better requirements, more info, and more time" as another resource that's sometimes missing.
That's all good and well until you come across this...
This is an actual pattern we found written by a former "senior" dev. In multiple places.
If that doesn't deserve a WTF, I don't know what does...
That's just generators +
yieldin pseudo-C, innit? xDThis point: "The dev/engineer was doing the best they knew how."
It's both realistic and a problem.
Let's assume first the person who wrote the code is a competent junior programmer at least (which as others have pointed out is not always the case). Even given that there is a massive gap in experience in knowledge between that person and a seasoned expert, and even moreso with the top programmer types.
It's often hard, from these positions of experience, to look at noob code and not cringe. Even if the code is correct it just wouldn't be the way they did it. It's not wrong per-se, but it's so far from their ideal solution as to be indistinguishable from wrong. This can apply to the structure of the code itself or the concepts and architecture behind it.
As to legacy code, it's sometimes okay to place blame. Occassionally it's good to callout people on their questionable coding practices, even those from the past. Assigning blame doesn't resolve the current issue, but it sometimes can prevent future issues.
Usually when I look at code and say "what idiot wrote this?"...it turns out to be me 😂
That is the best kind of lessons a dev can get from life :-)
And the most harsh, still I love to look at my old code and see how I improved over the years.
Yeah I recently rewrote something I wrote 15 years ago. My code now is much more structured and disciplined but the real shock was how much easier things are going from c#1 to c#7, all those little improvements over the years mean so much less code to write...and maintain.
The best therapy I found for this was delivering a project on a tight deadline :)
Reading through my code now I often wonder:
Nice post! I'm definitely guilty of this too. I've begun to hate the term "legacy code" because we're so quick to assume we're going to trash it and rewrite it, when chances are that's not the best move for the business. When I hear myself or someone else refer to something as legacy code with an eyeroll, I have this little voice in my head that says, "You mean that code that's solving a business problem in production?" Such a tough habit to get past...
It's really hard to get into somebody else's headspace, especially when it was weeks, months, or years ago. We don't have the context necessary to even begin to understand why it was done this weird funky way. But sometimes, we "fix" it, then context begins to reveal itself to us by way of bugs.
Yeah I dunno... blog.codinghorror.com/why-cant-pro...
That feels more like an organizational issue.
I am interviewing now. From five candidates four sent absolute rubbish. The task is very very simple.
Well, that’s way more difficult to be patient and emphathize than shit on the previous dev’s code. And yes, it’s a skill, not every person has.
Thanks for a great article.
Developing software is mostly psychology.
"What were they thinking when doing it that way?"