In my experience people like this think in terms of tools they can use. They read an article about some shiny new thing and watch a conference talk about it and think "wow thats cool, what can I use it for?". Often times their shiny new tech will actually solve a problem, but it might be far from the best solution and it might bring a whole host of other problems.

IMO the key to reason about things like this is to ask "What problem are we solving?", clearly identify it, then brainstorm a list of potential solutions (including whatever shiny new toys this dev wants to use), then run through each solution and list the pros and cons.

Also, try not to start out hostile to the shiny new tech, let the proponent of it do all the talking, just ask questions but don't argue against it, save that for the very last minute. Otherwise it could go a bit sour if you are both clearly on opposing "teams". Finally, try asking the question "what are the downsides of this new technology?".

There was an excellent article published here in the last 6 months about developing in the "problem space" it was about exactly this kind of situation. I just wish I could find a link for it but I can't. Maybe somebody else remembers the title of this article?

The question is, how did it get so far? If you are leading the project, those decisions wouldn't go by you quietly.

Generally, when making a choice, try to establish a process of evaluating technology. This requires your co-workers to bring arguments other than "it's new and shiny".

We've done this in our company for all major decisions in our tech and tooling stack and in the end, it gets buy-in from all parties (or "disagree and commit", which I quite agree with).

I probably should have been clearer in the original post, but I put "lead" in quotes for a reason. We don't really have a explicit lead on the project, but I was the one who pushed for the project and handled most of the upfront system design work. It's not my project, but it feels like my baby.

You could be direct with the coworker and call them out on their ulterior motive to pad their resume, but if you've misjudged their motive you'll look silly. If being direct is not an option, attempts to dissuade the coworker from using shiny tech overall won't work. Two suggestions --

* A more granular pushback is needed, for instance, "we shouldn't be using package X because it's not MIT license" or "the package has a higher memory footprint for what we need, have you tried package Y instead."Document these pushback arguments into a checklist to ensure your coworker has checked off before using new shiny tech.

* Convince others rather than your coworker of arguments against using shiny packages, articulated in terms of delay, extra cost, problems down the road, etc. It's an indirect approach but you won't be alone in pushing back on the coworker's scheme.

I have been working with a younger colleague doing just this. Résumé driven dev. Every week in the daily meeting, he just feeds us with an unknown API that no one had ever hear of. In the first week I was impressed but over time, I discovered painfully he did not know, almost all the time, the thing he was talking about. Usually I actually tried these new API but discovered latter, whenever I blocked on a technical aspect, that he had never actually used it.This shocked me...

7 month later we do our daily meeting, but no one really cares when his turn is on and he talks about a 'wonderfull new API' that 'do the job better... because we know he doesn't know what he is talking about. His resume is a wonderfull resume, but I discovered recently he had been working in my company as... à salesman. This clicked in my head, : resume driven dev is like salesman resume : Shines allright but don't expect to deliver.

Recently, I left a company where resume driven development resulted in projects being months behind, buggy, hard to work with, and over complicated.

The people who chose to use unproven tech for uses cases it wasn't designed for were obviously promoted.

I don't know if there is a good way to deal with the situation if your managers are hands-off.

If you are the lead, call a meeting, explain the tech stack that will be used, explain that their performance will be judged based on meeting deadlines using said tech stack, summarize this meeting in an email to your leadership, in this email explain meeting deadlines depends on using the tried and true tech stack you chose. If they refuse or come up with some contrived reasons why your plan won't work, methodically and politically knock those reasons down, institute daily stand up meeting where they have to explain progress or blocking issues. If employee misses deadlines they go on probation and then get fired. If management does not support you, find a new job then give your notice.

If people got fired for missing deadlines in software development everyone would be fired.

At some point at every company they pick a stack and go with it.

The only thing we have is job skill management while working for others. Careers have become just that. And the shiny tech goes well on resumes, and the managers probably don't mind it if he's been allowed to put thousands of dollars of company resources to do it. Odds are that the management wants to sell it as being based on the cool new tech to help justify the project, aka we couldn't accomplish this with old tools, or we're staying up with the ecosystem. The point is that there are a lot of decisions that don't propagate down the chain.

Yep, I've seen it before, its part of "short timers syndrome".

Frankly I've built some tools with weird thing (a lolcode CGI was the oddest) but when you're doing something orthogonal to what your team is working on its counterproductive for everyone. The team or project manager should have a chat with that person. If they don't fix the problem, you should probably find a new gig or ask for a transfer.

It sounds like you do not believe you can stop it.

Given that, try to limit the damage.

Allow them to do 1 day a week on shiny but must do the rest on mainline.