« Failure as Progress

Failure has a negative connotation and reasonably so; it literally means that the thing you set out to do did not happen or happened incorrectly. Looking at each step and being distressed by failure is not only a drag, it’s unproductive. Altering your perception and response to failure can make life an entirely more enjoyable and fruitful endeavor.

SpaceX is a private Space Explorations and Technology company. Basically, they launch fancy rockets and eventually want to take us to Mars for colonization.

To make a Mars trek a reality, they have to bring the cost of a ticket down to the point where they can sell to non-millionaires. Rockets today are virtually disposable. They’re launched, debris falls to the ocean and that’s it. One big way to lower the cost of a trip could be to make rockets actually reusable. Reusable rockets are more akin to how we think of Airplanes now. Landing a large needle-shaped rocket isn’t that simple a task though. They have to correct for the speed, angle, wind conditions, everything. By my count, they’ve attempted 12 propulsive landings, 3 went famously, with others having varying levels of success. Many were considered successful simply for the fact that they were able to collect a ton of data and correct their systems for the next flight.

We are not expecting a successful attempt this time around but we are learning — John Federspiel (Lead Mechanical Design at Space X)

Space X didn’t set out to make a rocket landing possible, work for several years and output a rocket that can land upright out on the ocean. They worked for several years using what they know as a launchpad to new questions and experiments. They measured at every step and used those measurements to make decisions about the next mission. The key to the progress is to “commit to failing in a new way.”

In order to succeed, or fail enough to succeed, you first need to define it. One of the biggest mistakes I’ve seen is when a project has significant work done without understanding what the ultimate goal is. You’re simply chipping away at something, but you have no clue what. In order to fail at a thing or succeed and move on, you have to have a tangible goal post that you’re working towards with a definition of “it worked.”

A concrete example of this is writing; let’s say I’d like to write more. I’ve told people I’m trying to write more and initially I did. A month or two went by and someone asked, “how’s the writing going?” and I responded, “It’s going ok.” And that’s the end of it. What’s wrong with that? Well, aside from it not really going at all, I had no measurable concept of whether writing was going well. I had no baseline to measure against.

In an alternate universe, when I’ve decided to improve my writing, I write up that I’d like to output one post per week and publish somewhere at least once a month for the next 6 months. This time, when a friend asks how my writing has been going, I can loosely compare my actual writing to my goals and decide whether I’ve been failing at writing. If I have been failing I can adjust my expectations or better define my goals.

The time boxing of a goal is also important. If you have a supposed infinite amount of time to succeed or fail, then you never fail. You’re really just in a constant state of in-progress until you “succeed” which, aside from being unrealistic, doesn’t teach you anything because you don’t get to learn from any sort of failure.

In Software Engineering there’s a well known development technique called TDD — Test Driven Development. Rather than writing code and then testing it, you write a test and then write the code that makes that test pass. One reason people find it useful is that finding proof that your code works comes fairly naturally.

As an Engineer, TDD sounds a little backwards; maybe I don’t know exactly what I need to write so how should I know what test to write? TDD implies that if you’re writing code before you know what you need then you haven’t thought about your problem. This act of defining success for your code forces you through the motions of understanding what you need to learn from the code, what isn’t there now that I need to be there? TDD can instill a sense of constant failure. You write a test that will fail, watch it fail, make it not fail. It provides a quick understanding that a big red “F” isn’t a bad thing, now we know something, definitively, that we didn’t know before.

The problem with success-sans-failure is that you don’t know the range of possible failures, yet. I prefer to have failed at some point along the way because at least then you’ve picked up some more concrete understanding of the problem at hand. You might call SpaceX a Stellar example — do enough of what you know is feasible while trying to experiment with things that will fail initially. Learn from acceptable amounts of failures while succeeding enough to stay afloat.

When I was a Junior Software Engineer I feared some of the changes I was making. I feared them not working properly and I feared critiques, initially. I came to learn that all the critique, the failed tests, even errors in production were just a fact of progress. Remove the fear and jump in the deep end, learn. Its a lot more fun and you’ll find that you understand everything far better than if you had spent 10 times the amount of time trying to just “get it right.”

I’m a Software Engineer at Highrise. We build a Simple CRM. Check out my rants and recommendations on Twitter.

A couple footnotes for the curious. In regards to any research I did on SpaceX, most of the inspiration and some of my basic understanding comes from Wait But Why. Do check them out, but if you’re curious about the SpaceX article, specifically, check that out here. There’s also some great stuff in their latest (5/6/2016) launch stream video. My count of launches is listed in their well-groomed controlled-descent Wikipedia article. I have some feelings about TDD but I didn’t want to muddy the point of the article with those feelings. I will write more explicitly about TDD (because I feel left out) but if you are interested, some assessments of the practice are worth checking out by c2 (more of a collection) and some opposing viewpoints from David Heinemeier Hansson.