The Stanford Encyclopedia of Philosophy defines mono no aware as

a “pathos” (aware) of “things” (mono), deriving from their transience

The term was constructed by Motoori Norinaga in the eighteenth century to encapsulate the mood which was central to the Japanese. This was particularly focussed upon the impermanence of things and a slightly melancholy awareness of this. But there is also a quiet rejoicing as our awareness allows us the opportunity to witness the beauty in these.

The annual sakura (Cherry blossom) in Japan is a good example of mono no aware. Every year thousands of Japanese families visit parks to witness and celebrate the mere days of sakora. Before it falls from the trees and is no more. I recommend the excellent book Hokkaido Highway Blues if you want to learn more about this part of Japanese culture.

So why am I writing about mono no aware in my software blog?

After reading about this term I looked at my day-to-day life through the lenses of mono no aware and realised this philosophy could be applied to software engineering.

We should think about the products we build as impermanent. Often we go into building new products with a sense that they will be serving their purpose for many years to come, happly ticking along. But we know this is not the norm, most products have a lifecycle of mere years. So perhaps we should build our products for the here and now and resist the temptation to future proof and crystal ball.

If we accept that our products are impermanent, then this will lead to a fleeting awareness our users will have of our products. This highlights the importance of releasing early to ensure they see the beauty of the products for as long as possible.

This understanding of transience can also be applied to our code. We often write tests to help build and understand the product, but often there is a reluctance to delete those which no longer have any value. Even though we may have mentally sweated to create these tests we should be prepared to let them go. They have served their benefit and we have briefly enjoyed their beauty.

Accepting the codes impermanence will also help us to be less precious about changes that others make to code that we have worked on. In both commercial teams and open source projects we see examples of individuals who re-write, rollback and change others commits. As engineers we should be prepared to let others shape the code to their world view. Even if it means losing code that we have been proud of. Thanks to version control you can always go back and revisit it - like a photo of the sakura.