First Rule of Coding: Don't Panic.

by Dr. Monroe Mann, PhD, Attorney, MBA, LLM, ME

Here is the first rule of coding: Don't Panic.

And here is the first rule of debugging: Don't Panic.

All of us coders go through periods of "Awesome! It works! I'm amazing" and "Oh no! It's broken. I can't figure this out. I'm a failure."

Am I right? If you're a coder, you know I am right.

About six months ago, I didn't know how to properly debug something. I assumed something really hard was going to be really easy. I assumed something really easy was going to be really hard. I didn't even know where to start.

Well, all that's behind me. First, don't panic. When you panic, that's when your brain stops functioning normally as a good problem solving tool. So instead of panicking, you just need to follow these simple steps:

1. BREATHE. Take a deep breath.

2. DIAGNOSE: On a piece of paper, ask yourself, "What are some reasons why this happened?" and just start writing down all your answers. No matter how crazy or stupid, just start writing. Why? It gets your out of "I have no idea what to do!" and into problem solving mode. If you are coming up blank, open up your text editor and look at each file name, and then the file itself, and ask, "Might this file be related?"

3. KEEP DIAGNOSING: If that doesn't help you figure out where the problem is, realize that you're perhaps not looking in the right place. Go through the process that a user likely went through to cause the error. Go through every link, every controller, every model, every view and ask yourself, "What could have caused this?"

4. ASK OTHERS: It blows my mind how many stubborn coders are out there. If you can't figure something out, ASK SOMEONE WHO CAN. I tell my staff constantly, "Don't be arrogant and cocky! Get over your ego! If you don't know how to fix something, say something!" Case in point: I'm a code mentor here, and yet, I also use code mentor. Why? Because sometimes I get stuck myself and my staff and I can't figure it out, so I come here, and ask for help from someone more experienced than me. So consider that: if I am not 'too cocky' to ask for help, then you shouldn't be too cocky to ask for help either!

5. TAKE A BREAK: Sometimes just stepping away from the problem and doing something non-coding related can solve the problem. When you come back, you may be surprised at how quikly you find the issue.

6. ONE MISPLACED CHARACTER CAN CAUSE HORRIBLE ERRORS: This happened to me. For days I was trying to solve the problem in the seeds.rb file. After numerous attempts, I couldn't find the problem, so I found someone on code mentor to help me. Guess what? The problem wasn't seeds.rb. It was countries.txt, which seeds.rb was referencing. Guess what: there was a - when there should have been a --. One missing dash caused rake db:seed to fail every time. Wild. And now I know: the error you get may not be telling you what you think it's telling you. Try to look beyond the error and see if perhaps there may be something else causing the issue.

7. KEEP LEARNING: Finally, part of the Don't Panic advice I shared above also leads to a simple admonition: keep learning. It's amazing how much better coder I've become in the last six months, just by doing two things: constantly learning (through books, free online bootcamps, and online tutorials) and constantly putting what I learn into practice. If you saw me six months ago, you wouldnt even recognize me as a coder. And six months from now (November 2019), you won't recognize me again. Why? I keep learning. Every day. I never assume, "I've learned enough" because the truth is: we will never learn enough. So, keep learning. The bugs you encounter today will be laughable when you look back on them in the future. Keep going. Keep coding. Keep learning. Keep improving.

Thanks so much for reading!
-Monroe

P.S. - Never assume how long something may take to fix or do. You can make an estimate, but don't assume something is simple, and don't assume something is hard, until you first take the time to really look at the issue! Too often, you can say, "Oh, that's gonna be easy to fix," only to discover that someone modified the code and now it's not going to be as easy as you thought, or vice versa. Take the time to accurately ascertain how long something will take, and when in doubt, estimate that it will be more complicated than you think. Odds are, it will be!