Hacker News Reader

Comment by zoom6628 | Hacker News Reader

As an older person in tech I see ageism alive and well in tech. The young ones don't understand why we oldies roll our eyes at hearing the 13th iteration of "this is ground breaking new idea" or when we gently interrupt a personnel or strategy discussion with a few use cases from the past to illustrate the pending shit-storm being proposed.

Time for the world realise this tech stuff and programming has been around about 100 years! Let that settle in. A century of code. So the tech population is now clever and curious 8 year olds all the way through to 80+ curious and seasoned Algol programmers. And we ALL have value.

#endofrant

View on HN

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.

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

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.

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.

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

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

What were they coding on in 1924?

Tabulating machines were developed by IBM’s predecessor for the 1890 census and used in various forms until evolving into punchcard computers.

The Jacquard Loom predates that by over 80 years. I'm sure we can stretch the definition further and go back even farther.

Things were a bit more collaborative back in the day.

https://www.jpl.nasa.gov/edu/news/2016/10/31/when-computers-...

The engineering knowledge that went into the WWII fire control computers was clearly a form of programming.

You will also notice the words "computer", "input", and "output" are used without needing to be explained.

https://youtu.be/s1i-dnAH9Y4

Ada Lovelace was coding in 1843.

How have you kept the ageism from scaring you off or just turning you off to go to another industry?

> The young ones don't understand why we oldies roll our eyes at hearing the 13th iteration of "this is ground breaking new idea"

Why not constructively contribute by explaining what could be different for the idea to work this time? Or if you hate innovation (i.e. retrying age old ideas slightly differently - hoping this time it will work), why don't you pick another industry?

Reply on news.ycombinator.com