Live data from Hacker News

I ruin developers’ lives with my code reviews and I'm sorry

habr.com

81–90 of 199 posts

Re: I ruin developers’ lives with my code reviews and I'm sorry

#81
Everyone is capable of writing crap code ... Code that might give the impression of working but is unmaintainable.

PRs are conversations. Every team member should be able to request changes to start a conversation. A conversation about the code should focus on what tradeoffs are necessary to get stuff done now along with a consideration of how comfortable every team members feels they can maintain the code.

Teams where PR approvals are considered endorsements, where PRs are rubber stamped, where developers throw fits when others dare to ask questions etc are detrimental to both getting things done and maintaining a sane working environment.

Don't confuse the code with your worth. The greatest asset you will ever have is the ability to be openly critical about code you have written while understanding the right level of imperfection for a given circumstance. This only comes with experience. The more you nurture your ability to view your own code critically, the faster it comes.

Since we all have blind spots, take others' questions seriously.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#82

> If a guy brings me his code, and it has mistakes, it brings insane pleasure from how smart I feel [...] And if you tell me that you haven’t had this feeling ever, then you’re lying. Tell me about higher goals, training rookies and all that — I know you’re simply too full of themselves. And if you try to tell me that you learned to defeat that feeling (however it manifests in you), then I must be a pink unicorn. I r…

The other thing to keep in mind is that most code is fine.

When one company buys another the quality of the code is a calculation in the sales price. But it's a small one, and it takes a real dumpster fire to move that needle.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#83
post #55

Nothing makes working at a place more unbearable than having to deal with someone that gives an excessive amount of criticism on working code, at least that's how I feel. I've been in that situation before and it made me never want to submit pull requests. It made me even madder when other developers, whose code was no better than mine but had been at the company longer, received basically no critiques. Some might sa…

> excessive amount of criticism on working code Because it creates technical debt, that's why people get frustrated with shit code. They just aren't properly equipped how to convey/teach/train/fix it without coming across like an asshole.

> Because it creates technical debt

Does it ? Sometimes, the code reviewer has taken less time to analyze the problem and has not seen all problems a simpler solutions would bring.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#84

> If a guy brings me his code, and it has mistakes, it brings insane pleasure from how smart I feel [...] And if you tell me that you haven’t had this feeling ever, then you’re lying. Tell me about higher goals, training rookies and all that — I know you’re simply too full of themselves. And if you try to tell me that you learned to defeat that feeling (however it manifests in you), then I must be a pink unicorn. I r…

I have worked with people like the author. They suck. They destroy entire teams and often times the feedback is 99% pedantic personal preferences because why would they do something useful like setup the linter and propose the silly things they always nit pick.

These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different places I worked.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#85
post #8

I have been on several teams that found the following article "Unlearning toxic behaviours in a code review culture" very helpful: https://medium.com/@sandya.sankarram/unlearning-toxic-behavi...

I'd like to point out that every one of the "correct" examples is longer, sometimes much longer, that the "wrong" example preceding it.

I've found that I usually start with the "correct" way and end up regressing to the "wrong" way as more and more work piles up, stress builds and deadlines approach. I guess the "correct" way only works if the organization actually prioritizes it and gives reviewers the time to do it the "correct" way no matter what stage the project is in.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#86

Earlier quoted context omitted.

Not to be rude - but... have you asked for it?

I don’t think this is rude. I haven’t asked them. I should ask for more feedback. I haven’t asked because: I was a latecomer to the team and they had an established process Cultural differences between myself and them Honestly, I’m not sure all of them are experienced enough to give a useful critique

Code reviews can also have the opposite effect, I sometimes ask mentees of mine to review PRs of mine. Not necessarily to get their feedback, but to get their questions and to help transfer knowledge.

I used to do that when I started working on open-source as well, doing code-reviews to learn the code base (often I would not submit the review to not create noise)

Re: I ruin developers’ lives with my code reviews and I'm sorry

#87

This except there is no right way and there are 'n' equally good ways of solving any real world problem. It's only worth pointing out flaws if something is genuinely bad and I mean bad. Otherwise you are using a gut opinion to trash someone else's emotional health. Yay! you found an edge case that breaks a piece of code that will never get hit while the other million and 1 edge cases that haven't been found are still…

> there are 'n' equally good ways of solving any real world problem.

This is objectively, mathematically, incorrect. There are optimal solutions, and for some/many problems, there is one optimal solution.

Re: I ruin developers’ lives with my code reviews and I'm sorry

#88
post #25

Earlier quoted context omitted.

Maybe you just write incredible code the first time, every time? Can't discount the possibility!

IME, if the tests don't fail the first time you run the code, it says that the tests aren't actually hitting the new behavior. (Maaaaybe 1 in 100 times the code is actually right the first time.) Likewise, if there's no comments on a pull request, it hasn't been read...

I'd have agreed once, but at some point in my life I realized most of my code really was working right the first time, even messy javascript. Anyone else have this experience?

Re: I ruin developers’ lives with my code reviews and I'm sorry

#89
post #51

Maybe the tone doesn't translate but this guy sounds insanely egotistical. I feel truly bad for his family and anyone he works with.

It strongly reminded me of this graph of different cultural norms for phrasing criticism:

https://mobile.twitter.com/sebjilke/status/10364067943591731...

(I believe TFA is Russian, so read the Eastern European graph)

Re: I ruin developers’ lives with my code reviews and I'm sorry

#90
post #34

What would happen if all PRs were submitted/reviewed anonymously, and the feedback was just as impersonal as a stack trace?

As someone for whom face accountability is the only thing preventing me from eviscerating my peers, this sounds like a dream come true.
Post reply on HN