I almost failed out of a coding bootcamp — this is how I bounced back.
By: Sarah Daniels
Tags: Coding, Software Development, Learning, Programming, Life

Failing. It’s 100% inevitable, and it’s absolutely okay.

Forget about what you know and how you feel about failing. When it comes to learning how to code, it’s what you want to do. Failures slowly build you up to success.

Think of it this way: you’re a total n00b and coding has pwned you hard. It’s cool because you can respawn and try again, except you don’t lose your god tier loot or 50 pounds of salted meat with each coding death. You gain something. You just scored yourself a +1 intelligence buff and better insight on what you need to do to get this thing to work.

It hasn’t been easy for me to accept this. My current gig has a very different opinion of failing. I’m a registered nurse working in a neurology ICU and failing is a big, bad deal. Failing to do something properly could result in hurting or killing someone, losing your license, going to court, and possibly facing jail time.

We’re all taught that failing should never happen, and if it does, it’s a permanent stain on your work or academic record. It’ll follow you and probably bite you in the ass come time to apply to college or another job.

I had to learn how to go against everything I’ve been trained about failing. A complete 180, it had to be regarded as the best way to learn how things work together.

Really sucking and feeling stagnant in my progress at a bootcamp became motivation to finally change the way I look at programming. How I was accustomed to studying was not working. I took copious notes and consistently reviewed them — the way I was conditioned to learn for over 15 years of traditional education. While notes were great for me to understand the fundamental components of new concepts, it gave me a false sense of competence. I could look at a black lego and say “this is a black lego”, but I couldn’t build you a model of the Death Star with it.

This left me feeling incredibly defeated. How could I go from my “guaranteed to get me that A” studying techniques to hardly comprehending how to build basic apps?

I began to believe this was not for me. I convinced myself I had made a terrible and expensive mistake signing up for this. I’m admittedly a dreamer with loose connections to reality — I’ll romanticize the crap out of everything in my life…but how’d I let myself think I’d actually be successful at programming?

These thoughts continued to sink deep and I shut down.

I didn’t ask for help, I had little motivation, and I was digging myself a coding grave. I was (unfortunately) seasoned to understanding and processing information easily. I knew how to get good grades and play the game of studying for standard multiple choice exams. For one of the first times in my life, I struggled hard to pick something up. I was never taught HOW to struggle, how to deal with it, or how to work around it. It was just “here is the information. Study, retain, regurgitate”.

One insanely difficult week, a sleepless night, and a reality check later — I knew it was time I seriously took the advice of my peers and instructors.

I had to finally change the way I learned — an incredibly difficult thing to do in your late twenties. At any age, really. I abandoned my notes and insecurities and just coded. I utilized google and “console logged” everything to death. I used what I already knew, which was surprisingly a lot more than I was giving myself credit for.

I dove into the “build and burn” process — I’d build up an application, celebrate my victory, destroy it, and do it all over again. I wasn’t convinced of this technique at first, but it quickly became clear that this was a wonderful way to understand how components of your code work, discover new issues, and how to troubleshoot them. This is not the same as writing a sentence or a word over and over again to commit it to memory — concepts become clearer with building the same thing repeatedly, slowly abandoning crutches like notes and Google until you have a more defined idea of what to use and when.

Stepping back a little bit, I recognized my problem: feeling inadequate and unmotivated because my code doesn’t work. I can’t find the issue. Screw this.

Solution: TEST EVERYTHING AS YOU CODE.

Nothing is too small to confirm. Something doesn’t work? It becomes a learning opportunity and a single, focused issue to tackle. By basking in the light of those little “test passing” wins and giving yourself grace, you are self-sustaining your morale and motivation. It’s absolutely okay to rest on your laurels for a moment for sanity’s sake. Test it, celebrate, and move on. In the end, you have working code and you maintained your mental health throughout the process.

I can’t take complete credit for these revelations and I’m deeply thankful to have someone who graciously pushes me to be the best version of myself. This leads to one more epiphany I experienced — don’t do this alone.

I am independent to an absurd fault and asking for help has always been difficult, but I have remarkable people in my life who can sense when I need it. Have someone who legitimately cares about your success. Confide in an instructor, your significant other, your dog, whoever.

This process has molded me in more ways than I expected.

Code will chew you up, spit you out, and you have to somewhat enjoy that process. The trick is knowing what actions you need to take.

The steps don’t have to be huge or impractical, it’s in your power to make them small and doable. Every large piece of intimidating code can be broken down into something much more emotionally forgiving.

We are resilient beings. Use drawbacks to propel yourself forward.