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 wit...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
Thank you for your post. It is echoing in my mind for my all career. I think it is not a popular strategy - thinking about the hardest parts at the beginning of the task but I am able to move only that way.
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 can pull each other back on track if we start to wander off down a dangerous path.
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!
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 😁
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!
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!
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!
Great post - being able to identify road blocks and critical pieces early is very crucial.
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...
That's a great post Steven. And some great comments on this post. Thank you
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.
This post is a great read. Thanks!!
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!!
And sometimes we are slow because we are slow. Which is also ok. The amount of working hours which were wasted because of bullshit product decisions far outweigh my "slowness".
My tip: set a deadline!
And always remember about that Parkinson’s Law.