I'm Slow And That's Okay
Tags: career, productivity, problemsolving, personalgrowth
Published: 2020-10-14 14:54:55

---
title: I'm Slow And That's Okay
published: true
description: 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.
tags: career, productivity, problemsolving, personalgrowth
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/h1mncbbgiucmgrogqrok.jpg
canonical_url: https://www.stevenhicks.me/blog/2020/10/i-am-slow-and-thats-okay/
---

Yesterday I had a 1:1 with my coworker/friend [Nicole](https://twitter.com/deliciousnachos). 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<sup>[(1)](#footnote-1)</sup> — 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<sup>[(2)](#footnote-2)</sup>.

---

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 below or [on Twitter](https://twitter.com/pepopowitz/status/1316374951868260353).

And if you're interested in learning more strategies for solving complex problems, check out [this talk I've given called Getting Unstuck](https://www.youtube.com/watch?v=3XscuivvUzI).

---

<a name="footnote-1"></a>
<sup>1</sup> 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](https://quoteinvestigator.com/2013/04/03/eat-frog/). But whatever — today thanks to the book [_Eat That Frog!_](https://www.goodreads.com/book/show/95887.Eat_That_Frog_) we interpret this (possibly made-up) Mark Twain quote to mean "do the thing you most want to procrastinate."

<a name="footnote-2"></a>
<sup>2</sup> 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.