Accepting Failure In Your Code
I hit the fourth module out of five in my coding bootcamp and everything started going insane. We had been forewarned by alumni that many of them found Mod 4 to be the hardest, many failing the assessment test that comes with each mod and needing to retake it. Then, as I had just started adjusting to the shift from on-campus to remote, I was hit with an internet service outage during the heaviest learning phase of the mod and couldn’t even attend the lectures. I lost two days out of five in an already super-condensed curriculum. I felt the pressure of a neutron star in my head.
But, at the expense of moving past Asian stereotypes, I welcomed a good challenge. I did what I could to make those days productive, attempting to make sense of the labs that I could access without the guide of context from the lectures. It was rougher than ever, and I knew that the only thing I could do was slam my head against my problems and hoped they broke down before I did.
The struggle was real, let me tell you. But what is a gain without a little sweat? I activated my hyperfocus mode, the redline, “that” which must not be used, and clung on to the material just enough to handle the Mod 4 assessment test handily. But in addition to the material, I also took notes on the way I was handling the learning itself. I appear to some of my cohortmates to just “get it” and have the “right kind of mind” for programming, but I assured them that the only way I get to where I am is through frustration, perseverance, and willpower. Nobody just “gets it” the first time. Well, except this one girl in my class who might as well be Isaac Newton.
As for the rest of us, our journey to learn requires being comfortable with failure. One of the hardest parts about coding is how dumb it makes you feel. Maybe you’re working on a solo lab and somebody asks you how you did the bonus deliverables while you’re getting a 404 error on the second step because you didn’t read the readme. Or you spend an hour trying to pinpoint at exactly which point your redux flowchart your code is breaking at but everything looks right, until you realize you used forEach to render your HTML elements instead of mapping over the array. And then there’s all the errors that pop up. All the scary red text that tell you you did something wrong.
But if there’s ever a secret to getting into coding, it’s that you need to conquer your fear of failure. Yes, failure is scary. If you fail to pass your tests in high school, you get scolded by your parents. If you fail at your job, you get fired. If you fail at impressing that girl you had a crush on for years, you get embarrassed for decades. And if you fail to find food for your tribe, you risk the lives of your fellow tribesmen. Fear was vital for the survival of our species way back when, but it has no place in the confines of your terminal and your browser console. One of the most critical aspects of a good programmer is how well they handle errors.
Errors are clues that guide you to the solution. They are the hints that the sphinx dares not give. Errors will happen. And they should. In my earlier days of learning programming, if my code didn’t work the way I wanted it to, I would panic, overcorrect my code, and get frustrated. Now, whenever I get an error, the first thing I do is read the error message and try to figure out exactly what it’s telling me. If I have a page that is supposed to display data after fetching to an API but isn’t rendering anything, I might check the HTTP response codes. 500 error? Maybe the API key is busted and I need to generate a new one. I plug in a new API key and get a different error message: cannot read property ‘map’ of undefined. This is great news, because even though my problem isn’t solved, at least I know my API key was the previous issue and I’m closer to where I need to be. After throwing in some console.logs, I can see that data is coming in from the API in my main component but is coming up undefined in my child component; I forgot to pass it as a prop.
This cycle of addressing one small, specific error, making an educated guess, and testing one small, specific change in code, then moving on to the next, is key in debugging your code. It can be tedious and it can be frustrating, and that’s okay. Coding isn’t easy; that’s why companies pay the big bucks for a good programmer. They need someone who can deal with the struggle of getting through their own errors. The only way to get good and to be efficient at coding is practice. Practice as much as you can, experience as many errors as you can. The more errors you experience, the more educated your guesses are as to what the solution is and the better equipped you’ll be the next time that error shows up.
An expert is a man who has made all the mistakes which can be made, in a narrow field. ~Niels Bohr
Nobody likes frustration and it is going to happen. What you have control over is how you handle it and how hard you push through it. Keep trying different things; eventually something will work. The super-braniac cohortmate I mentioned earlier isn’t actually a machine, she’s just extremely good at immediately trying different approaches to fixing her errors when she hits them. She is efficient about solving her problems. We can all learn from her, but everyone has a limit. It’s okay to be frustrated, and it’s okay to take a break. And when we come back to our desks refocused and re-energized, let’s remember the wise words of Jake the Dog:
