This is a Good Error

*If you're looking for the original, more in-depth 2023 Laracon Talk on this topic, "Getting Unstuck" by Joel Clermont, check it out on Youtube!

No, I'm not a sports coach, a psychologist, or a monk, but your mentality, your attitude toward getting stuck, is the first, and most important step to unstucking yourself.

Getting stuck is inevitable. Eventually, you will not know something. Eventually, you'll get tangled up in your own web of clever abstractions. You'll look at the screen in disbelief, thinking, feeling, "I've tried everything." For me, the feeling is a hot, frantic, silent scream flowing from my spine into my brain--and even though my mind is anxiously fast, time goes even faster; my mind ricochets through reiterations of every possibility, every failed strategy, like a Sisyphean pinball game. It's a lot like being "in the zone" except the zone is hell.

It took many, many such occasions for me to begin to recognize this pattern. Unchecked, this feeling can turn into hours of swimming in circles. But the sooner you become familiar with its emergence, the sooner you can break free.

So, how do you adjust your mentality, practically?

• Develop awareness to recognize when you're spinning your wheels
• Have a growth mindset

How do you come to recognize your own patterns?

Thunk is famous for its retros. Everybody's talking about it. Retros expose what's working, what's not, and something even deeper: that, oops, we care about each other. Practically speaking, having this type of self-reflection baked into your process allows you to address struggling outside of the struggle.

If you don't have a team or they don't do retros, writing about your coding experience/patterns, and revisiting that writing, will help.

I won't go in-depth on growth mindset here, but it's a way of reframing hard problems as rewarding challenges.

"This is a good error." -- Daniel Coulbourne

"Just come along for the ride." -- Jeffrey Way

Both of these quotes have inspired me greatly.

The first time Daniel paired with me (to get my very first dev environment set up), we encountered errors here and there. Instinctually, I got frustrated, and I wasn't even doing the work yet. But I noticed Daniel didn't. And when the error messages started changing, he even said that they were good--because, yes, we were "stuck", but we were moving.

You can look at an error, or a problem, as defeat; but you can also look at it as an indicator of an opportunity to grow. Getting stuck gives you a path, a direction to explore.

At Thunk, I am easily the dumbest person in the room. But it means I have the most to gain, the most to learn, from being in a room full of smarter people--and that is exciting to me. New programming concepts can be complicated, confusing, seem backward or inverted, or be otherwise unintuitive. But if I can come along for the ride, and trust my team, over time and effort, the fog will lift. Thanks Jeffrey.

Once you can take a step back from the whirlpool of being stuck, and start to see it as an opportunity for growth, you can implement actionable (and inactionable) steps to help you through:

• Explain your problem
• Make it simpler
• Take a break
• Have a Daniel

Explaining your problem, through writing, or talking (to yourself, a friend, or a rubber duck), is a great way to focus in on and isolate what you need to do. It can reveal new angles of attack, help communicate the problem to other people, and help you understand it again later if you need to come back to it.

When I'm stuck, sometimes it's because I don't fully understand the materials I'm working with, but this usually only surfaces clearly when I try to explain it. This can be discouraging, especially if you've faced a similar issue before, or if the duck becomes disappointed in you. But, this is an opportunity to develop a deeper understanding of your codebase and tools. Reading docs, forums, and iterative questioning with AI (or a patient friend or saint) can help here.

Sometimes you can't establish whether being stuck is due to the new feature, or the old codebase, or both. The custom bells and whistles, and the 7 steps of UI interactions you need just to set up the problem, get in the way. Use a playground, or a bare bones repo, and replicate a minimum viable version of your problem. This type of variable isolation has made certain interactions way easier to grok.

Something I've been doing lately (where it's possible): throw everything into its own test. Go ahead. You can make a class directly in the test. You can put a migration in the test! There are some limitations here, but for me, tucking as much logic as I can into one file helps to see the full scope.

I hate taking a break. To me, breaks feel like defeat. But, adjust your engineer hat (I picture an old-timey, sometimes lego, train engineer): taking a break is efficient. You can sometimes cheat by simply pivoting to a separate todo.

As a performer in improv comedy, I will sometimes struggle in scenes when my character remains stationary. For many of us, a mental blockage is tied to a physical blockage. Veteran improv teachers taught me that physical movement, even just picking up a coffee mug or throwing away a piece of trash, could give you time and generate momentum to move the scene forward. Even just moving through a small, rote task might give your brain the break it needs to jump-start again.

Like how going to the restroom seems to summon your waiter to take your order, once you've pressed "send" on a humble appeal for help, it often seems to summon the solution out of thin air. If that doesn't occur, hopefully you've sent your SOS to a Daniel.

Everyone needs a Daniel. A Daniel (machine/psychic) will spelunk deep into the earth's core and submit a PR to God's repo just to fix your problem. But seriously: community, and the humility to ask it for help, is everything. And if you don't got it, you can buy it, here: thunk.dev (see mentoring).

I sincerely hope you found this helpful in some way. If you have methods not covered here, great "How I got unstuck" stories, or need a Daniel (or a Thunk), let us know here: thunk.dev, or share with us on our Twitter!