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...
For further actions, you may consider blocking this person and/or reporting abuse
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?"