Skip to content

Instantly share code, notes, and snippets.

@stevenjackson
Last active February 13, 2017 01:45
Show Gist options
  • Save stevenjackson/51d13ae5b5bfb3456efc78dd756bc5fb to your computer and use it in GitHub Desktop.
Save stevenjackson/51d13ae5b5bfb3456efc78dd756bc5fb to your computer and use it in GitHub Desktop.
Looking for Failure

Abstract

Do you avoid failure? Learn to succeed by embracing failure!

Discover how you can use failure to learn faster, build resilient software, and enable innovative teams. Learn how cognitive biases make failure seem unattractive. Explore experimenting with failure to overcome this stigma and supercharge learning. Investigate the skills to reframe failure and enable a mindset and culture suitable for success in a world full of random events.

Summary

Failure provides critical feedback, but we're conditioned to avoid it at all costs and forget it quickly when it happens. How can we challenge this natural human bias? I've spent the last couple years digging into "pop" psychology and thinking about how books like "Thinking Fast and Slow", "Antifragile", "Drive", "Blink", and "Outliers" apply in a software development environment. I'm most excited about the idea that if we can make failure "safe" then we can use it to learn things that we would otherwise be tempted to avoid and ignore because it might go badly. A focus on failure, both deliberate and accidental, has been beneficial in moving my projects beyond the no defects, 100% test coverage type focus and towards finding innovative ways to detect and quickly reverse failure. This is not a perseverance, "Fail fast" or failure-fetish message, but more around the idea that failure is as good as success if your goal is to improve - so stop avoiding it! It's a “soft" talk, but it's going to be most relatable to software developers, as that's where all of my stories and background come from - testing, continuous delivery, and version control are some of the examples I draw on. My ideal outcome is to get people talking about this idea of failing purposefully and see where it goes.

Details

Failures are interesting. They tend to teach lasting personal lessons, but we are loathe to share them. The solutions that allow us to overcome failure after several attempts become deeply internalized but difficult to share why they matter. We need to get comfortable talking about failure. Unfortunately our brains are wired to screw this up. When confronted with a failure, we are conditioned to ignore it, make ourselves blameless, or create elaborate strategies to avoid the possibility of failure altogether. I’d like to present another alternative: embrace failure. It will happen. That’s ok.

We'll explore these ideas:

  • Embrace failure to avoid Regret Avoidance
  • Anti-fragile software is easy to change
  • Debt makes you vulnerable
  • Local failures are preferable to global failures
  • Tests(experiments) are change enablers
  • Reversing expected failure can teach us how to reverse random failures
  • Blame prevents innovation

For each hypothesis I give a brief background of what bias I’m trying to overcome, some examples of how it applies to the practice of writing software, and second order effects I achieved while testing the hypothesis.

@stevenjackson
Copy link
Author

Feedback welcome!

I’ve gotten very little traction on this subject in the past and I have a number of theories, but don't really know. It might be:

  • Abstract is not compelling
  • Topic is "soft", uncomfortable
  • Not interesting to programming conferences
  • Failure is overly-fetishized in the startup world
  • The takeaways are not concretely actionable
  • I'm obviously not an expert on this topic
  • ???

So any feedback to address those topics would be super appreciated!

@samjonester
Copy link

samjonester commented Jan 26, 2017

I like the idea. Here are some possible ways to refine it :)

  1. Self Conf submissions are "Abstract + Notes to reviewers", so how would you restructure this to fit that format?
  2. The summary and details should focus on the audience instead of talking about the talk.

Abstract

Move "Come succeed at failing!" to the first or second sentence. Then line breaks then a short compelling explanation.

I'd change "This session is about how you can use failure to learn faster.." -> "You will explore how failure can be used to learn faster..." (or something along that line). You've got almost that same thing lower in the paragraph. It feels more compelling so maybe move it up front.

"Learn about cognitive biases, like regret avoidance" is a little tough to parse when scanning an abstract as a reviewer or possible attendee.

Summary

"Failure is not simply something to be avoided, but is critical feedback that we often rush to forget." I had to read this a few times. Maybe use 2 sentences instead. Same with the next sentence

Details

Maybe instead of saying "here are my hypothesis" say something about how introspecting on them has positively influenced your daily mental health and the code that you write? Definitely shorten the explanation of why you're listing bullets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment