As a beginner there will come a time when you will write something that either has a bug, doesn’t work properly, or just won’t run/compile. It will seem no matter how hard you try, you just can’t figure it out and you’ll feel absolutely stuck. So what do you do when you’re stuck? I’ve seen this many times while mentoring beginners software developers who have just started programming. Here’s my list of 10 things to do, when that moment comes.
1. Read the whole error message!
I know this sounds silly, but sometimes beginners just look at error messages and don’t bother to look through the whole error message, including the stack trace. Looking at the stack trace can give you insight into where the error is happening and possibly what other file called the error. This allows you to piece together the whole problem, and gives you a broader picture besides just where the error is happening. Sometimes, the point at which is the code is failing isn’t always where the code needs revision.
2. Google the error message!
Sometimes the error message may not have that much detail and in some languages, may not even make sense to you. In these instances, copy and paste the error message into Google and see what the results are. An important tip is to make sure to leave out anything that would be specific to your programming environment. For instance, if there’s a path that’s shown, leave out the path.
3. Print stuff out on the screen or in the logs
Just start printing out values on the screen/log wherever applicable. If you’re going through a loop, throw logs before the loop, on every iteration of the loop and at the end of the loop. If you’re calling a function, print out the values before you call the function, while you’re in the function and the results of the function. Print out as much as you can to start figuring out what is going on with your code.
4. Take your best Guess!
When you start you may have an intuition on where the issue is. Add logging around where you think the error might be. Definitely try things out on our own before asking for help! Sometimes beginners are scared to break things even further, but part of getting better is just making the attempt. Make sure your code is saved and revisioned, and try!
5. Go back to a point where the original code was working
Go back to a point in time where your original code was working and then add your changes one at a time. Do step #1 and add logging all over your code. Then start making the changes one at a time while compiling/running your code on every change. Examine the logging to see where you might have gone wrong.
6. Comment-out code
Start by commenting out your code in different points and see if you can predict the outcome and variable values. If your predictions aren’t right, then start to explore why. Look at the code before and after your comment to see what was going on. Make sure to add logging to see the values before, in and after function calls.
7. Step through debugging
One of the best ways to find your problem is to use a step through debugger. Most IDE’s have this and the icon is generally a little bug. Add breakpoints in the code where you think the problem might be and see what the variable values are when you loop through. This allows you to see what exactly is happening and allows you to explore different variable values while the program is actually running. If something doesn’t seem right to you, rerun the program with a breakpoint higher up in the code. As you get more advanced, this actually becomes the first thing you do when you hit a hard problem that you’re exploring.
8. If you’re not sure where the problem is, start cutting your code into halves
If you have a lot of code and you’re not really sure where to start, break the code in half by adding logging or breakpoints in the halfway point and the end of the code. Try and predict the values in the first half of the code vs. the second half your code. If your predictions are coming out wrong in the logging at the half way point, you know that the error exists in the first half. Now cut the first half of your code in half again and add logging at the beginning and at the quarter way point of your code. Keep going until you can pin point where the error is!
9. Take a break and walk away from the keyboard
Sometimes the best way to solve a problem is to stop working on it!. Why is that? Your brain learns in two modes, focused and diffused. Focused is when you’re concentrating on a problem, and diffused is when you’re relaxed and not thinking about the problem. In diffused mode, the brain is building and processing the information in the background and allowing the connections to form. This is why there a lot of stories where the person is not focused on the problem and they’ll suddenly have a “eureka” moment. A great class I recommend on this is the Learning How To Learn class on Coursera.
10. Ask for help
Last and certainly not least is to ask for help. However, this should be your last step. Most people willing to offer help don’t mind helping, but it’s really frustrating when the person needing help hasn’t tried anything, not even googling. It makes it seem like they’re asking you to solve the problem for them, instead of helping them. When you do ask for help, make sure to detail out everything that you’ve already tried and what the results were. Also, make sure to include all the relevant source code and config files that pertain to the problem. Make sure to say ‘Thank You!’ when the person helps you.