I simply ignored the first line and appreciated the rest of the response because it had good actionable information. I wish I had older mentors in engineering and CS when I was 20-35yrs to tell me their war stories and point me to promising areas of work.

This constant outrage at every perceived slight is a recent phenomenon of the Facebook/Twitter decade and it is suffocating.

Not at all, what the "30 year" commenter did is even mentioned in the HN guidelines. See the section In comments:

> Be kind. Don't be snarky. [...] When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

https://news.ycombinator.com/newsguidelines.html

Assume good faith, and try to get the point.

"That is a question that a junior developer would ask" is not on the same level as "that is idiotic".

If you're asking after "hot new tech" it's probably because you haven't been around long enough to see how tragically wasteful the "hot new tech" treadmill is. The "30 year" comment manages to communicate that very directly.

Or, perhaps, because you enjoy playing with “hot new tech”.

> This constant outrage at every perceived slight is a recent phenomenon of the Facebook/Twitter decade and it is suffocating.

Frankly, the OP said something rude. It's not a "perceived slight". It was unnecessary, offensive, and presumptuous. Why shouldn't they be called out on their behavior? Congratulations on your ability to ignore the first sentence, but that doesn't excuse OP.

Lol —— CANCEL THEM ALL!

#RickyGervais2020

Not OP, but I think there is a reason for it, although I do agree it might have been better phased.

Assuming Good intention, ( Which I think OP is ) sometimes it is a little hard for people under certain age to understand certain things. It is simply a reflect on our stupidity that when we were young, we too were also singing, praising and hyping all the shiny tech. And we were burnt by it.

So it was more like a suggestion to those under 30, here is what I did, I was stupid. and if you are under 30, please consider my follow experience as some sort of guidelines.

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.

I thought it was valuable. Sure, it could have been worded differently, but it was also fine as is.