Ask HN: As a dev manager, how do you deal with a prima donna?

I don't believe he's a good dev.

Sorry..

If he's been re-writing large swaths of code he sucks, and he will cost you way more than you can afford.

I worked with a dev who convinced the boss to let him and rewrite a large bit of our app. While he did this new features for the existing app were on hold and bugs were on hold. We pissed off clients and management. Eventually a few devs went behind the upper managements back and fixed bugs in the old system, and added minor features.

6 months later he had finally finished.. It was loaded with bugs, and the best part he was the only one "smart enough" to maintain it.

Then one Wednesday at 10:30 am he closed his laptop and walked out.

None of the other devs who knew his chosen stack would touch his steaming pile of Not_made_here code. Not willingly at least.

A year later the original app was once again "the app", and we had a party when we finally killed the project.

He's a shite dev. A good dev makes the least amount of changes they can get away with. A good dev makes the customer happy because they pay his/her wages.

My suggestion. Get rid of him, before you lose other devs.

Oh.. it was demoralising as hell working with him. I and a few other devs almost left. My recruiter tipped me off that he was likely leaving (when I told the recruiter why I was leaving). I stayed. It was close.

You may be right. The developer does, objectively, write good code. Was it so much better than the old code that it was a worthwhile endeavor? That is debatable. Some of it was style change, some of it was idiomatic changes. There was, as far as I know, no performance change or refactoring that eased code maintenance or anything like that.

Rather than being a "bad dev" he may be simply a "bad value" -- good, but not worth the pain.

Structural change for performance improvement or making the code less error prone are the 2 big reasons I can see for rewriting code. 3rd being if the codebase is just legacy and needs to be updated.

There's nothing wrong with an experienced dev improving code structure (at the expense of working on more tickets) but it needs at least an engineering or business justification generally.

Rewriting is quite an effort. It's a no-brainer when the existing code is buggy, slow and it's acknowledged by everyone that it needs to be done. On the other hand, not rewriting might mean nobody wants (or is even able) to work on a particular code base. Postponing it too much in the future can mean the project fails and if management doesn't understand in time there's a problematic code base that means devs have no support for what they do. From OP's description it's not possible to see if there are any objective points for the quality of the code (e.g. linting, test to code ratio, uptime)

Sounds like you have a talented developer on your hands without enough experience for the business sense. Maybe for the inter personal sense also.

Sounds like a mid level developer since they have the code skills but lacking experience and inter personal skills. I myself have been in this phase once, although I achieved significant improvements in UX, performance and maintainability though changing structure.

I would say just low key ask them what's the business case or engineering justification for the rewriting. Ask them to justify the justification, just probe their process. Over time hopefully you can converge an agreement.

You mentioned his views are binary but this isn't very important. Maybe he's just being to the point or concise. A bigger issue could be if he's hurting other people's feelings with comments in which case that just needs to be brought to his attention if he doesn't realize.

All the code there was likely written by existing members of the team so criticizing that code could be taken badly by other people, well intentioned or not. Ask him to think about other people hearing somebody criticize the projects they worked on.

I have hired developers for past 7+ years (full time, freelance and in between). I personally have experienced that no matter how great they technically are (debatable at times), they are of not much value if they cannot work with a team. If they are too much about "me me me. I know best", I don't care how much code you can write. They usually don't last that long anyway.

I judge a good developer by what they focus on especially in early days in a team. If they come in and start shitting on everything current state, they either lack real experience or are too arrogant. I would rather have a developer say "Hey I was wondering why we do this process abc in xyz way. Was there a reason because it seems inefficient but I wanted to understand better".

However, don't judge too quick. It may be possible that this developer is trying to tell you something which you as a manager must understand. If they truly care about the team and the customers, try and listen. If they don't, cut them loose.

Love this site, it explains how to deal with all of the developer archetypes: https://neilonsoftware.com/difficult-people-on-software-proj...

Funny how the approach is normalization by demoralization, and how the dev is expected to satisfy his ego by becoming a manager, that is a new adversary for the same manager that is demoralizing them? Diva Dev evolved into Diva Manager?

I disagree with the solution to this one. Most of the time, the diva developers are insecure. In some cases, you just have to give them more job security.

Definitely true if the intentions of said diva are good. Although, if they weren't then they'd probably be classified as an asshole rather than diva.

I think most divas generally have good intentions, even a hero complex.

I worked at this project where a very smart developer started working on a certain very important product. He fixed bugs, added features, etc, but he was kind of a pain to deal with, so over time the previous developers left him alone handling everything. Eventually other people joined to try to help the efforts, but they all always ended up being 'slaves' to this developer: they needed him in order to understand the code, anything they implemented had to follow this dev's desires, otherwise he block them on code review. That product became his baby, everything was bound to his will.

Over time, the codebase started getting more and more bizarre (to his taste) and eventually people stopped trying to help him: he was too much of an asshole and the codebase was too impossible to understand. We got to a point where we needed very significant changes to that product do be done in 1-2 years, and as technically brilliant as this person was, he would never be able to do it alone. We tried to put people to help, but they had no chance: the new features were full of bugs and deadlocks. Our projects got super late and we delivered some very shitty products to our customers.

Then a team of people started working on a replacement for this product behind this developer's (and his manager's) back. Everybody except he, his 'slaves' and his manager got super excited for it. We're still building it and recently announced it to him and his group. We're going to spend 10-20 man-years to replace this product. Management expects this developer to keep maintaining the legacy product, nobody wants him to join the replacement project.

Yet, management still doesn't even consider the possibility of firing him!!

PS: I hope nobody gets offended by the term 'slave' here.

A manager calls one of their reports a "prima donna."

Now the team has two problems.

Good luck.

resists learning anything about the other technologies in his projects' tech stacks

Sorry for quoting out of context, but I also do that. The reasoning goes: when I have to do something and it’s clear how to do it, there is no need for “the other way”. I perceive it as changing routes daily just for novelty, against boredom. Old tools have nuances, so do new ones. But the work is done by me + tools, so the best combination is me + what I know to the bone.

Is this bad for a developer? Does that stress colleagues often? No catch, just asking.

And I do learn ofc, after some “it sucks too much” threshold. But years of early development taught me to raise that bar much higher than my procrastination pikes, otherwise I end up in a loop of jumping tech and never get satisfied.

Edit: to make it clear, other described “traits” I do not have.

I think your approach to this situation is fine. There are poor ways to handle it, though.

A recent example: The developer maintains a tool that communicates with another internal system maintained by another group. That system is being migrated from a suite of applications running on internal blades to something that runs on kubernetes. The migration affects how processes are accessed (IP addresses and ports), and changes are required on our end.

This developer does not know anything about kubernetes and does not know anything about the changes in the other system. He does not understand why any access methods may have changed, and he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. To be fair, he does not need to know anything about kubernetes to make this change, but his resistance to the modification almost demanded an explanation of why it is necessary, and then it devolved into the situation I just described.

> he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before.

Imo, He's honestly entirely justified in being annoyed by this. It sounds like the other team has unilaterally decided to complicate things by migrating to kubernetes and breaking backwards compatibility. If it's just as simple as updating config files to point to new IP addresses that's one thing (which would be better solved with DNS honestly) but it sounds like it's a bigger breaking change than that, which is kind of bullshit.

If you are changing an internal service at a company it's your job to get buy in from the clients of your service beforehand, not just cram the changes forward and expect them to adapt.

> Is this bad for a developer? Does that stress colleagues often? No catch, just asking.

I dunno if it's bad for you, but it's often better for the business to use fewer tools that are good enough than to use more tools that are perfect. There are often people that need to go between tasks for various reasons, and when tasks share tools, it can be easier to understand what's going on.

For colleagues, a team member that's always trying to pull in new tools is causing stress because someone needs to redirect them towards using something already there.

Well, you have definitely a lot of leverage by being a Manager. For the better or worse, you have much more leeway and can push the developer out of the company if you want. But that would make you a terrible Manager, like others in many companies.

One think that might help you to digest that situation better is that... while he has to write features and make things work in your company, all you need to do is mostly play politics and you have much more time than him to make yourself look good and him... that is actually in the trenches making the company work, bad.

This is why you as a Manager, you should actually help him to work effectively. To me, he looks like the carries the company and you are just there to help him do it. You need people like this in a team and need to know how to keep them happy and motivate them to also move up the ladder. If you aren't able to do that, you aren't really meant to be a Manager.

I've this episode many times. Manager joins and already starts gaslighting the person who is carrying the team. Eventually person leaves and Manager is left off with an average team with silly output. Things get reorg'd and Manager keeps having a silly performance all around the company, but as they paint always with good words, things work well for the Manager.

As a Manager, you are expected to have the soft skills to handle people with different personalities and have more deeper social analysis of a situation. From what I've seen, you've already called him a "prima dona" and seem to need to work on those skills. You should also be able to call the developer when they say something not nice or toxic and learn how to build him and incentivise him to change.

He also must be under a lot of stress and you can only gauge that by working on the team and knowing the Developer a bit more personally.

Get his trust and develop him. I've said this before, but if you aren't able to influence people in that way, you can probably have even a considerable good management career in your view and of other peers, as managers get a lot of leeway with that. But you won't be a top manager.

The fact that you've labeled him like this before even getting a good gist of the situation is a red flag and tell me that there's a bit of inexperience on this from your side. Try to get this "prima dona" out of your head and instead find a way that you can both profit from this situation, He'll be helped by your coaching skills and developing people, which is, BY THE WAY, the #1 skill for a Manager. You in exchange will get a person that can perform well and grow with you and the company.