Tell me you’re a senior software developer without telling me you’re a senior software developer

How do you recognize a senior software developer. It’s not like they all wear badges or have custom-made cups. Well, some do, but not all of them. I think the easiest way to recognize a senior software developer is by the stories they have. You can judge one’s level of seniority quite well by how many, and what sort of problems, they had to go through.

I broke the production environment.

Introducing a bug in the production environment is a rite of passage for software developers. If this is the first time it happens, it might feel like the world is about to end, but there are some valuable lessons to be learned when the dust settles: 

• You learn to keep calm under pressure – Running around and screaming is not a particularly effective problem-solving strategy. You have to stop, take a deep breath, and have a long hard look at the state of the world you are in. You need to calmly assess, what is broken, what are the symptoms, what changed that might have caused the issue. And it does not come naturally, it’s an acquired skill, one that you must master before calling yourself a senior software developer. 
• You learn to be results focused – The first order of business when there is an outage is to make sure the production environment is up and running. That’s it! That is the focus. All the actions you take should be moving you closer to that goal, or they should be deferred for another time. This is another skill that can be learned: prioritizing under pressure and ruthlessly push back on anything that is not essential to achieving the target
• You learn how to improve so it doesn’t happen again – After the dust settles, and the production environment is back up, it’s time to put your detective hat on and dig through the rubble. What caused the outage, why it happened, how was it not caught before it made its way to the production environment. With all that info, it’s now the time to harden your release process. Add checks and balances to prevent a similar issue from happening in the future. And you have to have the commitment to push for the fixes to be implemented. It’s easy to say, the issue is fixed, it’s not a problem any more, but a truly senior developer knows that the issue is fixed for now and, if the root cause is not addressed, it’s only a matter of time before it happens again.

I had to pay the price for my decisions

As time goes by, you start accumulating some battle scars. Some of those scars will be caused by none other than yourself. Decisions have consequences. And some decisions have long term consequences. 

There is an art to making good long-term decisions. And, in order to improve, you need to make decisions and suffering the consequences. It’s a two-step process: Step one is being asked to make the decision. As time goes by, you will be asked to make more and more decisions. When you start out, you have limited impact on the project by design. However, as you progress in your career, you, usually, find yourself in a position to make harder and harder decisions, with wider and wider impact on the team, project, department, company etc. 

Step two is staying around long enough to suffer the consequences of your decision. You might not want to hear this, but there is value in staying with a company for a few years. There is a lot to learn from observing how a team, project, company, department evolves over the years, from the inside. Making small, incremental changes and seeing how those changes shape the future. 

A few lessons a developer picks up: 

• You need to keep in mind the long term consequences of your decisions. Your plan might look like a fantastic idea now, but if in 3 years time you will have to be the one to fix it when it breaks, you might consider another route.
• You learn how to implement a decision from start to finish. Changes have to go through a process. Some team members might embrace it, some might disagree with it. You learn how to harness your team member’s enthusiasm and give reassurance to the sceptics. And learning to maintain the pace through a long-running change in an invaluable lesson. 
• You learn when to reverse a decision: Things don’t always work as expected. A good software developer should be able to tell when it’s time to cut your losses and change course. 

I had to take the blame for someone else 

As a senior developer, you are often given ownership of tasks you are not meant to implement, but delegate. And, inevitably, sometimes there are problems with the tasks you delegate. A senior developer should be willing to take the blame if the task failed, even if he wasn’t the one doing the work. And they should do that for several reasons: 

• First, it was your task, you got the assignment and it’s your responsibility to ensure it gets done, regardless of who does the implementing. Next time, put in place processes and checks that prevent issues when handing over a task. And learning how those processes might look is valuable knowledge.
• Second, it fosters an environment where junior people can learn and grow when they know you got their back. 
• Third, it teaches you how to grow a thick skin and not be affected by criticism, how to present bad news to your bosses and that you need to follow through with your actions, good and bad results alike. You will find this to be a really useful skill. 

Conclusion

Getting to “senior software developer” is a journey, and some steps are not always pleasant. Everyone makes mistakes, but a true professional is one who learns from the mistakes and becomes better for it. 

Further reading

Your estimates are probably wrong, but you should do them anyway

You’re not writing code, you’re solving problems

What you need on a programming job — besides programming skills