How competitive programming ruined, then fixed, my code reviews.
I used to be the kind of reviewer who would suggest algorithmic improvements in every PR. “This could be O(n log n) instead of O(n²),” I’d write, and then I’d paste a fifteen-line rewrite that saved maybe four microseconds on a function called twice per deployment. My colleagues learned to dread my reviews. I thought I was being thorough.
Competitive programming taught me to see algorithms everywhere and runtime never. The scoring function is wall-clock time, and the difference between O(n log n) and O(n²) is the difference between passing and failing. I carried that instinct into production code, where the scoring function is entirely different: it’s whether the code is understandable at 11 PM by someone who didn’t write it.
I still suggest algorithmic improvements. But now I ask three questions first. Is this on a hot path? Does the improvement make the code harder to read? And would I bet my own weekend on-call shift that the optimization is correct? If the answer to any of those is “no” or “maybe not,” I leave the comment unwritten.
The real lesson of contests wasn’t how to write faster code. It was how to distinguish between code that needs to be fast and code that just offended my aesthetic. The former gets a comment. The latter is my problem, not the author’s.