Live data from Hacker News

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

habr.com

151–160 of 199 posts

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

#151

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

Sometimes I’ll look over PRs early on, notice the entire approach is bad, and leave a comment.

People often got annoyed, they would say their PR isn’t ready yet.

That’s fair, I kind of understand, my intention was to just save them time going down an incorrect path though, because I know it’s going to be difficult to convince them later they need to rework days of work.

Not sure what the solution is.

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

#152
post #78

I speak Russian and used to read habr.com a lot, which is a Russian-speaking platform where the community members can post on topics related to software engineering, computers, and tech in general. (As you can notice, habr.com have also been trying to gain an English-speaking readers for some time now.) So I read or saw multiple articles in Russian from this specific author. Actually, the one linked in this post is a…

[flagged]

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

#153
post #10

Earlier quoted context omitted.

There are many ways to solve any problem. If I reviewed every PR with the standard "is this exactly how I would have done it", I too would be destroying every PR I review. And I'm not even that good at coding - I'm the type of generalist who cares about things like the business beyond the code base. What really matters is whether the code is solid and whether it will actually cause problems. Just because a PR isn't c…

> If I reviewed every PR with the standard "is this exactly how I would have done it", This, too many people think their way is the only way. It only takes one cancelled project or one company going bankrupt (and 100,000s loc going "poof") to understand this work we do, really doesn't matter all that much in the end.

It is a really humbling thought that every single one of our entire life's work as developers is one unfortunate astronomical event away from vanishing as though it never existed. Kind of puts it all into perspective really.

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

#154
post #115
post #84

Earlier quoted context omitted.

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…

I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to nev…

Your team is fairly typical, for at least a large subsection of the industry.

> But the devs, man. They just don't care.

Well, maybe. Or they just don't know how to write better code.

Either way, the bigger problem is the team management that allows this.

> I do my best to avoid rewriting wherever possible

Why not? If the other devs truly don't care, you could take it upon yourself to clean up the code base little by little when you can.

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

#155

There's something to be said for "Marine Drill Instructor" responses. When the DI is screaming profanities at recruits, [s]he is preemptively saving their lives. The manner in which it is done, is actually a component of the training. A significant part of military training, is to deprecate the individual, in favor of the team. The DI is not an individual. They are the sharp end of the elite organization that the rec…

When the DI is screaming profanities at recruits, [s]he is preemptively saving their lives. The manner in which it is done, is actually a component of the training.

This is true but it's not simply because it breaks down individual identity and makes the team more important than personal ego. If you can't stand unflinchingly in the face of yelling and cussing, you can't stand unflinchingly in the face of live fire and people trying to kill you.

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

#156
post #129

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

Yeah, I was afraid I'd see myself in this post, because I'm known for giving tough reviews. But I don't. I feel terrible whenever I give a tough review. I agonize about how to say the difficult things that need to be said but do it in a way that won't sting as much, and I know that often, it's going to sting anyway. I feel like I failed for not helping the other developer know how to do things better in the first pla…

One thing that I find that helps is, instead of saying that this thing is wrong, I just put in what would be right, and I do so with little commentary; usually `code block` -> `code block`.

Another thing that I think helps, at the CR stage, is asking after their thoughts for putting the thing together the way that they did. This DOES run into the potential problem of showing that they didn't put thought into it (or that part of it), but....

...there's a certain extent to which it's not your fault if they get to the CR and get a tough review. It's your organization's, "a month of work saves an hour of planning"-style. The developer who wrote the code getting the tough review wasn't set up to succeed, and IMHO that's more a comment on your org than any of the developers involved.

To bring it back around to your personal process, my (unsolicited, haha) advice is that if you're finding yourself giving a tough review, switch to a 1:1 review / pair programming session. Async text communication is hard and prone to miscommunication.

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

#157
post #55

Earlier quoted context omitted.

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

That is exactly why many harshly critique code. But I've never found their versions to be any less full of tech-debt. Usually it comes down to personal style. "Oh Brenda hates if/else, better convert it to ternary before I submit it. But Oh No! Bob is reviewing it instead! He hates ternary and always wants if/else! I'm doomed..."

This is why automatic code formatters such as Prettier -- are absolutely genius for teams. (It doesn't work for your particular example of ternary vs. if/else but the point still holds.)

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

#158
post #115
post #84

Earlier quoted context omitted.

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…

I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to nev…

You'll always run into that problem if you care. Most of the time this results in having a clique against you who'll make your life hard, for example with increased bureaucracy.

If the manager is on your side, it's possible but not fun.

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

#159
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)

Very interesting to see those cultural differences.

Hilariously, the first graph is titled "Objective distribution" (of criticism phrasing). That's not how language works...

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

#160
post #115

Earlier quoted context omitted.

I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to nev…

It’s possible there are things you are still learning, or context you are missing. You sound still early career enough that the years will likely mellow you out and teach you to better appreciate the ups and downs of building things fast. You know what’s worse than no abstractions? The wrong abstractions.

Not the OP but also a full stack at my five year career mark and your last point was an appreciated reminder.

I dread cleaning up solutions that I designed earlier where with hindsight, I made a lot of wrong assumptions. I still make wrong assumptions today, they are just designed less brittle.

Post reply on HN