There exists in the technology world today the myth of the glorious failure. The praiseworthy failure. The gently notorious and spectacular failure. Everyone should fail all of the time, right? Companies should fail fast — fail well. Fail in a humorous way maybe, suitable for later rehashing over craft beer. Not failing? Push harder — you will. To fail is to be epic and to learn. Worstward Ho and all that.
But when it comes time to actually fail for real in the world of technology and business — particularly in the world of very large platforms with millions of users and millions of dollars at stake — I suspect that I am not the only software person who doesn’t find much relevance in the startup-era jingoistic kind of failure. The fact is that we have basically managed to completely divorce ourselves from the psychology of what it means to thoroughly fuck up. Moreover — failure sucks. It’s excessively and inappropriately worshiped by people who work on the interwebs and build companies, but who (I suspect) do little of the un-sexy work that actually props up most of the web.
At my job, I’ve been tasked with a rather broad technical project which might be said to fall into the category of low reward, high risk. It involves the underlying data structures and some of the hidden internal plumbing behind a product used by tens of millions of people every day. A mistake on my part could at best introduce hard-to-find bugs, or worse temporarily render parts of the product unusable for a short time, or worse still corrupt some underlying data that would take a long time to restore, resulting in a wide outage. Success, on the other hand, means that nothing (apparently) changes. Status quo. I’ve feared failure in this project. I’ve really feared it. I’ve feared that one day I’d start some script off running and realizing it was doing something horrible and then be unable to un-do it.
I think this kind of fear of failure has been useful.
It’s been fear that caused me to approach this sort of work with the caution it deserved. I’ve been checking and testing all the code I write many times. I’ve been allowing time for problems to emerge and others to weigh in before I move on to the next phase or task. I’ve built redundant safeguards into the code so that data-destructive things that shouldn’t be happening have a vanishingly small chance of ever occurring. I’ve slowed down and not pretended that every. single. thing. on the web or with people needs to happen at light speed.
I’m finishing up this project now, and it looks like it will have — not failed. I’m glad I took it slow. I’m glad I was afraid.