It’s a really useful approach and that any programmer should have in their toolkit, but it is a defensive approach.
There’s lots of time when a defensive approach is the right one for the job, but just keep in mind that you are slowing yourself down to look good. This makes it a very useful technique professionally, where you going slower might result in the whole team going faster due to better communication. It’s less useful in personal or exploratory work, where the commit history is not usually a primary deliverable and you could gain a lot of overall throughput by accepting poorer commit hygiene.
Allowing sloppy commits is most important to being able to ship the tiniest fixes and improvements. A few pixels out of place, one misspelled word, a single tiny usability improvement for your handful of mobile users… When you emphasize that no change is too small to go through the full formal release process independently, what generally tends to happen is that people respond by only working on the largest, most important changes. You can easily end up with code that’s basically-right but just feels unpolished to use, like the people who made it didn’t truly care about the fine details of the thing.
(Author here). Note that this was already published in https://lobste.rs/s/bxs6dh/plea_for_more_mikado
Thanks for letting me know—I thought Lobsters had duplicate post detection?
Thanks for a great article!
It’s a really useful approach and that any programmer should have in their toolkit, but it is a defensive approach.
There’s lots of time when a defensive approach is the right one for the job, but just keep in mind that you are slowing yourself down to look good. This makes it a very useful technique professionally, where you going slower might result in the whole team going faster due to better communication. It’s less useful in personal or exploratory work, where the commit history is not usually a primary deliverable and you could gain a lot of overall throughput by accepting poorer commit hygiene.
Allowing sloppy commits is most important to being able to ship the tiniest fixes and improvements. A few pixels out of place, one misspelled word, a single tiny usability improvement for your handful of mobile users… When you emphasize that no change is too small to go through the full formal release process independently, what generally tends to happen is that people respond by only working on the largest, most important changes. You can easily end up with code that’s basically-right but just feels unpolished to use, like the people who made it didn’t truly care about the fine details of the thing.