[kybernetyk]

Some years ago I was doing paid for code reviews. I learned many things but one particularly relevant to this article is: You can only tell if code is shit after you have dug through it for at least a few days.

Sure there are the obvious mistakes like non-idiomatic code style. But that's easy to spot. But for anything that is related to the problem domain and not the language itself you need to dig deeper. Because there might be a very good reason why something is done the way it is done. And later you might think: Hey, that's actually a pretty good solution.

Wading through piles of code by dozens of different developers made me humble and nowadays I think twice before calling something bad.

[pivnicek]

Indeed, I came across a last_day_of_the_month SQL implementation today that I showed my colleague who's instinct was that it was shit, but upon closer inspection, it seems quite clever.

[Too]

Checking the history of the file can also be quite revealing. First version usually looks good. Later, most commits are just trying to squeeze in new functionality by changing as little as possible of the existing code. 20 check-ins later the original design is no longer relevant and mostly consists of exceptions because nobody was brave enough to refactor. Getting refactoring approved could also be hard by in certain cultures and organizations because "why change something that is proven to work in production"