This year, I have made 60% more git commits than last year, objectively more feature development, without burning any extra time.
During the same period, I have kept my 11PM - 7AM sleep routine, contributed more supportive tasks at work such as cultural development, and maintained longer streaks on Duolingo.
All of the above has been possible thanks to problem breakdown. It is a common technique that applies to almost all types of knowledge work, which comes with some great benefits.
In my case, each commit represents the solution to a less scoped problem. This results in faster review time, and more constructive suggestions from reviewers.
On the opposite, when a single solution covers too many grounds, it would take much more time and effort to review, so the agility of development takes a hit. Even worse, reviewers would say “screw it” and blindly approve the behemoth solution, defeats the whole purpose of peer reviewing and fast-track derailing product quality to the netherworld.
Suppose you need 2 hours of contiguous time to solve a large problem. During that process, unfortunately, you may get interrupted. Those interruptions will cost you a lot of time to switch your mental state back into the zone.
However, if you break such a problem down to 5 smaller ones, on average, each will need just about 30 minutes. 30 minutes of uninterrupted time is much easier to come by than 2 hours.
Even if you do get interrupted in that case, since each problem is about 1/5 complex of the original one, it would probably cost just 1/5 of the time to recover from the interruption. Simple math. Your short attention span will thank you for that too.
In an ideal world, you can pursue after your inner perfectionism without consequences. But in reality, there is always a decision to be made on when to stop pushing further. Otherwise, it may result in your time running out, or budget running dry, or blocking more of your teammates, or maddening more of your clients or stakeholders. You certainly do not want any of those.
So by breaking down larger problems down to smaller scopes, it often becomes easier to realize which ones can be deferred, or even dropped. At Basecamp, they call it Scope Hammering.
Smaller solutions for smaller problems give faster wins. Faster wins create a healthy momentum to carry you forward and build positive morale.
Every real-world technique comes with tradeoffs. For this one, it’s the time overhead. The less experienced you are in the domain, the more significant that overhead can be. But given the benefits, it’s well worth it.
So stop chewing through that complex problem, go ahead and break it down.
Thanks to my wonderful coworkers at EQ Works for reviewing and breaking down this article.
Also thanks to Rain WZQ for the amazing illustrations.