The title is not a typo.
In the software development industry, failure is not only tolerated, but expected. Software development is hard, it changes constantly, and no one can reasonably be expected to understand absolutely everything at once. Everyone fails to a certain degree, though some more than others. Even upper level engineers sometimes don’t succeed, and that’s okay.
What is important is how you treat failure. Each instance of failure should be a learning experience – deep down we’ve all heard this trope, but in practice it is harder than we sometimes realize to take failure as anything other than personal. It is truly a sign of a strong individual when one can fail gracefully.
The other important part is that once we realize failure has its upsides, we can look at new experiences in a different light – one in which we either succeed and learn something or fail and learn something. In either case, we have accomplished something, even if it wasn’t necessarily the end goal. When we do this, we reduce the consequences of failure – we make molehills of what we thought were mountains.
Understanding Failure
Failure can be a simple thing, or something with more consequence. This post will cover both.
Maybe you pushed a feature out that had a particularly nasty bug. Maybe you overran a deadline you committed to. Maybe you accidentally deleted some important production data with a bad update statement (WHERE clauses save lives). Maybe you were fired.
All of these things produce a negative emotion to some degree. It’s important to view them impersonally when you’re trying to learn from them. And it’s important to not make a mountain of a molehill when you don’t need to; rather, it’s much more useful to make molehills of mountains before you fail.
This is not to say you shouldn’t feel sad or angry or whatever emotion failure conjures for you – it’s just important to realize that failure is not the end of the world and it does, in fact, get better if you learn from whatever mistakes you may have made. This is definitely not a nihilistic credo that I’m pushing.
To go back to our previous examples, maybe you could do some more manual QA before you pass off your code to prevent that nasty bug from making it to production. Or you work on your estimation and communication skills to either stop deadline overruns or better communicate when it happens. Or you work with your organization to put guardrails in place to prevent data loss in your production DBs.
The last one is a special case – getting fired has larger consequences than the others.
On Getting Fired
New and mid-level developers alike (and newer workers of really any industry) are usually somewhat fearful of being fired – imposter syndrome is very alive and well. That’s totally understandable – after all, this represents a failure with huge consequence, usually a loss of income for both yourself and any dependents you might have.
If you have these feelings, I encourage you not to fear it, though, because this really is a molehill and not a mountain. When you do this, the stress and negative emotion seeps into other areas of your life and you end up setting yourself up for failure in the future. Often, this is for no reason, as especially right now the job market is so hot that it’s incredibly easy to find a job where you are financially compensated as well or better than your current job. In fact, it’s more likely than not that you’ll bounce back.
Benefits of Molehills Over Mountains
If you make a mountain of a molehill, it’s easy to look up from the base to the peak and despair over the effort required to climb to the top. If the task is particularly important to you, you’re now more likely to fear the consequences of failing to summit your not-mountain and delay starting the task at hand because of it. You’ll procrastinate to prevent yourself from experiencing negative emotions rather than be proactive to experience all the positives you’ll gain by undertaking the task – even if the positives outweigh the negatives!
Conversely, and perhaps counterintuitively, the opposite approach reduces your stress and allows you to tackle the task at hand with a better outlook. You will likely perform better at the task and accomplish it more quickly and easily than you otherwise would have, and it’s all due to the outlook you take before you start.
The great thing is, this applies to all aspects of life, not just software development. It is simply a particularly good time to take advantage of reducing the consequences of your tasks as a software engineer because the cost of adoption of this technique is so low – minor failures are expected and egregious failures lead to loss of job. But as we’ve already covered, the job market for engineers is so hot right now it’s likely you’ll emerge on the other side of that on par if not better than current state.
A Personal Case Study
I practice what I preach.
At my last job I took on a project I really had no business handling (I didn’t choose to take it on, and I did warn that I thought it wasn’t a good idea). I was too junior, the deadlines were too tight, I had almost no help, and the consequences of failure (for the business, not me) were just too high.
The task was to convert and migrate all the data from our primary Rails monolith application that had been around 10+ years to a 3rd party vendor who had set up a custom API for us to do so. It would need to be packaged into huge JSON files and uploaded into the partner system, and we had about an 8 hour time window during off hours to try to get this done. The partner system could only accept the data in batches of 10,000 records at a time and it took about 2 minutes per batch to upload (!). We could reliably process at most 8 batches at at time, and the data needed to be inserted in the right order to ensure that everything went in cleanly. This meant that if a particular batch failed, we needed a robust way to handle that failure and retry it as it meant that all the subsequent data was blocked until it was resolved.
Now, I’ve neglected to do the math here, but suffice to say with the given constraints, the timeline this gave us would have been described by business leaders as “aggressive” and by me as “impossible” and possibly “insane”.
This project was doomed to fail from the start – and it did, spectacularly.
Don’t get me wrong, I put a lot of effort into making it work. I even got reasonably close to the time limitations by letting the process run over a period of weeks before the migration was scheduled by allowing it to capture only the deltas between subsequent runs. I was incredibly proud of the work that I was able to put forward – it represented a huge learning achievement for me and it was by far the most complicated project I had worked on to date. I became somewhat of a leader on the team that I was on because it showed that I could architect elegant solutions to complicated problems with very little oversight.
But by anyone else’s account, it failed.
In fact, it failed so spectacularly that I ended up leaving that role. I had told my wife before I started working on the project that if conditions didn’t improve (i.e. they didn’t listen to the myriad concerns that I had with the project), I would look for another job. And so I did, and I found one that I currently have using the experience I’d gained from my “failure”. On my last day at the company, the CEO sent out an email halting all work on the project I had worked on, and took steps to sever the relationship with the vendor I’d been working with. Last I heard, they’d completely cancelled the project altogether.
So while this was a failure for the company, it was a success for me – I’d “failed” to accomplish my goal, but I’d gained extremely valuable experience, a new job, and higher compensation, all without sacrificing stress for something I couldn’t directly control.
Some Other Mountains Molehills of Mine
All of these things are events in my life that I was at least a little uncomfortable with before I started tackling them. Over time, I’ve used them to learn to accept failure and have become a better human as a result.
Cycling
I started cycling in 2014 when I was 20 pounds overweight. I think for my first ride I averaged 14 miles per hour and traveled only 7 miles. It was difficult.
Fast forward to today and I’ve completed multiple imperial centuries (100 miles), regularly average 20+ mph, and race competitively. Strava says I’ve ridden over 22,500 miles since I started. I’ve even ridden and raced against (and beaten!) people who are now professional cyclists! Looking back, I would have never thought this was possible.
My Bootcamp
I (like many others) dropped a lot of time and money into a bootcamp. I couldn’t have afforded to fail, but I didn’t let that stress me out.
I told my now wife that I wanted to enroll in January of 2019, I enrolled in February and got engaged 1 week after starting. I finished the bootcamp 1 week before getting married (after only planning a wedding for 3 months, wow!), immediately took a job 4 hours away, and moved 1 month after getting married. My new wife didn’t get to move with me, so we lived apart for 4 months til she could make the transition as well.
If you want to talk about tough and stressful (i.e. a mountain), I could have let this really get to me. But I don’t regret it one bit, because I’ve refused to let it under my skin. Today, this has set my family up for future successes and provides for the lifestyle we like to live.
This Blog
I don’t consider myself a particularly eloquent writer. I treat this blog more as a stream of consciousness for whatever’s on my mind at the time. Sometimes I get technical; sometimes I don’t. It’s really whatever I feel for that day.
When I started it, I questioned who would read it, if anyone. I conceded that the answer was probably “no one”, so I just started posting musings for fun. And to be honest, I’m a little uncomfortable with the thought of lots of people reading what I write, because it means I feel I need to put lots of effort into the content.
All that went away earlier this week, though. I posted an article to Reddit titled Metaprogramming Smarter Hashes in Ruby that I had written about a toy gem I wrote. I got a couple hundred views from that posting, but then it was picked up by Ruby Weekly and featured in their weekly mailer. All in all, a couple thousand people viewed my little article.
Literal Mountains (Ha!)
Yeah, I’ve hiked and ridden up a few of these.
One time, I did a 16-hour road trip with my cycling training partner to spend 3 days riding the mountains of Boulder, Colorado. Or when my wife and I honeymooned in the Pacific Northwest and spent a day at Mt. Saint Helens (I was the weird kid that wanted to be a volcanologist when I grew up).
What’s Next?
Well, the great thing with this mindset is that once you start tackling things that you previously thought were difficult in the past, it becomes sort of a flywheel in your life. Once I realized, for instance, that the time and money spent in my bootcamp was insignificant compared to the result it brought me, it also made me realize that going back to school for other things is totally within my grasp.
I think in the next year I’d like to learn to fly a plane. Maybe we’ll travel the globe. My wife has started talking about running her own business. Maybe I’ll take up woodworking or some other physical hobby.
All I know is those mountains are starting to look smaller every day.
That’s all for now. Thanks for reading!
- ← Previous: I Now Hate Liquid
- Next: Building Raspberry Pi-Powered LED Sports Scoreboards (and Other Displays) →