
Ask HN: How to Deal with a Coworker Practicing Resume Driven Development? - azdle
I&#x27;m working on a project with pretty significant potential impact where I work, but which is currently staffed pretty lightly. Myself and one coworker are the primary devs, with a few more working on things that are related. Overall the project has been going pretty well, if a bit slower than we&#x27;d all like, but recently I&#x27;ve been having some trouble. The other main dev&#x27;s habit of practicing Resume Driven Development is starting to get in the way of progress.<p>At first it was fine, the tech choices we both wanted lined up with existing tech in the company, we pushed a bit further with some choices, but it was all generally stuff that was in use by our team already. Then slowly but surely they have been pushing the tech choices further to places that don&#x27;t really make sense, but are rather just shiny things from the tech giants with use-cases that don&#x27;t match what we&#x27;re trying to accomplish.<p>Unfortunately the two levels of people up the chain of command from us are very hands-off managers, so despite the fact that my direct manager (different from his) has told him it&#x27;s not a good idea, he&#x27;s still gung-ho about his current foundational change of what we&#x27;ve been working on for months.<p>This is the first non-trivial project that I&#x27;ve &quot;lead&quot;, so I&#x27;d like to see it completed.<p>Before this devolves into me ranting, I&#x27;ll just ask, how have you dealt with co-workers that are more interested in playing with new shiny things they think will look good on their resume than working to complete something?
======
world32
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?

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

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

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

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

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

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

~~~
gtirloni
Please tell us how that is helping retention at your company.

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

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

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

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

