Hours of Planning

A fellow engineer at Soundstripe, Kyle Boe, relayed a comical yet thought-provoking aphorism that he had picked up from one of his ex-colleagues:

"Weeks of coding can save you hours of planning"

– Kyle Boe's buddy

He definitely should have taken credit for that. Law 7, Kyle.

I initially didn't think much of it. But it kept springing back into my head. I gave it time to grow on me, and it definitely has. You've almost certainly been asked the rhetorical question "how do you eat an elephant?". And you can measure the bites however you want, but you still have to plan to some degree: where to start, for example.

I used this planning-first approach to launch HTTPizza recently. It lets you configure observers that test the response of HTTP endpoints to detect outages, errors, etc. The changes started to roll in as plain old commits along master in the early days, but I decided to try something different once I realized that I was actually building a product for myself, not just one of my toy apps or intellectual pursuits. So I made a GitHub project to plan and track work. As soon as something strikes me as relevant, it lands on the project page, whether it's a fuzzy post-MVP idea or a critical bugfix. When it's time to get something built and shipped, it gets converted to a repository issue. Issues get closed by the PRs that merge the work into master. Then the app is deployed. It's a simple workflow, but it suits my one-man team.

I find that walking an idea (no matter the scope) through the development process by writing out the requirements and downstream work gives you a concrete starting and stopping point. Almost like fruit on a tree, the tasks will become ripe and ready to pick up. It also becomes easy to notice when work isn't necessary. The easiest and fastest work is the work you don't do at all. The runner-up is the work that you realize is completely overengineered, and pare down into something that can be builty quickly without compromising functionality.

Another benefit of this approach is constantly having a line-up of work to pick and choose from that suits the time constraints I have. I try not to start anything that I can't finish and deploy in one sitting, since it's possible I won't revisit the project for a few days, and reading through the code to reassemble all of the contextual information about the work is not something I'm keen to spend time on.

At the end of the day, this is really just a love letter to writing things down. Engineers may be smart, but it's a tall order to remember anything and everything that ever crosses your mind. Plus, writing ideas down forces you to be able to communicate them, which is invaluable—the recipient of that communciation might not always be the future you.