skip to Main Content
green palm tree

Key element – Serenity

It’s not uncommon to feel a lack of peace at work, regardless of the work you do. However in software there are so many ways in which we do not control the environment that our work occurs, leaving us with the difficult challenge to find serenity in our day to day efforts.


I want to address the potential questions you might have about what “pride, serenity, and inspiration” might have to do with building software. I chose these three positive emotions because I find them to encapsulate the most important characteristics of being a really healthy software developer.  It’s important that we strive to build software that we can be proud of, and to do so with balance and calm so we don’t succumb to external forces, while consistently finding ways to keep our motivation and creativity.

It’s not that I’m pushing an argument that software is not mostly a science. Rather I’m saying there is an art in it as well, and if we include this in our model for building software then we must address emotions. Software is a human endeavor. People build software, and work with other people to build it, and we all have emotions, so it is critical we do so with positive emotions to make the outcomes more durable.

Why is this any different than other coaching to help work with people? Simply put software is the most prolific form of work, wherein the outcome has the potential to reach millions and even billions of people. Not only in the usage of software, but also in the building. For some of us the software we build is used by other developers to build their software, and that has a compounding impact.


There are many practices to improve one’s inner peace. Some of them are derived from religions, and others from natural humanistic beliefs. Serenity is a word I use to define that inner peace because I find it adds an additional quality that is important: the ability to continuously encounter uncontrollable forces and find peace. Software has a unique characteristic that makes it very different from other forms of building or engineering, and that it is forever faced with changing environments. All the way from chipsets executing the logic, to the languages we choose to write it, to the versions of runtimes it runs on, to the resources on the server it’s running, to the data being provided it, and finally from the users that may operate it.

There is no way to control any or all of these environments with absolute certainty. So if this is true, and we cannot change any of this, then why do we suffer any emotional friction when any or all of those things bring problems to our software? This question is why serenity is one of the key elements of coaching for Attainable.

Accept those we don’t control

The quickest way to upset a software developer is to assign a deadline to anything they’re building. And that is just one single variable in the development of software, as we’ve already established! If this is how easy it is to disrupt our inner peace, what chance do we have for serenity if everything is out of our control?

We ourselves are not out of our control. We can find ways to mitigate and in some cases resolve issues that arise outside of our control. Software developers can make design choices that improve the conditions for these issues. Teams can create processes that are flexible and accommodating allowing for disruptions, but not destroying momentum. Software is infinitely changeable and therefore adaptable to many unforeseen issues.

More to the point, we can simply control these problems by accepting that we have no control and committing to finding a valuable solution. That’s a tough one to digest. It’s not the easiest thing to do, and it takes practice.

  • make resiliency a first-class design choice
  • write code that is impermanent, and open to change
  • deliver working software everyday, just-in-time

Change those we control

The phrase “context is everything” is important to completely absorb. When we encounter issues with software, it is a high likelihood that we create more of a problem than truly exists, simply by how we respond. Usually this is because we’re ignoring the context of the problem, filling in the gaps with opinion, and creating a biased and unfounded situation for ourselves.

Most often this occurs when we try to decide the quality of our software. Let alone the myriad ways we might test our code, and the value of those tests, how we write our code is a judgement of quality that we’ll rarely control. Invariably we find ourselves defensive or insulted when our work is judged, and in the other direction we over-assign the intention of others when judging their work.

However serenity can be found, and is a skill that can be grown in this regard. If we are mindful that we learn everyday, and that today’s great idea is tomorrow’s worst headache, we can also remind ourselves that we are not our code, and that should allow us to change it.

Know the difference

The difference between the things we can and cannot control is usually us. It is rare that software is forever imprisoned by an external force. Instead it can be changed, and that is entirely up to us. We control when or how that might happen.

Deciding which things are unchangeable vs. things we can change, is also not something we have to address by ourselves. In fact, in many cases it’s best if we seek feedback about this. How often have you spent time on a problem, only to learn later that the rest of your team didn’t think it was important?

  • Ask for feedback to drive clarity
  • Trust your team to help discern the issues

What can we do?

Serenity is not something most of us are naturally gifted with. It takes practice, and is not an easy skill to acquire. Our own personal beliefs and opinions very often get in our own way. Finding ways to separate our identities from the problems is usually the best first step. But it requires more than that to persistently find peace in software development. It requires repeated acceptance of the things we can’t control, the diligence to change those things we can, and the mindfulness to know the difference.

I am an engineering manager, product engineer, full-stack developer, and professional coach, with over 20 years of experience in application and systems development. I am successfully putting together code and culture for any size team, from enterprise to start-up.

Back To Top