Have you ever worked on a brand new codebase with talented engineers, only to find out a year later that it turned into the same "archaeological strata of quick fixes" as your last legacy project? I know I have, and it happened many times.
My go-to blame target for this was usually micromanagement and imposed unrealistic deadlines. And I'm sure these play a significant role in it. But a recent conversation led me to understand another cause of this – untimely feedback. Or, to be precise, feedback that was requested or given too late.
I think many of us know the story. Someone starts working on a new capability. They spin off a feature branch and keep tinkering with it for a couple of days. Then they submit a PR. Thousands of lines, large diffs, the feeling of being overwhelmed and then the despair when you find a fundamental flaw in the design. The one that is not disqualifying, but one that would require a complete rewrite to do the thing correctly.
From there, there are two options. And neither of them is good.
First, you can point that out and request changes. This is also known as "being that person". Nobody wants to have this label. Plus it frequently results in a heated back-and-forth when the author desperately wants to avoid spending another week on a full rewrite.
The other option is to let that pass. You reluctantly approve the PR and the code lands in the trunk. You know it will cause trouble in the future and it inevitably does. The codebase got worse, the tech debt increased. But you don't want to be that person and don't want to have "the talk" with your manager about The Velocity.
You might think that this could have been avoided if the author asked for feedback first. But why didn't they? Is it because they like to work this fait accompli way? Most likely not. In fact, maybe they did ask for early feedback but nobody provided it.
This also happens a lot. Someone writes a high-level description of a solution and... no one bothers. It would require taking this description and translating it yourself into something more tangible. That's the way to spot a problem from a high-level description. It constitutes an effort, often much bigger than just glossing over a ready-to-review solution. This creates a cycle that is hard to break:
- People don't ask for early feedback, because they don't think they'll receive it
- Late feedback is not given, because it's too late
- Code with design flaws gets merged, not because of someone's bad faith or inability to write a good one, but because two pairs of eyes are usually better than one
My takeaway from that is to ask for early feedback more often. Even if I don't believe in receiving it, just creating a possibility of it might pay off in the future. And to try to push myself to give early feedback whenever it's viable, even if I don't feel like making this mental effort. As a side benefit, this would also make the development process more collaboration-based than sign-off-based, which is definitely a win.
Top comments (6)
collaboration-based Is for sure a win
I agree about the timing of feedback. When PRs grow to thousands of lines, it's tough for reviewers and design flaws get missed. Breaking changes into smaller, incremental PRs might help. The fear of being "that person" is real, but sometimes it's worth the awkward moment to be candid. On the coding side, if you're getting ready for technical rounds, PracHub's question banks have been solid for me, especially for those tricky follow-up questions that can catch you off guard.
IME a big problem here is that it's not just between two developers. I'm trying to be always open to feedback, even if it means I have to redo something from scratch. But historically, sometimes a manager barges in, saying that if it works, we ship and no more working on that. By "being that person" you sometimes risk accusation of slowing the company down, which can have consequences.
What I like about this early feeback idea is that it eliminates that risk to a certain extent too. Maybe I should underline it more in the post itself.
Indeed. That's why, when the uncertainty is high, I will submit a merge request telling the colleagues I am 30% done, not 90% done
Thanks for sharing, Paweł, I think most of us feel similarly to you. PR is definitely too late to give design feedback.
I think this is the problem right there - designing should occur before code writing.
The solution is early(er) alignment.
This can be as simple as a meeting where assigned lead (only, haha?) dev brain-dumps their thinking how the problem will be tackled, giving early possibility of someone suggesting better ideas. Or as complex as a thorough design diagram, ERDs etc. Alignment will come naturally in teams where devs have worked together for some months and know each other's style and capabilities. No need to design yet-another-CRUD feature. But where something unusual is requested, spend some time thinking about a solution, challenges, and present your thinking to the team.
Thanks for the comment. You are right that there are multiple ways to solve the issue.
My experience is that nobody listens on such meetings. People nod, while actually doing their job in the meantime (talking about full remote setup here). Then they "wake up" during the final review, that this is fundamentally flawed. Of course, it helps a bit in a sense that "you had your chance to speak up" and the conflict does not arise. On the other hand, you probably ship worse version of the software in the end.
Incidentally, the discussion was sparked because someone posted very long and detailed document about an issue. There were two problems with that:
Surely you are right that it becomes easier to find a perfect time and means to more experienced teams.