Live data from Hacker News

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

habr.com

101–110 of 199 posts

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

#101

Earlier quoted context omitted.

The sweet spot is somewhere in the middle. Too laissez-faire and you end up with a ball of mud.

Super critical code review culture can also end up with balls of mud. The two are not exclusive. Example is a team I was on that would critique the hell out of syntax and grammar in javadocs, formatting of annotations arguments, stuff like that, fine. But never look outside the source file for how any of it fit together. No design planning cause "code reviews". End result was tons of duplicated code everywhere.

I've submitted code that was reviewed like that, and it was super frustrating. Stuff like, "your javadoc uses invalid markup", when submitting code to a project that has almost zero javadoc to begin with.

I mean, sure it doesn't render well as HTML, but its readable with the code and the rest of the project has none so...

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

#102
sounds like the folks that quit didn't have their lives ruined by his attitude and outlook, rather they had their lives improved by being allowed to move away from such toxicity.

ego is one heck of a thing. this guy sounds terribly painful to work with.

i also agree with another commenter, if tearing people down gives you pleasure, you might be wise to seek counseling.

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

#103

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…

I got annoyed by people leaving "philosophical" or "style" type comments in code reviews - i.e. nothing related to functionality or performance but just different ideas about how things could be written without obvious advantages. Then I realized I could just write something like "Thanks for the feedback. I've addressed the points that I feel are critical, the remaining comments can be addressed in future if necessar…

While I think you're taking the right approach for getting the work done, maybe the comments aren't entirely worthless? In some cases, those are the best comments I've gotten when having someone review my code, even if I didn't make a change because of them. They're something for me to think about and either incorporate or not in some way in later work.

In other words, I think it's correct to not consider every comment to require a change unless it really needs it, but that doesn't mean a comment that doesn't require a change for the current work should necessarily be ignored because of that.

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

#105
This is why I now use tools like SonarQube (commercial static code analyzer) to drive most code quality reviews. SonarQube also gives justifications for all of it's recommendations, so it serves as a training tool as well.

The only I things I manually look for in reviews are overall readability, sensible naming, high level adherence to the architecture/design, and data system/database/API queries.

After 20 years of writing code and leading teams, I've found that most of the stuff developer blogs and the OOP community fret over simply doesn't matter in most cases. The high level interfaces are often more important than the low levels details, and static code analyzers do a decent job of pointing to problems. I've almost never seen bad code that didn't also have many issues in the static analyzer.

It also matters what kind of code you are writing - foundation code or something that will be used by thousands/millions of developers should have a higher bar than some internal one off. However, I've seen enough very profitable companies running on total crap code to believe that code quality is the most important thing.

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

#106

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…

IMO the absolute worst is excessive criticism while missing a serious business logic or functionality bug. In my opinion the first priority of code review should be to prevent mistakes in the code at hand

> In my opinion the first priority of code review should be to prevent mistakes in the code at hand

I disagree. The first priority of code review is WHAT problem is it trying to solve and does it actually solve the problem.

If it's not even solving the problem correctly, pedantic nitpicks are inconsequential.

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

#107

There are a few types of comments on code review that I see: 1. Critical mistakes 2. Style guide mistakes 3. Non-optimal design (in your opinion) #1 Always receives a comment, obviously. #2 Always receives a comment, but we have good automation here so it's not too much of a worry. #3 Is where it gets interesting. A lot of the time, commenting about this category is prematurely optimizing and it's a waste of time for…

[deleted]

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

#108

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

>Stop being an asshole, and find non-assholes to work with. I think the process of realizing he needs to do that and doing it is what he's describing in his article. Generally people don't open up about how their behavior is toxic unless they recognize it as a problem. And, though my experience with Russian culture is limited, I understand that competitiveness and criticism is the rule, at least in the STEM fields th…

We are all products of our environment/the past. Things change when someone says "I don't like what I've become and I don't want to be this way anymore."

Those folks often get undue criticism, especially if they choose to speak up in hopes of fostering positive change in others.

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

#110

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

Same, I've never felt anything like this. I find code review tedious and the only thing I really care about is if their code is properly tested or not.
Post reply on HN