> And if you tell me that you haven’t had this feeling ever, then you’re lying.
I haven't. I love it when I see a great PR that I can just stamp "Approved" on.
The last thing I want to do is close something as so bad it's unsalvageable.
I ruin developers’ lives with my code reviews and I'm sorry
131–140 of 199 posts
Re: I ruin developers’ lives with my code reviews and I'm sorry
#132In my opinion, when doing a code review over a weaker developer, as the stronger developer you should show your strength by making commits to help them improve their pull request, instead of passing back-and-forth a bunch of passive-aggressive comments. If you are reviewing someones work and you go back and forth more than a couple times, you should step in and pro-actively help resolve. Together as a team you draw t…
Definitely not; but, I would recommend, in the comment, to share alternative code and sample usage that they can take advantage of and apply themselves to their own code.
If you overwrite all their code, what have they learned?
Re: I ruin developers’ lives with my code reviews and I'm sorry
#133I 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…
The article is actually really useful; it’s a good example of how to not think of code reviews. If you relate to any of the text except for the last three lines, it means you’re reflecting on and running code reviews wrong.
A code review is an opportunity for the reviewer to learn about someone else’s coding style and improve it when necessary, and the reviewee to learn their flaws and just how other people see their code. Because everyone has their own viewpoint with their own flaws. Not an opportunity for the code reviewer to show that he’s smarter, or the reviewee to be “humiliated” that his code isn’t perfect.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#134Earlier quoted context omitted.
Strange, I’m on a team rn with people who just approve everything. I’m craving some constructive feedback.
I think part of the problem with the bullying described in the article and the "approve everything" approach starts with the framing of code reviews. Instead of "please write this code, submit a pull request, and I'll tell you what you did wrong," I have recently been saying to new coders "take a shot at this problem, and when you've got something working let's get together and refine it, there is some context it wil…
Hm, we've discussed doing more smaller concept reviews. Doing "first try" reviews sounds like a good alternative.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#135Earlier 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..."
If code reviews are centered around style the entire org is fucked.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#136Nothing 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…
Strange, I’m on a team rn with people who just approve everything. I’m craving some constructive feedback.
I think the issue is when a code review is “do this”. Especially when it’s small things like formatting, and I have to wait a day for the PR to be approved (or they catch another formatting issue).
It’s better when code reviews are suggestions, the reviewer doesn’t nitpick (or at least fixes that stuff themselves), and small things like formatting are enforced by a linter.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#137Buddy, don’t blame the yhe industry for your argumentative nature. Blame your dad. And unless the company pays you for every line of code you comment, you’re better off spending more time with your kid.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#138> 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…
How do you typically screen for such personality characteristics? I'm curious since my current role involves interviewing a lot of engineers. I too have noticed similar traits in others in the past and I shamefully admit that I myself was pedantic about silly semantics and syntax in code reviews. Sometimes criticism of someone's code was warranted, and sometimes it wasn't and it was just me being picky (I like clean, readable code).
Re: I ruin developers’ lives with my code reviews and I'm sorry
#139Earlier quoted context omitted.
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?
Depends on the language. Strongly typed languages like Rust and F#, even Typescript to some degree, yes. Most of the time if it compiles it works.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#140There 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…
With number 3 I usually leave a comment but it's something along the lines of "Why did you decide to do x instead of y. I think y would be better because..."
I don't necessarily want or expect them to change their code but I want to make sure they're considering multiple options and intentionally choosing that path instead of just copy and pasting something from stack overflow (as an example.)