by KronisLV | 2025-11-30 15:25:20+00:00
> your honest assessment will likely help both the coder and the manager

While I'd like this to be always true, there will be cultures and even individual egos for which this will never be true.

Someone who's considered a senior dev in the org might dislike your assessment (regardless of what external resources and industry practices and any number of people's experiences say) and might turn your suggestions for how to make their code a bit better into a bikeshedding argument until either one of you tires out and gives up (no relation to which opinion is even right or what's best) or the manager gets pissed off at the both of you and has to intervene (not necessarily thinking badly of you) and the traditional methods like "pulling rank" wouldn't work either if it's a senior engineer. Even if you do everything right in how you approach it and frame it positively and everything else.

In part, this might be because there's no one set of guidelines for "this is what good code looks like", especially because of how fast moving and disjointed and underregulated the whole craft is (might settle down in a century idk). It might also be because that mess leads to vastly different opinions on what's good (e.g. how some people take SOLID/DRY as gospel, others don't, to the point where WET is a thing). And some people just don't care and don't see things the way you do.

Concrete example: once saw a bit of code that had nested service calls. Suggested to the person that this will lead to the N+1 problem in database interaction. They said that it's okay because the other code is written like that in the app already and that this code is easier to reason about. A month later I had to actually show them cache hit/miss statistics after implementing caching as a band-aid on top of the nested code because there were deadlines and nobody could rewrite the whole thing as a DB view. In that particular case, there wasn't even mean exchanges or whatever, just endless bikeshedding about whether something is needed or not that lead nowhere, even when graphs and data were presented by me.

Same for opinions on how much logging or code comments should there be, stuff like dynamic SQL generation vs DB views and a bunch of more nebulous things, though often with a quality of life impact instead of something so concrete as above, where pages started taking 20-30 seconds to load once the DB was properly populated with a lot of data.

So yeah, absolutely do your best effort and try to orient yourself towards open minded egoless developers in a cooperative environment. But sometimes that's not what life will give you and you might just realize "hey, naah, person X is the problem 100% here but it might be possible that I cannot do anything about it in this environment". I've also been person X, of course, but in general I think more honesty would be good.

Like figuring out why our national e-health project failed so badly as it did and putting the people responsible for the failure in jail after a proper root cause analysis is done, if they didn't seek proper remedies in an adequate amount of time: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/09.04...