How to handle a highly productive employee but who reacts extremely emotionally to code reviews?

Question

I currently work with a smaller environment as a manager of a team. Everyone on the team is very talented and gets things done, but we have someone who is far above anyone I have ever met in my 40 year career. He is the rainman of software development. Just upon being hired and two weeks in, he forked our source code and managed to complete nearly all of our backlogged items to learn about the application. He even spent the rest of the time mentoring our 'senior' developers. Prior to him, we were struggling to get by and just making ends meet.

This however comes with a catch. Our code reviews play out like the following:

Employe A - Why did you name this variable "that"? I think we should try something different.

Rainman - Wha...?

Employee B - This is rather confusing for me. It isn't the code but I am just having a hard time wrapping my head around it, can you place a comment detailing what's going on for me?

Rainman - (Heavy breathing...snorting)

Employee A - Overall I think this is good, but could you make sure you tag your check ins with X so that we know where it belongs to?

Rainman - (Starts bawling like a banshee)

From there he has to go home for the day until the next morning when he is okay. Going home for the day is okay, considering the mountains of work he somehow accomplishes during the few hours he isn't crying. This happens several times a week. Other employees have just accepted it and it no longer bothers them and I've had numerous meetings with them to ensure this.

My question is how can my team and I get on the same emotional level of someone who is nearly irreplaceable and I have no intentions of getting rid of? I would like tips on how I can calm him down as I have no experience in doing so.

Answer 1

Let's start by taking about two steps further back:

If you have a team that is so deadlocked that a single person can make the headway you've described, you have a dysfunctional team. It just isn't possible that a single person is so much "better" than a group of talented professionals. Something is seriously wrong there. You either have an organizational problem constricting their skills, or you don't have the level of talent you believe you do. This is the primary issue you have to face.

But there is the issue of how to manage this person's talent as well. I will grant for the sake of argument that he is somehow an order of magnitude more skilled and insightful than anyone else on your team. If that is true, then you need to take the most emotionally adept person on your team and assign them to "insulate" this person.

First and foremost, stop referring to him as "Rainman" - If you are referencing the Dustin Hoffman movie, then that reference carries a lot of baggage, both positive and negative. It "pigeonholes" him in your mind and the mind of your staff. This person is an individual who may have mental health issues. That doesn't mean you get to look down on him. You wouldn't look down on an amputee nor a parapalegic, so give this person the same respect. If you intend to respect the talent, then respect the person, as well.

Second, find a way to integrate him. Let him be brilliant, but when it comes time to do the code reviews, have the "insulator" comment and rename as needed, and explain clearly to the talented employee, "Your work is brilliant. There's just some rigamarole that we have to do in order to integrate it into our process so it's approachable by our junior developers. Steve, here, is going to help accomplish that and keep the 'clutter' out from under your feet." And before you know it, Steve will understand a lot more than anyone else, and hopefully bring the skill level of your whole team up.

Finally - after this is rolling along, take a long, critical look at your "old" team. Something isn't right, there. There shouldn't be this much "Room" for even a wonderfully gifted programmer to make such a sea change in your team.

Answer 2

Have you tried asking him how to make code reviews more tolerable for him? Using the examples you listed above, what if they went more like this?

• Employee A - This variable X, I think maybe it would be clearer for everyone if it was TotalSalesThisWeek. Is it ok for me to rename it?

• Employee B - [asks questions until they understand the code and grasp the missing piece of information]. Is it ok for me to add a comment summarizing that, for the next person who reads it?

• Employee A - I tagged your check ins with X so that we know where it belongs. If you remember to tag it then you won't see an edit after you check in

The pattern I see with these is that you are all asking him rather open ended "fix this" kinds of questions after criticizing his work in some way. While I don't know anyone who would cry over this, I do know people who'd be irritated. For example, telling me my code is confusing would embarrass me, and asking me for a comment to explain it might actually be laughable - if the explanation is pages long, it's not going in as a comment, is it?

Normally I'd insist that the person who did the work in a way that doesn't meet the group's standards be the one to fix it. But in this case, I think having other people offer/ask to make the change will be more practical. Over time, he may choose to adapt his work to prevent these sorts of requests, or he may not.

But that said, it could be that the current arrangement is in fact working for everyone. He gets upset and goes home sometimes, but if he renames the variable, adds the comment, and tags the checkin when he comes back the next day, so you have a clean code base, and the rest of the team have accepted his differences with a shrug, you don't have anything to fix. If your code base isn't clean though, I suggest having the code reviewers offer to make the fix, in a nice way, and see if that lowers the emotional pressure at all.

Answer 3

The user Mat's Mug hits on a critical idea in their comment:

[...]be impersonal (count the number of "you" and "your" in Employee A & B's review comments)[...]

It is your call about whether this is worth the effort, but if this person is truly as valuable they seem then I think it will be well worth it & it will make everybody's experience more pleasant. You might even gain additional productive time from this person in this way.

---

Examples

Before: Why did you name this variable "that"?

After: Why is this variable named "that"?

Before: can you place a comment detailing what's going on for me?

After: We would benefit from a comment detailing what's going on.

Answer 4

I've seen (as of this answer) the team dynamic mentioned, his responses, your responses and other dynamics of "You" and "Rainman" mentioned...

Something I haven't seen mentioned: Company Coding Standards

Where do these questions/answers fall within the realm of a Coding Standard? Naming Conventions, Commenting code, tagging... all sound like stuff that should be codified within a standard.

If there is no standard, then it comes down to "He said, She said" and personal preference. "That should have this name... this should have a comment... This should be tagged like this" - all personal preference based on whoever is running it currently.

If "rainman" is a good programmer, I'd bet that (s)he adheres to best practices, up to date methodologies, etc. Part of "clean coding" involves making everything readable, understandable, self describing, etc.

A large part is consistency.

You gain that with a standard that the whole team/company should follow. Whether that includes tabs or spaces, SemVer or something else... 20 different ways to control Capitalization Conventions.

I think that creating a set of standards - or adopting a set standard for your stack like C# Coding Standards - would alleviate most of the "I think you should..." and move it into "This doesn't adhere to our documented way of doing things". (even if the reality is everyone already does it the same way, and "I think you should..." is merely perception)

That removes "Us" vs "Rainmain" and moves it into "You are doing AWESOME but please follow procedure".

Answer 5

The first time I had my code reviewed, I found it to be a very unpleasant experience. I was part of a "gelled" team - we all got along well and respected each other's abilities and socialized to some degree. Yet, when my code came under review I felt like I was being attacked. To be fair, I was the first "victim" of the process for what was a very young team, so we all had to build experience. In hindsight, it was all constructive and beneficial; it just didn't feel that way in the moment.

My point is that you have to have a little empathy to really know how your feedback will be received, and bear it in mind for delivery. In your case, the person in question seems to be more sensitive than most, so you just have to pay a little closer attention to your delivery.

One rule of thumb when delivering constructive criticism is to not forget to comment on the positive. Also, you don't want to seem like you are attacking the person. Nobody likes to have others pick out all the flaws in something they have invested pride in creating. Be mindful about using the word "but" and how it can turn what may have started out sounding positive into a criticism. It's also a good idea to always end on a positive note, and it never hurts to repeat a compliment.

When it comes to making adjustments to the work he has submitted for review, instead of telling him to change something or even asking if he could, perhaps phrase it along the lines of "perhaps we could..." as in the team - you, him, and everyone else. You are all on a team working together toward a common goal. Perhaps he just needs a gentle reminder that although he is completing assignments as an individual, just like everyone else, the team shares responsibility for the result of all the individual efforts, and therefore everyone has an interest in making the final result the best it can be.

Example:

"You've done excellent work as always. Can you help us to better understand a few details? This variable named X - it represents (...) right? With that in mind, could we name it (...) instead? This section of code - it would help us later if we had a comment to explain (...). Can we add a tag to this commit? Again, it's great work."

Answer 6

Quit badgering him

If this guy is one of the best guys you have, then you need to give him some leeway and let him work the way he wants to for the main part. If there's things he's doing which are counter to your working framework, then address those.

It's clear that he has a particular personality trait, so you need to work with and not against that. If you can work out what provokes his outbursts and do what you can to avoid those triggers, then things will get a whole lot better for everyone.

P.S. Calling him "Rainman" even while posting anonymously as you are now (I'm assuming you create a new SE account purely for this question) is (in my opinion) really inappropriate.

Answer 7

I wonder, is there a problem here to begin with?

Sometimes we interpret what we consider abnormal behavior on the part of others as a problem that needs to be fixed. This is not necessarily so. For example, a friend of mine has a wife who cries quite frequently (by male standards - i.e. maybe once or twice a month?). He told me that every time that happens he feels uncomfortable and tries to come up with ways to calm her down. This includes (a) distractions; (b) presenting the glass as half-full; (c) admonishion; (d) assumption of blame and escape, with inevitable period of 'bad mood' for a limited duration. After a while all this began to irritate his wife and she finally psychoanalyzed the situation, and asked whether he thinks her crying is a problem to be solved.

Why, indeed it is a problem when people cry, isn't it? We learn from childhood that cryling is kind of a 'last resort' of a response. Therefore, when this threshold is reached we assume that somethign has gone wrong to the point where it cannot be left unattended, and we rush to fix it.

Now the kicker: Turns out, not necessarily. To his wife, crying was an absolutely healthy and normal coping strategy with all kinds of crap. In other words, it was -- from her perspective -- her normal way of handling some kind of stress or sadness that happens now and then and is just a part of life. On the opposite, if she were to hold it all inside and let it build, it could have evolved into more serious psychological issues (like depression). Basically, she totally flipped the script on him. It turned out he was making a bigger deal out of it than she was.

In case you are interested, now when my friend's wife cries, his default is to let her go at it for a bit while minding his own business, then (after she is done) ask if there's something he can do to help, or if she wants to share, then (if she does) simply LISTEN FOR A LITTLE WHILE, without giving ANY advice or solving any problems, unless she specifically asks for it. Usually a 5 minute rant is all there is to it, and then they go on making weekend plans or whatever else. Non-crisis averted.

Could it be that an emotional reaction is Rainman's best strategy for releasing some psychological pressure, and if that pressure is not allowed to be let out in the best way he knows how, it could lead to deeper problems down the road?

The moral of the story is, we often make assumptions about others based on our own understanding of the world, and act on these assumptions without first testing them for validity. Could the moral of that story be applicable to this case? You be the judge, but I wanted to share this as something to ponder in relation to your Rainman. Perhaps freaking out emotionally is just how he handles mild constructive feedback, and it's not a judgmenta against either you or your team, and not a problem to be fixed. If this could be a remote possibility, I suggest a very brief informal 1-on-1 to ask him (very politely) that you noticed he has appeared a bit phased by some of the discussion in the meetings and seems to need time to recover.

Just share it as an observation and ask whether this is something you or the team need to be concerned about. Let him adjust your perception and suggest strategies for deescalating such situations, if indeed any deescalation is necessary or desired from his standpoint. Make sure to lace this conversation with a good-size dollop of praise.

I have a suspicion that letting him guide how such situations are handled may be the best approach, rather than assuming out of the gate that it's a problem to be solved and trying one tactic after another (possibly leading to some real issues down the road), when in reality this could be better off left alone. Letting go of a problem is sometimes the only right way to address it. In our action-oriented business culture we do not often consider inaction as an option, but sometimes it works better than anything else.

One last thought. If 80% of the 'emotional response' behavior is associated iwth Rainman's attendance of code review meetings, might it be possible to let him decide whether he prefers to attend those, or to communicate regarding the code in some other way? Perhaps he is much better at taking feedback on instant messenger, or by email, or in a one-on-one 'follow up' meeting with you where you share the outcomes of the code review that concern him, than in a group face-to-face format? Some people have handicaps in regards to specific communication modalities, which fall away and become non-issues in other modalities (e.g. that buddy of yours who always prefers calling instead of emailing, or vice versa). Might be worth a try - as long as it's cool with him and doesn't make him feel singled out or isolated, of course...again, let him guide this and you should be fine. Good luck!

Answer 8

Change how you do code reviews

Face to face code reviews are becoming an antiquated practice as teams become more global, and as software development speeds increase. Instead of code reviews in person, reveiw each branch in the tool as the changes are approved.

1. Use a code review tool that allows for inline comments

Physchologically this will do what DoritoStyle's answer suggests. It removes the human from the discussion. You are now discussing "the code" and not what the "coder did".

github.com and gitlab both have built in code review tools.

If this developer has expirence with open source tools, or a fast paced software development company, this workflow will likely be familiar to them.

---

2. Increase the frequency of code reviews

"When something is painful, the way to reduce paint is to do it more often, not less".

It sounds like you are having a large meeting to do the code reviews. Code reviews should be small and done every time a feature branch is ready to merge to master. If the developer is ready to merge multiple feature branches to the 'master' branch per day, that means there should be multiple small code reveiws per day. This only becomes scaleable if using a code review tool.

3. Review code before merging branch to master

Its not clear from the description when in the pipeline the code review is happening.

The purpose of code reviews is to ensure quality before being accepted. Code that has already been merged is psychologically 'complete', and any critisims are too late.

---

If you continue to do code reviews in person:

• sit side by side, not across a table
• only 1 person reviewing code at a time, code review is not a group review
• overcommunicate reasons why doing code reviews

Answer 9

Let's make sure that this programmer is CLEARLY made aware that questions about instances in code are not attacks on his intelligence or coding ability.

A lot of brilliant people do have underlying emotional issues, and a good chunk of these people have either not been diagnosed with something or been diagnosed incorrectly.

I myself have Aspergers Syndrome (DSM-5 Autism Spectrum Disorder...ugh) (read as interpersonal skills not top notch, some difficulty picking up on social cues, as well as other things) so sometimes I can vastly misread a situation, and my reaction will thus be.....off, compared to the expectation of others.

Now, this does not sound like this programmers case, but there definitely sounds like there is an underlying issue, as well as likely a dose of "everybody wins" syndrome. I kid.

This is not as much a situation of needing to get your team on his emotional level, as much as it sounds like a situation where there just needs to be a little bit of, for lack of a better term, "team bonding." I think he needs to know he is part of a team, and not just some coding powerhouse.

Answer 10

Your job is to maximise the useful work done by your team, while treating them in a way that they don't run away. And if you manage to actually create an enjoyable workplace, even better.

It seems you know that with this employee, the work he does outweighs any drawbacks of his personality. With all his problems, you much rather have him on your team than not.

So when code reviews are done, let someone do them who is both senior and adult, and when there are things like not enough comments or something not tagged correctly, that person takes a note and fixes it themselves after the review - so that your developer can go on and do more work.

Someone mentioned "bus factor" - if you have someone who does the work of two people for one pay, that person isn't irreplaceable. He is very easy replaceable by paying twice as much by hiring two people to replace him.

Answer 11

When I first started at the company I'm at currently, I was seen as this person as well because my side of the story was dismissed due to being the new guy.

When I started I was working with a guy who was super nit picky about ridiculous things - mostly grammar in comments and minor stylistic choices (that were within the coding standards) and he was also against me doing anything differently than he would or using things he hadn't seen before. Problem was, while he and I had the same number of years of experience (11 at the time), his was all on this one project at this one company, while mine was at a lot of other companies in senior and lead roles, so he was quite sheltered / hadn't really seen the outside world. He was also inconsistent about what he demanded during each CR so even when I tried to just do it his way it was impossible to please this person.

Anyhow, he and this other dude didn't get along real well either (the other guy said he tried to avoid working with this individual) and the work I did bridged the gap between these two folks.

The problem was that boh people absolutely demanded I do things the way they wanted to the nitty gritty detail level, but they didn't agree with each other and instead of working it out, they would team up against me even when they demanded opposite things.

That lasted about 6 months and all my complaints to management just reflected on me poorly and nothing changed.

When our immediate boss was on vacation once this individual went to our bosses boss and said I was being subordinate. Our boss returned and clarified I was not working under that individual so was not being insubordinate. It was ridiculous.

The situation eventually changed itself when I was able to get to another team.

I've been around 4 years and things have been fine.

I've never been treated so poorly in a professional setting and was really struggling to figure out how to handle it as it was a new experience to me and management wasn't helping.

Maybe you should talk to your person and try and find out what their POV is? Maybe your "old timers" are being egotistical jerks?

Answer 12

I am not sure you have a problem. Your star is emotional, but you say he comes in the next day and is fine. You seem to say his level of productivity is high and I gather he is not unraveling. You also say the rest of the team accepts his behavior. You don't say there are threats on the horizon. If so, I would vote for "steady as she goes." People vary. Let them vary. Don't interfere unless interference is clearly warranted. People who act differently than you expect are not a reason to interfere. Highly productive people are never usual.

I do have some concerns. How did you get this star? Do you know why he left his previous job? If he had problems there, that might be a clue to how to prevent it with you. Second, look at your team carefully. A new star is usually disruptive and requires effort to soothe ruffled egos. You seem to imply that no one resents a new talent who has fixed a ton of issues as a side effect of reading code. If I were one of your long term team, I would feel chastened, and I might consciously or subconsciously attempt to sand bag the new star. Picking on silly stuff in code reviews might be a way to do it. I hope you have tried hard to make sure none of that is going on.

My experience is that a new star can adversely affect team productivity more than a middle of the road developer. Stars generally take care of themselves. It's the rest of the team that needs tender care.

Answer 13

A person like Rainman needs an structured and organized framework, that's why people like him usually have repetitive behaviours and also extreme order. If he's a real Rainman you'll see that each paper is always in the same place even if his desk looks awful or his code will always have the same aesthetic. Also, Rainman people is stressed if they need to interact with other people, specially if the conversation isn't logical for them.

So, to have a nice relationship with him you must respect order, keep clear rules and reduce conversation to the minimal possible. Do not waste your time torturing him saying "Why did you name this variable "that"?", instead make a rule to give names to variables and give it to him saying "this is the rule for names".

Answer 14

I think, the recommendation from the code reviewer should be binding only if:

• A bug has been spotted. Bugs may happen to any developer and any would say thanks, most of sensitive souls including.
• The developer has no experience in general, or experience with your code (first month, more if the code is really very complex).
• You do not have a proper document describing how do you want your code to be written.

In other cases, it may be better to have the reviewer recommendations optional. The further events depend on the personality of the developer, but many would apply the reasonable recommendations anyway. If somebody systematically deviates from the mentioned guidelines document, such things must be discussed during the meeting (including discussions on how much the guidelines are reasonable and why). If the developer does not apply fixes, reviewer may apply them instead - this is an efficient way to convince that the guidelines are easy to follow and must be respected. In some cases the reviewer this way may discover the reason why the things are implemented differently (the current version looks more readable? "right approach" results untestable code? something is outright impossible?).

Power games, requiring to apply numerous changes that are more a matter of opinion are also a problem.

From here, the action items would be:

• Restrict mandatory fixes to reported bugs only.

• Make all other suggestions optional.

• Write the document on how do you want the code to look like and make sure all know where to find it.

This should make the life for people who do not like code reviews much more bearable. Code review is significant stress, not found in most of professions (teachers or doctors really do not like when you go to the two of them just to compare), and it is important not to pull more than the human nature can handle.

Answer 15

I will not address the fact, that one employee can outclass whole team. I will only address the problem of rainman (or any member of the team) getting furious during code review.

There are people who thinks faster than the others. There are ways that fits to some people much more that to different ones. Some people are super fast when problem is approached one ("their") way but absolutely lost when the approach is (slightly) different.

I have studied applied physics, physics of plasmas and thin fims growth. Right now I am working at faculty of mechanical engineering. Sometimes, the approach and habits of my colleagues drive me crazy (usually what tools they are using and how they are using them); sometimes I drive them crazy (usually by not mentioning crucial information that I find obvious or arguing about something finding out, that we are wanting the same thing from the start). In other words, sometimes it seems like we are from different universes...

Have you asked your rainman, what part of "Why did you name the variable that?" question upsets them? Was the question too dumb in their dumbness scale? Was it mocking their workflow? Did the tone of the question make them feel uncomfortable?

Make yourself a list of tasks:

1. Realize, there is a problem. Check
2. Name the cause of the problem. Waiting...
3. Find the cause of the problem out.
4. Find out the way(s) how to prevent the problem to occur or how to prevent the problem from escalating.
5. Create appropriate rules and stick to them.
6. Discuss the rules with whole team

Do not try to solve it without rainman being asked or involved in the solution. Do not extrapolate their mood, reactions etc. Do not try to solve it behind their back. Do not try to hide anything under the carpet.

---

Maybe, there is a member of the team who is being driven crazy by rainman's work and behaviour and haven't exploded yet. What has been told cannot be untold. Try to find compromise between all the members. Maybe short (anonymous) questionarre could help.

• Q1: What do you find wrong on our code-review sessions?
• Q2: What do you think can improve the code-review sessions?
• Q3: What do you like on the code-review sessions?

Answer 16

I would approach this the same way I would approach any other performance issue. Explain that you have noticed a behaviour and ask how you can support the employee.

Try phrasing it more around help and assistance than discipline.

I know you sometimes get upset at work. What can we do to help you? Are there any processes or mechanisms we can put in place to support you?

Answer 17

Rainman is doing great work. His behavior is unorthodox to say the least, and I am glad that you and the team have taken stock of the situation and decided to take and the good along with the bad.

Make him feel safe in your environment, find out what makes him tick and if he is happy and comfortable being in the firm, the chances that he will jump ship are minimal.

I am assuming here that you and the team understand his idiosyncrasies and have taken a live and let live attitude to them.

You may be able to suggest to him better ways to react to what upsets him but whether he listens is another story. I usually advise others not to let things get to their heads, especially if I know that their heads are a hodgepodge of emotions just waiting to pour out the minute I turn on the faucet. It's amazing how most people don't get upset when they tell themselves "I won't let this upset me, because it's not worth it to get upset". Suggest to him responses to stressors that might work better for him while minimizing the negative impact on everyone's sanity. And keep the suggesting friendly, helpful and non-intrusive.