Jake Worth

• debugging

We’ve all seen this: a frustrated coworker hunched over a computer after hours, flailing alone against some impossible bug.

Go home, coworker. Or more importantly, don’t stay stuck.

I once took a CS course that featured an online puzzle where you had to perform a series of tasks in a seemingly random order to solve it. The solution was not discoverable without brute force. You just tried each step until something happened, and then you tried another. It was maddening, and I gave up.

The course presented this as a lesson in resilience. Sticking with a problem without clear direction. I learned that, along with an anti-pattern I held onto for years: staying stuck.

Sticking with a problem is a virtue in programming. If we all walked away anytime we were stuck, none of us would become expert debuggers. But if you’re really stuck, the process soon loses value. You’re no longer learning resiliency, you’re just feeling defeated and questioning your life choices. When you get there, I think it’s time to step away.

My advice is to timebox your solo debugging. Give yourself twenty minutes to an hour to spin your wheels. When that timebox ends, ask for help from somebody more experienced. You can still learn, because they not might want to or be able to solve the problem. They might only offer an idea. That meager crumb can be lead you back to the trail.

If you can’t get help and it’s an appropriate time, go home. Let your subconscious work on the problem while you sleep.

Don’t stay stuck.

What are your thoughts on this? Let me know!