I hope you understand where I'm coming from. Big patches take a lot of time and effort to review. There's a lot more that can go wrong in the review process. And if the patch gets rejected, you've wasted a ton of effort with nothing to show for it.
I definitely understand how and why it helps, but I have issue with this practice for both personal, social and specific-to-this-situation/project - related issues.
(I'm listing them in order to either get help solving them, or to get leniency in understanding my struggles to apply this method)
Global -
It's possible to notice an issue only once you're well underway of something else. What do you do once you notice it? If the issue stops you from continuing what you're doing, you can't just ignore it? But do you just discard what you did? Also, is the issue even
fixable in the code's current state? (said like this, it just comes out as an organization problem, but it comes into play further ahead)
Personal -
I have this blessing/curse called hyperfocus. This leads to two things.
1- When I notice an issue, my attention may shift over that issue. That probability increases with the issue's prevalence (e.g. is it stopping you dead in your tracks? Does it just need some temporary workaround?).
This is made worst by the fact that my brain doesn't have any kind of "filter". Common people can ignore/filter out the voice of other people, or noise, when trying to focus (up to a certain point, of course). I can't. No matter what I do, if I hear something, my brain will (attempt to, "spent resources to") process what that is, no matter how debilitating to my current situation this is. It's the same thing with thoughts. If this issue pops up often/has a wide repercussion, I can't just "ignore" it.
2- I can't select what I hyperfocus on, and it's pretty much always on "something". This means that if I lay something down, there's little to no chance of me coming back to it, because I'll be focused on something else, and would need to be focused on something "related"/"close" to it to give my hyperfocus a chance to latch back on that thing.
This exacerbates the "Global" problem mentioned above. If I just discard my current work to temporarily work on the issue, I just won't be interested in the original work anymore...
If I wait to fix the issue until I finished the originally planned work, I'll have forgotten about the issue...
Project-related - KoLmafia.us and submitting patches
Multiple issues come to mind.
1- Some mafia developers have openly admitted to having a "If it ain't broke, don't fix it" mentality. What do you do if one of the "smaller changes" you could submit on its own doesn't actually have any negative impact in the code's current state, but becomes a problem in what you're trying to do?
Splitting big changes into smaller ones (plural) is a good idea in general, but in those cases, what do you do if you can't make the case for each of these smaller changes, individually? Especially if you submit them *before* the big change that relies upon this/these smaller change(s) is finished, so you can't immediately show how the fix is helping?
2- continuing the previous entry, in a way; submitting a patch means waiting for it to be approved or rejected (or asked for something to be changed, questions, etc.) (and with timezones, that can means things going as slow as 1 post per day). What do you do meanwhile? I can't just "wait", without touching the rest of the project, I'll lose hyperfocus! What do I do if the individual fix is rejected? What if there's no answer? Do I just continue the bigger project that relies on it anyway?
Project-related - using Git (more like a nitpick than an actual obstacle to using this method)
The fact that we're using Git means that we have to submit .patch files that submit the whole change in a single step.
Using github could help in showing the individual steps used to achieve a goal without having to submit a different patch each time.