The Power of Making Mistakes

Slides from a talk I gave at Squares Conference in Grapevine, Texas, on March 27th, 2015.

------------------------------------------

[SLIDE: Joel Glovier intro]

I'm Joel Glovier. And I'm a designer at GitHub. I'm @jglovier on GitHub and Twitter. I'd love to hear feedback or questions later so hollar at me on Twitter if you have questions or comments. Or, find me on GitHub and fork one of my projects.

[SLIDE: Home office slide]

I live in Mechanicsburg, Pennsylvania where I work remotely.

[SLIDE: Me, & Ash]

This is me and my wife Ashley. What?! Is that Samuel L Jackson photobombing our picture? Ha! I never even noticed that.

[SLIDE: Me with kids]

Ashley and I have three beautiful, precious little terrorists. Shoutout to my wife because she's at home with the terrorists while I'm here all week.

[SLIDE: GitHub title]

I work for GitHub where I'm part of the Creative team.

At GitHub we're known for a few things. We're known for:

[SLIDE: Octocat]

The Octocat. She's our crazy, nonsensical mascot. Her full name is Mona Lisa Octocat.

[SLIDE: Creating git]

We're known for Creating Git.

[SLIDE: Linus Torvalds]

Which is totally not true. Actually Linus Torvalds created git as a version control system specifically suited to the needs of the Linux community. But lots of people still think we created Git, so that's always worth clearing up.

[SLIDE: Asyncronous culture]

We're known for our asyncronous culture. We used to say that GitHub is a fully distributed company that happens to have a physical space. That's changing a bit as we grow and more and more people are working out of the office, but we are still very asyncronous in the way we work, in the tools we use, and how we manage projects.

[SLIDE: Remote stats]

In fact, currently 50% of our 275 employees work remotely across the globe.

[SLIDE: Open source]

And we're known for open source. GitHub is the world's largest open source community. Our whole platform is built around the idea of distributed collaboration, and the idea of making it better to work together than alone.

[SLIDE: GitHub nutshell]

So that's GitHub in a nutshell.

[SLIDE: Animaniacs]

I'd like to take an informal survey. It's super high tech - we're going to do one of those live polling things. Except I don't have a fancy URL for you to go to, so just raise your hand, okay.

[SLIDE: How many people use GitHub]
[SLIDE: answer slide ]

[SLIDE: Do you use GitHub for personal or work projects]
[SLIDE: answer slide ]

[SLIDE: Have you ever used an open source project in your work?]
[SLIDE: answer slide ]

[SLIDE: Do you contribute to OSS]
[SLIDE: answer slide ]

[SLIDE: Have you thought about open sourcing something]
[SLIDE: answer slide ]

[SLIDE: Talk title slide again ]

I often talk to people who feel intimidated by GitHub. We do a lot of user research at GitHub, and that’s actually a common sentiment among developers (especially those new to GitHub, or version control).

Chrissie Brodigan, who leads user research, has talked to lots of people who feel intimidated by GitHub. For some it's the complexities of using Git and the command line, for others it's the fear of contributing to open source projects and the risk of having people criticize what you've made.

But a lot of the time, when you dig down into what's behind that intimidation, what you really find is it's not really GitHub that intimidates them, it's the fear of making mistakes. And that's what we're going to talk about today.

[SLIDE: Talk outline ]

Here's a quick look at what we're going to talk about today:

First, we'll talk about how everyone makes mistakes, and how it's a normal part of doing anything. Then we're going to talk about why mistakes aren't a bad thing. And finally, we’ll look at the importance of making mistakes freely, and GitHub as a great environment for that.

[SLIDE: mountain transition ]
[SLIDE: 1. Everyone makes mistakes ]

Everyone makes mistakes.

[SLIDE: Captain obvous ]

I know you’re all thinking I’m captain obvious here, but let me tell you a story...

[SLIDE: Storytime ]

When I was a kid I was terrified of being on stage. Once, when I was in like 3rd grade, somehow I got talked into singing a song all by myself as part of the school Christmas thing. (I call it a thing because I don't even remember if it was a play, or a musical, or just some type of freak child trauma experiment. I mean that's what all that stuff is, right? They're just trying to make little kids pee their pants on stage!)

Anyway, all I can remember is that I was supposed to sing a song in front of hundreds of people, in a dark room with a spotlight shining in my face. And I was like 8 years old!

So I walk out on stage, and the music starts, and I start singing. And then suddenly I realized I was singing the complete wrong thing (I think I started the song on the second or third verse or something). So, of course I just stopped singing - I completely froze up. And then they stopped the music and rewound the cassette tape, and started it again, and I started all over. And it was terrifying, and it pretty much scared me for life for being on a stage.

Except it didn't. Because stuff like that happens to everyone, all the time, and we get over it. It's a natural part of the process. Almost everyone experiences stagefright their first time on stage (or every time), and everyone you see on a stage who seems bold and confident knows that feeling whether they still get it or not.

[SLIDE: Adam Osbourne ]

So this is Adam Osbourne.

[SLIDE: Osbourne quote ]

Osbourne said:

> People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster.

[SLIDE: Osbourne story ]

Adam Osbourne was a computer designer who created the first commercially available portable computer - the Osbourne 1. It weighed about 25 pounds, and it cost almost $1800 - which in today's money is roughly $4600. It was designed to fit under an airline seat, and that was the epitome of portable computing at the time.

Osborne and his company were very successful at selling their new portable computer, at their peak selling 10,000 machines per month. However, Osborne was himself no stranger to miskates.

In fact, his company filed for bankruptcy after a product announcement for newer, more advanced model, canabalised sales of the existing model in production while everyone held out for the new model. In fact, this effect of a pre-announcement of a new product causing a catastrophic collapse in demand for older ones, became known as the Osborne effect.

So Adam Osbourne new a thing or two about making mistakes.

[SLIDE: Picard facepalm ]

Let's all give Adam a facepalm, shall we?

[SLIDE: Mistakes we make ]

Actually - how about let's talk about some of the mistakes we make? These are some really basic examples, but just so we are all on the same page that we do all make mistakes, here are few things maybe you've done before:

[SLIDE: Mistake example slides ]

So these are some great examples of mistakes we all make from time to time, and they're a simple reminder that we do all make mistakes.

[SLIDE:Everyone does it, man ]

Literally EVERYONE makes mistakes. There are no perfect people, there are no perfect programmers, there are no perfect anything. The only 100% success rate is the percent of people who succeed at making a mistake at some point. It's obvious, and it seems like common sense, but for some reason we really do need to be reminded of this fact.

And why? Why do we need to be reminded that we're not the only ones making mistakes?

Well there are a lot of dynamics at play, that's why. New environments, new jobs, new frameworks and technologies to work with, reorgs, new social or cultural cues, the illusion that others aren't making the mistakes.

All of these things play into why we often forget that everyone makes mistakes.

[SLIDE: I have no idea what I'm doing dog ]

Is everyone familiar with Imposter Syndrome?

[SLIDE:Imposter syndrome ]

Imposter syndrome is a psychological phenomenon, in which people are unable to internalize their accomplishments *(wikipedia)* Or in other words, is the feeling that you don't belong where you are on your own merits alone, and it's rapant in the tech industry.

I mention imposter syndrome because everybody feels like they don't know what they're doing from time to time, but an irrational fear of making mistakes can be a sign that your actually dealing with something deeper.

I'm not trying to get you too introspective here, I just want to point out if you are dealing with something deeper, it can be helpful to recognize that mistakes are common to everyone, and not a sign that you aren't good enough.

[SLIDE: nobody likes mistakes]

Nobody likes to make mistakes. Nobody likes breaking things, or having to redo things. But why? If mistakes are so natural, why do we hate making them so much?

[SLIDE: Cat jump fail ]

(This is my one and only gif so enjoy it. And yes, I do pronounce it with a hard "g" for all you purists.)

[SLIDE: mistakes aren't fun]

Well for one thing, mistakes aren't fun. No matter how much we might enjoy laughing at other people's mistakes, it's never fun to be the one to make them.

[SLIDE: we are trained to avoid mistakes]

But perhaps more importantly, we are trained to avoid them. It goes all the way back to when we were little. At home and at school the message was always drilled into our heads that failure is bad.

Think about how school is setup - the entire system is setup to penalize us when we fail, and reward us when we succeed. We receive negative reinforcement when we make mistakes, and punitive reactions that teach us not to make those same mistakes.

We are taught to feel shame when we fail and that IF we try hard enough, or study hard enough, or are smart enough, we don't have to fail.

And that trained way of thinking about failure stays with us for years. Often for the rest of our lives.

[SLIDE: car crash img ]

And it's not completely unwarranted.

[SLIDE: There are real consequences]

There are real costs associated with the mistakes we make, so in that sense it's natural to want to avoid those costs or consequences.

When an airline pilot makes a mistake, the worst case scenario is that very bad things can happen to real people. When a doctor makes a mistake, there can be very real consequences to his mistakes.

And even in our industry, when we make mistakes, there are very real costs and consquences at play. Maybe nobody's life is in danger, but it's not out of the realm of possiblity. Someone has to write the software that pilots and doctors use in their work.

Or maybe the cost is losing your job. That's a very real thing to fear, with very real implications for your life.

So, it's not that there are not good reason to want to avoid mistakes. There defintely are real consequences that we want to and need to avoid. But what I want you to understand is that it's the consequences that we need to avoid, not the mistakes.

[SLIDE: mountain transition ]

And if all that sounds too pithy and philosophical, just hang with me for a mintute.

[SLIDE: Mistakes aren't evil section title]

Mistakes aren't evil.

[SLIDE: Ed Catmull picture]

Ed Catmull is the president of Pixar Animation Studios. He wrote a book called Creativity, Inc., which a number of us at GitHub read together last year. In his book, Ed talks about alot of the lessons he's learned from the years he's spent at Pixar, including during Disney's acquisition of Pixar.

One of the things he talked about that impacted me most is this idea of mistakes and failure, and how necessary they are to the creative process.

[SLIDE: Catmull quote ]

He said, "Mistakes aren't a necessary evil. They aren't evil at all. They are an inevitable consequence of doing something new."

He also talked about how there are two parts to any failure: there is the event itself, with its disappointment, confusion, and shame. And then there is our reaction to it.

I'll let you guess which part we can control.

Let me tell you another story.

[SLIDE: broken email story ]

Email sucks. Can I get an amen? Specifically HTML emails, as anyone who's developed them before can attest to.

One time I was responsible for shipping an email announcement. I created the template for the email, and was responsible for testing the template and shipping the email. Somebody else created the content - and as it happend the markup for the content area as well.

This particular project was an aside to what I was focused on at the time, so I just grabbed the content markup, and plugged it into my template, tested it in Litmus, and sent it out the door.

About 15 minutes later, somebody pointed out that there was a broken link in the email. My heart sunk.

While I had spent time testing the template markup, I never bothered to click the links in the content. And worst of all, I knew I couldn't just push a change and refresh the markup because hey that's not how email works!

No big deal, this email had only gone out to about 5,000 of the recipients in the queue.

Okay, yes it was a big deal - at least to me. I was terribly embarrased because I had to page someone from ops to go in and add a redirect for the URL immediately. It certainly wasn't the end of the world, and I doubt too many actual recipients even saw the mistake, but I was ashamed because it was my responsibility to test and ship the thing, and I failed to thoroughly check everything like I should have.

But I learned an important lesson from that experience: always test your email links!

And yeah - email sucks.

[SLIDE: Mistakes help us learn]

Mistakes help us learn.

[SLIDE: Edison quote]

Thomas Edison famously said, "I have not failed. I've just found 10,000 ways that won't work."

If we can just set aside the Edison/Tesla drama for a moment, the point is that sometimes all you do is fail until you eventually suceed, and if you aren't willing to push through the failures you might never even discover the answer to what you are trying to solve. Failures are a normal part of that process of invention and discovery.

[SLIDE: Richard Branson quote]

Sir Richard Branson of Virgin Airlines fame said, "You don't learn to walk by following rules. You learn by doing, and by falling over."

Anyone who has kids has seen this at play over and over. Or anyone who themselves was ever a kid. Did you get on your bike and immediately start riding the first time? Did you decide one day when you were 8 months old to just stand up and start walking? No, it's a process, and mistakes are a natural part of the process.

[SLIDE: Failing helps you slides... ]

Failing helps you identify problems you wouldn't otherwise have seen.

It helps you learn important lessons that you don't fully grasp until you experience them first hand.

And it helps you realize your shortcomings so you can become more careful in the future.

If mistakes are so awesome, we should make more of them, right?

[SLIDE: Step brothers "Yep" gif ]

(Okay I lied - I did have another gif)

[SLIDE: shouldn't try to avoid mistakes ]
[SLIDE: we should make them liberally ]

We shouldn’t try to avoid mistakes. We should make them liberally, and safely.

That's the whole point here. We need to make more mistakes. We need to feel free to make mistakes. We need to not fear mistakes as something bad, but embrace them as part of the natural process of doing anything.

Mistakes are inevitable, and necessary. But we can only realize the power of making mistakes when we can make them freely and safely. Only when we decouple the act of making a mistake from the cost associated with it do we really grasp how powerful mistakes are for progress.

[SLIDE: Gandhi quote ]

Ghandi said:

> "Freedom is not worth having if it does not include the freedom to make mistakes."

[SLIDE: Watson quote ]

IBM founder Thomas Watson said:

> "Would you like me to give you a formula for success? It’s quite simple, really. Double your rate of failure."

What did these wise and successful people know that we forget? They knew that failure - making mistakes - is not a bad thing. It's an essential thing.

[SLIDE: Catmull quote]

In the book I mentioned, Creativity, Inc., Ed Catmull talks about how at Pixar their intentional approach to the creative process is to embrace mistakes, and make them as quickly as possible, because by making mistakes you rule out possibilities, and you uncover things you haven't seen until you explored the thing that doesn't work.

> "To be wrong as fast as you can is to sign up for aggressive, rapid learning."

It's because of this connection between failure and success - specifically that they are intimately tied together - that we need to embrace failure, and mistakes. And we have to realize that the cost of making a mistake is something altogether different from the act of making a mistake itself.

[SLIDE: Mountain transition slide]

So we talked about how everyone makes mistakes, and we looked at how mistakes in and of themselves are not a bad thing.

[SLIDE: Making mistakes freely title]

Let's talk about making mistakes freely.

What are some of the ways we can mitigate the cost of making mistakes to achieve the benits we get from making them? I'm going to focus on answering that question for the next few minutes together talking specifically about using GitHub as an environment to do exactly that.

[SLIDE: Version control]

How many people here use a version control system? Git, SVN, Mercurial, Trac?

Version control systems are the ultimate mistake mitigator. They give you an environment to make mistakes freely, without fear that you're going to overwrite something you can never get back.

[SLIDE: Git ]

And that's what GitHub is literally built on. It's built on Git, which specifically excells at distributed projects.

If GitHub went down today, all the world's code would not be lost because every repository that's checked out to someone's machine is completely independent of GitHub's servers. You might lose your comment and discussion history, but your code's entire history still lives on your machine.

[SLIDE: GitHub Desktop apps ]

Now, for those of you who said that Git or the command line was a barrier to using GitHub, this one is for you. The GitHub desktop applications for Mac and Windows abstract away most of what makes Git intimidating. It's intentionally not a full-featured Git client, it's a GitHub client.

[SLIDE: Mac app screenshots ]

What that means is you can use the Desktop app to do things like cloning branches locally, view your history, view and create new branches, commiting your changes, resolve merge conflicts, and now even opening pull requests directly from the app.

[SLIDE: Feature branching ]

At GitHub we advocate for something we call GitHub flow. And one of the fundamental components to GitHub flow is creating feature branches.

Feature branching is where you create a branch of your project specifically to work on a new feature. You name the branch specifically for the scope of whatever you're working on, and then you commit all your work for that specific feature to that branch.

The benefit of working with feature branches, is that it confines your changes to one specific branch, so if you break something, it only affects your local environment. It's like a sandbox where you can try out new ideas without fear of breaking something important.

This way there's always a branch that is fully functioning and deployable (your master branch), and you can deal with merge conflicts, and broken code within your branch to make sure that it's all working properly before you merge back into master.

[SLIDE: Pull requests ]

Pull requests. Now this is where the magic happens.

[SLIDE: Shia magic ]

(Didn't see that coming, did you? You thought I only had one gif.)

[SLIDE: Pull request screenshot ]

Seriously though pull requests are kind of like GitHub's secret sauce. How many people have ever opened a pull request?

At GitHub we do everything with pull requests. Starting work on a new feature? Open a pull request, and open it early. Spotted something wrong with someone elses code? Open a pull request to fix it.

How many people get confused by pull requests and what they even are? Here's a simple way to think about them:

A pull request is basically just a place for you to review changes you are proposing to make with your other collaborators, and have a discussion around them before you merge the work in. This is great because it provides a forum for stakeholders to voice their feedback about your work, and a place for fellow collaborators to provide critical input on your code.

[SLIDE: Entweb features screenshot ]

I thought it might be helpful to show you how we use pull requests in our workflow at GitHub. So lemme run down through a recent project and how we used a pull request to ship it.

This is our features page on the GitHub Enterprise website. After we realized the need for this page, I opened a pull request where all the work took place.

[SLIDE: Entweb features pull request walk through... ]
(...walk through pull request...)

Everything we do at GitHub is ultimately about getting people to open a pull request. That's our key metric. The more people are opening pull requests, the better we believe the world will be. Because that's where collaboration really happens. That's where we come together to get everyone in the same room and hash it all out before we ship something.

[SLIDE: It's happening gif ]

[SLIDE: Deployment ]

Finally, depoment is another great example of how GitHub gives you an environment to make mistakes freely. Specifically, with tools that integrate with GitHub, like CI services, and Hubot.

[SLIDE: Hubot ]

How many people have used Hubot before?

[SLIDE: Master is always deployable ]

The first principle of GitHub flow is that master is always deployable. What that means is master is always a clean and working branch.

Well in order for this to be true, we employ continuous integration services like Janky and Travis CI that run our tests and report back on the status of any branch that has an open pull request.

[SLIDE: merge green ]
[SLIDE: merge yellow ]

So here's how it works: If the builds are passing, the merge button is green. If the builds are failing, you get a warning to let you know it's not time to merge yet. And you can configure these type of checks for any repository.

[SLIDE: Hubot ]

We also use Hubot to report the status of all these things in our Campfire chat rooms. And Hubot is also wired up to listen for new merges into master, and auto deploy when something does get merged in.

Hubot is smart enough to know when a build is passing or failing, and will deploy if everything is passing. That way you never have to be worried that you're deploying broken code.

And if something does happen to go wrong, another way that we mitigate that risk of unexpected failures (for example if there is a breaking change that no test has been written for yet), we do what's called branch deploying first, where you actually just deploy the branch instead of master, and then wait a few hours or days to make sure everything is okay, then merge it into master once it's been on production and no errors have been reported.

[SLIDE: making mistakes freely recap ]

So these are a few of the ways that GitHub can help you make mistakes freely. The important thing to remember is that GitHub is really just an environment that helps you mitigate that cost of making mistakes, so that you can focus on what you're trying to create without having to be afraid of breaking things.

- Version control gives you a history of your work.
- The GitHub desktop apps help you focus on doing your work instead of dealing with the command line.
- Feature branching gives you safe place to explore new ideas.
- Pull requests give you a forum to discuss your work with stakeholders and collaborators.
- And deployment tools like continuous integration take the risk out of pushing code to production.

[SLIDE: talk recap ]

So if you only remember three things from today, here are the important points:
1. Everyone makes mistakes
2. Mistakes aren't evil
3. Make mistakes freely

[SLIDE: title slide again ]

And that's the power of making mistakes.

[SLIDE: thank you ]