If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
These projects were the cornerstones of businesses sized from a couple dozen to a few hundred employees.
the point about being around for longer to see the effects of your mistakes assumes you're not a cog in the wheel.
> the point about being around for longer to see the effects of your mistakes assumes you're not a cog in the wheel.
Ideally—yes. In practice, decisions that should take QARs into account but don't are made by almost any IC level. I have seen systems designed by interns. You could say it's a company culture problem, and I would partially agree. On the other hand, tech companies have a tendency to lean into empowering ICs and so what ends up happening is that inexperienced engineers design systems that are only reviewed by overworked (and maybe not particularly experienced and/or motivated) senior ICs.
Startups are so chaotic and fast-paced that one usually only needs 1-2 years (if not less!) to see how earlier decisions pan out. Very frequently the stack and the codebase undergo monumental changes in that short period of time due to the changes in business requirements and scale.
Mega-corps are vast engineering efforts with hundreds if not thousands of daily contributions. While I could technically go back and try to evaluate my choices from 6-7 years ago, it would be fairly hard to decouple my individual contributions from the changes that happened afterwards (functional/non-functional feature requirements changed since then, the codebase is unrecognizable, etc). 6-7 years is just too long of a time frame for certain eng areas (web/native product is a primary example). Saying that, I can imagine that there are slower-paced areas where this time frame is more relevant, e.g. database engine development.