I have spent a lot of my forty work hours a week over the last five years looking for a way out of burnout. Sometimes, it is an active process. I write plans about the next phase of my life, make changes, or throw myself into a new job or hobby. At other times it is more passive. I stare down the clock in my latest chair-warming job. Then I can get home to stare at that clock and warm a more comfortable chair.
It Is Just A Job
Some people say that their route to a more fulfilling life was to abandon professional pride. They treat work as a necessary evil that pays the bills and enables the music, parenting, flying lessons, extreme crochet or other activity that acts as their outlet for self-definition. That does not work for me. I am like the stick figure in XKCD #386 who cannot go to bed because someone is wrong on the internet. To me, the whole world of software could be better. I feel a personal mission to make it better, and a personal sense of underachievement because it is not better.
I cannot disentangle the causality. Is software broken because I burnt out, or did I burn out on the realisation that software is broken? I do not know. To quote Hemingway, this state crept up at first slowly, then all at once. I have discussed the all at once part before. It actually feels self-righteous, being either the only person of at least one of a select band of the enlightened. The few who “get it.” I get to sit there, not contributing to what I know to be the problem. By not contributing at all.
Damn Them All To Hell
This is also very isolating. Whether your One True Way™ genuinely is the better way, people will not want to deal with the cynical manner in which you tell them that they are doing everything wrong. Of course they do not. It is neither a kind nor a helpful thing to say. And of course, you do not really want to hang around with those losers who do not get it, anyway. If you find a playlist of my developer conference talks, you will see a long gap. It is not just that I did not speak, I was not there. A lot of friends that I had made there became people I stopped talking to. Apparently because I thought I had some insight into how the abstract representation of little lumps of silicon worked. Because I was angry that this insight was not shared, that the light was not shining uniformly.
Life was like perpetually living the last scene of the Planet of the Apes. The scene in which Charlton Heston discovers the statue of Liberty, realising that the world of humanity has been destroyed through humanity’s own idiocy. I apologise if I have just spoiled Planet of the Apes for you. It is kind of an iconic scene, so I expect even if you have not seen it, you know it happens. The world of software engineering is not brilliant at maintaining and sharing its own history, but the glimpses I got gave the impression of some antelapsarian or antediluvian land of milk and honey in which programming was more thoughtful, more careful, more betterer.
A Guide To Burnt-out Software Engineering History
Ada Lovelace showed me how to design a computer program when nobody had even built a working computer yet. Grace Hopper demonstrated empathy in programming language design. Edsger Dijkstra taught me how to prove that my software worked, and Bertrand Meyer showed me how to compose big provable systems out of small provable systems. Meyer relied on the work of Alan Kay, Adele Goldberg and others, who showed generally that big computer programs are best made out of independent small computer programs, running conceptually on independent small computers. Richard Rashid and Avadis Tevanien let me into the secret of what an operating system would look like if you built it that way. Sophie Wilson proved that one person with a microcomputer can design a CPU architecture. Niklaus Wirth went one better, and designed everything from the hardware to the applications.
Wirth’s insight was conceptually expanded by Donald Knuth, Kent Beck and Ward Cunningham, who showed that the best way to build a large capable system is to start with a small capable system, and work with a small capable team.
Somehow, the millions of people doing scalable Scrum to shovel their story points of Javascript into a container running on a 1970s minicomputer OS, sitting in a virtual machine on a hardware platform evolved from a washing machine controller, did not seem like the lesson we were meant to learn. Tricking the machine into enabling anything beyond a megabyte of memory by leaving “real mode” did not seem like the apotheosis of our art.
From Nothing To Something
Of course, I did the most obvious thing in the circumstances: nothing. In my headcanon, I was mere months away from becoming the instigator of a new computing revolution. A system based on the things I had learned would eclipse Windows, macOS and all of the other contributors, with a lean team of a half dozen or so people. It is easy to see how my strategy of barely producing anything at all would get me there!
Gradually, though, things did begin to change. The lesson I really needed to learn would be taught to me later, but somehow I started acting on it anyway. Once it became explicit, its effects accelerated. A friend told me that what I needed to do was to tell stories. A signatory of the manifesto for Agile software development told me that.
We were reflecting on the direction taken by Agile software development and its proponents. It is easy to see that a collection of values, principles and practices created by people who were “uncovering better ways of developing software by doing it and helping others do it” had run out of steam. People talk about dark Scrum and its effects on workers down the software mines. Suspicion is cast upon “scaling Agile” frameworks, and on the processes promoted by people selling what they claim value “individuals and interactions over processes and tools”. It was in this context that we discussed the importance of telling and repeating stories.
Story Time
If a story is told once, even if it has a huge impact, that impact will still lessen with distance and time. Being disappointed in 2019 that the Agile manifesto is no longer effective is like turning up to an American Independence Day party on July 5th and complaining that you do not see the fireworks. But on July 4th, the fireworks were loud, bright, and easy to notice. And the story of that July 4th party is itself derived from the story of July 4th 1776.
All of the truly impactful, enduring stories survive not because they were told, but because they were retold, added to, and reinterpreted. Jesus and Mohammed have a huge influence in the modern world not because they told their stories hundreds of years ago, but because people are telling their own stories about those people and those stories today. Each of those new stories may individually have a small impact, and the focus of the message may shift over time, but collectively these stories reinforce and redistribute the central message. The story is regenerated each day.
So telling stories is important. Half a year ago, Adrian and I decided to come together and share our stories, along with those of our guests, relating to what we see as important matters in the world of “the software itself.” But telling stories does not just involve broadcasting sentences at recipients. It means understanding who the listeners or readers are, empathising with them, and understanding how the story will resonate. Sharing stories undoes the isolation of burnout, by forcing you (or me) to connect with others.
Getting Up In The Morning
A month ago, I shared the story of my burnout, including the fact that it was a story without an ending. I asked who else had experienced this, and what they had done about it. The empathy and connection was overwhelming. So many people were going through, or had been through, similar situations. And they wanted to share their experiences, commiserate, or ask for help with their own cases. When people tell you that “you are not alone” in dealing with mental health issues, it is no mere platitude.
One person, the lobste.rs user olivier, mentioned the concept of Ikigai. It is a Japanese word, translated as “what you live for”, and describes a framework for finding your purpose. Your purpose is at the intersection of what you love, what you are good at, what the world needs, and what you can get paid for. I saw in this an opportunity to find the work that would have meaning for me. Taking some coloured marker pens and a sheet of static whiteboard paper, I drew the Ikigai idea as a four-circled Venn diagram. I thought about each of the things that are important to me, and plotted them on the diagram. Then I explored how to shift or combine them into the magic Ikigai region where all four circles intersect.
To The Exit
I came up with this mission statement: “I make it easier and faster to create high-quality software that respects privacy and freedom”. This is a story I can tell other people, to help them understand what I do. It is a story I can tell myself: both to remind me of the value of my work, and to consider whether an opportunity advances my mission. If it does not, I am merely keeping the chair warm until the next time I quit.
It does not matter if some work is only tangentially aligned with the mission. That work tells a small story that supports and reinforces the bigger story. It is a step forward. A step toward being proud of my work again.
Cover photo by David Monje on Unsplash.
