Every so often, you get into a rabbit hole. You start working on a new issue. You have a rough plan in mind; it should take a few days. But on every step, you discover another problem to fix. It’s as if the deeper you go, the more complicated and messed up your project looks.
It can happen over a few days or even a few weeks, and that’s dangerous because you might not notice it, but you are in a Task Tunnel, and you might exhaust yourself.
It happened to me, maybe once or twice every year.
It feels terrible, you’re stuck, you’re not making progress anymore, and you are burning your brain on something that should be simple. Often it’s accompanied by decision paralysis: should I keep going? Should we throw everything out? Can I get rid of this and pass it to another colleague?
Here are a few bits of advice that do not involve writing more code. The problem might be beyond repair. Our current approach does not work, so we need to take a step back.
These are the steps that have been very useful for me over the years:
This one is important; you are not in this tunnel because you are a bad developer or not fit for the job. It’s likely the opposite: you are trying to do a good job, and that’s why you are stuck.
The issue you are trying to fix might be ill-defined. It might be out of your expertise zone. It might require taking decisions that are not up to you. It might not be worth it.
Take a break, get some fresh air, take a step back. Then follow the rest of this plan. Don’t overthink because you might be out of thinking juice already.
As professionals, we tend to present a version of our work that is perfect. We exult confidence, and we try to make everything look easy. It’s even worse now: we work remotely, and we can’t sense each other. Someone on the team might be tearing their hairs apart and pest at their screen. But if everyone is remote and we present our best during dailies, so you can’t tell. And the rest of the team don’t know either.
Remember that even if you’re in an organization that doesn’t tend to share failures, everyone struggles. That’s ok. And that’s ok to share about it too.
I’d share something like:
I’ve been making very little progress on X for the last Y days and it’s wearing me out. I’m writing a quick summary of the issue so that everyone can chip in. It may take a few days.
This message allows teammates to hop in and help. If they can help immediately, they might share more context about the task. And at least it’s clear to everyone that there is something to be fixed and the team must assemble to help fix it.
First, congratulation, writing down a diagnostic, and communicating about your work is always useful. This write-up is an opportunity to grow and refine your soft skills. It might even fix your issue.
These are the sections I use and that help YOU lay down the problem and the TEAM act on it. It doesn’t have to be perfect! Just add enough context so that other members of the team can start asking questions.
Make it clear to everyone, even if they are not working on the task.
It might feel like you haven’t progressed, but you did. Failed experiments and failed attempts are experiments and attempts anyway.
“I assumed I would have to…” “I assume going this other way makes no sense because…”
“Here are the things taking my time now: …” “Where I’m not making progress: …”
“These are the components, features, systems that are interacting with the issue and making it worse.”
These questions are a starting point for a discussion with your team. Write a quick draft, don’t try to answer them.
Is it still worth it? Don’t let sunken costs fool you, if a task double in complexity it might lose all priority. “After working so long on X, I’m questioning if we should keep doing it.”
Can we reframe the issue? “It seems that getting rid of X might make it smaller.” “Or we could just implement Z and validate that it’s worth doing the rest.” “Maybe we need to refine the success metrics.”
Who should get involved to help me with this? Throwing a task at another colleague sucks. But let’s be pragmatic. Maybe there is someone who can help or who might be better equipped to deal with the issue.
Especially if you are working remote.
Share your diagnostic and propose a peer programming session with one or two colleagues in your team.
If you’ve never peer programmed before, try now. Even if you don’t solve the issue, you can bounce ideas at another brain and discuss your progress. Now you are twice as strong, and you can add more details and raise more issues in your diagnostic document.
Every time I got stuck, I rediscovered these three steps. From my first year as a developer to today. I hope this will join your toolbox and prove useful.
Let me know how it goes,
Subscribe below to get more bits of advice and content on Lean Software Engineering for Makers.
Founder of Singulargarden, I help my customers release products without creating giant piles of code.
I worry about overly-engineered software, and I hate seeing people waste their time and money. I help junior
and senior teams validate their products with lean and frugal architectures.