As the lead developer at Overit, I’m consulted on a daily basis for my ‘expertise’ by clients, by account managers, by business owners, by colleagues and by my own team to create solutions for problems I’ve never thought about before. I’m expected to be on the top of my game and ready with the right answers to problems, even when I have little to no background knowledge of the particular situation. I’m asked for my opinion, my advice and my solutions.
When that’s not happening, I’m writing code. I’m calculating every permutation of an application’s logic. I’m anticipating a user’s interaction with unknown data. With every line of code I write, I’m thinking not only about what problem I’m solving but what problems my code could introduce into the grand scheme of an application as a whole. I’m keeping track of an assortment of variables as they are manipulated by a half dozen files and even more functions within my codebase.
My livelihood – hell, my identity – is based on my mind working at 100 percent efficiency and 100 percent capacity, literally, 100 percent of the time.
I do this – and I believe I do it well – not because of any inherent awesomeness on my part. I do this well because of my experience.
I do this well because I’ve FAILED.
Yes, I’ve failed. More than once. I will fail again.
Sure, that’s not exactly something you want to hear a developer say, right?
It’s okay to talk about failure, because we all have failed.
It’s not a popular conversation to have – the one where we admit we’ve failed – in any profession. Especially in the development field. We’re supposed to be the brilliant minds behind success. We’re supposed to know the answers. We’re supposed to be the smartest people at the table.
We’re not supposed to be human.
In interviewing developers for a position within our team, I always ask one particular question:
“When have you failed?”?
You have. It’s a given. It’s inevitable. It’s a question for which I get an answer just 30 percent of the time. I’m often met with a sideways glance. It’s looked at as a trick question, but it isn’t. I know, of course, to admit one’s own fallibility isn’t something generally done in an interview.
I’ve worked with amazing developers throughout the country, including people at the top of the profession. We’ve all failed. We all have that project that just bombed – and it always sticks with us. For whatever reason, it didn’t work the way it was supposed to. Think about every developer who worked on the Apple Maps application. It failed. We know one guy got fired, and there are probably more that we don’t know about.
For me, failure came on a large application I was building years ago. It was an application that collected large amounts of data from users and created analytical reports based on that data. I was younger then, I was trying to prove myself, and I was thinking I knew everything. I dove in. I was excited. I had it all figured out in my mind. I was soloing this project, and I was going to be amazing!
About a month in, after countless sleepless nights, I realized I screwed up. I remember spending a complete 18-hour stretch writing a mind-bending, 2000 line function of purely procedural code that confused me even while writing it. When I finally tested it with data, I realized – in a bizarre mix of horror, panic and heartbreak – that it didn’t function as intended.
I was tired. I was in over my head.
My team saw this. They watched as I made mistake after mistake – to patch up other mistakes. They stood by, and they watched. My team’s director and our lead developer watched as I buried myself deeper and deeper.
They did the best thing that has ever happened in my professional career. They let me fail.
Any they knew it.
My team let me fail, and I became a better developer from it.
I was finally forced to admit that I, the brilliant programmer, had failed, and that I had a lot more to learn. Within a weekend, my team swooped in, rewrote functionality that I had messed up, and fixed it all. It launched, and much of my code made it to production, but it was in spite of me.
The application went on to be a success. I was credited with working on the project. People patted me on the back. My team knew what happened, but nobody scolded me, nobody pushed me out, nobody fired me. Instead, the team (myself included) moved on to the next project. And then the next.
They didn’t need to point out my failures. I did that myself. I thought about quitting. My ego wasn’t just bruised; it was shattered in a million pieces. I wanted to go back to being a waiter… I wanted to remove “application developer” from my job description.
Instead – I forced myself to grow.
I identified where my shortcomings were. I studied the parts of the code that I didn’t get. I studied the fixes my team came up with to problems that I wasn’t able to solve. I learned.
I realized that I didn’t plan enough, and I didn’t think through the data well. I didn’t take into account the entirety of the application. I failed to correctly analyze the scope and scale of the data, and I failed to understand how that data would be used.
I’m a better developer today than I was then – and it’s in large part because of that project.
Nobody likes to fail.
Failure – specifically as a developer – is hard. It’s a snapshot of our minds that we put into every project. How we think, how we compute problems in general – it’s all out there, plain for everyone to see. It’s deeply personal.
And when we fail, it’s as if someone is critiquing not just what we do, but who we are as a person. When we fail, we realize that our minds aren’t processing data the way that we expected them to. When we fail, we realize that we didn’t just fail at a job – we start to question how we think in general.
Coding is complicated. Just like life in general, we learn. We grow. Failure in programming is – just as it is in life – inevitable. It’s a given. We’re supposed to, and thus, failure should be embraced. Failure should be an expectation. It’s essential in our personal growth and in our professional growth.
Today, I lead a team of highly talented developers. Even as I lead them, I know that – just like in life – I am surrounded by people who back me up – just as I will back them up.
What matters most is what we do in the face of failure – how we fix our mistakes, and how we grow. In our case, I’ve seen developers take projects they’ve messed up and completely refactor the code on their own… not just to fix problems but to prove to themselves that they can do it. That they’ve failed, but they’ve learned from it.
I’m never going to like to fail.
It will happen. When I fail again, I will learn from it. I will grow. I will be better, because failure will teach me.
Several months ago I looked back at the code for that application I wrote all those years ago. The crazy 2000 lines of code that didn’t make any sense then made even less sense now.
I rewrote that code for my own satisfaction – proving to myself that I could. That I learned. That I was better.
It took an hour.
