I have a friend who talks about programming making you feel alternately like a genius and an idiot, and every developer I’ve mentioned this to since laughs and agrees. Years ago he sent me this picture to illustrate his point:

I think about this a lot when I’m wrestling with a problem, whether it’s a new concept, bug in my code, or whatever. It’s actually a salve to my wounds, because it reminds me that whatever issues I’m having today will probably be gone tomorrow - or even maybe in the next hour.

Rassling Tactics⌗

Since I left my 9-5 last fall I’ve been working almost entirely alone on projects, and sometimes it’s scary to think that if there’s a problem I can’t solve…the problem just won’t get solved. There’s nobody there to save me - no managers, no teammates, nothing. So when the spooky spectre of failure starts looming large, I’ve started thinking about tactics for both solving tough problems and for powering through the self-doubt.

1. Take a break⌗

This is pretty common advice, but for real, it’s true. Is it the end of the day and you’re hip-deep in a seemingly unsolvable - or at least super frustrating - problem? It’s time to walk away.

Go to bed, go for a run, go play a video game - I’ve solved seemingly tough problems easily the next morning more than once. You’re not going to want to walk away, but trust me - just walk away.

2. Gauge how far down the rabbit hole you need to go before diving in (aka, timeboxing)⌗

Timeboxing was something I talked to people about a lot when I was a manager.

<puts on manager hat>

Time management is a key skill for anyone, not just developers, and in particular when you’re working through a difficult problem. How to pursue a particular line of troubleshooting can seem like a gut decision, but you can put a time limit on how long you follow any train of thought. I’ve seen people spend hours on a potential solution that ultimately bore no fruit; when you’re deciding how to attack a difficult problem, it’s imperative that you consider how long to spend on a test or potential solution before diving in.

And I mean that literally - say to yourself, “Self, if I can’t get anywhere with this in the next hour, I’m going to put it aside and try something else.” Don’t get tripped up by the “But I’m almost there” headspace (maybe you are…but also maybe you’re not). Timebox yourself, and be willing to let it go when you reach the time limit.

Also don’t forget to do any test-coding in a separate branch so if you do need to reference it later, you can. 👍

3. Don’t be afriad to use all of your resources: ask your friends, coworkers, and submit that question to the support channel.⌗

I was recently working with Clerk to add auth to a personal project, and spent 2 full days trying to figure out a bizarre issue where one component would load successfully while another wouldn’t. I was stumped for long enough to where I finally decided to bite the bullet and ask some questions in their Discord channel (see above “timeboxing” for how I maybe should’ve done this sooner 😅).

This was new for me - when I worked on a team there was always somebody who could help me with additional knowledge or simply better Google-fu. Having to describe my problem to strangers kicked my imposter syndrome into overdrive, but I eventually did it. I ultimately fixed the problem myself, but supportive folks in the Discord chat took my problem seriously and had multiple suggestions for me. It was a good experience for me and it helped get me over the hump I was stuck on.

Plus I used my former-coworker Slack space to vent my nerves to other supportive folks, so I used multiple resources for this problem!

4. Remember that this too shall pass.⌗

Remember the graph at the top of this post? I promise, your feeling of utter despair will pass. You’ll read the right article, have the right conversation, turn it on and off again and find the solution. You’re not dumb, you’re just - temporarily - stuck. It’s not forever - you’ll get there.