Yes, I might have phrased it better, but the intention was that at a younger age, you perhaps didn't yet have to upgrade a legacy projects with semi-obscure tooling where the original developers have long left; or have had to hack your code in a dirty way because the team leader might have read about e.g. an experimental frontend framework and a DB system that is in alpha status, but still orders the team to use it (to show the company that he/she is using cutting edge tech), so 80% of the time you're just figuring out how to get the system running instead of actually creating value for the project.

The first time it happened, I was like "it's fine, we can just rewrite modules A and B". As the years go by, I see it more and more. And now being a freelancer and having been in about about 15 projects, 1/3 greenfield and 2/3 legacy, I see a pattern.

Use the most appropriate tool for the task (taking into account not just the tech itself, but also the market, the maturity, possibility to find developers, etc), not the "hot tool of the day".

Yes. In the Parcel and WebPack threads I was reminded shiny new things often have edge cases that are unknown, not well known or known with no solution ( yet ). And I simply dont have the time and energy to deal with those, much better to wait for it to mature before jumping in.

If someone has worked on 20 projects, they have encountered edge cases, undocumented behavior, or incomplete implementation few enough times to believe 'it's just this framework / library / language.'

When you've worked on 100+ projects (and accumulated a few pathologically obtuse, worst-case horror stories), you realize it wasn't bad luck, but those landmines inevitably lurk in every younger stack.

Maybe you get lucky and don't step on one. But that doesn't change the overall risk based on their existence.

As Torvalds said in the spinlock back-and-forth: it looks simple, until you're looking back over two decades of patching edge cases that you never saw coming without the benefit of hindsight.

And having that experience makes you look forward very differently.

(At least where production, must-work code is concerned. Go nuts with toy / personal / experiment projects!)

> Yes, I might have phrased it better, but the intention was that at a younger age, you perhaps didn't yet have to upgrade a legacy projects with semi-obscure tooling where the original developers have long left; or have had to hack your code in a dirty way because the team leader might have read about e.g. an experimental frontend framework and a DB system that is in alpha status, but still orders the team to use it (to show the company that he/she is using cutting edge tech), so 80% of the time you're just figuring out how to get the system running instead of actually creating value for the project.

You're conflating age with experience. Yes, somebody that's younger is likely to have less experience, but the two words are not interchangeable. Their link is definitely not strong enough to begin guessing peoples' ages based on their level of expertise.