4 ms·

I've heard that exact same adage used in reverse by those "6-7 years at the same company" engineers against engineers with careers of shorter stints. The logic

I've heard that exact same adage used in reverse by those "6-7 years at the same company" engineers against engineers with careers of shorter stints. The logic being that if you never experience 5/6/7+ years of continuous ownership, you never get to see how your decisions pan out, and you miss out on other forms of longitudinal experience. 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.

dilyevsky 3y ago
What are these 7 years projects? Sending a man on the moon? Most large software projects take 2-3 years or else they run serious risk of getting cancelled completely
- classified 3y ago
  Webshit has a famously short half life, but there are many companies that want real products with real support and development over many years.
- mcbishop 3y ago
  Your question gets a SaaSy reply.
- deleted 3y ago
  [deleted]
- tomasGiden 3y ago
  Very much depends on what you are working on. What SaaS is ever stopped being developed and doesn’t need ownership after 2-3 years? Products with embedded software might ship in 2-3 years but many still need bug fixes and new features long after that so therefore needs ownership.
  - dilyevsky 3y ago
    If it’s a saas then original mvp will take anywhere from 6mo to 2y then it either dies or scales in which case it’ll be nearly rebuilt again with a much larger team this time. Therefore you will not learn anything on year 4 that you didn’t already learn in year 3
    - spiffytech 3y ago
      As a data point, I've worked at several companies powered by software they'd begun writing ~8–20 years earlier. No rewrites. These projects were the cornerstones of businesses sized from a couple dozen to a few hundred employees.
- CipherThrowaway 3y ago
  Is this an honest question or one of those HN social status signalling things where we all feign unfamiliarity with what software development looks like outside of the YC bubble? Not snark, seeking clarification.
  - 1920musicman 3y ago
    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 3y ago
      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 3y ago
        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.
  - 3y ago
1920musicman 3y ago
That's an interesting point. Can't say I agree based on my experience in both small startups and mega-corps. 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.

dilyevsky 3y ago

What are these 7 years projects? Sending a man on the moon? Most large software projects take 2-3 years or else they run serious risk of getting cancelled completely

classified 3y ago
Webshit has a famously short half life, but there are many companies that want real products with real support and development over many years.
mcbishop 3y ago
Your question gets a SaaSy reply.
deleted 3y ago
[deleted]
tomasGiden 3y ago
Very much depends on what you are working on. What SaaS is ever stopped being developed and doesn’t need ownership after 2-3 years? Products with embedded software might ship in 2-3 years but many still need bug fixes and new features long after that so therefore needs ownership.
- dilyevsky 3y ago
  If it’s a saas then original mvp will take anywhere from 6mo to 2y then it either dies or scales in which case it’ll be nearly rebuilt again with a much larger team this time. Therefore you will not learn anything on year 4 that you didn’t already learn in year 3
  - spiffytech 3y ago
    As a data point, I've worked at several companies powered by software they'd begun writing ~8–20 years earlier. No rewrites. These projects were the cornerstones of businesses sized from a couple dozen to a few hundred employees.
CipherThrowaway 3y ago
Is this an honest question or one of those HN social status signalling things where we all feign unfamiliarity with what software development looks like outside of the YC bubble? Not snark, seeking clarification.
- 1920musicman 3y ago
  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 3y ago
    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 3y ago
      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.
- 3y ago

1920musicman 3y ago

That's an interesting point. Can't say I agree based on my experience in both small startups and mega-corps. 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.