
Code Health: Respectful Reviews == Useful Reviews - mooreds
https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html
======
PragmaticPulp
I agree with the premise. Workplaces are much more enjoyable when everyone is
respectful, professional, and courteous to their peers.

Most of these guidelines are reasonable enough. I think it's important to keep
the DOs and DON'Ts list to the minimum, though. These interaction guidelines
become counter-productive when they try to be all-encompassing definitions of
good and bad interpersonal behavior.

I worked with one team who had an ever-expanding code of conduct. Each time
they had a conflict, they tried to add rules to the CoC that they thought
would prevent the conflict. Good intentions, but counter-productive execution.
Three things happened:

1) New hires had to learn to navigate a minefield of obscure code of conduct
rules. They tended to shutdown and socially isolate themselves for fear of
accidentally triggering another obscure CoC issue, like including emojis in
code reviews. The safest thing to do is only interact with close allies within
the company, and minimize unnecessary interaction with anyone else. Silos.

2) The CoC became a tool for power plays. For a few bad apples, the CoC became
a list of gotchas that they could use as a power play against others. At one
point we had someone reading every Slack conversation and code review just to
call out possible CoC violations (remember, this includes things like using
emojis in code review) so they could call other people out on their
violations. Substantiative conversations moved to private messages or in-
person conversations. Not healthy. Partially solved by adding a CoC rule about
minding your own business and explaining healthy ways to share the CoC with
others.

3) Human interactions started to feel robotic, almost scripted. This one is
harder to describe, but each interaction with someone in public or outside
your close friend group started to feel like everyone was following a mental
script for how our conversations could proceed. Conversations felt like a
mental checklist of what was an acceptable way to discuss a differing opinion
or answer a question without the possibility of stepping on anyone's toes. It
became draining in ways that I haven't experienced since. It was a huge relief
when I moved to another company where people were allowed to talk freely to
each other, like professional adults.

~~~
bluntfang
Hmmm number 3 doesn't seem like a negative or counter-intuitive. I feel like
software devs (in bay area startup world, or FAANG) are usually a certain
demographic and they usually come from a place of privilege where they've
never had to do the mental work that's involved in communicating effectively
across diverse demographics.

~~~
PragmaticPulp
> Hmmm number 3 doesn't seem like a negative or counter-intuitive.

This is the core of the problem: Some people like the idea of robotic, semi-
scripted conversations according to a well-defined set of rules. They think
that if there's a rulebook, they can predict how people will respond to them.
Or worse, they think they can control how people react and respond.

Yes, we should put some constraints around egregious communication issues as
well as provide general guidelines, but the important thing is to let people
interact naturally within those loose constraints.

> I feel like software devs (in bay area startup world, or FAANG) are usually
> a certain demographic and they usually come from a place of privilege where
> they've never had to do the mental work that's involved in communicating
> effectively across diverse demographics.

It's a fallacy, though. You can't create perfect rules for human conversation.
Everyone needs to build those interpersonal and conversational skills, even if
it's somewhat painful along the way. The basic skills can be guided with
simple rules and guidelines, but the problem comes when you try to control too
much of the conversation or set the constraints so tightly that it's a
minefield to navigate.

~~~
bluntfang
>Some people like the idea of robotic, semi-scripted conversations according
to a well-defined set of rules.

Thinking about the words you use in daily conversation with diverse peers
doesn't have to be "robotic". You're just being exposed to how other people in
less privileged positions have to think and act, and that's uncomfortable.

>You can't create perfect rules for human conversation.

Is anyone here claiming that their goal is perfection?

>Everyone needs to build those interpersonal and conversational skills

And there's nothing wrong with receiving help and guidance while you're on
that journey.

~~~
concordDance
> Thinking about the words you use in daily conversation with diverse peers
> doesn't have to be "robotic".

I'd much rather save my mental energy for the coding.

If having to carefully think about how every turn of phrase could be seen and
completely giving up on being able to make friends at work is the price of
hiring less privileged people? I'd rather stay in my privileged monoculture
thanks. The underprivileged can go join the company with the underprivileged
monoculture and everyone can be happier, communicating in the style they
prefer with people who are ok with that style.

~~~
twothumbsup
"i cant make friends if i cant make dumb jokes about minorities and women"

------
quelltext
While I agree with the core of "DON’T: Criticize the person. ", I'm not sure I
agree with the example. I get that avoiding "you" and "your" can help with
setting the tone, but ultimately it matters more what is said in particular.
The DO example to me seems overly distant, almost snarky and amplifying
criticism in my mind, like somebody explicitly telling you "don't take it
personally":

"This concurrency model appears to be adding complexity to the system without
any visible performance benefit." just screams "I think this is shit but I'm
not gonna tell you more directly because we have a policy not to do that".
Might be only me, maybe.

In my experience, I have received a lot of comments with "you" and "your" on
them but they were still constructive. But when I received very sterile ones
like the DO example I typically felt a bit weird, guilty, like someone
actively avoiding to tell me what they think, or colleagues using extremely
formal/polite language. A lot of things can carry weird undertones, depending
on context.

~~~
pavlov
It does come off as passive-aggressive. The tone is so final and closed to all
discussion.

If I were on the receiving end of that feedback, I'd much rather have the
reviewer write something like:

"Can you walk me through the rationale for this concurrency model? It seems
complex for what we're trying to achieve at this stage."

~~~
nerdponx
As some other commenters wrote, you can probably be more direct:

"Why use XYZ pattern instead of ABC? This seems more complicated than
necessary right now."

There's also a useful communication/pedagogy technique I learned many years
ago called "praise, correct, praise". You frame a "correction" or negative
feedback with either neutral or positive feedback. The idea is that the other
person receives the feedback without feeling "stung" or associating it with
negativity, which could reduce their receptiveness or even their ability to
retain and/or apply the information.

~~~
elgenie
“Praise, correct, praise” is less fawningly known as “shit sandwich” and
appears incredibly patronizing to anyone who is either aware of the method or
possesses minimal skills of observation.

~~~
stevens32
The fact that at least an effort was made does count for something, I believe.

~~~
Jamwinner
But the motivation for that effort varies from 'this person is actively
seeking to manipulate me with poppsych to use my failed career as a stepping
stone' to 'genuinely concerned about how I feel about recieving critical
feedback.'

------
jeremydeanlakey
They didn't have my favorite one: using questions instead of statements For
example, "Why did you do it this way?" instead of "Here's why you should do it
a different way". (or "have you considered...", "what are the benefits of A vs
B", "is this going to meet this requirement or avoid that problem")

This approach has helped me because

a) It feels less aggressive (more like you're working through it together),

b) It prods them into thinking through what they missed, and

c) It prods for information that I might be missing. I might actually discover
that I'm wrong and the other person considered more information.

~~~
asdfasgasdgasdg
In general I agree with your point. I just want to point out one particular
edge case where it can be misapplied.

The one thing I always want to be careful of with questions is to make sure
they don't come off condescending. One example of an anti-pattern with
questions is to ask

"Why did you do <obvious mistake>?"

In that case, clearly they didn't mean to make the obvious mistake. Asking the
question implies that they did it intentionally, when surely what actually
happened is they overlooked the error. Instead, I just point out the mistake.
"I think you forgot to check for null here." comes across way better than "Why
didn't you check for null here?"

The general principle I find useful is to try to say exactly what you mean.
When you spot an obvious mistake, there's not really a question to be asked.
You are trying to note the mistake, so just use a statement to note the
mistake. When it's less obvious, or it's a judgment call, a question is great,
because that's exactly what you're trying to do: ask whether another approach
might be better.

~~~
overthemoon
Few things in a professional setting annoy me more than what you're
describing. I left the default date on a form once and got it back with a note
that said "why did you put this date here? Today's date is XYZ."

You got me. I thought it was 2004. Thanks for correcting me, now I know it's
actually 2019. Pretty shocking that I'm actually 15 years older than I
thought! I guess I'm a huge moron!

------
danans
The most disrespectful part of the "Don't" examples are that they are _vague_
about their concerns while simultaneously expecting a concession from the
other party in the review. They say, "your code/approach is wrong, but I don't
feel like explaining why I think it's wrong".

That's what sets up the context for the you-s to be interpreted as jerky.
"You" can certainly be used in a non-disrespectful way, but not when the rest
of the comment it is attached to is disrespectful.

Code reviews are like small debates, and successful debates do involve
courtesy, patience, and arguing in good faith, which are also basic life
skills.

------
jacobsenscott
On the spectrum of best to worst way to do code reviews - pair programming is
the best. Writing comments, no matter how respectful, back and forth is the
worst.

When I do code reviews I split the difference and "pair code review".

My preferred method:

I start by realizing the author has had more time to really think it through
than I did, give them the benefit of the doubt, and realize I have some faulty
assumptions up front (the classic "Building twitter can't be that hard!" type
assumptions we see a lot on HN).

Then I read through the code on my own but don't post any comments, or only
post "uncontroversial comments" (spelling, forgot to scope a query, etc)

Then it is time to pair. I start a screen share/video call with the author and
let the author take the lead and walk me through it. They tend to find most
issues on their own just by talking it out (rubber duck code reviews). Usually
the author posts comments on the PR while doing this, not me. When I see a
problem I can guide them to the problem with a few prompts and we can discuss
it and resolve it right there, without any back and forth in pr comments.

Only after doing all this would I consider asking the author to make major
changes or re-dos.

Sometimes I'm in a hurry and I don't do all this, and it often leads to hurt
feels, pr flame wars, etc.

~~~
klipt
> Sometimes I'm in a hurry and I don't do all this, and it often leads to hurt
> feels, pr flame wars, etc.

Have you considered framing all your suggestions in the form of questions?

Eg "have you considered doing this using <X>, because the style guide suggests
it/it might be faster/etc"

That way if they have already considered it, they can just respond yes, and
give the reason they didn't do it. And if they haven't considered it, they can
think about it and make a more informed decision.

Maybe this is a very passive approach but it seems to work for me. Inspired by
a sci-fi writing workshop I took and the tips they gave on how to critique
without turning it into a confrontation.

~~~
strken
Reframing statements as a question is less effective than training yourself to
actually ask real questions. If you're 99% convinced that something is wrong,
it's no use asking a question like "have you considered not leaving a print
statement in the middle of your code?", but if you're only 90% sure then
there's already a question you need to ask.

This may or may not be what you suggested, sorry if it's redundant.

------
pkamb
> DO: Assume competence.

The code reviews I've had the most trouble with are the ones where I can't.
Blatant copy/pasting, 20 blank lines checked in, unrelated configuration
changes included, one-line fixes implemented via complex logic, zero git
hygiene/cleanup, zero self-review of the code review before assigning it...

If I leave a comment like:

> This logic is repeated in both view controllers. Should be DRY.

I'd love to be in a situation where that was actually intentional and a DRY
implementation was considered but abandoned for X reasons.

Far more likely is that they needed it in 3 places and thus pressed CMD-V 3
times.

~~~
BeetleB
> This logic is repeated in both view controllers. Should be DRY.

It may well be a good idea _not_ to be DRY.

[https://news.ycombinator.com/item?id=20395901](https://news.ycombinator.com/item?id=20395901)

~~~
pkamb
> I'd love to be in a situation where that was actually intentional and a DRY
> implementation was considered but abandoned for X reasons.

------
iorrus
Maybe it’s a cultural thing but I find many of examples given to be worded in
a way I would find a bit duplicitous. I’d prefer a much more direct approach
and I’d be reluctant to trust anyone using these kind of couched expressions.

See here:
[https://m.imgur.com/gallery/ltn3bla](https://m.imgur.com/gallery/ltn3bla)

------
nbar1
Practices like this are ridiculous. Of course you should be respectful in a
code review, but you should also be to the point and ask questions if you
don't understand why they did something they did, even if there is a "better"
way you know of. That's how people learn.

The examples they give are just bad.

~~~
Japhy_Ryder
I agree. Really poorly done - I'm surprised this is on the front page of HN.

~~~
DoofusOfDeath
Perhaps, but I'm finding that the resulting discussion surfaces a lot of
wisdom, good ideas, and different perspectives.

------
nawitus
"I don’t understand this." is a valid review comment. Of course sometimes you
can expand on the comment, but sometimes it's enough.

~~~
jchw
IMO, it’s a waste of time. How does the person who wrote the code know what
exact thing you don’t understand? You also aren’t asking a question so it’s
not really easy to answer. This stuff tends to take multiple review cycles to
resolve where a more specific question might actually clarify things in one
cycle (It’s never good to assume your lack of understanding means it doesn’t
make sense, of course.)

~~~
nicoburns
Depends on your review process - if that comment acts as a trigger/marker for
a face-to-face conversation then it makes sense.

~~~
bradford
If you want to trigger a conversation you could just as easily say:

"lets discuss this"

And avoid putting the burden of ambiguity on the author of the original code
under review.

------
otakucode
As a person who prefers profanity and hyperbolic exaggeration and over-
reaction when dealing with technical topics (about which no sane person would
do things like threaten violence, so it becomes funny for someone you know to
do so), I entirely understand the need for policies like these. I am fully
aware that I am not all people or even necessarily normal. Reviews inherently
involve other people, and unless you are in a closed and close-knit social
group, it is very easy for people to misunderstand things and be unaware of
the subtext a person might be intending to communicate with.

I don't really understand why (at least not enough that I could effectively
change the situation) some folks conduct themselves as if everyone else is
their best friend and knows them intimately, knowing when they are joking,
etc. Is it a matter of stereotypical 'social awkwardness' that society derides
intellectuals with? Or something different? I haven't personally come across
people that are earnestly writing code review comments with malice, but have
certainly seen some that could be seen as overly negative/aggressive/etc by an
outsider (they were written in a very close-knit team amongst friends,
though). I presume most all problematic comments come down to
misunderstandings.

------
he0001
I’ve experienced where code reviews have worked well and where they actually
have been more hurting for morale than useful. The difference between the two
was that how well people knew how to work with the frameworks they were using.
In the failing team the participants didn’t know what their tools and code was
doing and the code reviews basically became ravings about code formatting.

Another effect were it took days to do a code review because each review had
to be explained in detail, instead of have a common understanding of why the
changes should work or be different.

The effectively consequences of this was that people only asked reviews from
other people that either accepted everything or didn’t have the adequate
knowledge about tools so the code just became worse and even less aligned with
what the frameworks required.

This was recognized by the management and a huge effort were put into
educating the staff so the common knowledge about the tools were raised. This
was really appreciated move and, although the team still struggled at least
the reviews became better.

I don’t know if just respectful reviews work if you always feel, even if the
reviews are kind and helpful, as the one needing a lot of explaining to commit
your code, particularly if you are on a deadline and stressed out. People get
fearful and defensive if you don’t get what’s wrong with your code.

It can also be the other way around, that you get loads of questions and
downright wrong reviews which then has to be defended. And this is the
beginning of disagreements which could cause tensions and ultimately
disrespect.

------
keithnz
funny, I'd add :-

DO: Avoid using DO and DON'T

DON'T: Use DO and DON'T

They feel like "Political Correctness" rules and that can backfire (not that
the advice isn't good advice!), oddly enough, another google guideline posted
a while back on code reviews I thought got the language better
[https://google.github.io/eng-
practices/review/reviewer/](https://google.github.io/eng-
practices/review/reviewer/) . It uses language like "In general, reviewers
should favor..." which, to me, comes off a lot better than "DO:", I think it
leads to the "better" idea of improving the way you do things and conduct
yourself and the advice is giving you more tools to use during reviews, and
that it feels like its always an open to further improvement and that there is
a certain tolerance to not always doing it in a good way. Where the DO/DON'T
approach seems to create an idea of there being a definitive way of conducting
yourself which tends to irk people. Base definitive rules are the same as most
legal requirements of conducting yourself in a employment situation.

~~~
zajio1am
I think this is particularly good point. In general, i would consider
sentences in direct imperative mood as grossly inappropriate (for code reviews
or anything else), unless from someone in position of legitimate power /
competence.

It is interesting that they do not hesitate to use such disrespectful form in
blogpost about respectful code reviews.

------
m0zg
How do you deal with people who take _any_ critique of their code as a
personal affront? I'm working with one of such people right now, for the first
time in my 25 years in the industry. I'm a consultant, and he's an FTE. I'm
considerably more experienced and senior and management knows it. The guy's
PRs have been sitting in the queue for over a month now because there's no way
I'll let him submit his shit code to master, and he just won't clean it up.
That's not how I phrased it in the review obviously. I explained how the code
could be improved (and why it needs to be improved) and gave concrete
suggestions, using the most diplomatic language I could come up with. I
explained to his manager why the PR is stuck. His manager is conflict-averse,
so he won't push the guy, knowing how easily he gets offended.

I mean ultimately, my contract ends in January, so I could just merge the PR
and say "après moi, le déluge", but in case I encounter such people again in
the future, what do people usually do?

~~~
sundbry
Go sit next to him with a cup of coffee tomorrow morning, and fix the PRs
right there. Say "Let's do some quick pair programming and close these
lingering PRs real quick."

He should appreciate the initiative, and communication is much more effective
and resonant in person.

~~~
m0zg
Thanks for the suggestion, but judging by my other interactions with the guy
that'd be catastrophic. It goes without saying that we've already communicated
in person about this.

------
rb808
I find really hard about code reviews is how people have different styles.
Some people writing more procedural, some more functional, some want to use
Actor model, others like layers, others like having loads of dependencies
injected. What are you supposed to do? Haven't even started on the plethora of
libraries and frameworks.

~~~
netule
Stick to whatever conventions already exist in the project for consistency.

~~~
ken
I can count on the fingers of one hand the number of programs I've seen in my
life longer than 100 lines with consistent conventions.

------
seanwilson
No mention of providing positive comments? e.g. "Very readable. I think this
abstraction will save us a lot of time in the future too.". It's tiring to
work days on a commit only to get a bunch of fixes back with no understanding
of what people consider good tradeoffs and high quality for future commits.

~~~
Aeolun
And then your commit is merged, and all your great code is going to be used.

While I understand wanting to be praised to some extend, wanting to be praised
for doing your job still sounds a bit off to me.

That said, getting multiple rounds of fixes bothers me to no end, so I guess
it’s always merge after the first round of fixes.

~~~
seanwilson
> And then your commit is merged, and all your great code is going to be used.

It's more about understanding what qualities in your code your team
appreciates. There's a big spectrum in code that gets accepted for being
amazing and code that only gets barely accepted too.

> While I understand wanting to be praised to some extend, wanting to be
> praised for doing your job still sounds a bit off to me.

Do you think it's weird that people in other industries might say "great
work!" from time to time? Seems like a basic part of social interaction to me.
I don't want to work with robots, especially the people in code review
discussions that say everyone should just have a thicker skin.

Only getting negative comments back from people and "pull request accepted"
notifications is a cold environment to work in, especially if you work remote.

~~~
Aeolun
> Do you think it's weird that people in other industries might say "great
> work!" from time to time?

Not at all, it’s just that I personally don’t say, or expect, a “good work”
message unless I’m honestly impressed by what was written.

I’ve received that once or twice, and given it a few more times (in 10 years).

But just saying good work to keep someone’s motivation up, that is something I
would have to consciously think about.

------
l0b0
I often phrase code review comments as questions with _specific_ goals in
mind, such as "Would this be simpler/faster/clearer if [refactor idea]?" or
"How about [alternative]?" This makes it clear that I, as a reviewer, do not
have all the context that the author does, and that it's a good chance they
_did_ consider those ideas but rejected them based on previous experience.
This may be as simple as a broken third party thing that they had to work
around, or prioritizing differently.

The only thing this misses is code style, but holy crap automated code
formatting tools are such enormous time savers for reviews. Black + isort on
Python code and Prettier for everything else makes code reviews easily three
times faster.

------
majestik
These are all just basic principles of being a working professional, if any of
this is non-obvious you have a culture problem not a code review problem.

~~~
kradroy
I'm a manager and you'd be surprised at how many engineers (and people in
general) can take issue with wording in communications. And all it takes is
one person. More times than not that person is an overachiever - one who wants
everyone else to be perfect, or one who wants to always be perfect. So much
time is wasted sorting out miscommunication.

Just read through the other comments here regarding feelings for each of the
comment types.

Personally I have a thick skin. Even harsh, direct verbal criticism doesn't
faze me. I'll laugh in your face and tell you to get the fuck out of mine.

~~~
hi41
>Personally I have a thick skin. Even harsh, direct verbal criticism doesn't
faze me. I'll laugh in your face and tell you to get the fuck out of mine.

I like this attitude. How do you develop this. I am exact opposite of you what
you said. I get depressed for the slightest criticism. I want to learn how to
develop thick skin. I think it arises from my need to impress everyone around
me and my need for their approval.

~~~
anchpop
I see what you're saying, but "I'll laugh in your face and tell you to get the
fuck out of mine" is usually a very poor way to respond to criticism in the
workplace so you shouldn't necessarily aspire to it.

~~~
raxxorrax
I tend to disagree. Solving conflicts with this personality type is often
easier because it will stay on topic and you can still share a coffee
afterwards.

~~~
vkou
Many people have been raised in a social environment, where that sort of
behavior is considered hostile and disrespectful. If you're laughing in
someone's face, they have no idea of whether or not you think their work is
shit, or they are shit.

The OP believes that it is not hostile or disrespectful.

If neither group changes their behavior, he's going to be the one who lose out
in this exchange. He can feel he is in the right, he may even be in the right,
but that's a bit of a questionable hill to die on.

------
gherkinnn
> _If this is an optimization, can you please add comments?_

That’s a snarky one.

------
shriphani
CMU's RPP:
[https://www.cs.cmu.edu/~weigand/staff/](https://www.cs.cmu.edu/~weigand/staff/)

Was surprisingly effective. Probably something to it - that department has
maintained lasting productivity longer than the lifetimes of many companies.

------
deeteecee
Good guidelines for the most part. I don't really see anything wrong with "Why
are you using this approach? You’re adding unnecessary complexity" though.

------
euske
I just want to see more examples. Every situation is different and people
should adapt their responses to different personalities. Real examples taken
from real code reviews with contexts (chat logs and whatnot) and its aftermath
would be fun. Maybe I can dig some GitHub discussions and list
"funny/great/bad code reviews that went great/awry?" Also, as a thought
experiment, it would be fun to think what if Gordon Ramsey did code review.

~~~
pnako
>what if Gordon Ramsey did code review

Just read the Linux or OpenBSD developer mailing lists. Linus puts the fear of
God into Linux developers. Theo puts the fear of Theo into OpenBSD developers.

------
thrower123
My biggest concern with this sort of thing, and it's a general criticism, is
that the suggested way always comes across as very weak, roundabout, and
doesn't ever convey the same kind of sentiment as the language that is
discouraged.

You can be direct and unambiguous without being an asshole, but the suggestion
usually is to use some artificial passive-voice construction that no real
person ever speaks like, and which completely blunts the criticism.

------
sandoooo
so which of the following things are the author claiming with the ==?

\- all respectful reviews are useful \- all useful reviews are respectful \-
all disrespectful reviews are useless \- all useless reviews are disrespectful

Which of these things would the author defend when challenged, and which are
they gesturing vaguely at and hope to slip under the radar?

------
huherto
Before criticizing something, ask yourself "Is it wrong? Or is just not the
way you would do it?"

------
softfalcon
Ultimately, any rules you create tend to break down, as there is always an
edge case personality that will dislike the way you worded something.

The best advice I have seen applies to regular conversation as well as code
reviews:

When you see something that is confusing, incorrect, or debatable, take a
stance of genuinely attempting to understand the other person's mindset before
offering feedback.

\--

For example, asking questions in a respectful manner such as:

"Would you mind elaborating on why you chose this pattern of implementation?"

Will result in a positive conversation while also having them document in the
review their mindset for posterity and further clarity of discussion.

\--

From there, constructive conversation and asking if they're interested in
feedback/alternative approaches can happen.

This way you maintain respect and show an honest attempt to understand others
with every comment and suggestion you make to a PR.

\--

tldr; ask questions to gain perspective before you start dictating to others
how things should be done.

------
m3kw9
Coders has the biggest egos. One wrong word, it’s like a landmine when ever I
code review.

~~~
raxxorrax
It is often decried as ego, but sometimes they just care about it. Excessive
fandom can be another example of this.

------
droithomme
All of the examples of dos and don'ts in this article recommend obtuse,
indirect, and unclear baroque language over clear and straightforward
language.

------
AdmiralAsshat
I think it's worth noting that the three authors of the article are all women.
This is an explicit rejection of the "Lead Developers are your gods, and if
you can't accept their vile/vulgar/abusive takedowns during code reviews as
sage wisdom, you need to grow thicker skin" mentality that is particularly
repelling to women in the tech community.

~~~
silveroriole
Those of us who got into programming BECAUSE of the famous ‘characters’ of
open source and their ranty comments find it quite repellent to have codes of
conduct and women in the position of cultural politeness enforcers. Even using
an emoji/joke might be wrong? Really? The idea that women are uniquely
invested in this sort of stuff only damages my perception as a female
programmer. Who’s going to want to joke around with me or review my code if
I’m the fun police?

~~~
voxl
You missed the point. The point is a person with power over you needs to be
respectful of that power. Your boss is never going to be as buddy-buddy with
you as a coworker, because your boss has a lot more say over your pay and
whether or not you're going to be fired.

The famous "characters" of open source are notorious, not famous. No one looks
at a Linus rant and says "Wow I want to try my hand at adding a patch for
Linux!". No, they say "Wow, I want to have that kind of power!"

That's just the rub, isn't it, you don't get to decide that we have to be
hazed because you want the potential to hold that power of us.

~~~
silveroriole
> No one looks at a Linus rant and says "Wow I want to try my hand at adding a
> patch for Linux!".

People who think it would be awesome to get their code past Linus, and at
least very funny and instructive to have their code shat on by Linus, do :)
Some of us just don’t care about or even like ‘hazing’. You know, cause once
you show you can take the hazing, you’re in the group.

Yeah I don’t want to be, like, epically pwned by my boss on a code review at
work, but neither do I want my coworkers believing that I may find a smiley
emoticon or “I don’t understand this” to constitute some sort of hostile
environment.

~~~
gatherhunterer
What is the technical advantage of being intentionally abrasive?

It has the drawbacks of ostracizing those who are less confident with English
and would prefer direct communication, the potential of being misunderstood
and intimidating those who would prefer a more professional approach. If it
cannot make the code better then it is poor engineering practice.

~~~
XCabbage
It's kind of odd to ask this question in response to a comment that already
specified _two_ possible advantages. Namely:

1\. It sets up a challenge that incentivizes people to try to contribute; they
"think it would be awesome to get their code past Linus"

2\. It serves a form of initiation ritual (a hazing) to give people a sense of
belonging to the group

(I'm not sure I personally buy point 2, because as far as I know Linus is nice
to newbies.)

Beyond that, I can list plenty more:

3\. It builds trust in your sincerity. If you openly bitch about everything
that pisses you off, then when you say that something is decent work, people
know you mean it.

4\. As a direct consequence of point 3, it makes the environment much more
welcoming for people with scrupulosity complexes, who might otherwise worry
that they're just being a nuisance who everyone would rather not have around
(but is too polite to shoo away)

5\. It drives away hyper-PC social-justicey types who would otherwise impose
CoCs and disrupt everything with conflict and hatred.

6\. It sets a tone in which people feel free to speak freely, which sets
people at ease who would otherwise be anxious about accidentally giving
offence (perhaps because they have poor English skills, perhaps because
they're neuroatypical in some way that affects their social skills).

Are there downsides too? Sure. But this is just the age-old set of tradeoffs
between having a politically correct space and a politically incorrect space;
different people will feel alienated (or _be_ rejected by the group) in each
of them. For me, anti-PC spaces are home; they're where I feel comfortable and
safe and able to contribute, while PC / intersectional feminist / social
justice spaces feel oppressive. I guess silveroriole feels the same way.

~~~
gatherhunterer
It sounds like you have a lot of triggers and do not do well when confronted
with opinions that contradict your own. Many people prefer a less emotional
environment but if you need to be surrounded by like-minded people and cannot
put your personal feelings aside for the benefit of the product then you have
the right to pursue a comfortable environment.

------
sergiotapia
Is this so heavily upvoted because it's written by women or because it's by
google?

These all seem Professional Workplace 101 stuff. Blog bait really.

------
jorblumesea
Sure, if you have a company that wants to produce useful code and not haze
employees. For many companies, especially in big tech, code reviews are more
about asserting dominance than actual helpful suggestions. Looking at you,
AMZN...

~~~
lnanek2
I've noticed that at my current company as well. There's one reviewer who puts
a comment forcing someone to come meet with him every PR, often the comment
shows he hasn't even read the description, let alone the code. It's just a way
to prove he's the owner and gatekeeper and no one else can commit to that area
without coming to him in person.

------
l5870uoo9y
Oblivious everyone prefers to keep a good office atmosphere, but code reviews
also has to convey clearly what the problem and ensure code quality is
sustained or improved over time. Being to vague and "nice", can mislead
developers to think that it is optional to fix the problem. Companies that
produces great code, are those who have a strong meritocratic culture where
directness and quality stands above niceness and vagueness. Companies with the
opposite, whatever that is (perhaps a democracy or indifference), tends to
produce worse code and prevent developers from improving.

So, be decent and direct (not nice and vague). And make sure to also praise
progress and good code. End of the day, most developers prefers honesty and to
become a better programmer.

~~~
asdfman123
Don't confuse aggression and assertiveness. Have rules, and stick to them.

I can scream and yell at my dog all day long because he pulls on the leash,
but I'll just be angry and the dog will continue to pull on the leash.

If I'm calm, kind, but firm, I find it's usually quite a bit more effective.
I'm not getting angry, but if my dog wants to keep walking, he's got to calm
down first. I'm willing to wait.

