Response to a bugfix suggestion said to just report bugs (not suggest solutions). Is this typical? [closed]

Question

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!

Thanks,
Morty

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,

--Rick

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

TL;DR

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.

Answer 10

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

Answer 11

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.