I Am Slow And That's Okay

It's taken me many years as a developer to become comfortable with the speed at which I work. I'm slow! Recently my friend Nicole helped me understand more about why I work slowly.

A super sweet Lego camper in pieces

Yesterday I had a 1:1 with my coworker/friend Nicole. I told her about my continuous fight with being a slow developer. Especially when working with developers who move quickly, I often feel shame about not "producing" quickly enough. Having dealt with this for a long time, I thought I'd understood it. But Nicole helped me understand it far more deeply.

I've long explained that I was slow because I explore problems thoroughly and I set a high bar for myself before considering my work ready to review. Nicole helped me realize that, sure, I carry those attributes...but they probably don't cause my perceived slowness. They might even be side effects of what causes me to move slowly.

She described feedback she'd received about her approach to design. She'd been asked to show her work more often, in an incomplete state, to show her progress. When she put that into practice she didn't receive the praise she was expecting — she received different negative feedback. Her team was expecting her to show a low-res version of the entire design each time she shared her work, but she was showing a high-res version of very small parts of the design. To her team, it looked like she was obsessing over a few details and losing sight of the overall picture.

Nicole explained that she was focused on those few details because they were the hard parts. They could make or break the entire experience. She hadn't lost sight of the overall picture — she had identified the biggest obstacles to the overall picture and she was de-risking them. Figuring out the hardest 20% of a design was critical to how the rest would fit together. Once that was done, the other 80% would fall into place. But because she started by working out out the critical details, it appeared externally as if she wasn't making much progress.

At this point I interrupted. "YES NICOLE!". This is why I move slowly. I'm doing the slow/hard parts first instead of last. For the first 80% of time in a project or task it will look and feel like I am accomplishing nothing. But I am doing the hardest work, preparing to make the other 80% of the work take 20% of the time.

The approach you use to solve a problem is a learned adaptation. Something has taught us that this is the best approach, or at least the best approach for us. For Nicole and I both it's an adaptation to failed projects. She's been burned by designing too far ahead, without giving adequate consideration to technical details that could break the design. Similarly, I've been burned by putting off the hardest 20% of a project until the end. Finding out near the end of a project that all the work I've done won't actually work is frustrating and I don't enjoy it.

If I eat the frog(1) — if I tackle the most difficult challenges first — I'll find any blockers early on. I'll also set the work up to move quickly at the end. Proving the concepts up front enables me to easily assemble the components once I know they all work.

It's like I'm building a super sweet Lego camper. I could follow the steps in order from 1 to 527, but if I know steps 126, 390, and 409 are going to be extra tricky, it would behoove me to solve them first. Figuring out those three critical steps will take me a while, and there won't be much visible progress. But once they're solved the other 524 steps will snap easily and quickly into place(2).

How do you approach problems? Do you save the hard stuff for the end, or do you eat the frog and tackle the difficult parts early in a project? Share your strategy with me on Twitter.

And if you're interested in learning more strategies for solving complex problems, check out this talk I've given called Getting Unstuck.

1 Abraham Lincoln once tweeted that Darkwing Duck said that Mark Twain once wrote "eat a live frog first thing in the morning and nothing worse will happen to you the rest of the day." I would link you to a reliable source for this quotation, but there doesn't seem to be one. In fact, the most trustworthy information I've found on this quote finds no proof Mark Twain said it. But whatever — today thanks to the book Eat That Frog! we interpret this (possibly made-up) Mark Twain quote to mean "do the thing you most want to procrastinate."

2 I know this isn't a watertight analogy. Even I just follow the Lego instructions from step 1 to 527. But real life projects don't come with 527 sequential steps and beautiful illustrations so please just go with it.