To grow as an engineer keep risking failure
That’s the moment that an artist really decides who he or she is. If they keep on risking failure, they’re still artists. Dylan and Picasso were always risking failure. This Apple thing is that way for me. I don’t want to fail, of course. But even though I didn’t know how bad things really were, I still had a lot to think about before I said yes. I had to consider the implications for Pixar, for my family, for my reputation. I decided that I didn’t really care, because this is what I want to do. If I try my best and fail, well, I’ve tried my best.
— Steve Jobs CNNMoney/Fortune, November 9, 1998
One of the most important characteristics of making progress in any area as a software engineer is being willed to fail or to let things fail. More precisely, being willing to risk failure. By risking failure, there is an opportunity for growth since it forces you to move out of your comfort zone. That’s why usually senior engineers have stories of many failures, when they deleted a DB in a critical moment, an ETL job stopped working for a week without anyone noticing or reports have been sent out on the wrong date in a particular location. They were taking a risk. Sometimes based on (over)confidence, sometimes based on prayers. All of these stories span from people willing to risk the possibility of failure. And the many stories we don’t hear about are those where the pipeline worked for years with minimal intervention, a new database is running in the background after migration with no downtime, multiple services simply working. Unfortunately, stories of things just working ™ are not as popular, published or promoted. But all good stories of personal growth as an engineer come from a place of the willingness of risking failure. Modern tooling makes failure easier. For the most part, we now have the ability to rollback to previous versions of applications with a click on a webpage. I hope you can do it with a click, and if not, source version control software like git can help with moving to another point of the source codebase and at least get the fire out of the way.
What happens when we are afraid to fail?
It might delay things by adding more checks than the impact of a feature might require. Some people will even argue over the viability of a solution trying to deter others from touching sensible parts of a codebase. What are sensible parts? Hot spots in the application are frequently called endpoints, modules and libraries that have existed for a long time and no one wants to touch, pieces of code that when it fails, execs are called or pagers are sent in troves. You would argue there should have been tests and other environments and all of that. And probably was, still, the live and breathing application, a.k.a prod keeps being the soil of the best bugs you can possibly find. And nothing is real until it is in prod and being used. Nothing beats reality. What are you missing by not risking failure? First the opportunity to improve a part of the codebase that others feel adverse to. And growth. Your own growth. Confidence and skills are both acquired through doing. Going through the motions. When you deflect to other engineers to take care of the hot spots you are deferring your own growth. You are also refraining from accountability, which is another important characteristic of progress as a software engineer. Staying accountable for things possibly breaking can only lead you to be more careful of them not breaking in the first place. Or at least incorporate ways to debug issues and observe the application behavior better.
When risking failure works against you
Risking failure is great when you are starting in your career. There is literally not much to lose. However, for many people, risking failure in a career that does not see them as default is too risky. It can mean risking everything. This creates a paradox of growth, you can’t show growth without risky projects, getting risky projects can mean a bigger risk for your position in the company. So many times people would just stay put on simpler tasks. Or getting instructions of what to do from others, let the consequence of making a decision ricochet their position or careers. This is of course not serving them or the company and in the long run not serving anyone.
Being willing to fail does not mean is easy
Risking failure is not easy, nor should easy be an expectation. Tasks can be hard in either the technical complexity, the business complexity, or the newness of some aspect of it. It is sometimes nerve-wracking and stressful. It requires more work, more attention to detail and better emotional agility. It also means putting yourself on the proverbial line of fire. And that’s is what will propel your growth, and make your experience more than a reflection of the same work over the years.
