The fifteen days since my last post are the longest I’ve gone all year between writing. My resolution at the start of this calendar year was to write 50 posts in 2020. So, I’m not quite behind yet, but I am glad that my reasons for missing two weeks eventually led to the topic of tonight’s post.
The first, and most practical reason I’ve fallen behind my writing schedule is that June and July are the busiest months for my 9 to 5 job. (Well, lately, more like my 8 to midnight job.)
To keep myself sane while dealing with my work deadlines, I’ve found myself tinkering around with an idea I’ve wanted to try building for years now. Oddly enough, it’s not yet-another-app, but a website (web service, maybe?). And it’s actually something that’s designed to be self-hosted. I haven’t yet decided if it will (eventually) be open source, or if I might solicit feedback from friends (real and online) just in case it’s more useful than I think.
But I digress.
This topic of this post is about a pattern in how I work – my process – that I only recently noticed the other day. In hindsight, it’s how I’ve always built things – how I’ve approached new projects. But for some reason, I never clued into the fact that, yes, this is how I work. These are the same steps I take with each new “thing”. And this is the step I’m currently on.
It was that realization that prompted this tweet last week.
Step 1. Build it as fast as possible.
Step 2. Wait 48 hours.
Step 3. Try again.
That’s not exactly it, but close. The longer version is…
Sometimes the idea for something new comes in a flash of inspiration. And other times (as in the current case) it meanders around in the back of my head for years – just waiting for the right moment or combination of external factors.
For this project, it’s the result of the rebirth of the indie web movement, my long time interest in self-hosting and owning the tools and data I run my business with, and Apple’s WWDC announcements about Safari and their OS’s upcoming privacy improvements.
But whatever the idea or genesis, there’s always a tipping point where that initial spark really catches fire and I have to build it now. I don’t know how to describe the feeling I get in my head (my whole body really) other than electricity-at-the-thought-of-new-possibilities. It also feels incredibly similar to when the dumb part of my brain is trying to convince the smart part of my brain that the ridiculous impulse purchase I’m considering is actually a good and rational thing to buy.
And so, full steam ahead, I try and build a proof-of-concept as fast as I can. I give no regard to code quality, architecture, performance, look and feel, anything. My only goal is to see if I can make it work in some functional way in the simplest form possible.
Writing code in this state is an ultimate high for me. It’s a pure act of creativity. Sure, I enjoy alcohol and other substances, but no feeling I’ve ever gotten from those things can compare to the literal buzz I get when my hands on the keyboard are perfectly in-sync with the instructions pouring out of my head.
And while the word may be in my job title, I hate calling myself an “engineer”. Beyond the math, there’s almost no engineering involved in how I approach the code I write. That doesn’t mean I’m not careful, thoughtful, or that I don’t make well-reasoned decisions, but I’ve always viewed my development style more like art – sculpture, specifically.
I start with a raw block of material and massage and shape it towards a final form. Sometimes, especially at the start, I may have no idea what the end goal is. But over time as I add new pieces, move and rearrange others, it takes on more definition, structure, and patterns emerge. If you look closely, you’ll see influences from prior art and other developers, too.
That’s all to say that the things I build are rarely assembled from a blueprint. They’re organic, and I’ve often found myself at odds with other peers in the industry because of that. But that’s a topic for another post.
Once the prototype is done, once I’ve proven to myself that my idea is possible, I let it sit.
For a day. For a week. In one unique instance, seven years.
During this time I focus on other things. My real work, my family, baseball (2020 season?), whatever. Anything other than the new project. And as I go about my day, my brain will naturally start to surface ideas, features, goals, must-haves, and nice-to-haves. All the little details and tentpoles that would eventually define the full scope if I choose to move forward.
If I’m on my phone or in the car, I’ll jot down (or dictate) the idea into Drafts. If I’m on my Mac, the note will go straight into Trello, which is where all of my personal projects are tracked.
It’s also the naming phase. I almost never have an idea for what to call the project when I start building it. But during this ideation downtime, coming up with a good name for the new thing seems to be a natural byproduct of listing every possible feature.
And so, once I’ve given myself enough time to sit. To think. To let all that initial, throwaway code settle and be still in my mind, I’ll revisit it with fresh eyes and attempt to place it into one of four buckets.
- This is crap / dumb / stupid / a nice distraction but not worth pursuing.
- This is great – but only for me.
- Other people might like this.
- Other people might pay for this.
In the first case, I save everything to git if I haven’t already, and move on. (I never throw away code, though.)
Number two is often very likely. I have lots of one-off projects and tools that are only useful for me.
If I think it’s useful and worth sharing, and if I’m also willing to stomach the shit-storm of asshole internet trolls who find joy in complaining about the quality of code other people publish for free, I’ll post it to GitHub. I love doing this.
But if I decide it might really be useful, typically based on feedback from friends, I’ll begin thinking about how long it might take to reach an MVP if not even a 1.0. Is there a valid business model? Is it something I feel comfortable asking strangers to pay money for in exchange for the responsibility that places on me as the developer and support person?
And if all those stars align, I’ll officially add it to my Trello development calendar, and it’ll be done just as soon as I finish the other 437 projects ahead of it.
But once the project reaches this stage, I know enough about myself to understand that I do my best planning and thinking visually. And given that the prototype was built with almost no thought to UI / UX, and that I now (hopefully) have a long backlog of features in Trello, I’ll spend whatever amount of time it takes to settle on a “final” look and/or flow that I can move forward with. (I put “final” in quotes because, ha, this stuff is never really done and will be changing forever.)
It’s just my personality and a near like writer’s block in my head, but until I’m convinced I’ve nailed down the main window (if it’s a Mac app), the first few screens (iOS app), or HTML/CSS structure (web app), I can’t write any more code. It’s impossible for me to move beyond the working prototype stage until I have a basic shell or the chrome to put my ideas into.
It doesn’t matter if the UI I settle on will eventually be completely thrown out and replaced, but it has to reach some initial threshold where my inner critic says “Ok, that’ll do for now.” Only then can I continue.
And it’s that first, final design stage I find myself in with this current project. I’ve got a working prototype churning away on a DigitalOcean VPS this very moment that I’ve been using every day this past week. And I’ve got 200+ cards in my Trello backlog. And I’m aching with excitement to stretch some development muscles I haven’t exercised in years.
I love this part.