Start small. When starting something new, it makes sense to cut it down into easily manageable chunks, from anywhere to 5 minutes to an hour, that can be completed with relative ease. It doesn’t matter whether you are trying to build up your exercise capacity, writing computer code, reading a textbook, learning some new skill, or whatever. Everything, in the beginning, benefits from making the task small and fun. Completing it gives you a sense of accomplishment, that you are capable of fulfilling the task that previously you did not think you could do.

And, once started, there’s momentum. In a piece of code, you may start off doing something badly, but it works. Then, you’ll see some small way to improve it. Then, another, and another. Eventually, you get to the point where it looks like you knew what you were doing all along, and the task helped you to learn your way there.

But, there is another side of this kind of incrementalism. Invariably, your learn enough that your initial ideas and effort weren’t the best place to start. Or, your goals change. Something tends to happen that makes you want to completely refactor what you have been doing into something new. You’ll want to rewrite the code or essay. You’ll decide, now that you can run, perhaps you should run a marathon, as a challenge.

Partly, incrementalism gets us to the point where we have a skill, and we want to challenge ourselves, to do something bigger than what we could have imagined before we started. This is great, when it happens.

But, another thing sometimes happens too. We get complacent. Rewriting the code is a lot of work, and incrementalism is all about work, but in small size chunks. But, getting yourself in a mental mindset to redo your incremental work is the same as when you start out trying to learn something you didn’t know before. Except, now you have a better understanding of how much work is required, and it will be harder to just want to do incremental changes. You’ll want to do more, because you have the capability to do more. However, this desire also has a tendency to cut into your enthusiasm.

Why refactor the code, when what we have is “good enough” for most of our purposes? The calculus of benefit tends to run this way. Further, the more people are involved, the more inertia will set-in. This is why revolutions always require vanguards because its at the vanguard that the enthusiasm for wholesale change is nurtured and acted upon.