Hacker News Reader

Comment by jdw64 | Hacker News Reader

Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt.

Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.

View on HN

At this point, I think 5 or even 10 years would be a more appropriate number (except for minor updates over things that have been around for a long time).

I clearly remember there was a time coffeescript looked really like the future of javascript.

> "only use things that have been around for at least three years"

Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.

Just curious, what kind of work have you done where this conceit feels valid in your mind? My career, at least, feels like an exception to this, but I guess its conceivable to me that it could be otherwise. You have had a lot managers push newer frameworks/technologies on you? Is this more VC startup land, or something else?

Maybe I'm old, but at least in web dev it doesn't feel that long ago that someone had to argue for, e.g., Vite over webpack, Svelte over React, etc..

What kind of work have I done? All kinds of webdev and SWE-adjacent roles since the late 90s. Startups, scale-ups, SMBs, huge enterprises. FT and contract / consulting roles (w/ titles containing words like "Principal", "Architect", "Director" and "VP").

In a world where everyone followed rigid advice to stick to 3yo+ tech, Vite wouldn't exist, let alone have people to argue for it. Nor would the web, for that matter.

I'm _not_ saying "chase the new-and-shiny for its own sake", and I don't recommend introducing immature or untested dependencies in production. But it's essential to learn how to gauge the quality of a mature solution -- and IME the only way to do that is to have something to compare it to (ideally, something newer and better). Develop an instinct for separating the signal from the (considerable) noise by trying things. Newer isn't always better, but the arc does trend towards improvement. Dev tooling is rife with examples, and a great place to start.

As for "You have had a lot managers push newer frameworks/technologies on you?" On the contrary -- I've had managers wedded to outdated cruft that threatened to drag the whole enterprise down. Resistance to change is sometimes fear masquerading as wisdom.

Finally, note this whole thread is in the context of an update to the MCP spec. In the world of AI, 3 years might as well be 3 centuries.

Keeping up with changes is valuable.

At the same time, it's often smart to avoid putting things into production that haven't matured or demonstrated staying power.

Or, to badly mangle Postel's law:

Be liberal in what you learn, and conservative in what you deploy

Sure. No real disagreement here. (See also my replies to peer comments here.)

Three years is nothing, what kind of work do you do where you need something released in the last three years?

And I’m not OP, but I would assume the senior developers made a distinction between try and use.

What models do you use in your work?

Depends on the thing.

I had to give maintenance to things people deployed to pad their resumes with "shiny new thing", and it was not fun.

If you intend to deploy and leave that as legacy for some poor shlemiel, sure.

If you intend to stay and actually keep things running, it's much better to use tried and tested stuff.

Trying is not the same thing as advocating for and implementing products features using unproven tech.

Ive been in this industry nearly 40 years and I have seen many many people push new tech and later fail to deliver and suffer the consequences.

Experiment where it doesnt matter, everywhere else boring and old is a virtue.

I hear you. "Choose boring tech" is a reasonable default stance. IMHO, designing resilient systems in anticipation of change, and finding ways to incorporate the best of what's new, is the nature of the game and what helps keep it fun after all these years (closer to 30 vs your 40, but I'm no spring chicken).

Reply on news.ycombinator.com