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.
Top comments (49)
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.
Thanks!! :D
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.
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.
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:
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.
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 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 😁
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.
Really great article Steven. Your strategy is so counter, in the best way, to modern dev organizations. Refreshing.
I'm curious – have you spoken to your team members on this? Do they experience your "slowness" as you do? Also, do you and your team plan sprints or work differently because of your strategy? And if so, how has that affected overall team culture and work?
Thanks!
I am a pretty open book when it comes to my struggles - I've definitely talked about this with many teammates over the years. Most of the feedback I get is supportive and positive, and many have pointed out (as many have in these comments) that in the long run, what I feel is "slowness" leads to work being fully complete faster. On the other hand, I've also gotten feedback to show my work more often and communicate progress better, and I'm working on those improvements.
I do think work is planned differently based on who is leading it. Projects that I'm leading end up with the more difficult challenges split into their own stories instead of rolled into others. If we're building an interface that has 5 subsections to it, some projects will have all 5 rolled into one story. If it's a project I'm leading, my preference is to break that into at least two stories: one that proves the connectivity end-to-end (and includes 1 of the 5 sections), and one or more stories for the remaining 4 sections. In contrast, I've taken a more supportive role on projects led by others where all 5 were rolled into one story, and that's definitely a place where I've struggled with my slowness and felt like progress is hard to show until it's basically almost done.
"how has that affected overall team culture" - that's a very interesting question. Autonomy is very important to me, and it's something I push for on every team I'm on. This means different projects can be worked in different ways, based on who is leading them. I could see a lack of uniformity being frustrating for people who like consistency. I like my teams to feel like people have control over how they think about a problem or build something, though.
That makes total sense. A huge and hard lesson of leadership is removing yourself from how people get to solutions – a lot of folks have a penchant to control the whole process versus managing the solution.
I'm interested to see how organizations and cultures start to evolve for all kinds of work methodology and speed.
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.
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 :)
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.
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....
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 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 :)