[1920musicman]

My understanding is that they meant actual individual projects within large companies never take this long. So "projects" as in "features" that ICs work on. I agree with that point, I hardly ever get to go back an evaluate the decisions I made a year ago. Ownership changes happen all the time, plus refactors, stack upgrades, other code changes... No one I know gets to work on a single self-contained feature/area for 6-7 years straight.

[PH95VuimJjqBqy]

If you're working in a company that large then presumably you have architects and leads who are making broader decisions that you can see the effects of.

the point about being around for longer to see the effects of your mistakes assumes you're not a cog in the wheel.

[1920musicman]

I don't think this article limits the definition of architecture exclusively to very broad systems, like designing a new graph DB service. Architecture choices happen at all levels, and true systems architects are seldom involved in that.

> 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.