I was recently discussing the question of flow and pull request review. I’ve talked before about making PRs smaller in an effort to make them more reviewable.

But a common concern is “Yeah, but how do I make my changes smaller?”

This is a natural question, because often it feels like a feature you’re working on simply isn’t ready yet. Maybe it doesn’t even work yet! Maybe you’ve even broken everything in the process of getting your new feature in place.

One approach is often “just do pair programming”. This isn’t bad advice, but I think it really misses the point. Slicing is still useful even if you’re pairing.

So how can you possibly commit something like that, let alone make it a pull request?

Well obviously, you can’t.

You need to learn to write small and at the same time functional steps toward your eventual feature.

How do you do that?

Here are three tools or techniques to help you learn the art of working in smaller, working iterations.

• Test-Driven Development. I know you’re tired of hearing about this one. But it’s definitely true that it helps with small iterations. When doing proper TDD, you write a small test, then the code to make the test pass, then you refactor. This entire cycle takes anywhere from 30 seconds to, at most, 5 minutes. And at the end of every cycle you have code that works, and can be committed, and even made into a pull request.
• The Mikado Method. If you don’t like TDD, try this one. It’s a simple visualization tool and technique to break down your work into individual, stand-alone parts. Not long ago I interviewed the author of the book on the topic on my podcast. Have a listen.
• Test && commit || revert TCR is kind of a trimmed-down version of part of the Mikado Method. It’s kind of like TDD in reverse. In a nutshell: Make a small change. Test it. If it works, commit, if it breaks, revert it and try again to make a smaller change that does work.

What is your preferred method to slice your work into smaller pieces?