This one is for the doers: those who have stepped out of the dark, set aim for the heavens, and vowed to realize their dreams — costs be damned.

This one is for the pragmatists: to everyone around the world who values time well spent, and seeks to quantify every working moment with hard data.

I have a message for all of you; the big dreamers, slow starters, hustlers, and anyone else caught in the web of our modern world, without a definition to call their own.

You don’t have to solve everything today.

That’s right! There is no goal you cannot attain, but first, you must understand the problem well enough to break it down into small, actionable tasks. It may sound simple, but this kernel of wisdom is the basis for many popular work systems, most prominently GTD, but I’m sure there are many others.

For me, this piece of wisdom changed everything. As a young person, I learned to dispel confusion during early phases of a new project — which, in turn, allayed the ever-present concern associated with learning a new skill. Because I was able to break down larger tasks into their constituent parts, I was able to mitigate the overwhelming concern that some individuals experience when mastering a new discipline.

The toughest part is knowing how to apply this technique. When dealing with physical objects, how to deconstruct them is normally clear. But when you’re working with logically complex digital systems (such as a piece of software), the challenge of applying this methodology becomes more apparent. If you’re confused, allow me to explain.


Earlier today, I was working on a build system for one of my larger Node.js applications. It’s only a couple months old, but the build system relied on Gulp, and despite being relatively new, the process of building, versioning, and releasing the application was incredibly slow. Realizing that every one of our tools could be packaged as a standalone command line application (if it wasn’t already), I decided to forgo Gulp and it’s ilk in favor of npm scripts.

But, as anyone who has rewritten software knows, the process of a rewrite is anything but simple. In the case of my application, we had a handful of Gulp tasks, each with it’s own responsibilities and associated configuration. Needless to say, the existing system was overly complex; but I resisted the rewrite for almost a month because it wasn’t necessary.

Today, as I prepared for yet another round of testing, I realized that the slowness of our build system was blocking progress in other areas. So, I paused and prepared for the inevitable: the system needed to be rewritten.

A few hours later, I emerged with a snappy new build system. Is it perfect? No. Is it faster than before? Absolutely. But the interesting part is how I arrived at the specific toolchain: I specifically ignored the later tasks, such as versioning, until other, more pressing needs (like compiling CSS) were finished. This allowed me to focus on what mattered first.


You can do this too. Any problem, in any industry, whether the complexity is obvious or hidden, can be disassembled. Give it a try, and you’ll soon find that there is no problem too large.