Never again



2 mega PRs! They removed a lot of cruft and code debt, and created a huge amount of review debt. (The first one includes changes from its sub-PRs—the second PR above, and another small PR. Its own changed file count was ~140)

I could have split the second PR into three sub-PRs. But the old code was so deeply woven-in that each of those three sub-PRs would also have had 50-70 changed files. The choice was really between 4-5 large PRs with 50-70 files changed, or 2 massive PRs with 100+ changed files. I’m not sure I made the correct choice. I don’t know if there was a correct choice. Perhaps the correct choice was what was—just leave it be.

The relevant code was messy, it is now less messy. It’s still fairly noodley. I just hope this work made it easier to improve for the next person who has a go at it.

My lesson: never ever again do I want to create such massive PRs. Neither do I ever want to be at the other end of such massive PRs—reviewing them.

  • For a week of headache (doing the work), and another week of heartache (being frustrated with my work), I was rewarded with the only negative feedback on my probation review—should break up large work areas (like the two massive PRs).
  • Multiple times while they were in review, I wanted to close them and either create multiple sub-PRs, or just move the ticket back to the backlog. Going through my probation feedback, I still wish I’d done the latter—abandoned them and moved them back to the backlog. If the noodles have been tangled for years, they could have stayed tangled a few more.