The hardest part of finishing something? Starting it

I’ve been managing teams of engineers for a number of years and during that time, I’ve spent a lot of time helping my team members with their personal development. Inevitably, these discussions also very often cause me to perform a lot of self-reflection. One thing that I find very frequently both in the teams I’ve managed and in myself is a particular form of procrastination — failure to just get started. Once I’m able to get rolling on something, I can spend hours burning through code and completely forget all distractions. But while I’m struggling to get going, it’s really tempting to take a peek at my email, or Slack, or Hacker News and put off starting just a little bit longer.

How to spot it

Ok, so your team has agreed that a major feature/bug/refactoring is a priority and it’s your job to tackle it. But for some reason, you just can’t get the wheels turning. For me, this inability to get started usually takes on one of two forms:

Analysis paralysis: my brain takes off running with all the complexity of what I’m trying to solve. What if my approach doesn’t work? What if I’m missing an edge case? Has anyone else already solved something like this? What about this detail over here? How will it fit together with this other thing we want to start in two weeks? It’s very easy to become overwhelmed and to freeze up.

Delusions of grandeur: not only am I going to solve this problem, but I’m going to open-source the solution and anyone who ever needs to solve this problem in the future will use my library. I’ll get a thousand stars on GitHub and Elon Musk will probably give me a high-five. Dreaming about how awesome something is going to be is way easier than starting to code it (and can be quite a bit of fun!), but of course in pretty much every instance, the idea is probably not that great. John Carmack touches on this in his talks on “antifragile” ideas and points out that the only way to know if ideas are any good is to actually build something. You’ve got to get started.

How to break out of it

There’s no miracle cure for procrastination and everyone’s different. But here are some things that have helped me over the years:

Write it down: don’t just keep all these ideas, problems, and edge cases in your mind. Get it written down in your issue tracker, Google docs or Notion, or even just use pen and paper. This forces you to bring structure to an otherwise unstructured thought process rattling around your brain. I personally find checklists to be super helpful in this regard. Just start writing down the steps you’ll take to build the thing you’re going to build. It doesn’t even matter how far you make it or how “correct” your checklist is. What matters is that you write down the first few things you’re going to try. It’ll shift you out of analysis paralysis and into coding.

I do this all of the time when using Kitemaker to build Kitemaker. When I’ve got an issue assigned to me and it’s a biggie, I use the issue screen as my canvas to get the thoughts in my head written down and structured. And once all of this is written down, it has the added benefit of being really easy to ask for input from my teammates. Which brings me to the next point…

Talk it over: particularly with junior engineers, I’ve seen a tendency to get stuck in your own head — to sweat over a problem, even for days, instead of just grabbing a whiteboard and talking it out or (especially in these COVID-19 times) pinging a team member in your issue tracker or chat app. This tendency probably originates from some imposter syndrome issues, wanting to crack something open yourself and save the day or just general shyness. But here’s the thing — when was the last time you asked a teammate and it was a bad experience or didn’t help you move forward? For most, the answer is probably relatively close to “never” (though there are toxic teammates out there). Once someone else is onboard with your problem, it plants things squarely back in reality and makes it way easier to get started.

At Kitemaker, we’re big believers in “starting together” — collaborating closely across engineering, product and design from the beginning. If we’re working a feature, we don’t make separate issues for engineering and design, for example. We make a single issue where we can collaborate closely to deliver the feature. This makes it much more natural to get input from your teammates, which a great way to get yourself unblocked so you can start cranking out code.

Prototype small: if you think prototyping is just for banging out quick UIs for user testing and the like, boy are you missing out. One of the very best things you can do is start to quickly hack on the solution right in your existing codebase. Don’t worry about breaking tests, API compatibility guarantees, or anything like that. Just start to figure out how you’re going to solve the issue before you. Even if there’s git reset --hard at the end of the day, you’ll know how you’re going to tackle it when you start coding “for real”.

Prototype big: some problems are hard. Like, really really hard. For these, I often find it’s better to start with a small standalone project and figure out how I’m going to solve it without all of the weight of the real codebase bogging me down. Tools such as create-react-app and the like are awesome for helping you get started with these deep dives. Once you’ve gotten the hang of how you’re going to solve your problem, you’ll have a much easier time bringing your solution into your real codebase. I use this all the time working on Kitemaker — from experimenting on key navigation, to building our editor, to figuring out how to make things work offline, etc.

Timebox your procrastination: look, some procrastination is normal, maybe even necessary. Don’t beat yourself up about it. A trick is to timebox it. Go for a walk and let your brain run wild in every direction it wants, but when you get back to your desk, start on starting. Whether that’s asking for help, writing down what you’re going to do, or starting to crank out some prototype code, make yourself start after your structured procrastination is done.

Thanks for reading! Did you find this article useful? If you want to see more material like this follow @ksimons and @KitemakerHQ on Twitter.