Applying Software Engineering Principles to Our Minds

We plan our code with a lot of care. So, why don’t we look inward with the same care?

Photo by ThisisEngineering RAEng on Unsplash

I’ve been a professional software engineer for a year and a half now. I see a lot of stressed people in this industry, and I see a lot of people who have opinions about how to build the best system. Do we build something with maximum simplicity, or with the quickest method? Or do we build something with the latest, hottest libraries? How thorough does end-to-end testing need to be? Do things we build need to be able to shift and grow in the future?

I recently wrote a post about meditation for software engineers, and I wanted to continue that line of thought. In this post, I will discuss the ways these engineering dilemmas apply to our minds. How can we make ourselves better humans by following these principles?

Make it Boring

I went to a talk at JSConf 2019 by Jeremy Wagner called Make it Boring. This opened my eyes to the idea that some engineers think it’s great to create a system without frills and complications. As a junior engineer, I assumed that making code fancy was what all the experienced engineers did all the time. Apparently not.

What this really means is: it’s a good thing to keep things simple. When we think about making our thought processes simple, it seems beneficial because we often let the thoughts attached to our egos get amplified and distracting. We might be pulled in many directions, with pressure on all sides of us. If we slow down and stay quiet — serene — we can achieve a new system for our thoughts. We can learn to guide them to a place beneficial to ourselves.

Meditation can help with this. When you clear your head and start to stay in the simple and ‘boring’ place, you will discover things you never noticed before. And trust me, life will not be boring at all once this is achieved.

End to End Testing

We talk about end-to-end testing where real scenarios can be completely simulated before the code is in production. Tests capture all the ways our code can break, and run non-production code to see if things will work correctly. Can we apply this to the mind, too?