3 ms·
> "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 car
by chrisweekly 1mo ago
> "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.
- beepbooptheory 1mo agoJust 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..
- chrisweekly 1mo agoWhat 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.
- Bjartr 1mo agoKeeping 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
- chrisweekly 1mo agoSure. No real disagreement here. (See also my replies to peer comments here.)
- techpression 1mo agoThree 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.
- chrisweekly 1mo agoWhat models do you use in your work?
- surgical_fire 1mo agoDepends 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.
- DarmokTanagra 1mo agoTrying 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.
- chrisweekly 1mo agoI 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).