I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.
Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more.
I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
