Inspiration is found in many places, and is different for each of us. And because of the nature of business and capitalism, it’s sometimes very difficult to find or maintain inspiration for our work from an artistic perspective. And worse, we sometimes don’t believe it should be inspiring.
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.
In fact there are a few ways to consider inspiration in software development. Clearly there is the internal version of it, that we use to keep us excited and proud of our work. But also there is the external version of it that we use to give ourselves reference examples and move us past the blank white screen problem. Whatever your opinion regarding how much science vs. art there is in software development, nearly all of us would agree that without inspiration in some form, it is very difficult to write code.
Inspiration is important because it gives us fuel to keep going. In some ways it helps build pride in our work. More importantly it provides an answer to “why” we build our software the way we do, that is outside of the more traditional and scientific answers. At very micro-levels, inspiration helps shield us from monotony and boredom that very often creeps into our daily experience. The next time you’re reading older code that isin production, working, and presumably has no bugs, and you have the gut instinct to rewrite it, ask yourself with the utmost honesty: Am I wanting to rewrite this because it absolutely technically needs to be, or am I simply bored (uninspired) by the way it’s written now?
If you answered this question with honesty, you might be surprised to find that boredom is a significant root cause for refactoring code. And if that is true, then why not approach it with the goal of finding inspiration? Who says designing and writing code can’t be inspiring?
When we consider internal inspiration it’s easy to confuse it with our sense of drive or motivation. And to really understand our internal inspiration, we have to start with the question “why are we writing this code?” There is the obvious and relatively static answers like it’s our job, and because the business needs it. But neither of those are answers for inspiration.
The real answers for inspiration are deeper in those questions. In fact we have to look deeper for inspiration in many other ways, that we might not recognize. Here are a few more questions that we can ask to help find inspiration:
- Why am I structuring the data this way?
- Why am I testing the logic this way?
- Why am I using this particular language for this problem?
- Why am I designing the system this way?
It’s likely you read those questions and said to yourself “these are pretty standard design questions and don’t seem related to inspiration.” That could be true. You could simply focus on the science and rigor of these questions, consider the architectural trade-offs, the performance characteristics, and any number of other more structural and fundamental properties. But what if we answer those questions with more introspection? What if you’re interested in making your code beautiful?
As Marcel points out in that conference talk proportion, integrity, and clarity are properties of code that can make it more beautiful. And the inspiring quality of this idea is that those properties are not detached from the science and rigor of the code. In fact, they elevate the code.
Finding external inspiration for our work is very often overlooked because it is right there in front of us, in old and stagnant corporate ideas of value. If we unpack some of these things we can start to find more ways to achieve and deliver inspiration. What’s inspiring about building a feature that saves your users hours of time? Is it not important to empathize with your users and to appreciate that on any particular day your software “just worked” for them and saved them headache, hassle, and frustration?
Very often we detach ourselves from the end-users of our work because frankly we’re just not in front of them enough. Some developers can write software for years, and literally never meet a real user. In corporate or enterprise sized companies, this is likely the case. This is unfortunate because we never get to see the full impact of our work, both in good and bad ways. For example, nearly all of us would feel terrible to learn that our work created toilsome working conditions for our users. Rather we all want to build software that makes work easy for people.
What can we do?
To begin with we can acknowledge that inspiration is important for us. It isn’t some fanciful emotion that can’t be used in our day-to-day experiences. Instead it’s a key element to our health. We can find ways to be mindful about our internal inspiration, where we are getting it, and how we are applying it. There are also ways we can practice improving our inspiration by understanding the impact of our work and what value it truly brings to others. With coaching we can build skills to be able to look further than “our jobs” and to find ways to build software that is inspiring.