Admit that you are stuck
Photo by Markus Spiske on Unsplash
Recognizing that you are stuck may not be so obvious at first. But realizing that you are in a place where there are more unknowns than clarity is more powerful than you think. Not recognizing this can waste your time trying to make things work that aren't as necessary.
Not because you don't know how to do something and can't figure out how to get it working in 5-10 minutes, which means you're stuck. Getting the definition of "getting stuck" wrong and not trying any more could hurt your ability to solve problems in the long run.
Do not panic
Photo by Jasmin Sessler on Unsplash
First things first: don't panic. You understood. Mistakes aren't something to be feared or discouraged - they are actually learning opportunities! So take a deep breath to calm yourself down before trying to free yourself using any of these strategies.
Calmness is the first step to becoming a positive person. Have confidence in yourself and your problem-solving skills. You can find out, and it will be much more enjoyable if you do it in a learning and growing mindset.
Read error
Photo by Brett Jordan on Unsplash
Take the time to read the error you received. Not reading the error carefully or not understanding the error is a common mistake beginners make. By understanding the errors you receive and connecting the dots between each error message and the solution to the problem, you gain valuable programming skills.
Check your spelling
Image by Lorenzo Cafaro from Pixabay
Some of the most common errors we see have to do with spelling and syntax. It means that we misspelled or mislabeled something somewhere in our code. An example would be if you forgot to put quotes around your string. The code can't read your mind and doesn't equate String to "String" as expected.
Other common syntax errors are:
- Incorrect use of parentheses and braces
- Using the wrong number of equal signs
- Using different cases
You can avoid many of these mistakes by sticking to your conventions. An example of this is to always capitalize the first letter of your variables - that way there are no case errors.
Try to program using the style standards of the language you are using. Style guides help reduce the error rate by making your code more readable, making it easier to find errors.
Verbalize the problem
Photo by Alena Jarrett on Unsplash
Another helpful strategy to break free is to speak out loud about your problem. Your problem could be a section of code you're working on, a problem you're solving for a client, or even a personal project. Make sure you know what the result should be.
By speaking out loud, you begin to solidify in your head what you are trying to achieve. Then you can go back to your code and find out if it actually does what you want it to do. If there's a piece of your code that doesn't help you achieve your goal, that's probably where the mistake lies.
Break the problem
Photo by Pankaj Patel on Unsplash
If you think of your code as one big block, it can seem like a huge undertaking to track down a flaw. But if you break your code into smaller chunks, each of which performs a small task, it will be much easier to understand where the error is.
As discussed above, if you take the time to read and understand the error message, you will know what kind of error you are looking for. You can also use the verbalizing hint to talk about what each block of code does and whether that particular flaw might be in each block of code.
If you are still stuck, you may need to run the code backwards. This means reversing each step of the code until you find the error. This tip is especially useful if the code in the previous sections worked correctly. Chances are the error is at the bottom, so you will find it faster by working in reverse.
Search on Google
Photo by charlesdeluvio on Unsplash
Even though we said there's no magic button to help unblock you, sometimes Google is a pretty close alternative.
Be as specific as possible when using Google to break free. You can copy and paste your error message directly into Google and then see the search results that apply most to your piece of code. If the returned results aren't helpful, think about how to rephrase your search to get you closer to the solution.
Ask someone else the question
Photo by Emily Morter on Unsplash
There is nothing wrong with asking for help or taking another look at our code. While junior programmers often ask more experienced programmers questions, there's nothing wrong with having 15 years of experience and you're asking someone who has a few years of experience behind them.
It's complicated to know everything in the world of programming. There will always be something that someone knows that you don't know. Sometimes it's surprising to see where some of the best answers come from and some might come from people you never thought they could.
Ask your questions in the forums
Photo by Chris Montgomery on Unsplash
Many programmers look for other solutions to common problems, read the StackOverflow and GitHub forums, but never ask a question. There can be various reasons why many do not.
Some people are afraid to ask questions in public and risk being called unintelligent. However, it is sometimes surprising how many people ask the same question as you.
Others don't do it out of laziness. We get lazy by doing certain simple things without realizing it. For example, some programmers don't ask questions in forums because they don't have an account on that forum, even if they visit the forum over and over again. Creating an account is fast. However, the desire to look for similar questions leads you to not even try to post the question. In other cases, programmers need the answer right away and can't wait for someone to answer the question on the forum. Asking the question on a forum and working on it at some point while getting answers can be the most efficient use of your time in some cases.
Check the documentation
Not everyone does this at first. However, documentation aims to provide a single source of truth about how a programming language, library, framework, or architecture works. Spending some time reading the documentation will give you a better understanding of how things work and give you ideas on how to tackle the same problem using different approaches.
Take breaks or walk away
Photo by Alejandro Luengo on Unsplash
When you've tried different things and researched a lot of information, but still can't get things to work, you become tense and stressed. Taking a break is the best choice right now. Taking a walk or getting away from your computer are simple but effective ways to clear your head and relax.
You can choose to escape, but still think about the problem you can't solve. The main difference here is that you're not looking at a screen reading your code or online information that after a while makes it difficult for you to think clearly. Being able to place information in an environment with little or no distractions helps a lot in finding solutions. Just be sure to take a pen and paper with you to write it down when you meet him.
Let it go
Photo by Samuel Regan-Asante on Unsplash
There have been instances where the software has a certain bug which is never fixed as it does not affect the user experience or affect the business logic. Other times it's a bug that no one on the team has been able to fix before due to its complexity.
Whatever the reasoning, it's okay to not go ahead and try to make something work. You may not feel comfortable with this at first since you as a programmer want things to work. However, sometimes the best decision is not to insist on making things work that shouldn't work.
Gratitude for perusing my article till end. I hope you realized something unique today. If you enjoyed this article then please share to your buddies and if you have suggestions or thoughts to share with me then please write in the comment box.
Top comments (4)
For me no 1 - go to toilet :) solves so many issues just by walking away and come back...
No 2 - ask for help. As soon as you start trying to explain your issue to someone else, you will find many flaws
No 3 - rule of 4 eyes. What you dont see after several hours is often immediatly visible to a collegue or friend. Ask for their help
For rule #1 - yes, absolutely! When I were smoking, this helped a lot - while smoking a cigarette, you have time to distract and think about problem from new point of view. When I stopped smoking, brilliant ideas often comes when I'm in toilet....
Also, log files. If you work with someone else code - enable more and more verbose loging and try to read it. When you work in your own code - add logging messages everywhere, and one of thousand log messages will surprise you.
I have to admit, I still var_dump / echo / console.log A LOT :) never get used to debugger, console.log on the right place tells me much more much quicker :)
Great points. Coding often is a frustrating process - like all problem solving. Following these advices with patience is a must.
My personal favorite routine is to take a long walk in the nature.
Even if you not thinking - your brain does.