4 ms·

I use a similar strategy to this… much less formal but I’m excited to try this formal write up. My strategy was more like: 1. Start making a big change. 2. S

by tyleo 3y ago

I use a similar strategy to this… much less formal but I’m excited to try this formal write up. My strategy was more like: 1. Start making a big change. 2. See what breaks. 3. Move the big change to another branch. 4. Fix one broken thing and PR to main. 5. Rebase the big change back on top of main. Essentially trying to break off chunks of the larger problem in small commits. I’ve had about a 90% success rate with this strategy and when it works developers really appreciate reviewing the smaller commits than one monster change. I once heard that, “complex systems are built from simple systems,” and started to view my job more as identifying and working on the simple things to let the complex stuff fall out rather than attacking the complex stuff directly. Edit 1: one other thing I will add is that this strategy has the huge benefit of producing many smaller tasks that more of a team can work on and commit to main rather than having one engineer do the whole refactor or having folks working out of a half functional refactor branch with nonstandard git workflows. Edit 2: I've used this strategy in codebases with and without automated/unit testing. Where automation didn't exist, I've used dedicated QA staff. QA also appreciate testing small changes that impact part of a product rather than 'retest the entire product'. In environments where productivity is constrained by QA turnaround time I've prepared changes in a staging branch and keep having QA test the latest staging branch as soon as the previous has merged.

jonhohle 3y ago
Yeah, that’s my method as well. Start big and even fix nits along the way. Anything that’s in the way is fair game as long as all of the tests are passing. As fundamental, atomic changes are discovered, peel those off into separate commits and PRs justifying their current and future benefit. Rebase those changes on the big branch and repeat until all the changes in the big branch are merged. I’ve found that having a lot of small commits in my dev branch also helps makes rebasing easier. When there are conflicts, it’s easier to reason about what atomic set of changes they might affect than the whole wad. It also makes peeling off those changes into their own branch easier if things get to hairy.
- tyleo 3y ago
  Totally agree! When I work in this way I'll rebase all the nits up top where possible. I like to try to get the history to tell a sort of 'story of development'. Though this can be time consuming so I wouldn't fret about it if it becomes burdensome. When it works, this has a nice impact of dividing the PR into: 1. Here is what we were trying to do. 2. Here is all the stuff we also cleaned up which is somewhat unrelated but in the hot path of these other changes.
  - tome 3y ago
    This is great to hear. It's exactly how I work as well, and I find it very effective. In case anyone's interested I published a small shell script for splitting off smaller commits out of bigger ones. It aids my workflow a lot. https://github.com/tomjaguarpaw/git-split/ https://github.com/tomjaguarpaw/git-split/
    - jonhohle 3y ago
      That looks really nice. I like the idea of a sub-shell where all the work is either committed or reverted. I would like to see something like a “workspace” where even untracked files can be shelved in a named space and returned (or picked) after some operation. I could imagine a tool like yours where a snapshot of the current working set is made and a subshell with a clean repo created. Do some work, commit or not, and when the shell is exited, everything is back to the way it was (garbage and all).
JohnFen 3y ago
> started to view my job more as identifying and working on the simple things to let the complex stuff fall out rather than attacking the complex stuff directly. This corresponds well with what I think that software development actually is: it's almost entirely an exercise in complexity management.
growingkittens 3y ago
You also mention a good strategy for tackling ambiguous problems in any part of life. 10 Identify the problem factors as you currently understand them. 20 Solve simple patterns in the problem to expand your understanding. 30 GOTO 10 until complete.

by tyleo 3y ago

jonhohle 3y ago

Yeah, that’s my method as well. Start big and even fix nits along the way. Anything that’s in the way is fair game as long as all of the tests are passing. As fundamental, atomic changes are discovered, peel those off into separate commits and PRs justifying their current and future benefit. Rebase those changes on the big branch and repeat until all the changes in the big branch are merged. I’ve found that having a lot of small commits in my dev branch also helps makes rebasing easier. When there are conflicts, it’s easier to reason about what atomic set of changes they might affect than the whole wad. It also makes peeling off those changes into their own branch easier if things get to hairy.

tyleo 3y ago
Totally agree! When I work in this way I'll rebase all the nits up top where possible. I like to try to get the history to tell a sort of 'story of development'. Though this can be time consuming so I wouldn't fret about it if it becomes burdensome. When it works, this has a nice impact of dividing the PR into: 1. Here is what we were trying to do. 2. Here is all the stuff we also cleaned up which is somewhat unrelated but in the hot path of these other changes.
- tome 3y ago
  This is great to hear. It's exactly how I work as well, and I find it very effective. In case anyone's interested I published a small shell script for splitting off smaller commits out of bigger ones. It aids my workflow a lot. https://github.com/tomjaguarpaw/git-split/ https://github.com/tomjaguarpaw/git-split/
  - jonhohle 3y ago
    That looks really nice. I like the idea of a sub-shell where all the work is either committed or reverted. I would like to see something like a “workspace” where even untracked files can be shelved in a named space and returned (or picked) after some operation. I could imagine a tool like yours where a snapshot of the current working set is made and a subshell with a clean repo created. Do some work, commit or not, and when the shell is exited, everything is back to the way it was (garbage and all).

JohnFen 3y ago

> started to view my job more as identifying and working on the simple things to let the complex stuff fall out rather than attacking the complex stuff directly. This corresponds well with what I think that software development actually is: it's almost entirely an exercise in complexity management.

growingkittens 3y ago

You also mention a good strategy for tackling ambiguous problems in any part of life. 10 Identify the problem factors as you currently understand them. 20 Solve simple patterns in the problem to expand your understanding. 30 GOTO 10 until complete.