The Art of Unblocking Yourself
July 01, 2025 | 4 minute reading time
You’re staring at your editor. The code should work, but you’ve been fighting an error for a full day. You can’t figure out the problem no matter what you try.
Or you’ve been staring at an empty file, wondering what code to write. You’ve got a vague Jira ticket, a lack of context, and a codebase that is difficult to understand.
You’re blocked.
Now, what do you do?
It’s tempting—easy, even—to ping someone hastily. You drop a question in Slack like “Anyone seen this error before?” and hope someone tosses you a lifeline. Or it might be equally tempting to throw prompt after prompt at AI, hoping for a different result.
In this article, I want to describe some tools for overcoming obstacles in these situations. As you grow in your software engineering career 1, this skill becomes more and more important as you’re expected to work with increasing autonomy.
Let’s dive in.
Reading is a Superpower
The fastest way to unblock yourself is often the least glamorous: reading. Lots and lots of reading.
- Read the stack trace or error if you are getting one (don’t just toss it into Stack Overflow, Chat, or other AI tools)
- Pull up the language/framework docs to understand the nuances of whatever component you are attempting to set up
- Dig deep into your codebase, reasoning through how each bit of code works
- Search your company Slack, Wiki, etc. to learn if others have encountered the same problems you have
There aren’t any shortcuts to this one. And that is the point!
You won’t improve your technical skills and library if you give up on reading technical documents. You won’t level up your coding skills without reading lots of great code from other engineers. You won’t learn to understand business context if you gloss over quarterly business reviews.
Learn how to teach yourself new information by reading, and you’ll improve your ability to unblock yourself.
Change It Up
Sometimes, you’re not stuck because you are struggling to find or grasp new information. You might be stuck because you’ve been working on the same problem for so long that you can’t reason through it anymore. Or maybe you’ve simply been too distracted by notifications that you can’t refocus.
In these cases, you need to change something up. You need some form of disruption before you can refocus.
Here are some ideas that have worked well for me:
- Take a screen break. A few minutes of no screen time can be incredible. Take a walk. Sit outside. Sit inside with coffee and stare at the floor. Your body and mind will thank you.
- Rubber ducking. Explain the problem to someone—or something—else. Out loud. You’ll often surprise yourself with the answer mid-sentence.
- Whiteboard. Draw the execution sequence on a whiteboard. Step through your code line by line on the board, tracking important state. It’s incredible how quickly a visual of the execution will spot the wrong transition in the state.
- Change the question. If “Why is this broken?” leads nowhere, try “What would need to be true for this to work?”
- Log one more thing. If you’re debugging, print something new. Check a different assumption. Try the “dumb” idea. Sometimes the fix is just outside your current field of view.
Changing your process, environment, or mental state can sometimes be all that is needed to achieve a breakthrough.
There is a reason so many people talk about “Eureka!” moments in the shower: their brains were in a different environment, their bodies were relaxed, and they were making novel connections between seemingly unrelated information. It’s hard to be in that state when hunched over a screen for too long.
Changes things up when you are stuck and see what happens.
Asking for Guidance
Of course, asking for help is still part of the process.
Unblocking yourself isn’t about being able to do everything on your own.
Unblocking yourself is more about taking the initiative yourself vs. waiting on someone else to do it for you.
When you do ask for help or guidance, the way you ask is also crucial. Asking questions like
“This is broken. Does anyone know why?”
is sure to get little attention.
Ask a question like this
“I’m encountering an odd problem. I’ve tried reading docs A and B, which led me to try ideas X and Y. I’m still running into some trouble, though. Has anyone seen this before?”
and you’re likely to get help. You’ve signalled “I’ve done the work” vs. tossing a poorly formed question into the void at the first sign of friction. Not only will you get responses faster, the answers will be better because of.
Another effective pattern I’ve observed isn’t asking for a particular answer, but rather seeking guidance on a specific problem.
For example
“Has anyone used technology A to solve problem X?”
will likely get a lot of “No’s” or shoulder shrugs. It very well be that no one has used that technology to solve that problem before, so you stay blocked in wondering if it’s a good idea.
If you ask for guidance, however
“I’m trying to work on a solution for business problem X. I’ve started thinking about approach A and B. A requires using some of our new tooling for async workers, and I’m curious if anyone has some guidance on if I’m thinking through how to use it correctly. Does anyone have some insight or guidance on this?”
you’re much more likely to get perspectives, opinions, etc. from others. And that is what you are searching for: guidance to help you move to the next part of problem solving.
Learning to ask better questions is how you get better information.
Final Thoughts
Unblocking yourself is a skill.
It’s not about going solo or never asking questions (as we’ve seen, asking the right question is unblocking yourself). It’s about building the muscle of understanding. Learning how to explore a problem, how to shift your perspective, and how to reach for the right tools at the right time.
It’s a quiet kind of power. And over time, it makes you a much stronger engineer.
Happy coding!
- Though this advice can apply to many different careers↩
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.