In fall 2011, I was at an HR technology conference and heard a project manager from Facebook give a presentation. I guess the talk must have been about how to motivate and engage employees, but the only thing I remembered from it was that Facebook engineers are required (encouraged?) to push new code live at least once a day.
She explained that it gave them freedom to explore because it sent a message that if something was horribly wrong, there weren’t broader repercussions other than “fix it” and of course, “learn something for next time.”
“This is how we should be in our lives,” I said to my friend after the talk. “We just need to push the code live – whatever it is – see how it behaves – and then get information we need to make it better or move on.” We (who had never written a line of code in our lives) jokingly adopted the mantra, “push that code” in response to any instance of hesitation or uncertainty. It didn’t lead to many bold decisions, but it did lead to lots more analogies that mapped technical things onto less technical parts of life, attempts to draw wisdom from these comparisons – and of course, a desire to write about them.
Over a year and a half later, I was listening to someone discuss the “bad” code his company sometimes pushed live and what a good thing it was, mostly because the company is moving forward at the speed of light and solutions need to be implemented first, revised later.
But he added something important:
It’s also good because if you’re pushing things live all the time, it’s not a big a deal when something goes wrong. You learn to be ok with mistakes. If you wait forever to release something, it’s much more upsetting when something doesn’t work.
It had been a while since I’d first thought about pushing code as a metaphor for risk taking in life, but this phrasing hit me particularly hard. It truly points to both positive and negative feedback loops that connect failure and success.
Code, literal and figurative, breaks. The story we tell ourselves about that breakage impacts the story we tell ourselves the next time we want to build something. By nature, our brains latch more strongly onto negative experiences. If we build infrequently, when things break, the bad thoughts and feelings dominate our understanding and memory of the situation. The next time we have the chance to push something live, we act based on fear of failure rather than hope of success.
Lately, I’ve heard lots of discussions about how we can learn to fail productively. The answer, from both a cognitive and emotional perspective, seems to be: Fail with a higher frequency.
The more often we fully commit to trying things, the more balanced the memories become. Failure is less dramatic. We’re not afraid to change strategies if we need to, nor do we give up on things just because they’re difficult. We create because there’s a possibility that something could be good, rather than obsess out of worry that it could be bad.
That said, I couldn’t really think of a better catalyst for finally starting this blog – which will attempt to make observations about tech that relate to a broader crowd. For non-technical people, it may be an introduction to a new topic and a more analytical way of seeing things. For technical people, it may provide a more abstract perspective on otherwise reason-based things, or it may provide a good laugh, or more likely, it will provide an opportunity to correct me.
In the spirit of pushing things that are not quite perfect, I admit I’m not 100% sure how it will evolve. But if you’re at all interested in the attempts, mistakes and lessons learned, I hope you’ll follow along.