- 1 Post
- 4 Comments
I’m in the group being described here and the rustiness is real, but it isn’t the part that decides whether the code is any good. What I lost in the years of meetings was the current detail, which library does what this year and where the sharp edges are. What I didn’t lose was knowing what to ask for and being able to tell when an answer is wrong, which is what you’re doing most of when something else is typing. I’d be more worried about a leader who hasn’t reviewed a diff in five years than one who hasn’t written one.
nark3d@thelemmy.clubto
Programming@programming.dev•Stacked pull requests are now in public preview - GitHub Changelog
2·5 days agoThis looks useful for keeping a long change reviewable without leaving a branch open for a fortnight. Most of my pain with big PRs was never the size of the diff, it was that it had been diverging from main for two weeks before anyone opened it.
The discipline doesn’t go away though, it just moves. If the bottom of the stack sits unmerged you still have a long-lived branch, with everything else stacked on top of it.
The metaphor never quite works for me because debt is something you decide to take on, and most of what I’ve inherited nobody decided, it just piled up. What I do in practice is smaller than the metaphor suggests. I tidy the code I came in to touch and leave the rest for its own change, mostly because a refactor bundled into a feature branch makes the review harder and the bisect painful later. Agents have made that harder to stick to. Ask one to read a file and it’ll often come back having rewritten half of it. https://prickles.org/tenet/leave-it-better/P6
The workspace one holds up better. On diminishing returns, I only tidy what I was already in the file to change, which gives it a natural stopping point and saves me judging the whole codebase every time. Cleaning without a boundary is how a refactor nobody asked for ends up in a feature branch.