You’re new to coding. You’re eager, hungry, and excited. Also, you are probably confused, in over your head, and stuck. These feel like the two paradigms that plague most self-learners. Coding isn’t easy. If it was, everyone would do it. It comes with a paradigm shift in the way you think, as well as a necessary technical literacy. Each line of code you write is an instruction to a computer. Communicating with a hunk of metal and electricity isn’t always easy. They can’t troubleshoot their way out of problems, or understand your intention or feelings.
Well, at least, not yet.
It’s inevitable that something you code will fail. Keep this in the forefront of your mind. Let go the notion of perfection. You will never see it. If you do write code without something breaking, something probably broke somewhere else. That’s my rule of thumb.
I see programming an application like sketching. As the pencil hits paper, you make rough lines first, just trying to get the shape and feel of the thing you manifest into some tangible form. You may erase lines and to fix certain parts of the drawing along the way, making sure it looks good. The same goes with code, through debugging and refactoring.
As you do this you are bound to compile or run your code and have it nose dive straight into an exception. So, when that happens, what do you do?
Personally I had a huge advantage while I learned to code. I had dealt with broken computers all day in my day job prior to becoming a software engineer. I was a PC technician. I repaired PCs, be it software or hardware related issues. That built up my patience and tolerance with machines not doing what I wanted. Also, it taught me how to find and isolate issues. Believe it or not, troubleshooting is a legitimate skill. It’s all about understanding where to attack a problem first to save time and also to get you the best results. It’s also about finding resources or assistance when you’ve exhausted what you can do alone.
Next time your code breaks, don’t get upset. You have to detach yourself from your intention. Stop. Take a deep breath. Frustration or anxiety will only blind you and disrupt your analytical mind from burrowing into the issue.
Also, if taking a deep breath isn’t enough-- step away from the problem. This may sound like weird advice, but it’s worked for me many times. Grab some lunch or go for a walk. Let your sub-conscious work it out. I can even count how many times I came back and was able to immediately fix something that had been plaguing me.
Read the log or the error message. If you’re new to coding, it’s important you understand the basics of how exceptions work in your programming language of choice. If seems like the computer is spitting gibberish at you, then its time to get acquainted to the stack trace.
Parse through that information and pluck out the data you need to attack your issue. If you aren’t comfortable mentally reaching into the trace, it’s time for you to add a new bullet point onto your list of learning goals.
- Become fluent at debugging as fast as humanly possible. It will only save you time, effort, and embarrassment.
For me at least it’s about 80% of the time that the issue is a simple mistake that I made typing my code or through plain forgetfulness. IDE’s are nice for this, so use one. Don’t beat yourself up for doing things like neglecting to close a bracket, misspelling a keyword or variable name, or forgetting to assign a value. Those are normal and the type of problems you can fix easily by scanning your code or investigating through a carefully placed print statement.
Another tool to consider using is a debugger. I know Visual Studio Code and most IDEs come with debugging features. There’s even debugging built into the browser. A debugger will let you step through your code and pause it at certain intervals, so you can see the state of your application.
Depending on what you’re building, you may have packages and dependencies that your code relies on. This introduces something new and potentially dangerous-- someone else’s code. That code is often tucked away, out of sight and out of mind (as it’s supposed to be.)
If possible, you can dive into third party code. But, I found it mostly a waste. Most of the time, it’s just me not using the API they provide correctly. Backtrack the package or module’s documentation. Read it, familiarize yourself. Us it properly.
When in doubt, reach for the internet and the wealth of information available there. Chances are someone has dealt with the same issue and have already asked about it.
If simply Googling fails you, time to ask someone. Keep in mind you will get more mileage and better assistance, if you first understand how to ask questions about your code. You can’t just simply state your problem and hope for someone to come along and give you an answer.
I can’t tell you how many times I’ve seen someone post a question on a coding community, where the person provides either no code to evaluate, or a blurry cellphone picture of their stack trace. As someone who likes to help others, I find questions framed like that super frustrating.
There should be four items included in any coding question you ask.
- A respectful ask for assistance along with a concise description of the issue.
- A link to a repo or code sandbox. You need as much code as will be relevant to understand the application. When in doubt and if possible, send the whole damn thing.
- Include some background on the application and technologies it uses, also what you’re trying to accomplish with it. Knowing what you intend is just as important as knowing where you’re stuck.
- Make sure there’s a list of the troubleshooting steps and resources you’ve looked at. Retrace the mental steps you’ve taken through the issue. You don’t want to waste someone else’s time repeating what you’ve done.
Those four items may seem like a lot to gather up, but they will only help. An individual can jump in and take a more surgical look at your issue. Always keep in mind that the more accurate you can describe and think about things, the faster they will get resolved.
Action Items
- Study exceptions and error messages for your programming language of choice.
- Understand the information they provide and how to use it to fix issues.
- Take a deep breath and read your error messages.
- Look for simple and common syntax style mistakes, patch those up. This will solve most of your bugs and errors.
- If stuck, step away from your code for awhile and come back to it. Utilize Google to search for answers by giving the search engine relevant keywords.
- Ask for help, but make sure your question contains the four items I listed.
Interested in learning code? Check out this brand new Facebook group.