4 ms·
When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in
by silveroriole 8y ago
When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in X scenario? Maybe we should refactor this part out into a stateless microservice?” That avoids the resentment and makes you look less like a control freak, but still shows your competency/foresight. If they choose not to take your advice, too bad for them, but I try to make sure they end up personally fixing the inevitable problems and hopefully learning from it.
Other than that I haven’t found any great solution, but I have found it stressful and counter-productive to try and do EVERYONE’S thinking for them. They do not learn in that case, they just continue to outsource their thinking to you.
e: also 10+ rounds is excessive for a peer review imo, after 2 or 3 I’d be having a higher level design chat with their lead/manager.
- jeffrallen 8y agoOther useful phrases: "Here, I was expecting to see...", "This code made me look at this other code and they cannot both be correct...", and "It took me a while to see why this is correct. We could save the next reader time by..." Excellent code reviews take time and attention, which is why you need auto code formatting and $lang proverbs to take the uncontroversial stuff off the table early. Then you still have brain power left to give value from the review. Also: work hard to earn a reputation as a fair but tough reviewer. Then when you need to be a prick, people will know it's important and let their ego down.