Ryan Alban
@dreamofpsy.bsky.social
gamedev, tabletop/video games, sailing, miniatures, long walks on the beach
Or you might not ship at all, or all your good programmers quit at the end of the project (or earlier!), or... any number of other pathologies that having an unmaintainable codebase and not prioritizing the programmer's experience can cause
November 21, 2025 at 3:05 PM
Or you might not ship at all, or all your good programmers quit at the end of the project (or earlier!), or... any number of other pathologies that having an unmaintainable codebase and not prioritizing the programmer's experience can cause
This can also happen if the CEO is a particular kind of Agile purist...
November 21, 2025 at 12:06 AM
This can also happen if the CEO is a particular kind of Agile purist...
I've also worked on teams where you couldn't submit *anything* unless it was associated with a bug or feature ticket. Submitting the bugfix individually would mean opening a bug, waiting for production to approve it, THEN "starting work" by opening a review, etc. Shelving was not the slowdown there.
November 20, 2025 at 11:29 PM
I've also worked on teams where you couldn't submit *anything* unless it was associated with a bug or feature ticket. Submitting the bugfix individually would mean opening a bug, waiting for production to approve it, THEN "starting work" by opening a review, etc. Shelving was not the slowdown there.
I recently had a case where I had a "10% fix" that was in fact a 0% fix (crash happened in the past, but mysteriously stopped until something I did made it happen again). It was a change that had seemingly zero need to happen until my new feature came about, so I put them together.
November 20, 2025 at 11:28 PM
I recently had a case where I had a "10% fix" that was in fact a 0% fix (crash happened in the past, but mysteriously stopped until something I did made it happen again). It was a change that had seemingly zero need to happen until my new feature came about, so I put them together.
Something else I want to note: as someone who *has* in fact included bug fixes with feature work or refactoring in the past, my reasoning for doing so had absolutely nothing to do with workflow friction coming from whether I used shelves or feature branches. More to do with friction in other places.
November 20, 2025 at 11:25 PM
Something else I want to note: as someone who *has* in fact included bug fixes with feature work or refactoring in the past, my reasoning for doing so had absolutely nothing to do with workflow friction coming from whether I used shelves or feature branches. More to do with friction in other places.
Some experience. That + IC experience on AAA teams has taught me to expect that someone undisciplined enough to interpret workflow friction as "damage" and disregard process will do that regardless of how frictionless that process is.
November 20, 2025 at 11:08 PM
Some experience. That + IC experience on AAA teams has taught me to expect that someone undisciplined enough to interpret workflow friction as "damage" and disregard process will do that regardless of how frictionless that process is.
Not to mention, it means that I re-review the lines I'm including in the fix, and have opportunities to spot cases where a change is appropriate for the fix individually, but actually needs to be slightly different in the feature work. IME, I feel more in control of the process than I do rebasing.
November 20, 2025 at 10:55 PM
Not to mention, it means that I re-review the lines I'm including in the fix, and have opportunities to spot cases where a change is appropriate for the fix individually, but actually needs to be slightly different in the feature work. IME, I feel more in control of the process than I do rebasing.
Shelve fix, unshelve feature, diff feature against shelved fix, press a couple of buttons to "merge" the change up in the diff tool. Usually takes me <10 seconds, which IS more than I assume it would with git, but is still very much in the noise with all the other potential time sinks I deal with.
November 20, 2025 at 10:54 PM
Shelve fix, unshelve feature, diff feature against shelved fix, press a couple of buttons to "merge" the change up in the diff tool. Usually takes me <10 seconds, which IS more than I assume it would with git, but is still very much in the noise with all the other potential time sinks I deal with.
The individual fix lives in a shelf, while also being present in the feature work. As long as I submit things in the right order, the vast majority of the time I've found that P4 can merge things cleanly enough that the "unshelve, submit, unshelve, merge" flow takes under a minute for me.
November 20, 2025 at 10:50 PM
The individual fix lives in a shelf, while also being present in the feature work. As long as I submit things in the right order, the vast majority of the time I've found that P4 can merge things cleanly enough that the "unshelve, submit, unshelve, merge" flow takes under a minute for me.
But... I don't actually WANT to do that most of the time, because quite often I'd want to test the fix individually on my own machine before I even put it to review, just to be certain that I actually did get the entire fix and it doesn't break something else.
November 20, 2025 at 10:44 PM
But... I don't actually WANT to do that most of the time, because quite often I'd want to test the fix individually on my own machine before I even put it to review, just to be certain that I actually did get the entire fix and it doesn't break something else.
But... that sounds pretty similar to the workflow I described, though? IME it takes less than a minute to move some files into a CL, press the shelve button, then maybe like a minute at most given the size of most of my CLs to do the diff part.
November 20, 2025 at 10:44 PM
But... that sounds pretty similar to the workflow I described, though? IME it takes less than a minute to move some files into a CL, press the shelve button, then maybe like a minute at most given the size of most of my CLs to do the diff part.
"An hour or two of busy work" seems incongruous with my experience doing this kind of thing. What have you seen take that long?
November 20, 2025 at 10:42 PM
"An hour or two of busy work" seems incongruous with my experience doing this kind of thing. What have you seen take that long?
What does the git-based workflow for this that saves significant time over what I described look like?
November 20, 2025 at 10:31 PM
What does the git-based workflow for this that saves significant time over what I described look like?
And I've seen plenty of people do the wrong thing in git-based projects, too. If someone doesn't have the discipline to separate bugfixes and features and refactorings with one VCS, I would be pretty surprised if a small workflow improvements got them doing things properly.
November 20, 2025 at 10:30 PM
And I've seen plenty of people do the wrong thing in git-based projects, too. If someone doesn't have the discipline to separate bugfixes and features and refactorings with one VCS, I would be pretty surprised if a small workflow improvements got them doing things properly.
I don't follow how using git would solve those things. You still need to split the change off somehow and I wouldn't feel comfortable merging it unless I tested it individually, so the new feature work would still have to be stashed and unstashed and merged with the fix somehow, wouldn't it?
November 20, 2025 at 10:16 PM
I don't follow how using git would solve those things. You still need to split the change off somehow and I wouldn't feel comfortable merging it unless I tested it individually, so the new feature work would still have to be stashed and unstashed and merged with the fix somehow, wouldn't it?
If I get feedback that I need to address on the 10% fix, it's similar to the pre-submit flow. Shelve new feature, unshelve 10% fix, apply feedback, send to CR/CI, shelve fix again, unshelve new feature, use p4diff to merge updated fixes into the new CL. Again, not time-consuming enough to bother me.
November 20, 2025 at 10:08 PM
If I get feedback that I need to address on the 10% fix, it's similar to the pre-submit flow. Shelve new feature, unshelve 10% fix, apply feedback, send to CR/CI, shelve fix again, unshelve new feature, use p4diff to merge updated fixes into the new CL. Again, not time-consuming enough to bother me.
Unshelve new feature, back to working on that. When the 10% fix is ready to submit, shelve new feature, unshelve fix, submit, unshelve new feature, sync just the fix's file, merge, and I'm back at work on just the new feature. I'm sure git is faster but I don't find this onerous enough to switch.
November 20, 2025 at 10:07 PM
Unshelve new feature, back to working on that. When the 10% fix is ready to submit, shelve new feature, unshelve fix, submit, unshelve new feature, sync just the fix's file, merge, and I'm back at work on just the new feature. I'm sure git is faster but I don't find this onerous enough to switch.
I use pretty much the workflow you outlined earlier. Shelve current work, check out just that file, use p4diff to diff my shelved (new feature) file, "merge" just the 10% fix lines over to my checked out file, put that file in its own changelist, shelve the file and send it to code review and CI.
November 20, 2025 at 10:04 PM
I use pretty much the workflow you outlined earlier. Shelve current work, check out just that file, use p4diff to diff my shelved (new feature) file, "merge" just the 10% fix lines over to my checked out file, put that file in its own changelist, shelve the file and send it to code review and CI.
Or rather, never seen it done in a way that I thought solved more problems than it created. The potential for code and content getting out of sync seems even higher than in regular P4 usage, and it's already a thing there.
November 20, 2025 at 9:50 PM
Or rather, never seen it done in a way that I thought solved more problems than it created. The potential for code and content getting out of sync seems even higher than in regular P4 usage, and it's already a thing there.
And it just so happens that the new feature touches the file where the 10% fix needs to happen? I run into that case quite often
November 20, 2025 at 9:49 PM
And it just so happens that the new feature touches the file where the 10% fix needs to happen? I run into that case quite often
IME, there's no such thing as "a one time cost..." But if you say people make it work, I believe you. I've just never seen it done.
November 20, 2025 at 9:47 PM
IME, there's no such thing as "a one time cost..." But if you say people make it work, I believe you. I've just never seen it done.
I'm not sure I follow. You're talking about a case where there's an existing (different) feature with a bug that crashes 10% of the time, that I have to fix before checking in my new feature because the new feature makes it crash 100% of the time instead?
November 20, 2025 at 9:43 PM
I'm not sure I follow. You're talking about a case where there's an existing (different) feature with a bug that crashes 10% of the time, that I have to fix before checking in my new feature because the new feature makes it crash 100% of the time instead?
I'm just speaking from my own experience here that they were a net time saver. Maybe it helps that we didn't use them as "feature branches" per se but locked down "release branches," so there wasn't much divergence from the trunk branch?
November 20, 2025 at 9:41 PM
I'm just speaking from my own experience here that they were a net time saver. Maybe it helps that we didn't use them as "feature branches" per se but locked down "release branches," so there wasn't much divergence from the trunk branch?
I don't remember how much time they lost making it work and maintaining it, but I'd bet they spent more time on that tooling than the rest of us - who just adapted our workflows to play nice with the tools we actually had, rather than the ones we wish we had - lost to *not* having the tooling.
November 20, 2025 at 9:39 PM
I don't remember how much time they lost making it work and maintaining it, but I'd bet they spent more time on that tooling than the rest of us - who just adapted our workflows to play nice with the tools we actually had, rather than the ones we wish we had - lost to *not* having the tooling.
A few programmers I've worked with were so pro-git that they wrote their own tooling to let them use git while working on something and then submit their final commit as a P4 changelist. I was pretty skeptical of that, too.
November 20, 2025 at 9:38 PM
A few programmers I've worked with were so pro-git that they wrote their own tooling to let them use git while working on something and then submit their final commit as a P4 changelist. I was pretty skeptical of that, too.