Failure Is Normal

I screw things up all the time

I got my first computer in 1995 I was introduced to Visual Basic by a friend and pretty much immediately decided programming was what I wanted to do. I've been doing it ever since. A little bit on and off, but mostly, yeah, pretty much since then.

So it's been almost 25 years now. I currently work as a consultant. I run a lot of development teams for a lot of different companies. We have a variety of clients, everything from well established finance and engineering companies to small startups.

I think there a lot of misconceptions about what a developer should be and what we are and how we judge each other and ourselves... probably more ourselves than anybody else... that I think are really wrong and they're hurtful to us and they don't make us better developers at all.

Throughout my career I have built a lot of software. I have created my fair share (maybe a few more... 😬) of null references, caused quite a few infinite loops, caused machines to blue screen, to crash. I've taken out entire server rooms in the past....

I don't tell you these things because I want you to think I'm a bad developer. I want you to know this about me because that's all normal. Ok... to be fair, not everyone will take out an entire server room... But it's normal to make mistakes, to get things wrong, even to just downright screw up.

While I've made mistakes, I've also learned a lot from them and built a lot of software that has been used by thousands of people and stood the test of time.

I feel that's something that we miss a lot. We get this idea that failing is bad. It's very easy to relate failing to being a failure. And we forget that failure is normal; failure is a part of growth.

But it's normal to fail

So I think to start with, it's really important to just know that it is okay to fail. You can still be a rock star developer, you can be a huge asset to a company, create a huge amount of value and be open to the fact that you're going to fail.

I think we all need to kind of keep that in mind because we don't know all the answers. In fact, when I'm hiring a new developer, the first thing I try to find is not that they know all the answers. I typically try NOT to ask them many questions that they have to give me a direct answer to.

I ask them to work with me and to learn with me about something that they don't necessarily know. Because I think it's much more important that you can find the answers; that you're willing to learn and look and seek because, let's face it, even if you do know every single answer today you won't in a year. That's the way tech is.

Failure is a part of growth

I think we can do that by allowing for failure and failing quickly. We should push the boundaries a little bit and increment ourselves just a little bit at a time and push ourselves forward through that process.

There's this concept of progressive overload that's very popular with weightlifting, but I think it works in everything in life, particularly in development.

I remember when I was younger, I played a lot of video games. (My parents swore up and down I should work more on getting jobs and less on playing video games! Sorry mom and dad! 😁) In video games, the best way to level up was to go fight the bad guys who were beyond your current skill level, because you got a lot more experience for them. That was the quickest way to level up.

It's the same with development. If you push a little bit beyond your comfort zone, get outside of that and open yourself to... maybe bombing on this one, but learning from it. Then, when you do screw up, admitting: "Okay, I really screwed this up. What can I do better next time?" Then picking up and moving on from that. Get feedback from others, learn and improve yourself. That's the way to push yourself forward and get closer to being a really great developer.

Safety is a key

The problem is, it's very easy to say failure is ok and normal, but it's very hard to admit to failure because, in general, most of us have a reason to want to avoid that.

I'm scared because, let's face it, I've got kids, I've got to feed them, I've got a mortgage to pay. So when someone who's in some way controlling the money I have to pay for those things is asking me questions, I don't want to admit, "I don't know that" or "I've bombed that" or "I've screwed that up" because I can't do that safely.

Unfortunately, most places are not, as a default, safe places to admit failure. There's a chain of fear. When you tell your boss you did something wrong, they have to tell their boss something went wrong on their watch. When you're in an interview and you don't know the answer to something, even if the person believes you are able to do the job, they're afraid if they bring you on and things go wrong, they'll be held responsible.

In most situations, one of the best things we can do for ourselves is put ourselves in a position of safety. I'm going to admit, right now, this is something easy to say, but harder to do.

Money

One of the single greatest things you can do to put yourself in a position of safety is to put yourself in a good position of financial safety. Pay off any debts you can. Build up a little bit of money, even if it's just to cover your next month.

It's incredible the amount of freedom you get to say, "actually, you know what? If I screw this up, it's probably going to be okay." It's just amazing. It doesn't take a lot to get yourself in a position where you feel a little bit more okay about take a little bit of a risk here and there. As we said, you've got to push yourself a little bit outside of those comfort zones and take a few risks here and there. And the more comfortable you are with that, the more you're able to do that.

Have a backup (and/or back out) plan

Another really great lesson I learned early in my career is: have a backup plan. It's a numbers game. Eventually you're going to fail. It doesn't matter how careful you are it doesn't matter how many scenarios you plan for. Eventually you're going to miss something. Knowing what you plan to do when that happens can make all the difference in the world.

Early on, I had a manager who was absolutely awesome. He allowed me to go push my boundaries. And when I did screw things up he would show up right there and say, "okay, so this happened. What are you going to go do to fix it?" He would then proceed to protect me from everyone else while I did what I needed to do to sort the problem out and learn from it.

And at the time I didn't recognize how important that was, but that was one of the steps in my career that allowed me to understand, okay, so first off, failure is normal and second, I'm going to learn something from this. I'm going to figure out how to fix this. And it didn't take long before I was coming back to him the moment something went wrong, saying, "hey, I screwed up. This is what I'm going to go do. Is that okay?" And he'd say, "yeah, yeah, go for it. Get it done.".

I think having that lesson, learning how to create a backup plan to then not hide from it... not to brush it under the carpet or blame somebody else, but to actually just say, "yeah, I did this..." helped me change how I approach problems.

Transparency changes the picture

I think it's a very good way to begin to be a bit more transparent, to begin to be a little bit more open because most of us are hiding a lot of stuff. Just the act of not hiding it, simply by saying, "you know what? I screwed this up." It makes it okay for somebody else to say, you know, I screwed something up too. The next time, something comes up and they screw something up. They're much more likely to say, "yes, actually I did this. How do we get out of this? What do we do now? What's the next step?"

This is huge for leadership and for teams. There's no magic to it. There's no action plan. Honesty and transparency and respect go hand in hand and tend to spread on their own.

For developers, if your leadership isn't doing this, support each other. Be honest and share with each other. This is what I think of when I think about rockstar developers. This is what I want to be and strive for every day: Not knowing all the answers, but learning new ones all the time, being more open, being more transparent and pushing myself and others forward.

If you want to know a little more about safety and transparency, Kel and I have a couple podcast episodes about these topics:

Put On Your Hardhats!

Failure Is Good!

Also, this is based on a talk I gave at LeicesterJS. You can listen to that talk on the podcast as well!