1 to 3 minute read

There's nothing wrong with searching for help on the internet. It can save you a lot of time and even can help you learn. However, if overdone, can lead you to being over reliant on tools like stackoverflow.

Sometimes, stackoverflow just doesn't have the answer. Or sometimes, you can't use it at all (job interviews for example).

This is why it's so crucial to learn to fix the bugs yourself without needing any external help. In addition, if you're the competitive type, it's the best way to get ahead of other programmers (it's become a meme that most programmers can't code without Stackoverflow)

This also includes other websites and tools such as ChatGPT. We are talking about the use of external tools vs using your brain to fix an algorithmic error. Not just stackoverflow.

The 15 minute strategy

Balance is key.

Instead of copying and pasting the bug showing up on the compiler or interpreter into your favorit search engine, first spend 15 minutes trying to fix the bug yourself without looking anything up. If you forgot something like what the name of a certain method is you can look up the documentation Because you can't just "solve" such a problem as it requires knowledge of how the programming language's developers developed the programming language you are using. But when it comes to an algorithmic error such as an index error for example, you shouldn't fall for the temptation of looking it up on the search engine.

Over time, this will train you to be less dependent on stackoverflow and other tools.
However, there are 2 terrible mindsets you should be aware of, that if you are not aware of how to deal with it, can waste hours upon hours of your valuable time and crush your attempts at debugging pretty much any code.

Bad mindset number one: First writing the code, then solving the problem

First solve the problem, then write the code.

This is so important we even made a mug about it to remind ourselves of this every time we get emotionally involved with the bug and start maniacally typing away lines of code in desperation to fix the bug.

But how do we "solve the problem" exactly? What mental process must we go through?

Just remind yourself of these steps to solve any problem when coding:

First, understand why the problem is happening:

Through testing, re-analyzing your algorithm, and understanding the error message. Don't hesitate to journal your thoughts on a piece of paper or text file. You can use print statements to test your code.

 

Second, come up with an hypothesis of what the solution could be:

Like a scientist, come up with a credible hypothesis as to what could fix the problem.

Third, write the code:

This part should be the shortest. After coming up with your hypothesis, write the code.

Fourth, test your hypothesis by running your code:

If it runs smoothly, then move on. If not, repeat this process.

This mindset change alone can help you greatly in your development projects. However, by far, one of the most important mindsets to adopt is the second one...

Bad mindset number two: getting emotional and getting stuck in "the loop"

"Did I ever tell you what the definition of insanity is? Insanity is doing the exact... same fucking thing... over and over again expecting... shit to change..." - Vaas, Far Cry 3

 

This happens all of the time, especially when stackoverflow has no clear answer. We get emotionally attached to the bug, and we keep looping over the same potential explanations and potential solutions for the bug.
Programming can be confusing and, even, at certain times, very frustrating.

This is not specific to programming: even chess players can experience this.
Chess grandmasters will, when running in circles in their minds, "refresh" their thought process and minds by looking away from the chess board and thinking of something else. Then, when their minds are refreshed, they'll return to the game with a new perspective.

The same can be done in programming. Except you don't have to do it for a couple seconds (unless if you're competing in an arena). Ideally, you can walk away and do something else of importance for 30 minutes to an hour.

It'll allow you to calm down and get a new perspective of the problem and your code.