Hacker News new | past | comments | ask | show | jobs | submit login

Sure, ageism is bad. I'm in my 50s too and I've seen my share of hype cycles. But I think there is a danger of overreacting to the unbridled enthusiasm of younger people.

Every new cyle comes with ideas that are similar to what we have seen before. Sometimes I find myself thinking, OK, been there, done that, doesn't work. But I suspect that there is a sort of experience bias that lets me see the similarities far more clearly than what's new and different.

In every cycle people claim that it's nothing new and yet, with hindsight, we often find that small differences were important enough to change the world unpredictable ways.

I think it has value for older folks to contribute arguments and perspectives, but let's not be too self-righteous about it. Similar ideas can lead to very different outcomes in a different context.




> small differences were important enough to change the world unpredictable ways

I completely agree with this. I’m also in my 50s but I lean techno-optimist. Whenever there’s a new hype cycle, I’m looking for those small differences that might overcome the hurdles we’ve seen in the past. For example, the PicturePhone was demoed in 1964. Now we’re all on Zoom constantly. I’ve lived through many AI hype cycles. The current LLM craze is significantly different from past exuberance. LLMs aren’t perfect but they are remarkable when they work.


Sinclair C5 vs modern e-scooters and other lightweight e-mobility is another good example.

Same fundamental design approach, but needed another 25 years of improvement in battery and motor tech.

IIRC the first electric car was proposed in the 1920s or thereabouts.


One problem with ageism and youth bias in the industry is that we are still heavily populated with devs more interested in hopping on the latest framework they heard about at a conference than in actually solving users problems.

The amount of "how do I justify a rewrite because our tech stack is bad" posts you see in your typical reddit/etc programmer forum would remind you of this.


> devs more interested in hopping on the latest framework they heard about at a conference than in actually solving users problems. The amount of "how do I justify a rewrite because our tech stack is bad" posts you see in your typical reddit/etc programmer forum would remind you of this.

These are old complaints.

My dad worked in the tech industry since the pre-Mosaic days, and even then you'd hear the same arguments and complaints.

The same way people complain about React today is the same way people complained about Spring, and then about how old school C programmers complained about C++ with it "training wheels", and BASIC programmers complaining about "OOP", and old school networking types complaining about built-in TCP/IP instead of spinning up your own stack.

Technologies and frameworks change. That's how tech always works. Sure I can demolish a building with a sledgehammer, but why not adopt dynamite or bulldozers if it efficiently solves the problem.

At some point, all these complaints are just Ludditism from techies who didn't upskill and/or are unable to communicate.


I think the point wasn't against upgrading or refactoring to something better, it was about the youthful inclination to do that for its own sake.

Us older heads know how often it goes wrong, and know that without a tangible user benefit or commercially positive outcome... It's just busy work.


What's fascinating, and probably points to how young&naive IT org management also tends to be is ... how many let themselves be sold on these solutions.

Oh you are going to rewrite established solution X in Y in 2 years with 5 devs, and it's going to solve all of the problems we have in X, awesome!

Ignoring that solution Y is so new that the guy proposing it has never actually delivered an enterprise solution in it. And since they just got hired, they have no idea what the user facing problems X is actually exhibiting. Often the problems with X are organizational, managerial, and prioritizing. Switching tech doesn't magically change the decision makers.

Invariably hiring a guy who has a string of 18-24 month jobs on his resume, which, uncannily, is the typical runway of a Greenfield re-write project before heads roll.


No, the point is to weigh the pros & the cons.

Not every tech is the new Spring, OOP, etc.

Not every project benefits from being immediately migrated to the new thing.

Once you've been through a few train wreck "get on the latest thing" projects, you see the benefit of actually delivering to users, regardless of whether the tech is bleeding or trailing edge.

If you are a small tech org, the benefit of being able to hire a team of people who have SUCCESSFULLY delivered with TechX (which is 3-10 years old) can outweigh jumping onto the latest thing.


Im 42, been doing this for over 20 years, and I hate dealing with C++, React and Spring, for what it’s worth.


I was there when both react and spring were both and they were both revolutionary tools, especially spring, the only people unhappy with it were the J2EE vendors, us plebs were calling out the name of the lord.

I think the problem here is the usual bloat and enshitification that these tools eventually devolve to due to their success. People get so used to them they want to use them for everything and create this universe where you now forgot why they were created and the places they were useful.


With backwards looking rose tinted glasses, we can remember all the good tech people were slow to adopt.

But what about all the mis-adopted or abandoned tech that blew up projects.

The amount of stuff ported to NoSQL that had no business doing so. UML/Nocode tools in the 90s.

A lot of the push away from Java only for a lot of performance considerations pushing devs back to it. Sorry about the projects that got force migrated to Scala since it was, briefly, The New Thing.

The one man webdev app deployed firmwide on some brand new framework which was immediately deprecated.

Again, nothing wrong with any of these tech choices if they were driven by actual user requirements which exceeded the current implementation tech. But most of us know that is rarely the actual motivation of devs...


While UML/Nocode tools were (and remain) a mistake, I don't think NoSQL was one. I might dislike some solutions in general but stuff like Redis, DynamoDB, Cassandra, Parquet and many others have produced a renaissance in databases that we would not have seen if it was all in the hards of the relational database vendors.

MongoDB easy (in a way) replication put every single database vendor on watch and led even PostgreSQL to improve, i think we live in a different environment right now due to all the experiments the NoSQL folks made. It might not have all panned out but I think the whole thing was a huge positive for the market, people stated to experiment and try new stuff again instead of "oh it doesn't look like a relational model, it sucks".




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: