The one thing that always really terrified me was the idea of other people reviewing my code. I'd done lots front-end development work in the past,...
For further actions, you may consider blocking this person and/or reporting abuse
Fantastic post! You might be one of the only other devs who just gets the reference I am making by calling my latest project Readymade ;) readymade-ui.github.io
I honestly wish more people with art degrees would convert to comp sci.
I agree with all of the above. I would only add that sometimes it is ok to add a comment to a PR and still allow the code to be merged (and, with it, allow folks to learn by delivering).
I don't know about you guys, but when I know managers are breathing at the poor dev's neck, it is hard for me to stop a PR because of something like using a slightly less optimal method. I just leave a comment so the dev can apply it in future PRs.
Could you share an example line or snippet that your co-worker who leaves the comments about the indentation gives the 👍🏻on?
I'm known as the most thorough and strict code reviewer here and while I want to for sure start adding more compliments or calling out good things I have a tough time not just kind of assuming, "If I didn't comment on it, it's good." and leaving it at that.
I agree the shit sandwich is insincere and so I don't like doing it but I still would like to add more positivity. I realize that its proprietary code even if its just a snippet so if you can't share I understand.
Very nice article though! Thanks for sharing!
Yeah, I can't share actual lines of code, but I can give some examples. A lot of times the 👍🏻 is for refactoring, where the new code is a significant improvement over what was there before. Writing good tests often gets a 👍🏻, since we've all been working on that as a team. We've also been building our UI component library, so when we have the opportunity to include or create a new component, that gets a 👍🏻. Ditto re: adding useful comments on complex code.
Personally, if I see anything that makes me think "that was a good way to tackle that" or "glad we finally have that sorted out," I try to say as much to the person who coded it.
In a more general way, we also have a #shoutouts channel in Slack, where we are encouraged to call out someone who's had a "win" recently – not limited to code they've written, but for any work they've done. if you're feel like PRs aren't a natural place for you to add positivity, something like that may be a good way to accomplish something similar.
Great post! I am always the reviewed one and I agree with everything you said.
And I want to add up that the process of opening a PR requires attention as well, making a good description of what you've done (not only the code, but the reason behind it) makes it a lot easier for the reviewer to understand the context and to avoid a few questions like "Why did you choose blue" (not sure if it is the best example here, but I hope you understand what I mean).
That's a really good point – just throwing code out into the ether and going "okay, now review it" puts all the work on the reviewer. If you can provide those guiding comments, you're a lot more likely to get your code approved quickly haha
Great article, it really highlights the things people tend to overlook. I for one, thought shit-sandwiching was a good idea.
It's not the WORST thing you can do (it's definitely better than just being negative 100% of the time), but once you realize someone is doing it to you, you start to question whether the compliments are "real" or just something they said because they knew they had to find something to put on either side of the shit. Personally, I think it's better to just compliment and critique genuinely vs. feeling like you're obligated to make X compliments for every Y critiques.