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.

  • 26
    Working on the assumption that this is a real situation rather than some fiction inspired by this recent question, what have you already done to try to address the problem with this employee?
    – Lilienthal
    Commented Dec 9, 2016 at 14:35
  • 61
    You might also want to consider the Bus Factor aspect of this. If the rest of the team can't maintain the code, you'll be in a world of hurt if he ever leaves (i.e., "hit by a bus"). Commented Dec 9, 2016 at 14:38
  • 41
    Review the code, not the coder; be impersonal (count the number of "you" and "your" in Employee A & B's review comments). Don't criticize, condemn, or complain. See how can I be a nice reviewer? on Code Review Meta. Commented Dec 9, 2016 at 17:12
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Dec 11, 2016 at 9:27
  • 2
    Surely you would have had some inkling of this behaviour prior to hiring him, i.e. during the interview process. Did you not ask any questions of him then?
    – Möoz
    Commented Dec 12, 2016 at 2:43

17 Answers 17


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.

  • 20
    Just FYI, 'rainmaker' or 'rainman' has long been a term used for a person who brings in a lot of business to a firm, so the nickname used by the OP might well have nothing do do with a movie by that name. (Which I've never seen, BTW.)
    – jamesqf
    Commented Dec 10, 2016 at 3:26
  • 1
    Comments are not for extended discussion; this conversation about 10x programmers has been moved to chat. Commented Dec 12, 2016 at 1:19
  • 12
    +1 for the If you intend to respect the talent, then respect the person, as well.
    – kolsyra
    Commented Dec 12, 2016 at 8:19

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.

  • 10
    I really love this answer. The other thing I would think about whether the problem is related to the real-time, interpersonal nature of these requests. Some people really struggle with understanding verbal communication, body language, and other cues which can cause their reaction to be so out of line. Maybe you would have better luck addressing these kinds of issues through written communication. That should minimize the stress and pressure, and allow him time to think and process the question/request before responding.
    – Chris G
    Commented Dec 9, 2016 at 16:06
  • 5
    I'd think this is the right answer however this poor son behavior really hurts me. I can't stop myself thinking that the other employees are a) OK with this only in this moment and b) this will create a case. What if someone else has personal problems? Or another type of mental illness (I actually do not know if he is ill or not, BTW)? In my opinion this issue must be resolved WITH him unless you're planning to have a team of people (with a possible high turn-over) that gravitate AROUND him. Commented Dec 9, 2016 at 16:35
  • 1
    If this problem can't be solved in a reasonable way (also to respect other peers) then I'd prefer to do not hire him (and/or hire someone else with same level but emotionally stable). I'd also mention that maybe he is not above the average, maybe your reference is/was below the average. The fact that they have something to say during code reviews should be the evidence that it's not that clear. Sometimes two average programmers are better (both economically and for quality) than 1 "ninja" and 2 supporting mules... Commented Dec 9, 2016 at 16:40
  • 3
    There's no way this arrangement works for everyone if someone ends up in tears.
    – 2rs2ts
    Commented Dec 9, 2016 at 17:26
  • 2
    @jamesqf and OP ... contd. .... On the other hand, if you have a half page of WHY it is doing it. (Say documentation of the hacks that you had to apply to massage the 3rd Part API, or the algorythmic theory about why the following mathematical manipulations are appropriate/necessary/sufficient, or the history of the design choices and feature requirements that led you up to an unnatural end point) ... then you DEFINITELY need that explanation somewhere. Either inline, or as an external reference, like jamesqf says. (We favour internal wiki links where I am)
    – Brondahl
    Commented Dec 10, 2016 at 9:37

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.


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.


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


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.


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

  • 4
    And perhaps have someone explain to him that while this might be a major pain the first two or three times, after a surprisingly short period of time, it will decrease to almost nothing. The team should quickly settle on norms for things like variable names, comments, unit tests, and so on. Commented Dec 10, 2016 at 5:24

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.

  • 3
    Perhaps what you didn't read/don't understand Pete is that people have tried to address things which are "counter to the working framework", and the reaction was still to burst into tears. Commented Dec 9, 2016 at 15:01
  • 10
    I don't agree with this answer, I wouldn't call comments in a code review "badgering." It's extremely important that the code is readable (especially in this context since this employee seems to be more skilled than his coworkers) and by no means "badgering" to ask that it be explained. The code may outlive his time there, it may outlive all their times there, so it's important that it be maintainable by people in the future. Commented Dec 9, 2016 at 21:17
  • 5
    I disagree that letting it slip is a good option - company code practices usually exist for a reason.I do think that this hits a good point another way though - could more effort be made to be sure that this team member understands that his code is not necessarily 'objectively wrong', but it's just that he's on an inevitable learning curve towards fully absorbing company practices? Perhaps that knowledge would soften the impact of what seems to be perceived as direct criticism of his efforts.
    – jlmt
    Commented Dec 10, 2016 at 0:41
  • 1
    This is flat out wrong. Pandering is never the solution. Sure, it may make things easier for you, because then you avoid all conflict. But that's not your job as this guy's boss. Not at all. Commented Dec 10, 2016 at 1:29
  • 3
    I've been the guy on the team who was so much better than many others on the team. I spent one day with a coach who taught me how to code a bit slower but such that other people can understand and maintain my code. It was one of the most useful experiences I've ever had. Perhaps you can find someone to teach this guy how he can lift up the team. (Or hire another rockstar programmer/manager who can fix the dysfunction and make the team work better as a group.) Commented Dec 10, 2016 at 5:22

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!

  • 3
    This is a good point. Maybe it's an issue of perception more than anything else.
    – Kat
    Commented Dec 9, 2016 at 17:36
  • While crying might be a fine & healthy thing for an individual, in this case the person is crying during meetings and in direct reaction to comments from co-workers. At best that is unsettling for the rest of the team and probably affects their workplace moral (or else I assume the OP wouldn't have felt the need to post here).
    – user30031
    Commented Dec 9, 2016 at 17:44
  • 4
    This answer is also very long-winded; I think it could be much better received with a TL;DR.
    – user30031
    Commented Dec 9, 2016 at 17:44
  • @DoritoStyle, thank you for your feedback and all good points. I am still working on writing effective responses. What I find is that some OPs prefer shorter answers, but others appreciate extra context and find such responses more complete. While most responders might appreciate brevity, my primary audience is the OP and I tend to err on the side of a more complete than concise response -- but will take your comments into account...as soon as I am done crying? ;) With regard to your response, while a simple paraphrase might work for an 8 year old, I am not convinced it'll do here.
    – A.S
    Commented Dec 9, 2016 at 18:10
  • 4
    The level of detail is definitely not a bad thing; I do think a short summary in advance would satisfy both concerns
    – user30031
    Commented Dec 9, 2016 at 19:36

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

enter image description here

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

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.

  • For those who have not read my profile: Downvotes without comments are infantile Commented Dec 12, 2016 at 13:46
  • I think this might be a core point here. Someone who writes quickly and doesn't comment much probably thinks that the code just explains itself and there's no reason to add more description. It might be useful to stress that adding these features is not a reflection on the author, but that it is for the benefit of anyone else that may have to read the code. Commented Jul 29, 2019 at 21:28

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.

  • I think there is a lot of merit here to one point: It might be the better path to just have someone else do the "clean-up" if asking "rainman" to do the fixes himself is creating so much friction. Commented Jul 29, 2019 at 21:24

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?

  • 2
    What's wrong with correcting grammar in comments? Commented Dec 12, 2016 at 12:02
  • There's nothing wrong with that necessarily. It can be a good thing for sure. In my case I believe it was a control thing and made the code reviewer feel good about himself and superior perhaps. I'm not a mental health professional, but i think there is something wrong with this individual. In my case, the fact that there was a 2nd person involved I'm sure helped made it reflect on me and perhaps makes it suspect when others are reading it now (perhaps even you). It was a bad situation but I'm really glad it's over. I wanted to point out to the OP that there might be more going on is all.
    – Alan Wolfe
    Commented Dec 12, 2016 at 15:05

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.


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

  • -1 just for not only integrating the "Rainman" nomenclature, but for then repeating it three times. Not cool. Commented Dec 10, 2016 at 1:30
  • I think Santiago must not have gotten the reference.....if he did and still used Rainman....................... Commented Dec 10, 2016 at 5:54
  • I think that there's actually enough value in this answer that it's not worth downvoting just because the delivery is a little coarse. It may genuinely help in this situation to provide a clear structure for the individual to work within. Commented Jul 29, 2019 at 21:58

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.


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?

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?

  • "I would approach this the same way I would approach any other performance issue." As in: impose consequences if it's not resolved? Because that's generally what that means.
    – Lilienthal
    Commented Dec 9, 2016 at 14:41
  • 1
    The way it's described, it's not a performance issue. He does 200% of his daily work in 4 hours, starts crying, and goes home. That's not a performance issue.
    – gnasher729
    Commented Dec 9, 2016 at 14:57
  • 5
    @gnasher729 I would say it absolutely is a performance issue. Regardless of how quick or efficiently you work, being unable to communicate with your colleagues is a significant problem
    – JohnHC
    Commented Dec 9, 2016 at 14:58
  • This would usually be a fine approach, but given the coworkers already demonstrated lack of ability to receive constructive advice without taking it personally, I'm not sure it's a good idea in this case.
    – user30031
    Commented Dec 9, 2016 at 17:48
  • I like the answers from Wesley Long and Kate Gregory, but this one says in a succinct way: Try to involve the employee in the solution. Other replies seem to try to sweep the problem under the carpet. OP should at least TRY to get the employee's perspective. Maybe the coder can't articulate what bothers him. But you won't know until you try. The coder deserves to be involved in the solution to the maximum extent that he can be. I feel like gnasher729 is confusing "performance" with "productivity." That latter is just one component of the former. Commented Dec 9, 2016 at 22:42

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.

  • 3
    @VietnhiPhuvan As someone with an emotional/mental disorder, as well as a clear set of what is ethical and what is not.....I find not only your reusing of Rainman in the beginning, and then Headcase at the end, quite abhorrent. Commented Dec 10, 2016 at 5:57
  • 2
    You see insults where I see none, first, name calling aren't professional, Second, people react to them differently, as everything. Of course we could say 'just ignore it', but personally I consider that it's everyone's very right to not allow others to be called differently (or by their job's title). Finally they're banned by the Be nice policy, so even if, I'm sure of it, you don't mean anything bad, it is really better to avoid them at all.
    – Walfrat
    Commented Dec 10, 2016 at 23:33
  • Thanks for the edit! However, now I don't really see an actionable advice here.
    – user30031
    Commented Dec 12, 2016 at 15:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .