I'm a new employee at a software company, and saw an email sent to an coworker from a system owner, but with the whole dev team CC'd, and it got me a bit worried about the environment. I'm recently out of college so this is my first job so...is this normal in tech companies?

Sent to Rick and Cc'd dev team mail list:

Hi Rick,

I ran valgrind on the SpaceShip proj, and I think I found a memory leak in some of the platform code. I believe I found the source and the issue can be fixed with the below diff:

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp
 vector<part> parts = getSpaceShipParts();  
+shared_ptr<SpaceShip> p = new SpaceShip(parts);  
-SpaceShip * p = new SpaceShip(parts);
 engageInBattle(p, enemy);

I re-ran valgrind with the change, and it seems to fix the problem!


A pretty reasonable email I thought, which was answered with:

Hi Morty,

Thanks, but in the future please just provide the information about how to reproduce a problem, not a suggested fix. I don't read suggested fixes, because they predispose me to a particular idea of what the real problem is and what the fix should be. I'm better off going in fresh and deciding for myself.

In cases where I accidentally read a diff before realizing what it is, I purposely spend at least several days trying to forget so I can go into it fresh. So giving me a diff just makes it more likely I won't even look at the problem for some time.

Thank you,


  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Jun 21, 2018 at 21:12
  • It is very uncommon to have that type of communication, but, unfortunately its common that each company/team has a member that doesn't really function in a team, or is a know-it-all and so on. Basically, as long as this doesn't occur with most of your collegues, just try to avoid that one person and you should be fine.
    – Chapz
    Jun 22, 2018 at 8:11

11 Answers 11


No, this is not usual. You have run across a fairly common beast, however, the Elitist Super Entitled Developer. He's smarter than everyone else in his own mind and is entitled to be rude for the same reason. He has some ax to grind against Morty. Avoid him when possible and move along.

While he's certainly within his rights to want to investigate the problem himself, a civilized response is "Thanks for the suggestion, I'll look into it." There may be preexisting bad blood between the two or he may just be feral, but in either case while this behavior isn't unknown in tech, it's not acceptable or "usual."

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Jun 21, 2018 at 21:11
  • The tiniest fix I'd like to add is that OP is Morty's friend, not nescerily Morty. Jun 25, 2018 at 15:56
  • That's not a fix, the Rick has an issue with the Morty in this example. Morty's friend is the OP but is just an onlooker.
    – mxyzplk
    Jun 25, 2018 at 22:55

As a developer, I find the first report very very useful. No long explanation, no long valgrind trace to read. With that patch, I could immediately see what the issue is, and if I worked on that code recentely, I would probaby know if it is right fix or not even without checking the code. So I would just reply "Thanks for catching it", or "Thanks, that pointer shouldn't be shared, but I know how the issue should be fixed now that you brought it to my attention" or something like that.

Also I don't detect any feeling of superiority in the message.

Now CC'ing everybody might or might not be bad. The code might be something also others know about, so if CC recipient list is short enough, this is good. The mail is short enough, and everybody can immediately see from the patch if they should be interested or not, wasting only a little time. However, if there are people who aren't involved with that source code base in CC, then it was inappropriate.

Another issue is, if the person should be spending their time debugging an issue like this. However, unless they are falling short from their own goals, then taking responsibility of the whole software like this is generally a very very valuable trait. It shows enthusiasm and caring, rare thing really. These things can go too far, but it is so much more common to see team mates who couldn't care less about a bug in someone elses code, unless it impacted them directly.

To answer the title question. Morty's tone as presented in question is, to my eye, professional and normal. Ricks tone is... unfortunately not that unusual either, but it is unfortunate. We all have bad days however, so I shall not analyze a single anonymized message further. It could be a bad sign (and looks like it, TBH), or it could be part of quite decent workplace culture you just need to get used to.

  • 33
    "CC'ing everybody might or might not be bad" - in the case they knew how Rick acts in these situations, CCing everybody feels like the most appropriate way to ensure the problem does actually get fixed.
    – user81330
    Jun 21, 2018 at 8:52

I know the question was already answered, and I agree with the accepted answer, but I just wanted to extend this with more information.

What you've seen here is a a potential XY problem. XY problems are, in my opinion, something that every problem solver (not just programmers) needs to be aware of and avoid.

The principle of an XY problem is quite simple:

  • X is a problem and needs to be fixed.
  • Y is a solution, but not the best solution. Regardless, it is chosen (either through laziness or not understanding that there's a better solution)
  • When an issue pops up with implementing Y, people dedicate time on trying to get Y working, as opposed to actually looking there is a Z solution which fits better.

As a clear example:

  • X = I want to sort this Excel data.
  • Y = I can write an application to sort the data and save the file.
  • Z = I should learn how to use Excel's sort functionality.

This is essentially what has happened in Morty's email. Rick is incapable of labeling the request as either Y or Z, because Morty doesn't explain X. Explaining X is more important than offering the Y/Z solution, since Rick is capable of finding Z when he knows X, but he can't guess X out of nowhere.

This is the X problem:

a memory leak in some of the platform code

Note that it is quite vague. What was the issue? Where did it occur? When did it occur? Was it an edge case?

Then Morty proposes an Y solution. Since we don't know the specifics of X, therefore we have no way of gauging if Y is an appropriate solution for X.

This is why Rick pushes back against it. He's asked to change something (and effectively take responsibility for having changed something) without getting any choice. Morty has effectively undermined Rick's responsibility (writing good code) and is replacing it with a request for blind trust that the offered code is appropriate and good.

Think of it this way: You're a police officer. A man comes up to you and say "I need you to arrest that man" (Y).

The police officer should not comply, as he is unable to personally confirm that arresting the man is warranted.

However, had the man said "that man just killed someone in cold blood", then the police officer is able to actually understand the problem and decide on the solution (arresting the man) himself.

This is basically what Morty did wrong. I do think that Rick could've phrased it more kindly (if this were Interpersonal.SE I would definitely rephrase some of Rick's sentences), but his request is valid.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Jun 21, 2018 at 21:10
  • 3
    @JaneS comments are, however, correctly used to point out problems in answers. Jun 21, 2018 at 22:08
  • While I think mentioning the XY problem is relevant to whether Rick's request was reasonable here, I don't feel like this is an answer to the question the way you've written it. The OP asked whether Rick's tone was normal in the industry. You might consider reformatting your answer to focus on how Rick handled it, although the gist of his response is valid.
    – Bloodgain
    Jun 21, 2018 at 23:59
  • @BloodGain You might consider reformatting your answer to focus on how Rick handled it, although the gist of his response is valid. That is exactly what the last sentence of the answer addresses.
    – Flater
    Jun 22, 2018 at 7:28

Ignoring whether there is underlying tension between the two, a general communication problem or the standard tone at your place, I´ll want to concentrate on your question:

Is this tone unusual in a tech workplace?

No, this tone is not entirely unusual.

  1. People in the industry are used to syntactical programming languages and exact technical specs tend to sometimes forget tone in their communication. Often times this is not a problem as long as outsiders are not involved in the communication. Get used to a lot of cut-right-to-the-case messages.

  2. It´s a cliche, but yes there are also those nerds out there who just have poor social skills, so you better learn to deal with them and not take it personal.

  3. For a lot programmers "their" code is their baby. Getting pointed to some undeniable errors is one thing - messing with it can just trigger some defense mechanisms.

That said, it can be done in a better way. As a rule of thumb, to avoid such problems:

  • Praise public, criticize private.
  • If you have trouble with someone, don´t use e-mail at all for that!
  • If you find a bug, report it via a standard mechanism that is accepted by the team.
  • Don´t do someone elses work, unless asked to.
  • I like all the bullet points. The first two are a good general general guidelines in life. Jun 21, 2018 at 12:47
  • 1
    Re the baby, it matters whether the person has experience with open source.
    – Nemo
    Jun 21, 2018 at 14:02
  • 2
    Complaining about lack of reproducer is IMO valid. But requesting no solution is given is rather crazy. Being unable to ignore someone else's though means you can't ignore your own misleading thoughts. And if you can't, then good luck doing programming. You'd have to start one way and keep going in the same direction indefinitely. Or refactoring existing code? You need to understand what original idea was end then fold into the new paradigm you want to apply. Jun 21, 2018 at 17:14
  • 1
    Rick's declaration that he will deliberately add delay to the process, nominally so that he can rid his delicate mind of Morty's corruptive idea, is petulant, and completely unacceptable, and needs to be dealt with. If Morty is over-reaching (his skill and/or scope) a better balanced response would be "Thanks, Morty, and your quick suggestion might be part of the solution, but I'll need to review more of the problem to make sure it's the best approach. Meanwhile, can you please document this bug in our bug tracker? It's really important to put all bugs into it!"
    – CCTO
    Jun 22, 2018 at 20:49
  • @CCTO (and other commenters) You do realize that OP did not ask how to deal with it, yes?
    – Daniel
    Jun 22, 2018 at 21:58

There is some value to his sentiment. I know of many times where my hunch about a root cause led someone down the wrong path and wasted their time.

With most issues, every person has certain hunches that just "pop" out at them. I think it's worthwhile to try to harness this power. When I need help on a bug I'm stuck on, I try to avoid imposing my own hunches on them, so that perhaps theirs might be novel and productive.

But with the way he expressed it... he was being a total asshole.

  • 4
    I sometimes get web tickets with suggested CSS fixes for visual bugs. Problem is the selectors are usually super-generic (often based on just tag names or one class) and would break several other areas of the site. Still, i like the suggestion because it usually saves me some time finding the exact problem, then i can just namespace it out into something production-ready...
    – dandavis
    Jun 21, 2018 at 6:12
  • 2
    Could you expand on the impolite bit? This answer is great given it weighs both sides, but it's a bit uneven.
    – Tom
    Jun 21, 2018 at 8:03
  • 38
    I have to respectfully disagree. In technical troubleshooting more information is always more valuable than less. As the assigned problem solver it is the developers job to identify what is erroneous information from the customer vs. valuable details. Keeping some detail from the troubleshooter because you might "set them down the wrong path" is a ridiculous idea to me and i would reprimand any of my people who responded to a customer this way.
    – user48276
    Jun 21, 2018 at 8:40
  • 3
    can you please elaborate what exactly is not polite here? it seems completely free from offense to me, I'd like to understand it Jun 21, 2018 at 9:17
  • 3
    @SargeBorsch - the demand to not include ordinary, trivial information is utterly unacceptable in a collaborative project. And the stated intent to punish Morty by intentionally delaying the project only doubles that. It's written up to look nice, but the meaning is blatant, and improper. That the issue report includes two lines of diff is not a problem - it might or might not help, but it is not a problem. Now, if Morty is not supposed to be running valgrind, and habitually reports confused things, that might be something the organization needs to deal with, but this is not the way. Jun 21, 2018 at 14:22

Cleary not everybody agrees with this, but IMO this is a normal response, don't take it personal.

It's an easy to understand email, he motivates his reasons why he prefers not to hear your solution (not because it's your solution, but because he wants a blank slate to begin with).

It isn't personal towards you, or insulting, or undermining at all, it's an explanation. It's a bit direct for some people, but that's often a programmers quirck, being direct and (too) factual. You could read this whole e-mail in a normal tone of voice, where he explains his prefered method. Just because you're not a fan of it, doesn't mean it's bad practice, you'll encounter many people who'll work different from you.

I do agree that it might be phrased a bit more politely, but again, a programmer often just says what he means without all these loaded interpretations (which isn't en excuse, but it could be an explanation).

It's his job to fix problems, not yours. You've just spend time on something, which could've been used otherwise. Don't get me wrong, practising bugfixing is important! But study the applied solution and compare it to yours. Your solution might seem fine, but experience might teach you otherwise.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Masked Man
    Jun 21, 2018 at 14:31
  • 7
    @Martijin The question actually states that Morty is the "system owner" ie someone responsible for seeing that this gets fixed. Investigating the problem isn't really out of their overall job. Rick's email is in part an explanation, but it's an explanation of a demand to be protected from the kind of information ordinarily and usefully exchanged in such situations, and as such a demand that is fundamentally incompatible with a group project, no matter how nicely it is phrased. Rick is free to consider alternate causes and solutions, but not to shut down ordinarily exchanged communication. Jun 21, 2018 at 16:07

Both sides are at fault here.

Morty should have not cc.ed everyone on the initial email. By doing so he embarrassed Rick by pointing out his mistake to everyone. I don’t know if Morty was trying to score points by doing this or if he was simply foolish. However the result was the same from Ricks point of view. Morty would have been better off sending this email only to Rick so that they could fix the issue without anyone having to look bad.

Rick being embarrassed at having his mistake pointed out publicly reacted badly. He shouldn’t have put down Morty. He should not have publicly criticized Morty for trying to help.

One example of an email exchange doesn’t tell us anything about a company culture. However if sending public emails pointing out other people’s mistakes, and sending emails telling people they shouldn’t offer help are common there they you have a toxic culture.

Unfortunately, this kind of toxic culture is common in software companies in the United States. Much as been written[1][2][3] and said about the way a particular type of software engineers treat others, especially non-software engineers and people who are don’t fit their stereotype of a software engineer.

This culture is not the right way to treat people. Good company, managers and co-workers don’t tolerate this sort of culture. Good employees don’t publicly point other each others mistakes and good employees don’t dismiss help from others.

You need to figure out of this behaviour is acceptable in the culture of your department and company. If you think you are in a company which this is accepted you need to decide if you think you can change the culture and if it is worty the effort. An important thing to figure out is if this culture comes from the leadership or not. If leadership sets a bad example there will be nothing you can do. If this is the grassroots culture they you have some chance of convincing people to change. It will be a long hard job so you better decide that the company is worth fixing.

  • 12
    Maybe. Without more context we can't really know if the original email is "pointing out someone's mistake" or "sharing progress with the others involved in a group effort" - for all we know this is a key development in an area where's there's been a shared but non-specific sense that something was wrong. Note it doesn't say "in your code" - that might be an implicit assumption, but the text of the email is no more accusatory than a typical bug ticket, and better researched than most. Or it could be a very normal looking piece of text highly weaponized in its actual context. Jun 21, 2018 at 5:56
  • 10
    It's fairly common to cc the team when facing a important bug. Jun 21, 2018 at 7:42
  • 6
    "he embarrassed Rick by pointing out his mistake to everyone" Software contains bugs. Everyone involved in creating it knows and accepts this. I can guarantee that no one was operating under the delusion that Rick was an infallible programming god. Should they also delete their bug tracker because it's subversively a permanent record of Rick's personal failures? I don't get paid to pander to fragile egos. I get paid to make good software.
    – Michael
    Jun 21, 2018 at 9:06
  • 2
    @Michael “I don't get paid to pander to fragile egos.” Thats the sort of thing many people say to justify being an ass.
    – Ben Mz
    Jun 21, 2018 at 9:22
  • 1
    @BenMz True enough - I'm sure Rick could try to make that assertion after reading some responses here - but I think such a person would be misidentifying being polite with pandering. It's not the same. I'm always polite at work but I should not have to walk on eggshells around an individual because they can't handle the dev team being CC'd on email about an easily made mistake.
    – Michael
    Jun 21, 2018 at 9:30

Normal is quite subjective especially since you have no clue about the history of that workplace.

Either Rick has terrible interpersonal skills or there is some bad blood between those two people.

It is possible that Morty purposefully crafted a "reasonable" email hoping to trigger Rick.

Since you are new, you will need to evaluate whether this toxic behavior has spread to others as well or if it is a contained situation.

Whatever happens, just don't let it spread into your personality.


I am writing this with the perspective of a manager with experience that covers multiple aspects of this type of scenario.

is this normal in tech companies?

This is entirely normal for any company in virtually every industry, not just tech.

Broadly speaking, the email that was sent out to all members of a dev team that:

  • pointed out a suspected flaw ("I think I found a memory leak...")
  • stated an alleged solution had been found ("I believe I found the source and the issue...")
  • presented a laundry list of fixes to be implemented

To generalize this, what's happening here is that a directive is being given to Rick by Morty establishing a justification of the directive first then itemizing the specifics of said directive.

It further complicates the matter in that the directive was given in a group setting (cc'd to all members of the team).

Rick's and Morty's organizational relationship

We don't know the relationship with respect to the two individuals. However, it can be generally summarized as one of three possibilities:

  • Rick is senior to Morty
  • Morty is senior to Rick
  • Rick and Morty are equal

Is Rick supposed to be taking directive from Morty?

  • No? Then Rick is justified in pushing back
  • Yes? Then there's no need to CC everyone. Rick is still justified in telling Morty how he best performs his job.

This situation wouldn't be any different if it were....

  • Medical. Dr. Oz tells Dr. No he has diagnosed Dr. No's patient and to do X, Y, and Z without providing the symptoms to Dr. No.
  • Automotive. Engineer 1 tells Engineer 2 that a problem was found in Engineer 2's suspension design and the fix is to weld tab A to slot B without providing the test data to show the problem
  • Tech Support - Tech 1 tells Tech 2 that that there's a problem with Tech 2's system and the fix is to implement patches A, B, and C without supplying the error messages that indicated the problem.


Bottom line, the person responsible for doing the actual fixing is telling the person what they need to properly do the job. The only person that is potentially "out of line" is Morty for the passive aggressive behavior of cc'ing everyone.

This happens every day in every industry. It's nothing new or unusual.

  • 1
    Communication is extremely important.... In my team 90% of communication goes over slack/jira/github that everyone can see. For a solution that affects the product of a team I think you should always cc the whole team (or, probably just send it to the whole team). As for the actual problem in the email: A problem was found, a solution was found. Now you think the Lead makes good use of their time by discarding problem and solution and trying to verify that a problem exists and then come up with a solution that may or may not be better ? in doing so you tell the guy his work doesn't matter...
    – xyious
    Jun 21, 2018 at 19:02
  • @xyious - I will assume you down voted because for the reasons in your argument. Interesting. The question is not about who is in the right, the question is is the tone unusual. That said, whatever preferences the person responsible for making the change has, is their preference. Period.
    – Allan
    Jun 21, 2018 at 19:21
  • @Allan - a two line diff is not "a laundry list of fixes to be implemented" - wherever you are getting that from, it is not part of the situation of the question. In terms of Morty and Rick's roles, it's been explicitly stated that Morty is the "system owner" and from context it is clear that Rick is the current area guru for the code in question. Jun 21, 2018 at 22:16
  • So, @ChrisStratton you took the "diff" literally? SMDH. Let me ask you this.... do you think an attending physician tells the specialist what to do or does he tell him the symptoms and wait for a confirmation?
    – Allan
    Jun 22, 2018 at 0:30
  • I took the scale of the diff literally, and am quite confident that is accurate. The whole point of the question is that Rick threw a fit over an extremely normal, ordinary and proper action. You seem instead to want to respond to a very different situation than the one actually asked about, expressed also in your speculation about relationships not fitting with Morty's explicitly stated position. Jun 22, 2018 at 15:04
--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 vector<part> parts = getSpaceShipParts();  
+shared_ptr<SpaceShip> p = new SpaceShip(parts);  
-SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 

Unfortunately, this change does fix the bug (pretending the valgrind test is adaquite), but it's introduced something unwanted, a code philosophy fight. If you're not a regular contributor, don't get into code philosophy fights.

To avoid the philosophy fight, this should have been sent instead. Yeah it's objectively worse but it's in keeping with the style of the code already there:

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 
+delete p;

But with this answer from the developer, I take it he wouldn't have liked that either. I hear this tone quite a bit too much, even from people who should know better. It's not normal, but it's enough that you hear it a lot. I am disappointed.

  • 1
    This may be reading the diff a bit too literally. It's not a pull request, its a bit of code as speech in an email. In effect it's saying "perhaps we could fix it this way, or maybe you have a better idea, but this issue is important to my project which contains your code, and the issue seems to be of this form" Even when not merged, diffs like this are pretty normal communication between programmers. Jun 21, 2018 at 22:12

1) Communication: OP makes it seem like it's standard practice to cc the rest of the dev team. I don't ever see a reason to not include the rest of the dev team in a problem/solution that affects everyone.

2) Problem/Solution: Don't see anything wrong here. It should be done with a pull request, but assuming that's not possible here, it's fine.

3) Response: So many things wrong with it I don't even know where to start.
a) 'I don't read suggested fixes': This is absolutely terrible. Always read proposed code. There's a decent chance it's better than anything you can come up with....
b) 'I have to wait a few days before I can come up with a solution': Let me translate that: "I have to wait a few days before I can completely ignore the work you did and discard your solution. Not only will I waste time to get a solution implemented, I will also waste more time to come up with a solution for a problem that has been solved (by the code you wrote that I will discard)"
c) 'see what the real problem is and see what the fix should be': test it. Test it to see if there's a problem. Then test it to see if the problem was solved. You gain nothing by coming up with your own solution that needs to be tested rather than testing the proposed solution to see if it fixes everything. If it doesn't fix the problem then you can try and come up with a fix for the proposed solution or a fix to the problem altogether.

In my company I would have forwarded the response to my manager immediately and without comment. It's simply unacceptable.

  • Speaking from a manager's perspective, I would inform you each and every developer is an individual and every individual has their preferred way to work. We must each try to accommodate each other's idiosyncrasies. In this case, I would advised you (speaking as your manager had you been Morty) to respect Rick's preferred workflow by sending him what he asked for first and then follow up with what you believed (as in the email) was the problem followed by what you thought (again, in the email) as the solution.
    – Allan
    Jun 21, 2018 at 19:28
  • And for the record....the further I went in my career and gained experience, the less I relied on the "the diagnosis and the fix" without a clear articulation of the problem first. The exception to this rule was if the problem/solution came from a trusted source. I can tell you that I too, ignored potential solutions if they didn't conform to my requirement but it wasn't out of arrogance but rather a limited quantity of resources (i.e. time) to spend on deciphering other's work.
    – Allan
    Jun 21, 2018 at 19:36
  • So you would inform your dev team that it's acceptable (as an idiosyncrasy) to waste a dev's time (by providing a solution that will be discarded) and waste a lead's time (by him discarding a solution and coming up with their own) ?
    – xyious
    Jun 21, 2018 at 19:50
  • I would inform the dev team that wasting time by not respecting the wishes/requests of those responsible for their respective functions is what's unacceptable. Just because you assume the solution is the correct one doesn't mean that it is. It also boils down to the fact that the one responsible cannot validate the problem against the diagnosis and ultimately the solution. You're not advocating that someone should simply accept a diagnosis and proposed solution out of hand, would you? How much time would be lost then? How much time would be saved if the symptoms were validated first?
    – Allan
    Jun 21, 2018 at 19:56
  • 1
    Test it ! Test that the problem exists ! Test that the solution fixes the problem ! Then test that the solution doesn't break anything else. You would have to do the last two anyway. Why would you waste a solution that you haven't tested and come up with something else that might not even work ?
    – xyious
    Jun 21, 2018 at 20:03

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