How to Repeat Small Wins (1) — Breaking Things Down Is the Oldest Trick in the Book

This time I want to talk about a way to make it easier to solve problems and produce good results.

Back when I was building a product from scratch at a startup, I broke that huge goal down into ninety-one small milestones. The first item wasn't anything impressive. It was something like "write code that reads a single file correctly." Modern programs are generally built by combining components that each handle a small function, so I tended to build them one function at a time and add them up. Along the way, I'd check the results, and whenever something worked as designed, that counted as a small win.

The Oldest Way to Handle a Big Problem

This isn't some secret technique or know-how of my own. Computer science has a problem-solving strategy called "divide and conquer." You take an unmanageable big problem, split it into smaller subproblems of the same shape, solve each one, and combine the results. Merge sort works this way. So does binary search.

It looks simple, but it's more powerful than it seems. Say you're sorting a million pieces of data. A naive approach that compares everything against everything needs roughly a trillion operations (O(n²)), but merge sort, which splits the problem in half repeatedly (O(n log n)), finishes in about twenty million. Same problem, but splitting it up cuts the number of operations by roughly a factor of fifty thousand. The oldest, most reliable way to handle a big problem is simply to break it into small pieces.

Cut It Down to a Size Where You Can See the End

The key is cutting the problem down to "a size where you can see the end with your own eyes." "Finish the product, launch it, and make money" doesn't intuitively have a visible endpoint, but "correctly read this file format" does. So the goal of the first milestone shouldn't be completion — it should be getting started. As the saying goes, starting is half the battle.

In an unfamiliar project or domain you're touching for the first time, even something small always feels like a lot to handle. There was a time it took me a whole week just to get the code that reads a single file properly in order. But even starting this way, once the components piled up, the earlier pieces became material for the later ones, and things picked up speed. Small wins earned interest, and that interest kept compounding throughout the project.

This method had a side effect I hadn't expected at first. I'll pick up that story in the next post.

Reference: Merge sort — Wikipedia