Question 4
PR feedback: non-isolated side effects
A junior engineer comes to you saying a senior engineer won’t approve their PR because it has too many non-isolated side effects. How do you handle the situation?
Answer outline
This is both a technical problem and a communication problem — address both sides.
Review the PR yourself first and decide whether the concern is valid. If it is, work with the junior to make the feedback concrete and educational, not just a block. Non-isolated side effects usually means: functions mutating shared state unexpectedly, hidden dependencies (singletons, globals), or business logic entangled with I/O.
If the feedback is vague or overly strict, coach the senior too — good feedback names the specific issue and separates must-fix from style preferences.
Use the moment to reinforce team standards: document what nicely decoupled code looks like in your codebase so the same disagreement does not recur.
Principles
- Translate vague feedback into concrete, actionable guidance.
- Coach both sides — the junior needs direction, the senior needs to communicate better.
- Optimize for learning, not just unblocking.
- Align on shared standards so the same disagreement does not keep recurring.