Skip to main content

Making Building Software Fun

·524 words·3 mins
Alex White
Author
Alex White
Dad, cyclist and tech guy living in Ohio.

I’ve been writing software for a long time. When I was a kid, I loved making text adventures, spending countless hours planning the dungeons on pieces of paper. I wrote games and sold them to kids in the neighborhood on CDs. I built a stock market simulator (knowing nothing about the actual stock market) on a Palm Pilot during a family road trip. Back then, building software was fun.

My passion for building continued through college, where I released apps on Windows and Windows Phone. After college I built and launched my only app that’s ever made an actual profit, MetaShort.

But then, the fun stopped. As I advanced in my career as a developer, I lost interest in building. Anytime I sat down to build something, I’d be frozen with analysis paralysis. What stack should I use? What features should I add? Will this be profitable? How do I approach the design? Is this scalable? How do I optimize for SEO?

I’ve been stuck in this rut for years, but I think I’ve finally found the way out. The key to building, is to make it fun, and that’s a lot harder than it sounds.

As a kid, building games and apps was fun because I didn’t (couldn’t) over analyze it. I only knew BASIC and GOTO statements, so I made it work. My stack was Hotpaw BASIC, a Palm m105 and an infrared keyboard. That’s all I had, and I loved it. But now, I have too much experience, so I have to be intentional to let go of that.

I’m currently building BookLeaf , an open-source bookmark manager. I could have built it with Svelte or React, or maybe the TALL stack. I could spend countless days on the design, mobile responsiveness, etc. But this time, I intentionally didn’t.

I spun up a Laravel project and stuck with Blade templates, inline CSS and next to no design. I deployed with Forge + Digital Ocean so I don’t have to deal with devops. I’m building with what I’m most familiar with, so I can move fast. People talk about releasing an MVP ASAP to get user feedback, and while I agree on the quick MVP part, I have a different goal. An MVP gets me to a state of joy as quickly as possible, a MJP (most joyful product) if you will (sorry, had to).

The MJP is where I have something that proves to me “hey, you managed to build a thing, now time for the fun part”. Hacking on new features, using the app in my daily life, and occasionally hearing from other people that have discovered it. That’s the fun part.

But here’s the thing, my path to MJP is not your path. Your path to a joyful product might be creating a robust server infrastructure, or leveraging the latest frontend framework. And that’s okay. But make sure you’re not lying to yourself, not doing things because “well that’s best practice” or “what if a potential employer sees this repo” or even “how will I scale this”. Make sure your decisions are motivated by a MJP, not a MVP.