When I started in the Labs team at Net-a-Porter, the job description contained the following desired trait:
Candidate is unafraid to fail, but fails fast
This phrase was new to me at the time and it certainly wasn’t something I could say I was actively doing, but three years later failing fast is not only something I strive to do as a software developer, but something I look to do in aspects of my day-to-day life.
So what does this phrase actually mean? The phrase has two parts; let’s look at each of them.
…Unafraid to fail…
Being unafraid to fail is not something that comes naturally to most people. We’re taught from a young age that failing is a bad thing. We take exams at school where we are put on the spot and required to succeed on demand. It is ingrained within us to try to avoid failure as much as possible, and this fear of failure can have negative effects.
One of the biggest drawbacks that comes with a fear of failure is that it prevents you from experimenting and innovating. As a software developer, experimenting usually involves hacking out some proof-of-concept code and seeing where it ends up. This is a valuable skill to have, as it can lead to some great code.
A fear of failure can also slow down a programmer. When facing a programming problem, a developer will often have at least a vague idea of how to solve it, but fear of failure can prevent a developer from going with their gut instinct, instead opting to spend time researching for clarification or even looking for a pre-baked solution. Don’t get me wrong; research is a really important part of being a software developer, and it is often worth doing at least a little before tackling any programming problem, especially problems you are unfamiliar with. But sometimes, especially for small problems, it can be quicker just to code your gut instinct out and see if it works. Even if it doesn’t work, you will have learned something.
Building up a back-catalogue of failures is, in my opinion, some of the most valuable experience you can have. Those WTFs that I’ve coded, I remember much more vividly than other peoples’ I’ve seen or read about. I see this as a good thing, as it gives me confidence that I won’t be making those same mistakes again.
Failing in order to learn from mistakes is all very well, but it becomes a lot more valuable when you learn how to fail fast. If you spend a long time building a proof of concept only for it to fail, then that is a lot of time spent for a relatively small amount of gain. Being able to build many proofs of concept in a short space of time is vital to learning the most about a problem quickly.
Here are some techniques that I’ve learned to speed up building proofs of concept:
- Have a clear goal you want to achieve with your proof of concept and keep focused on it. Don’t get sidetracked and end up shaving a yak.
- Ensure you pick a small problem that will be achievable in a short space of time. If you have large, complex problem, break it down into smaller problems, so you are only trying to prove one thing at a time.
- Proofs of concept are meant to be rough around the edges. Fight the urge to spend too much time making your code pretty or production-ready. If your proof of concept fails, then nobody is going to see this code anyway.
Failing fast everywhere
This fail-fast philosophy can be a good way to improve at many other skills, not just software development. Earlier, I mentioned that I use it in aspects of my day-to-day life, and one of example of this is cooking. Experimentation in the kitchen can pay dividends, and often the time investment in cooking a dish is fairly small. So, when a dish does come out bad, at least I know I have failed fast, making the cooking lesson cheap.
I hope this article inspires you to try learning by failing fast, whether at work, in your hobbies, or in your day-to-day life.