"don't just make the change, make it easy to make the change first, and then make the change" is probably good software practice but does not play well with being impatient and wanting rewards NOW
Conversation
I usually follow "make all the change at once then crash and burn, realise your folly, then make it easy to make the change, then forget to make the change"
1
1
bold strategy
1
1
I added the last bit for dramatic effect, and I usually follow through. The crashing and burning is usually real though. I do it a few times on a branch before I know the best way to set up the change and finish it. It's important to have a culture that lets you do that though.
1
1
yeah especially on new projects i often try to change too much at once, realize a few days in that i could parcel it out into smaller easier changes, and just do over
1
1
Replying to
I've found that type systems help me a ton with this impatience. They give me enough structure to change lots of stuff and then divvy things into smaller chunks. And also feedback to say if I'm overreaching.
And yeah, I think we should be cool with doing it all at once in a fit of excitement, then doing it again in smaller chunks if it ends up with a better git history and easier to explain PRs. Totally a fine method. Excitment Driven Development™
1