Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests.
That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work.
When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due.
But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction.
To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.
> I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary.
As an engineer, I have rejected massive refactors in unrelated PRs: heck, I have rejected massive PRs period.
They always:
- are hard to review
- bundle a bunch of unrelated changes together
- hard to accept piecemal
- risky to test and deploy
- hard to revert
- hard to pivot according to new learnings along the way
- hard to improve
- have lots of review iterations
- slow down all the other work (conflicts, remerging effort for all the other changes in flight...)
- usually "one way doors" (relates to hard to revert)
When these are done as small incremental steps where we improve one thing at a time, none of the above hold, and coupled with a good CI/CD pipeline, take less time.
I know that many engineers believe there are things that can't be done incrementally like that, but I've always been able to give them a plan for any "impossible-to-split" refactor/rewrite.
That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work.
When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due.
But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction.
To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.