Meditation for software engineers

I’ve noticed that there are a lot of technologists and software developers on the Wildmind Community and among Buddhists generally. I don’t think it’s just by chance. Coders tend to have life habits that make us susceptible to certain problems of mind, but yet may predispose us to the skill that can address these problems: meditation. I’d like to outline those problems, highlight why we might be predisposed to meditation, and make a suggestion as to how we can improve our practice.

Although software engineering is a craft – not unlike carpentry or gardening – it’s a craft where no manual labour is involved. The raw material is pure thoughtstuff and the end product is invisible. So we are obliged to live most of our working lives in the world of abstract ideas, never laying our hands on our work. Another useful way to describe software development is that it is an editorial process. We are always working on a draft, building it out and then honing it down, over and over until we have something that is fit for purpose. And then we start again for the next release. This is a creative process and for that reason it’s intense and personal. We begin to identify with the code we produce. A third characteristic of this kind of work is that we spend a great deal of time trying to solve problems – either by studying an overall solution to a customer’s needs, or by debugging our first attempts at that solution. We move from problem to problem and use the same skillset – logic, experience, concentration – to work through each one.

Let’s look again at this combination of factors: we spend much time in abstractions; the work is intense and creative but requires collaboration with other intensely creative people; and we approach the world as a series of puzzles to solve or problems to fix. This internal regime of mind can lead to problems both inside and outside the office.

Abstractions are necessary for navigating a complex world. Without the ability to generalize from particulars and build up a mental model of reality, we could not function as human beings. But for long periods of time this is all software engineers do. We begin to mistake our abstractions for reality (whatever that might be), and in fact we fall in love with those abstractions and identify with them as completely as we identify with our hard-won solutions to complex engineering problems.

Meditation can be a process by which we return to direct experience. Some kinds of sit allow us to observe our thoughts and other mental constructs as they come and go, while we guide our attention to simpler sensory experience such as sound or the tactile sensations of the breath. By experiencing this first-hand, we can rediscover the limited nature of our abstractions and so use them better. An abstraction that is no longer fit for purpose – because things have changed over time, or because it was too simplistic – is a liability in code and in life. In code, we know that we must re-shape these structures to deal with new requirements, and we know that even if this can be a painful process, we will get into ‘technical debt’ if we don’t do it. The less identified we are with the old idea, the easier we can change or discard it, the better our code will be, and the happier we can work. Outside the office, we need to let go of old abstractions and make way for new ones all the time. We can do this if we practice agile self-development: discard ideas that have outgrown their use, confront the pain of change as early as possible in the knowledge that if we don’t, we will get deeper and deeper into emotional debt.

People who don’t work in the software trade and only have TV and movies to go by have been taught to believe that nerds are solitary creatures who work alone (in basements) and usually have personal hygiene issues. Many offices have examples of this stereotype and if this is true of your office, you’ll know who those people are precisely because of the fact that they stand out as exceptions. Most software developers are of course perfectly normal and sociable – and this is just as well because any software project of any reasonable size needs a team and that team will have to embody communication and emotional skills if it is to deliver. Software development is a high-pressure team sport. When deadlines are looming (that’s what deadlines always seem to do – they loom!) tempers can become worn but the need for tight collaboration becomes even more important. It’s crucibles like these that demand of us the kind of qualities that a constant meditation practice can help to develop: steadiness, patience, the ability to not take things personally, and the capacity to deal with stress without exploding or imploding.

Finally, there is our approach to problem solving. This is a very transferable skill in the sense that we can use it outside of the workplace. There’s nothing wrong with this as long as it doesn’t become the only tool in our box. Life is not a software project, or if it is, it’s the worst-managed project in the history of engineering: The requirements are never clear from the start and in any case they change by the minute; the interfaces to other modules are completely inconsistent and come and go as they please; there are multiple clients, managers and bosses; the team itself changes every other day and nobody ever really agrees on a design. You can apply all the logic, experience and concentration you like, but you’re still just firefighting. The kind of problems that life throws at us cannot be traced and debugged. And more often than not, they can’t be solved either. They have to be accepted – even loved. Try that approach in the office! There is no issue tracking system that allows a problem resolution status of Accepted and Loved. In the similar but opposite way, what we find in our todo list outside work cannot always be set to Resolved or Reassigned. And yet we very often act on the habit of our working hours, and try to fix everything that comes our way, or pass it along as somebody else’s problem.

But if our choice of career can bring all these problematic ways of thinking, it also brings with it the basic tools we need to mitigate them, and first among this is concentration. I’ve recently heard a good metaphor for what goes on when an engineer is mentally working on a solution: we are building a house of cards. Each layer is built upon the one underneath, but in a gentle way so as not to destroy what we have carefully constructed so far. This is why interruptions are so frustrating. When somebody taps you on the shoulder when you are in the middle of house-building, the cards can come crumbling down in an instant. Sometimes it’s not another person who taps on our shoulder, but another thought. What will I have for lunch today? Why don’t I check the online news? In order to be productive, we have learned to some extent the importance of extended periods of concentration, and how to maintain them. When you walk around the average software house, the reason you see so many headphones and earbuds in place is not because engineers are anti-social. They are just defending themselves against the crazy but widespread policy of open-plan office space, with all the noise and distraction that this entails. Concentration, which is central to meditative practice, is something that we know how to access.

Another positive predisposition to Buddhist meditation that engineers may have is an openness to certain fundamental concepts that underpin it. One of these concepts is anatta, or no-self. Bodhipaksa has described this beautifully in Living Like a River and in many blog posts. One of the most helpful images he has used is that of the car with hundreds of people inside scrambling for control of the steering wheel. There is no single driver, but a decentralized – even chaotic – process of control-passing from one process to the next. This concept is deeply counter-intuitive to many people who encounter it for the first time through Buddhism. But to anyone familiar with computer architecture, it makes perfect sense.

An engineer’s tinkering curiosity will serve well when meditating. We’ve used the system of consciousness for long enough – sooner or later we’re going to want to understand how it actually works. I’ve heard Shinzen Young make an analogy between meditative concentration and the microscope, in the sense that if we learn how to concentrate we can look more deeply and in more detail into our experience. He might just as easily have used the idea of the symbolic debugger. Meditation can be the tool that permits us to understand how our minds work and follow its loops, uncovering problems in the software and allow us to refactor as we go.

So we have some factors in our favour, but I think we can take things further. There is a change we can make in our in order to transfer our professional skills onto the meditation cushion. As a group, we need to become emotionally smarter by learning the skill of self-compassion.

There is a phenomenon known as the Imposter Syndrome that is quite prevalent in Silicon Valley and other centres of engineering excellence. A lot of people walk into these cathedrals as employees and feel unworthy, less smart than their peers, and expecting to be uncovered as frauds. These are smart people who are carefully selected, but yet feel that they have slipped through by mistake and that sooner or later they will be found out. I don’t know to what degree I personally suffer from this syndrome, but I’ve seen something strange happening when I’m trying to solve a problem: I feel physically and emotionally unwell until the problem is solved. When I examine the source of that stress (using mindfulness meditation as the debugger) I find fear. The fear that I am not smart enough to fix the problem or solve the puzzle. The fear that I will be found out. This fear becomes the overriding motivation to solve the problem, but paradoxically it creates obstacles and only delays the inevitable solution. I wonder how many of my colleagues go through the same thing. This isn’t a very smart way to manage one’s emotions, inside or outside the office. A more kindly approach would serve better. If we can be more gentle with ourselves then over the long run we will end up being more productive, easier to work with, and happier.

The Wildmind Community is almost half-way through 100 days of daily meditations on Lovingkindness. If you find the above description of the life of a software engineer to be accurate, or if it at least sparks that engineer’s curiosity in you to experiment with meditation, then consider this an invitation to join us.