Failing Forwards

Behind one success lay a thousand failures.

22 days ago, I embarked on a 15–week journey through the Flatiron School to become a software engineer. There are a lot of things I would like to say about the process thus far, too many for a small blog post. And so I would like to focus on what has been to me the most foreign, most difficult, and most rewarding aspect of the bootcamp so far. The failure.

Anyone who learns something new will find setbacks and failures along their journey. It does not matter whether that be learning how to drive, how to speak French, or how to spend what appeared to be a ceaseless period of time tucked inside a two-bedroom apartment in New York City, failure and setbacks are the companions to progress. From my admittedly small foray into the coding world up to this point, which includes these 22 days and another month spent as an undergrad making an endless runner game, it is clear to me that there is no other skill

There are a few observations about failure in coding, that are unique to coding, that I would like to touch upon at this moment. First is that failure is not a bad thing. I know this sounds simply, and even a little culturally cliché, but it has a very grounded, practical affect on my experience as a budding software engineer. As a student outside of a coding environment, my relationship with learning and with information was always set onto a particular track or pattern. The student receives information, the student digests information, the student presents information or is tested. The best students, the smartest students, will reach that third stage showing their A+, 100%, gold-star mastery of the information. Failure, in that scenario, represented a state of being lesser. Coding isn’t like that. The idea that you can take a lesson, fully process it, and then return with an immaculate product as a student simply isn’t realistic and so what I am encountering, and what I believe most new coders encounter, is the realization that we are going to fail, we are going to fail a lot, and that’s ok.

This cascades into my second observation of failure, which touches upon the difference between the learning patterns of coders and engineers and those of more traditional learning. In coding, failure is a non-binary. What I mean by this is that when you code, and you get something wrong, it is not zero-sum situation. I know that the little devil that whispers in my ear will tell me that I am failing as opposed to passing, and I must admit there is fraction of the truth in that. But where failing in coding separates itself is in the act of failing, in the how of failing. There are dozens of ways to fail in even the most simple lines of code. From the most inane syntax and spelling errors to the conceptual flaws that come from how we structure and build our code on a macro scale, the myriad of pathways is astounding. What separates this act of failing from others in different spheres of learning is in how present and consistent failure is, and how it is treated as an informant rather than judge. Failure in coding is not a condemnation of any sort, it is in fact most necessary. The reason that coding and coders have such a special relationship with failure is because coding is a dialogue between person and computer. When there is a flaw in the code, the computer will return: “I don’t understand what you mean here because of this”, all in real time. This dynamic action is at the core of how coders make failure part of their power.

This all leads me to my last observation about failure, something that I’ve called benchmarking. If a person is doing any sort of coding bootcamp, YouTube instructional, or simply learning on their own, one of most fundamental skills in coding is how to save your work (the correct answer is often).

The extension of benchmarking relates to failure because at any point in a project a flood of different things can go wrong, each with an array of cascading effects and the best way to insulate code from these dramatic effects is by saving work and creating benchmarks in your own project. To use a simple metaphor, it’s like saving your progress in a video game. As a player, moving forward in a game right after a save point gives them the freedom to explore and be more daring with what they try because they know that the absolute worst thing that could happen is that they return to a location only some small distance in the past. Coding is the same way. Benchmarking the achievements in your code allows you to continually integrate and evolve your code through the sequence of failures that will inevitably occupy your path in developing whatever application you have in mind. It gives you the license to pursue different answers for problems in your code because you know that you’ve insulated yourself from those problems by creating a benchmark that you can always return to. This serves as a stabilizer for your failures. Instead of a failure sending you into a spiral of doubt, frustration, and panic, you have a platform to assess the situation from, a vantage point where you can calmly react without being inhibited by the fear of failure, but rather to be informed by it.