Live data from Hacker News

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

habr.com

31–40 of 199 posts

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

#31
> 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 really can't relate at all. I feel the opposite. I often feel angry (I realize this is not a GOOD response either!) and always feel sad. I don't want to have to do more work. I don't want a reminder that my previous feedback didn't click with them.

I'm constantly looking for ways to do less tedious work, through automation and such, and code review for bad code is the worst sort of tedious work. I want to learn things, but code reviewing bad code doesn't teach me anything - I want to work with people who can teach me things when they review my code just as often as the reverse.

My takeaway from that has been to try to intercept people earlier in the planning and designing and start-of-coding process. If a bunch of bad code gets to code review, someone failed at explaining what this thing needed to do and how it should be done beforehand. The article claims this is always just itself a confrontational form of argument, but... it doesn't have to be. Stop being an asshole, and find non-assholes to work with.

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

#32
post #25

Earlier quoted context omitted.

Strange, I’m on a team rn with people who just approve everything. I’m craving some constructive feedback.

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

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

#33

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…

Conversely, nothing makes working at a place more unbearable for me than working with people that over-engineer everything. These are the types of PRs that tend to get the most feedback, and also the type of person that complains most when receiving this feedback.

* in my experience, of course.

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

#35

Earlier quoted context omitted.

Strange, I’m on a team rn with people who just approve everything. I’m craving some constructive feedback.

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

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

#36
If you want some empathy with the guy whose code you are reviewing, go pull up some of your own code from a few months or a year ago. Do a mock code review on it.

Maybe everyone else only writes good code, but this works for me every time. Even after over 30 years coding, I still have no problem seeing how imperfect the code is that I wrote as recently as last year.

And don't ever make it personal, anyway. Adopt a neutral tone, phrase comments abstractly as how they relate to team goals, how the code might be made clearer, etc. Don't accuse, don't belittle, don't try to look smarter than you are. And try to recognize the difference between the stuff that actually matters, the things which will actually be a headache down the road, and the pointless details that are just not how you'd have chosen to code something.

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

#37
Having an auto-formatter like Prettier or `go fmt` has been a huge boon and productivity gain for the teams that I've worked with. No longer having code nitpicks on formatting has saved so much time going through reviews, and it really increases the signal to noise ratio on pull request comments too.

Would definitely recommend those for any teams that have a similar teammate as the article author on their team.

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

#38

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

My reaction to this was that this guy should not be making code reviews ever.

That emotional reaction in combination with conviction everyone has the same one disqualify him.

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

#39
post #25

Earlier quoted context omitted.

Strange, I’m on a team rn with people who just approve everything. I’m craving some constructive feedback.

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

I don’t think this is me, haha

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

#40
Ouch. I’ve had a few cases of developers on the verge of being fired because of bad code causing friction with the team.

Code reviews never help in those cases. There is always an underlying cause: the developer is trying to rush to prove something, or maybe over-engineering for the same reason. Maybe he has some issues at home, or isn’t sleeping well. Maybe it’s just lack of experience. Maybe it is a personality issue and the developer is trying to save face by sticking to his guns.

Either way, I find that it is much better to have private discussions with the developer to increase the code quality via mentoring, or pairing. It helps removing the defensiveness, doesn’t make them feel publicly humiliated and doesn’t spend the time of the team with the review-fix cycle.

Post reply on HN