At some point while sitting at our desks, we’ve all experienced code fog. It’s like a mixed feeling of confusion, frustration, and exhaustion. Code fog happens when you’ve tried to compile your code and it’s just not working.

You’ve chopped, changed, and Googled your way through every possible link. You probably have even made it to the 12th page of your Google search.

Code fog is notorious for causing imaginary table-flips and no — you’ve checked — it’s certainly not caused by a missing semi-colon. It’s something deeper and you can’t quite figure out what.

Rather than force yourself through the painfully unproductive process of debugging, here are some things you can do to help cure your code fog and gain a sense of clarity once again.

Why Bugs Happen

Bugs happen because there’s a gap in our knowledge. It’s also the main reason we instantly turn to Google when we get stuck. But oftentimes, the answers that Google gives tend to be snippets of something bigger. Sometimes, the gap in your knowledge is so big that looking at snippets is simply not enough.

You need to take a step back and look at the bigger picture. What does this mean? First, you need to identify the type of issue you’re facing. Is your code overly complicated? Then it’s a programming pattern issue. Is your code not working the way it should? Then it’s a gap in your understanding of the framework or library. Is your code not compiling? It might be a dependency issue.

When you have a programming pattern issue, the quickest cure is to slow down and look into functional and OOP patterns for your chosen language. If you’ve got a framework or library issue, then you need to look into the wider topic surrounding your issue. If it’s a dependency issue, you’ll need to trace the relationships and versions to figure out where the blip is.

Don’t try to look for a solution, it’ll continue to give you tunnel vision. A big-picture approach can lead you down a very different road from what you’re currently experiencing.

Sometimes, You Just Need a Break

As developers, our brains can get stuck in a funky loop and cause tunnel vision towards our code if we’ve been working on it long enough. We start to see only what we want to see. When this happens, you need to give your brain a break from the issue and go work on something else. A 12 to 24-hour quarantine from the problematic code is usually enough for most of us to properly disconnect and come back to the issue with fresh eyes.

According to the Science of Learning Journal, when we become frustrated or fearful, the part of our brain known as the amygdala kicks in. Based on past conditioning, it only makes us aware of the immediate threat — which in our case is the problematic code. The more we focus on it, the more we become entrenched in our own created mental boundaries and fail to see any systematic connections that may be contributing to the bug.

So take a break — go and do something else, then come back to it with a different attitude and mindset towards your code.

Seek a Second Opinion

One of the perks of peer programming is that there is always a second opinion on your code. As a developer, we may think of our code as infallible, however, another pair of eyes with knowledge of different topics and past experiences have the ability to inject an alternative perspective.

Most of the time, we work on our code alone, but when bugs arise, and before your brain becomes overly fixated on them, ask a colleague for help. Just have them to come over and review what you’ve coded. Get them to ask you questions about the code.

They don’t have to solve it for you — but their questions can lead you down a different path towards your solution. Everyone has their own flow of thought when it comes to debugging and chances are that they’ll think differently from you.

Final Words

Code fog happens because you get stuck. To become unstuck, you need to do something that is different from what you’re currently doing. You can’t expect a different output if your input remains the same.

Code fog sucks but it always eventually clears. You just need to be patient with yourself and work on constantly expanding your domain of knowledge. This is because you never quite know when something seemingly random will come in handy. It’s also one of the best ways to prevent code fog in the future.

As Steve Jobs once said in his Stanford commence speech —

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.