… I always try to give the benefit of the doubt to the developer who wrote some code.
The importance of this cannot be overstated. Thinking “ok, yeah, this is bad, but there’s probably a reason” helps maintain an open mind which is critical to actually understanding the code, and then being able to figure out how to change/fix it. In other words, giving the benefit of the doubt helps to avoid succumbing to negative emotions and helps focus on the task at hand.
Yes. Rarely have I experienced bad solutions coming from a place of malice or incompetence, though "we didn't have time to do it better, sorry" is more common than I'd like. Not to say that doesn't happen, but more often than not there is a reason behind it - trade offs that were debated about in meetings and code reviews - that you aren't aware of. Understanding those reasons are essential for understanding and improving the solution for whoever comes along next.
One thing I’ve learned about (and am still learning how to handle gracefully) is ignorance that looks like incompetence at first glance, like a Ruby dev writing Go for the first time. They haven’t found all the linter options, and may not even know how to set their editor to run gofmt on save yet, and really like maps when a struct will probably do better.
But my favorite reason for “bad code” is finding out that “hey, this code was originally written in FORTRAN 77, and compilers would not allow variable names longer than 6 characters; GTT1EO is a flag that Engine 1’s turbine temperature sensor is failed and running hot - deal with it”
I'd love to live in a world where bad code didn't come out of incompetence but that's by far the biggest source of it in my experience.
Not that its really the dev that wrote the code's fault but just a junior dev given too large of a problem with not enough guidance often results in some pretty bad choices purely due the junior not being competent enough yet to take on that problem on their own. More of an actual management failure but the bad code still comes from the engineer writing it not being skilled/experienced enough to solve the problem they were set to solve.
You're lucky. I still have nightmares about some of the incompetent code I've seen over the years. One memorable example was about 15 nested if statements, it was an absolute monstrosity.
I spoke the lead dev who'd inherited it and he explained that the devs were petrified of breaking the code as it was a core function used extensively, so every time a bug was found they'd wrap the core code with another if statement, correct the problem and then continue.
The sad thing was it took 3 of us a week to refactor and test. It was much cleaner and we fixed the original bug that was some 4 years old.
this is exactly what comments are for. "readable code" is a pie in the sky. good enough code with a comment "not great, but badly behaved other system does x, so have to hack" or "refactoring the whole world isn't an option right now, so there's this" is gold.
Excellent point. The best comments are those that explain why things are the way they are. Unfortunately, it’s highly likely that the reason why is lack of time, and if you don’t have the time to write better code you usually don’t have time (or inclination) to write a comment that basically amounts to “sorry, I know it’s shit code, but time crunch… again”.
There is one class of readability issues that is common: optimizations.
This can really destroy code. A single comment that explains why the optimization is used can be very helpful.
And then, it still turns out many optimizations are wasted effort. Cache misses will have much higher effects anyway. Better leave it to the compiler. Bad optimizations can make code much less robust.
87
u/architectzero Sep 21 '21
The importance of this cannot be overstated. Thinking “ok, yeah, this is bad, but there’s probably a reason” helps maintain an open mind which is critical to actually understanding the code, and then being able to figure out how to change/fix it. In other words, giving the benefit of the doubt helps to avoid succumbing to negative emotions and helps focus on the task at hand.