Wow, even though I already had over a decade experience under my belt at the time this was written, it still feels hopelessly archaic. Granted, the problems outlined were (and probably still are) real at certain types of companies, but the proposed solution is so wrong-headed.
The only honest takeaway here is that if you want to write software as a large company, then you need technical management. The foundation of good engineering work is competence and trust; in other words, the team must have the chops and there must a trusting direction with management (both ways). All this faff about documenting every last detail and have it reviewed by "experts" for $100/hr is the most ridiculous kind of bunk. There is a time and place for technical documentation and its review, but not as a solution to a fundamentally broken team.
"Terrible" is often emotionally laden and unprofessional. Better to simply specify the ways in which it fails to meet general standards or the stated requirements.
Because it’s a waste of time to say it. It’s entirely emotional and subjective and not helpful.
Now, instead of listening to you and giving you a response, this person is in some kind of an internal spiral. They will either push back, equally emotionally, or they’ll shut down. It’s a rare bird who will take that kind of feedback in stride. Even if you find one of those, you’ve most likely lost personal capita with them in the process.
Stick to the facts and learn to manage your emotional feedback. I came up in these kind of “blunt” cultures, and it was a terrible waste of time and energy, and it took a long time to unlearn these patterns of behavior.
IMO everyone produces some terrible work early in their careers. It is part of the learning/growth process. I wouldn't want to work for a manager who told me "This is terrible", nor would I dream of saying that to an employee of mine, it would unnecessarily break their spirit. I think that would cultivate the type of environment where people are afraid to voice their opinion for fear of being embarrassed, etc.
"this is terrible work" is a childish outburst, not a meaningful criticism that could be used to improve anything. The people engaging in that kind of behavior are the ones who sabotage building things.
It's always hard to balance delivering fast vs delivering quality software. I've been involved into multiple similar reviews were I'm coming as an outsider and assess existing platforms. Both what people will typically call "legacy" but also "modern" (read microservices) ones. Without a clear governance and consistency any of the approaches will end up with similar issues: performance, scalability, hard to extend/maintain, excessive use of tooling (there was one platform that kept all logs in a log aggregating tool, but didn't have any way to get the raw data). You can be fast and consistent/have a clear vision. No need to get it to production "no matter what".
> Cheaters won't spend their efforts to fix it to release
What reasons would developers have to 'cheat', as you call it? If they are experienced enough to recognize something like problematic N+1 queries, why wouldn't they rewrite them, regardless of the effort? Further, what reason would they have to write them in the first place, if they know better?
The only honest takeaway here is that if you want to write software as a large company, then you need technical management. The foundation of good engineering work is competence and trust; in other words, the team must have the chops and there must a trusting direction with management (both ways). All this faff about documenting every last detail and have it reviewed by "experts" for $100/hr is the most ridiculous kind of bunk. There is a time and place for technical documentation and its review, but not as a solution to a fundamentally broken team.