I ruin developers’ lives with my code reviews and I'm sorry

Once you become competent enough to identify clean code, understand that your perception of clean code is colored by your own experience and current mental context. As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago. After you've been at it for a couple decades you will come to the horrifying conclusion that your mental model is always incomplete, the human brain is weak, and it's hard enough to not get caught in the wrong local maxima without facing up to the immense challenge of choosing between global maxima in the incomprehensible problem space where software meets human needs in the hybrid meat/mental/cyberspace ecosystem where they exist and evolve over time.

The other implication is that no two engineers will ever see things the same way. It's not purely about technical strength—a weaker engineer might come up with a better solution given more time to think about it, or due to some other blind spot or skillset gap from the more senior engineer. Also, there are many issues of style and perspective where the important thing is consistency more so than some specific choice. In those cases there's a high risk of bike-shedding, and it leads to a fundamental truth of large scale software development which is that in practice you will never get everyone on the same page. Of course there are controls for this, but unless you have the budget and operational scope constraints of NASA (or perhaps medical device manufacturers) you can't actually enforce this without losing so much development velocity that your company is utterly uncompetitive in the market.

As you move up the seniority and scale ladder to larger projects and architectures, you will realize that you still only have 24 hours in a day, and it doesn't matter how smart or how right you are, the only tool in your built to increase your impact is a simple cliche: "pick your battles". There is absolutely no upside in nitpicking every line of code that could have a conceivable improvement. If you want respect from your colleagues, you need to get good at filtering what is important and what isn't, and only pointing out the most important issues, and doing it as early in the process as possible.

You know what's worse than the wrong abstractions? Copy and pasting your inline-styled div with a zIndex of 99,999 for the fifth modal in a row because you can't be assed to write a damned display component in anticipation of the next time you'll need to put a Modal together.

I appreciate the reminder and the helpful tone of your comment in general!

> As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago.

Just checked, and my code from 6 months ago looks identical to what I write at work. My programming style went through a few different phases but its variability has mostly leveled off since I've started writing in a mostly-functional style.

> It's not purely about technical strength

It's simple stuff like putting together a base Modal display component for re-use instead of copy/pasting that div with the inline-styled zIndex of 99,999 for the umpteenth time.

> As you move up the seniority and scale ladder to larger projects and architectures

I hope to side-step a lot of those pitfalls by exiting the ladder altogether and starting my own company where I take a fine-toothed comb to the process of onboarding new hires. Time will tell if the demands of scaling a company end up sidelining my desire for good hires, but software is still a somewhat nascent field, so the sky's the limit if you ask me!

> the human brain is weak, and it's hard enough to not get caught in the wrong local maxima without facing up to the immense challenge of choosing between global maxima in the incomprehensible problem space where software meets human needs in the hybrid meat/mental/cyberspace ecosystem where they exist and evolve over time.

This is a good way of putting it and it's why it's the problem I've chosen to work on for my first product as a startup founder. I call it Pidgin, and my vision for it is a GUI tool for refactoring and even writing code in a more deterministic and reliable way. I spend my mornings before my day job working on it. I think the fact that I think about code quality intensely at all hours of the day probably contributed to the emotional tone of my initial comment. :)

One of my peeves is a review that points out a bug/incorrectness without offering proof, or suggesting the fix/correct way. The reviewer might observe a code smell, but it's so much better dealt with a question-comment, e.g. "did you try?" vs "this looks wrong".

I generally aim to make every comment a question ("can we..."), and not make assumptions that the author didn't think of something already. Unless I just stating an objective fact that is clearly unknown e.g. "this duplicates library function x...".