Indie Hacker Diaries #21: Subtract Till You Drop

One of the most valuable coding lessons I ever learned was "extract till you drop."

The originator of that phrase, Uncle Bob Martin, explains that the most maintainable code breaks work down into single-purpose functions. So, given one large function that does many things, you "extract" each piece of work into its own function. The end result? It's much easier to reason about what a program is doing.

This was the inspiration for actions in Joystick (and previously, the action pattern I shared here). Lately, I've been thinking a lot about subtraction on the product side of things.

With Parrot, I set a hard limit on functionality and what UI I'd ship first, with the goal being to not spend more than a month getting it shipped. This week, I finished up work on Push (the deployment service for Joystick apps) and applied a similar rigor to my work there.

Instead of trying to build a complex UI and a ton of screens, I subtracted a lot of what I'd built from the earlier versions of Push. On the code side, I subtracted the more complex, on-instance library for managing logs and metrics and just migrated that code directly into Joystick. On the billing side, I came up with a few simple, flat rate plans instead of trying to charge on a per-instance basis.

Go figure, almost a month exactly from starting the rewrite: I'm finished. This really got me thinking about the role of subtraction and how it can be used to get you where you're going a lot faster.

Years ago—and those of you who've been following my work for a long time could infer this—I was big on big. I had this unsupported notion that what I released always had to "up the ante" from my previous work. This was fun early on, but eventually it led to projects taking far too long to ship (or being moved permanently to the dust bin on my computer).

Now, I'm really embracing the "less is more" approach to product development (and by extension, tool development). I’ ve accepted that the average attention span has dwindled to the point that, sweating the details on a lot of stuff isn't worth it. People, generally speaking, won't notice and won't care. They're not acting from a position of malice—they're just inundated with so much stuff that they don't have the mental bandwidth to really dig in in a way that they'll see what you see.

When it comes to your own products and work, I'd encourage you to consider this reality. The days of being able to "wow" people are more or less over. Now, it's better to be able to spark interest first, and then follow that up with "wow" via iteration. Instead of starting the fireworks display with the grand finale, ship something that's really good—but simple—first and then keep hammering.

This is the approach I'm taking moving forward. Instead of gassing out early with a big initial push, get the point across and then roll out more, potentially exciting, stuff later.

I can't say how well this will work just yet on the business side of things. But I can say that, for the sake of mental well-being, it's doing wonders.

Ryan