> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing
I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”
Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.
I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”
And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.
I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”
I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”
This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.
I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
> I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”
Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.
I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”
And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.
I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”
I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”
This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.
I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.