loading...
Cover image for I'm Slow And That's Okay

I'm Slow And That's Okay

pepopowitz profile image Steven Hicks Originally published at stevenhicks.me ・4 min read

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 below or 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.

Posted on by:

pepopowitz profile

Steven Hicks

@pepopowitz

JavaScript-y engineer with a love for being outside

Discussion

pic
Editor guide
 

I eat the frog, but then again lately I've been not eating the frog? I think I eat the frog a lot more on personal projects since I know that I can go the distance with it on my own time. In business life, I go after low hanging fruit and start to climb up the tree after getting that fruit. Okay, this is a super weird comment, but I hope it makes sense. 🐥

 

It makes sense! It's a lot easier to start slowly when you don't have to explain to a client why it looks like nothing is happening. Right now I'm working on a very supportive product team and I feel less of a need to explain my slowness. I can imagine if I was working directly with a client, I'd feel differently.

I'm also excited though that I can better explain WHY it might look like nothing's happening at times. Explaining that up front certainly wouldn't work with many clients, but I've worked with a few that would have understood & been cool with it.

 

Such a great point. Good to remain considerate and authentic!

 

I liked how you've extended the "low hanging fruit" metaphor.

 
 

That's me! That's the kind of developer I am! I don't always eat the frog at first, but I take the time to make sure I identify what the frog will be for the task at hand and be prepared for when it's time to eat it.

I only wish some superiors would notice it more often. I've had many bosses through my professional career, some who like this approach and some who don't. Right now, for the past couple of months I've gotten all my tasks approved by QA without any issues, while some of my peers who like to commit code ASAP have theirs sent back constantly, sometimes delaying the delivery of features by weeks. I know I might be doing right, but constantly hearing just that you're slow on getting things done kinda drags you down.

 

Yes! I know this feeling well. It can be really discouraging. It's hard enough to convince myself that it's okay to be slow; when I have to also convince my teammates that its okay it's exhausting. Hopefully your team starts to recognize that you're delivering the full results just as soon as the others, if not sooner, despite taking a different route to get there.

I'm personally hopeful that I'll be able to explain to others why it seems like I'm slow to get things done, now that I understand it a little bit more.

 

As an engineering manager, I would always prefer a feature which is done slower, but fundamentally right.

You should not worry too much about your speed, especially if you don't mesaure it objectively with some metrics.

My weekly observations over my team showed that people that are rushing, or doing things faster than others, in fact deliver worse results over the time.

They get more bug reports, they spend more time on "polishing" things, they spend more time in the next release to rework the code, because they didn't invest enough time in designing it before.

So in the long run, "slow" might not be so slow, if you see a broad picture.

 

Measurement is a very important emphasis in your point. It doesn't exist if you don't measure it. So one shouldn't bother with speed unless there is a solid feedback on it.

I also agree that performance should be handled considering cumulative effects in the long run. For example, I think maintainablity is one of the greatest bottlenecks out there and I am suspicious if delivery speed (of initial code) is even a bottleneck or not.

 

This is why I don't like scrum story-pointing.
I mean story points make pressure on developers to release fast and compete in the race for points on each sprint.

While often the most difficult challenges are part of the nonprogramming tasks, such as:

  • Help a colleague with a blocker
  • Talking to customers and improve requirements
  • Reviewing a PR(thoroughly) and left valuable feedback
  • Forseen possible problems, communicating to the team and planning a solution

I used to have a teammate who used to spent more time on these nonprogramming tasks, from my point of view he was a key member that made our team perform much better than other teams (big company with multiple teams).
At the end of each sprint, this guy had fewer points than other members if someone looked at the stats he was the worst contributor, lol

 

Yes, this describes me too! It takes a lot more work down the road to undo bad decisions made up front. It's good to take the time and make sure the road is paved even though it's faster and cheaper to use gravel.

 

Hi Steven. Great read, and one that particular resonates with me at the moment. Throughout a lot of my software development career I have been fortunate to work fairly independently having been the subject matter expert, however, I have recently left the corporate rat race and I am now working on an personal project / start up. It's now much clearer to me that I do "eat the frog". It's my family who are the ones looking in and I keep finding myself becoming defensive over my perceived lack of progress. I find it particularly difficult to explain to non technical people that I am trying to put in place generic procedures and design patterns that will help down the line, as they only see finished projects "on the web" and have no concept of the actual design and implementation process. (I guess this is a challenge I should work on) They want to see food on the table and me showing them back end code does not alleviate their worries. It is now a real battle for me to stick to what I believe to be the correct approach (eating the many frogs) rather than caving in and doing a few show piece "easy" visual things that others deem to represent real progress.

 

The way I heard it (from Twain's great-grandmother, of course) was, "Eat a live frog for breakfast and nothing worse will happen to EITHER OF YOU for the rest of the day."

More punchy, I think, but doesn't fit with your intended meaning as well. For your meaning, I just think of it as eating the crust first.

For coding, I tend to start with tackling the most interesting part I'm ready for. I think that's usually the hardest/riskiest (fail-fast), but sometimes I need to build up some momentum and familiarity with the problem space / system / etc first, by doing simpler things.

 

Ooo, that version is better.

It is nice to take a break from the frogs ever once in a while and get a boost from a quick win.

 

I used to say to myself, "If I could write code as fast as Mr. X, that would be amazing!" Then I took over Mr. X's project, and realized how many hard problems he solved badly, if he even got around to solving them at all.

I do like to eat the frog for sure. It just removes uncertainties from the project, and you at least have a possibility of being accurate when asked when the project will be complete.

One thing I've started doing with that hour before the morning standup is to tackle a simple problem that has no dependency on any of the the hard problems. I feel like I accomplished something, and that I won't have to interrupt a train of thought when Outlook starts peppering me with notifications that the standup is about to start.

 

Nice! I do something similar - I add a "shallow", "medium" or "deep" tag to all of my todos, and I'll knock out the shallow ones in between meetings, or at times when I know I'm not going to be able to focus deeply.

 

Genuine question, I'm hoping you can help me with something.

Why are you perceived as slow? How is "progress" measured?

I get that maybe you don't "show your incomplete state" and that you tackle the harder parts first (kudos, by the way).

But surely, judging two people on the same team, for one to be "slow" there should be some measurable metric, such as number of tickets (or story points) completed within a given time frame? And surely the comparison would be made fairly (e.g., your profile lists you as a Senior, so you should be compared to another Senior).

Is it just your inner monologue that deems you slow, or is someone telling you that you're slow?

For what it's worth, I equate slow with careful, deliberate, healthy progress. Though naturally there are limits when deadlines loom.

 

For me it's almost entirely inner monologue. I have received feedback that I should make work visible sooner rather than later, but most of my feelings of "slowness" are internally derived. I'm 43 and still working on accepting myself for who I am and how I work 😬

 

Thanks for the reply.

That sounds a lot like Imposter Syndrome to me. In our work environment, if I have someone talking to me about similar thoughts, I pull up the reports in Jira & break it down, use the system we have to demonstrate that they don't have an issue.

Might not help long term, but seems like it does for a few minutes at least.

It most definitely is! This is a topic my therapist and I discuss often :)

 

Thank you for writing this! I feel like as I'm getting more experience in the field, I've tend to become more conservative and take my time to plan everything and tackle the core/important things first. It can be hard since your impostor syndrome is just blaring up every time, especially when you have to do 'sprint review' and watch your peers getting the praise solely for the number of PRs that they pushed

 

Oh gosh, don't get me started on comparing how many PRs I push vs others. It's something I'm constantly noticing, but never helpful.

My personal takeaway from this... enlightenment...is that I could be more communicative. I have more I could communicate about why something's taking me so long. I could communicate more about the scope of the problem, the depth with which I'm thinking about it, the challenges I'm recognizing along the way. I hope you find the strength to advocate for yourself in a similar way!

 

One of the first lessons I got in my professional career was "do easiest things first" or "sort tasks to do by estimated time ascending" (of course if one doesn't depend on others).
Why? I guess that's so I can progress fast and stay motivated by "work moving forward" and I won't get stuck on hard task blocking me from doing smaller. And that's a situation I experienced many times when I was focused on the hardest thing that caused I didn't do other tasks.
My mentor said once "better done than none" what I interpret it's better to show small tasks done e.g. on daily scrum than say "I worked hard but can show you nothing". Many people, especially in management, are not interested in how much time you spent on solving hard things. They want to see effects and completed tasks in kanban.

 

I'm the other way around, I do all the easiest, quickest, smallest tasks first to allow myself to have the time to dedicate myself to the hardest work. This also depends on priorities but normally I work like that. This was also the way I operated back in school during exam season.

Though... you've made me realize that there is a huge downside to this at least when it comes to my life outside work. I procrastinate too much on the things I really don't like/want to do hahaha eating the frog is too hard for me, I'll leave it for tomorrow XD

 

One of the things I've most realized through this is that the approach to solving a problem is really personal. There are tradeoffs either way, and everyone has a different reason they choose one approach over the other.

For what it's worth, while I prefer to eat the frog with work projects, I definitely procrastinate the frogs in my personal life 😁. Looking at you, screen door that should have been replaced ten years ago....

 

Hey Steve! Cool to find you here. Really great article. I can usually find myself upfront on a project doing the same of trying to find the sticking points and making sure that we can do those right and well before proceeding with the basics. Probably likewise that experience of getting to the end and realizing we didn't think the hardest part though at the beginning and now we're stuck with limited choices. This feels to me like the sign of a good developer more than a reflection on your speed as a developer.

 

Hey Jon!!! Looks like you're still overseas - hope things are going well!

Thanks for the affirmation. I agree that this is what makes you and I great developers. I also think there's room for great developers to work more iteratively, and I think that's the main thing I was hoping to highlight. We don't all have to approach a problem the same way to be successful.

It is really nice to hear so much encouragement that I'm not the only one that approaches things this way 😁

 

I think that if you're "slow" (you take more time to produce something) then at the end of the day you're actually "fast" (you're in fact MORE productive) !

Sounds like an oxymoron, but bugs that make it into production are WAY more costly than spending a little extra dev time on thinking, planning, coding, testing and reviewing.

 

classic tortoise vs hare 😁

 

Productivity is not measured at a specific time It's more of a global indicator. If you are pushing code like crazy but creating tons of technical debt , sure at the moment it looks like your being productive but in the long run you clearly not.
On the other hand if you are producing the same thing as other but twice slower , you probably doing something wrong.

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?

I'm more of an iterating guy. The first iteration will be almost an empty shell , everything is there , but no doing much. That usally helps me to build a good architecture. Then i go deeper and deeper until specs are reached.

Focusing too soon on specific problem usually lead to bad design because you are too focused on the current difficulty and not thinking of the entier task.
I think it's also very important to be able to show quickly a global idea of what your doing to the customer/boss/whoever.It is usually a this moment they changed their mind and ask you to redo everything. If you only worked on complicated stuff , and everything change you 'll lose a lot more than if you only did meaninless/not complicated things

 

Sometimes, the hardest parts are clear from the beginning. Other times they require discovery. I've found that most of my speed in development comes from working on what is known until a hard and complex unknown reveals itself, and then pairing with other developers on my team to tackle the truly hard parts.

Pairing with another developer is incredibly valuable. We express our thoughts out loud, forcing each of us to clearly explain our plan of attack. We help each other past road blocks, and if can pull each other back on track if we start to wander off down a dangerous path.

 

I like the idea/view on this problem. I fight with the same. I actually allowed myself to make imperfect solutions. I think it is good to note this - that yo may be too much focusing on ideal solution. I understand your point of view and I agree, but most of the time it is connected to the perfectionism too.

If you are 100% it is not your problem, I congratulate you, cos you are very productive :)

 

Awesome post! I can relate to constantly feeling that I am not working fast enough, like I am thinking too much, about everything. But I do choose to feast on those huge slimy frogs first and they do take a lot of thinking. I also don't show much progress at first which is why it's important to communicate openly about your progress. If you work with the right people they will always understand or even grab a fork and help you out.

 

Thank you for sharing! I too feel this. Even though I am new and graduating this December, I have often wondered if I am good enough because I work a little slower. I made the decision to take this course called Open Source Development at Seneca College and I am so glad I did. It has helped me to read multiple articles on everyone's struggles. I don't feel so bad and I feel like I am part of a community!

 

Perhaps the issue isn't that you are slow, or that you tackle the hard parts first. Have you tried communicating that to others? So in a status report you might say:

I have determined that frazzing the boz is the most difficult part of the application. Therefore I will tackle it first. I expect to spend 20% of my development time on this task.

 

Thank you so much for sharing this! Although I am a new and graduating this December, I too feel the struggle of being too slow. I chose to take this course called Open Source Development at Seneca and I am so glad I am taking it. It has connected me to Open Source contributions and blogging about my work. It has also allowed me to read great articles like this one that make me feel like I am not alone in the struggle and I am part of a community of developers that help each other!

 

Some fast devs are just hackers, i.e. they do in fact get the work done, but it’s shoddy and they didn’t uncover the unknown unknowns.

I can’t work like that, it’s just not how I was raised. Because of that I used to feel like a slow developer too. Don’t worry, you’ll get to a point where you can maintain quality and ship quickly!

 

Wow! I get the exactly same path as you! And it's often so frustrating... because it seems that we don't know what we're doing and you start doubting yourself and feeling terrible about it. But I think you provided me a new perspective now! Thank you!

 

This post is a great read. Thanks!!

 

Abraham Lincoln misquote nails it:

To Cut Down a Tree in Five Minutes Spend Three Minutes Sharpening Your Axe

quoteinvestigator.com/2014/03/29/s...

 

When I work on shared projects with others I feel the same thing. I'll try to be more conscious next time to see the reasons why inspired by your article.

 

Great post - being able to identify road blocks and critical pieces early is very crucial.

 

This is happening to me currently. It feels as though I'm the only one Not making progress. I'm trying to not focus so much on others but its a struggle

 

I'm sorry! I hope you find the confidence and focus you need to get through it. You got this!!

 

My tip: set a deadline!

And always remember about that Parkinson’s Law.