How to deal with conflict and uncertainty about quality of requests in Code reviews?
Context: Working in a small startup where there are a very small number of wiser senior engineers
Everyone in the development team contributes to code reviews
Often I’m unsure about the quality of the feedback and when to act upon it
Sometimes people even change their mind after you have acted on that feedback which is frustrating and can contribute to the delay of finishing a task
Does this also happen in big tech? How do you handle these situations ?
Discussion
(3 comments)- 3a year agoMeta, Pinterest, Kosei
Depends on the size of the change and how disruptive it is to flip flop.
In general, no, this doesn't happen in Big Tech -- by the time you get to the coding stage, there should already be rough agreement on what to code.
If the decision changes, do a quick retrospective (either on your own or with the code reviewer) about why the decision changed. What new information did you get, and what could have been done to get that info earlier?
- 3a year agoMeta, Pinterest, Kosei
Sharing the masterclass which also covers code review: https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/how-to-write-better-code-faster-as-a-software-engineer-11192022/
- 4
a year agoIntuitI think what would work here is to have smaller prs which means less peer review comments but for places where that might not be feasible the first thing is to do is to have detailed pr review descriptions and second for people who are prone to changing their minds establish a quick sync before starting implementing their feedback.
That way you can learn from them but not have to worry about them changing minds later on.
