How to run a miserable code review
badsoftwareadvice.substack.com
How to run a miserable code review
1–10 of 122 posts
Re: How to run a miserable code review
#2So many missed opportunities for a small business.
A code review should never be done in person; instead all communication should happen asynchronously through passive aggressive messages left in GitHub. If you're on bi-weekly sprints, the review should be left to age for a minimum of 5 business days before any feedback is provided. Never write resolvable comments, but rather leave ambiguous musings of how a block of code could be cleaner. Assign the review to multiple engineers but never make it a formal part of their responsibilities. On special occasions, unpredictably merge a review with no feedback, or do so simply based on your mood. Loosely, and unpredictably, enforce documentation requirements. Most important: never update your product managers on merged features, so that they can experience the joy of discovery just like your customers!
Re: How to run a miserable code review
#3There is a good article approaching it from the other side here: https://mtlynch.io/code-review-love/ - I am not the author, but it's one of the few things I have bookmarked.
Re: How to run a miserable code review
#4I once worked at a place where about 5 of 15 developers sat on crucible all day fellating each other on code reviews. Anytime the rest of the developers would have code reviewed they'd be met with a long list of required changes that where "standards" the 5 had agreed on, and never communicated out side of their own comments in the tool. And the "standards" changed often, and the changes where never communicated either. Besides being a toxic culture, it was a real drag on development velocity to say the least.
Code review culture is so important, and so often completely disfunctional. I've quit jobs because of toxic code review cultures like above, and one of the main things keeping me at my current job is sane code review culture we have.
Re: How to run a miserable code review
#5So many missed opportunities for a small business. A code review should never be done in person; instead all communication should happen asynchronously through passive aggressive messages left in GitHub. If you're on bi-weekly sprints, the review should be left to age for a minimum of 5 business days before any feedback is provided. Never write resolvable comments, but rather leave ambiguous musings of how a block of…
Bonus if the vague comments relate to some refactoring that you'd like to do, the details of which exist only in your head. Meanwhile, yes, you know the existing code is like X, and has been like that for years, but obviously I shouldn't have followed it and it's all wrong. For details on how I'd like it to be, please read your mind.
Add an ellipsis to really drive home that only will any more explanations not be forthcoming but it should be evident that this is my problem...
Re: How to run a miserable code review
#6So many missed opportunities for a small business. A code review should never be done in person; instead all communication should happen asynchronously through passive aggressive messages left in GitHub. If you're on bi-weekly sprints, the review should be left to age for a minimum of 5 business days before any feedback is provided. Never write resolvable comments, but rather leave ambiguous musings of how a block of…
Do you work at the same place I do?
Re: How to run a miserable code review
#7Triggered. Missing from this is the experience where the reviewer rejects for something trivial, then you fix the issue in 1 minute, resubmit, and finally have to wait 24 hours for them to check their code review requests again.
Re: How to run a miserable code review
#8[deleted]
Re: How to run a miserable code review
#9Flag the code and unit tests for multiple petty issues and then forget to review your change requests. Eventually accept them weeks later without comment after multiple prompts from the developer.
Re: How to run a miserable code review
#10I once worked at a place where about 5 of 15 developers sat on crucible all day fellating each other on code reviews. Anytime the rest of the developers would have code reviewed they'd be met with a long list of required changes that where "standards" the 5 had agreed on, and never communicated out side of their own comments in the tool. And the "standards" changed often, and the changes where never communicated eith…
It's a good way to game performance reviews.