The ‘Joyful Work’ of Software Engineering

We rarely seem to talk about optimising for ‘joy’ in software engineering work. Why is it taboo?

We often hear about burnout in software engineering which we’ll relate to excessive working hours under excessive stress and pressure. But hard work and pressure can also be energising, rewarding, and inspiring. I’m working long hours right now, building a business during the week and building our web application over the weekends. I’ve not counted the hours and feel slightly frazzled at times, but I feel energised by my work rather than burnt.

So what determines whether hard pressured work leads to burnout or energised vitality? Perhaps it’s the sense of intrinsic ‘joy’ we derive from the work. I hypothesise that hard, pressured ‘joyless’ work’ leads to burnout, while hard and pressured ‘joyful’ work is energising.

Work

The productive and fulfilling use of our minds and bodies for the benefit of others. In essence, it’s a noble and joyful pursuit. The rewards of applying one’s mastery to unlock value and prosperity for our community, people and planet. Making our deepest contributions to the world.

But sadly, work is often experienced as drudgery and toil. Meaningless and repetitive tasks with echoes of Tailorism from which we derive little personal connection or fulfilment. Yet in the corporate environment, we feel compelled to ‘act’ as if we’re actively enjoying our work, continually attending to ‘impression management’, a performative approach to convey a certain image of us in the minds of others.

Why can’t we avoid the acting, and strive to make our jobs intrinsically ‘joyful’? Could it be that our ‘misery’ and ‘joy’ in relation to work are aspects of the many ‘undiscussables’ at work? We feel the need to hide our ‘misery’ by indulging in toxic positivity and dampening our pure creative ‘joy’ by reducing it to the acceptable and rational corporate language of efficiency and productivity. We’ll openly discuss striving for good productivity metrics, profits, and revenues, but how often so we openly talk about the upstream experience of ‘joy’ or ‘misery’ in software engineering, which is a primary influence over an organisation’s tangible outcomes?

Reggie

I have a picture of Reggie Perrin above my desk, and since 2020’s Covid times his picture has lurked behind me during video calls - my own interpretation of a ‘memento mori’ - partly a reminder not to fritter away my life on pointless activities, but also to try to find amusement in life’s absurdities.

You’ll need to be of a certain age and from the UK to remember Leonard Rossiter’s portrayal of Reggie Perrin and the absurdities of the working environment he had to endure. Watching the TV series, ‘The Fall and Rise of Reginald Perrin’ or reading David Nobb’s original book has literally brought me to tears as I relate to Reggie’s pain and suffering, culminating in his faked suicide filmed at West Bay in Dorset. I’ve secretly wanted to recreate the title scene where he strips naked and runs into the sea, but whenever I’ve visited West Bay it has either been too cold or too busy!

The actor, Leonard Rossiter, seemed to love his work. The raw energy and vitality he brought to the character shines through. But the experience of most people seems to be closer to the frustrated character he portrayed, Reggie Perrin, trapped in the absurdities and banalities of 1970s office life. Sadly, many people’s fate is worse than Reggie’s because Reggie became attuned to his authentic self through the series, and transformed as a person - whereas many of us stay stuck. Reggie had to endure the pain of not fitting in and the pain of breaking free, enlightened by seeing Plato’s cave for what it truly was, he was able to escape the chains of conformity, find his essence, and discover his own way.

Shame and fear

I can only speak of my own experiences in software engineering and the anecdotes of others, but I wonder if there is a sense of shame in talking about ‘joy’ at work. Could this be an engineering thing where we are inclined to defer to logic and rationality rather than joy or ecstasy? Do we fear being seen as weak or pandering if we express an intention to imbue a team with joy, or to unlock the potential of joy in ourselves as others?

Perhaps joy and misery are too raw, far too ‘animal’ to bring to work. The passions of the Id, to use Freud’s model. And so our Super Ego steps in with the shoulds and shouldn'ts that we’ve been socialised. We suppress our innate feelings through internalising the norms of our culture.

In the past, I’ve had snarky comments from a colleague about my management style being too ‘Kum ba yah’ or even that I should be less of a ‘union rep’ and more of a ‘boss’ - while hurtful at the time I’ve gained insight from those comments and have learned not to harbour any grudges. But it does underscore the risk in promoting the human need for ‘joyful’ work.

Personally, I see productivity as a by-product of joyful work. Joy is a good proxy for creativity, innovation, productivity and efficiency - all of which lead to organisational performance and a faster flow of value to customers.

Happiness

“I’ve never seen the happiness of your engineering team and the happiness of your users significantly diverge. I’ve never seen a team of absolutely miserable engineers creating a product that delights their users. And I’ve never seen a company with absolutely miserable users, where their engineers enjoyed their work.” - Charity Majors

Source: Charity Majors’ Recipe for High-Performing Teams

In our work at Human-Centric Engineering, Simon and I have noticed how we’ve tried to skirt around the idea of ‘happy engineers’, somehow the word ‘happy’ seems too fluffy, so we find ourselves defaulting to words like ‘engaged’, ‘purpose’ and ‘productive’ instead - why do we feel shame in saying the word ‘happy’? It’s good that Pharrell Williams, Bobby McFerrin and, of course, Charity Majors did not feel similarly constrained.

Speaking of musicians, I’m often fascinated by how they describe their creative process, and how so many musicians describe the way that music joyfully flows through them, rather than from them - How might this might relate to a software engineer’s experience of problem-solving and creativity? And then there’s the real-time co-creation of playing together in a band, listening out for the way other musicians are giving expression to the music, making micro-adjustments to keep in time, paying attention to the dynamics and creating the space for each other to make their deepest contributions. Do we experience that joyful co-creation working together in a software team?

John Frusciante’s expression of Joy

In the film “The Heart is a Drum Machine” there are a number of interesting observations from musicians as they talk about their experiences of creation. For me, the observations of Red Hot Chilli Peppers guitarist John Frusciante stand out. Here are some of his thoughts recorded on July 18th 2008:

“I think any music of any worth has been done by people who are very interested in the internal process of their soul and their mind that's taking place while they're writing music, their emotions, they've always been people who have been concerned with the process of what they do and haven't been very concerned with what the outer result of what they're going to do is when it leaves their sphere. And I believe the more that even a great musician becomes concerned with what it is when it leaves their immediate sphere, the less contact you have with what's going on inside you because you start to equate the music with the reaction it provokes as opposed to what it naturally is, which is just something that takes place inside you that you have been given the gift of being able to realise and to bring into manifestation”

So here Frusciante is connecting with the process of creating, rather than being concerned with the creation - with our focus on outcomes and on delivery, do we compromise some of the joyfulness of the creative process in engineering? Could a focus on joyful creation actually result in better outcomes and delivery? I don’t know the answer.

He also sees musical ability and self-expression through music as a gift. Do engineers see their ability to solve deep problems as a creative gift? Does it feel like a gift we are bringing to the world during the process of creation? 

Frusciante continues:

“A child has this relationship to the creative force  your parents gradually stifle your connection to that creative force and gradually shove your face in the concrete, and so do your teachers, and school system and everything's working against you, but the force of creativity - nature - is not working against you, it's right there for you at any time, you just you know you just have to be ready to not judge yourself and to be open to whatever is going to come through you, and to be ready to not judge it as it comes through but be all right with it whatever it is cuz it's just the universe expressing itself”

Frusciante’s egoless receptivity to whatever wants to come through him, as an expression of the universe - is that what it feels like for an engineer in their IDE tapping into the flow state, being stretched with a challenging problem to which they are applying their well-honed skills and experience, but not stretched so far that it becomes anxiety-inducing?

Frusciante carries on in a similar vein:

"I don't believe that a musical idea starts in your brain. I believe it starts at a place before that that we don't have any direct contact with."

"Everything that we create is nature expressing itself the same way that when a flower grows out of the ground or a tree grows out of the ground."

"Music is an ineffable thing that I don't think words can really do any good to really give us any true understanding of."

"The idea of somebody considering themselves responsible for a piece of music is ridiculous."

"I just believe these things are there waiting to be discovered."

"The more I got out of the way, the more I stopped believing that it was me that was doing it."

"I've gradually stopped caring about entertaining the audience in any way."

"The best thing to do is to live in the moment and to worry about the very next step."

"If your brain is open to them and if you've developed the right relationship to the laws of music and to your instrument, you'll just find them waiting there for you."

What can we learn from Frusciante’s thoughts? In software engineering, we often feel that to solve a problem we need to think harder or work longer. Yet, the answer tends to arise from changing our environmental context - reading a book, going for a run or a walk, meditating, sleeping on it or rubber ducking. Suddenly we find the insight, either from deep within our subconscious or ‘out there’ in the ether - it all comes from creating the conditions to tap into our natural creative potential.

Are software engineers really that much different from musicians? Frusciante’s perspective certainly won’t resonate with everyone, but I do there’s a worthwhile conversation to be having here, to help engineers find their creative calling and to find the conditions where our work joyfully flows through us.

My personal joy

In my own personal experience, I recall my early foray into programming, back in the early 80s writing computer games on the ZX-Spectrum. The games I developed never made it commercially, but the process was one of tapping into something beyond myself, a fully immersive experience of creativity.

Working on my own business projects as an engineer again allowed me to tap into that ineffable feeling of creative joy. And I’m even feeling it again right now as I’m working with Simon on our Human-Centric Engineering platform that we are hoping to release in early 2025. In my current work, I’m leaning heavily on AI for productivity reasons, I feel more of a Product Engineer than a Software Engineer, but I’m eager to get up in the mornings to crack on with it and enjoy the ‘Joyful’ work of seeing it come together.

I derive joy from writing articles, from the hard work of building a business, from the physical work of digging the garden for hours on end. Often this is ‘Type 2’ joy, the joy of overcoming struggle rather than the immediate hedonistic Type 1 joy.

While I found joy in creating software for my personal projects and business ideas, I rarely found it as a Software Engineer in the workplace. For me, the experience was mostly anxiety-driven - work taking longer than other people expected it to, and the continual worry about introducing bugs into production code. There was also the dispiriting nature of the product being broken down into tiny tasks, and not having as much say as I would like from a product perspective. Perhaps this is why so many engineers derive their quota of ‘joy’ from working on side projects.

I found more ‘joy’ in managerial roles where I could be more experimental and self-determined, but still, like Reggie Perrin, felt constrained by the heavy chains of corporate life. As an individual contributor, I was rarely able to fully express my true joy or misery, but as a manager, I tried to create a space where the expression of our personal experiences was normalised, without judgement. And this helped us to tilt the working environment a little more towards favouring ‘joy’.

Work is a natural human activity and as such shouldn’t be devoid of joy. Perhaps we could even get biblical in finding the original source of joyless work. The Genesis story of Adam's punishment for eating from the Tree of Knowledge, where God condemns him to forever toil for his sustenance, has arguably cast a long shadow over humanity's relationship with work. Has this narrative contributed to a pervasive view of labour as a burden rather than a source of joy and fulfilment?

By framing work as a divine punishment, it may have inadvertently fostered a cultural mindset that separates joy from productivity, viewing labour as something to be endured rather than enjoyed. This perspective influenced societal structures and work ethics over centuries, leading to the commodification of human effort and the prioritisation of output over personal joy. As a result, the intrinsic rewards of creation, problem-solving, and contribution might have been overshadowed by a cultural acceptance of toil and struggle, gradually eroding the potential for joy and meaning in work.

Elon Musk’s Joyful Engineers

I’m not the biggest fan of Elon Musk, but equally can’t help finding him a fascinating character to observe. While not an advocate for the widespread adoption of his management style, for the right kind of person, his companies certainly foster an incredibly creative engineering spirit.

Watching the arms of Mechazilla plucking the Super Heavy booster rocket from mid-air is something I never would have imagined seeing in my lifetime. The fist-pumping celebrations of those on the ground seem to imbue this sense of engineering joy I’ve been exploring here. These are unusual scenes for a modern engineering workplace.

So what are the conditions for Joyful Work?

There are many avenues to explore in answering this question that would justify an entirely separate article. So here are a few bullets in the meantime.

• Self-determination

• Close proximity to end users

• Adopting a product mindset in engineering

• Generative feedback loops - accurate and timely feedback

• Working at the right challenge-to-skill ratio

• Sufficient space for deep work

• Teams of high trust, and psychological safety

• Optimal flows of information to inform local decision-making

• Flexible work modalities that suit individual’s attunement to their creative forces

• Letting go of our egoic attachment to outcomes, and listening for what needs to be expressed by our code

• And if someone doesn’t love their work, then that’s perfectly OK. They should be able to call it out, it’s all part of finding our path or our creative muse.

I’d love to turn the idea of ‘joyful work’ from a taboo subject into something we actively strive for. So that we can ask ourselves ‘What would make our work more joyful’ without feeling shame or risking judgement from our peers.

Discussing this very idea with my friend

Johnnie Moore

today, he cautioned me that as soon as ‘joyful work’ becomes a ‘thing’ it loses its power - so we should perhaps strive for joyful work in stealth mode. Ask our teams about what brings them joy, but let’s not ruin it by turning it into a trite company value.

I’d love to work with an organisation that wants to run an experiment around the ‘intentional pursuit of joy’ as Richard Sheridan puts it in his book, Joy Inc., working upstream in engineering to find the triggers for joy, to then see what the downstream effects are on the various measures of value, the tangible, intangible and emergent effects of the intentional pursuit of engineering joy.

The human need for ‘joyful work’ and the eradication of ‘miserable toil’ is a greater cause than Simon and I can promote on our own. It already has bigger well-versed voices behind it - the likes of

Bruce Daisley

with

Make Work Better

and

Colin Newlyn

with

Decrapify Work

spring to mind. But this is a cause that affects us all, why shouldn’t we derive energy, and vitality from our work to feed the human spirit?

Too ‘woo’?

Hopefully, this article hasn’t been too ‘woo’ for the software engineering community. While the field of engineering often stereotypes itself as rational, logical, and unemotional, I’ve found precisely the opposite when speaking with engineers, especially on a 1:1 basis. I tend to find engineers some of the most interesting, curious, open, thoughtful, sensitive and creative people you could ever meet. Hopefully, this piece sparks some deeper conversations leading to more joyful work.

Perhaps I’m revealing my own corporate scars in this article and with them my own prejudices about the joylessness of work in the corporate world. I’ve had an affinity with Reggie Perrin, ever since the series was broadcast on the BBC back in the 70s. Perhaps this affinity lies in never quite fitting into the corporate mould, and the many struggles I had in trying to fit in - and these experiences, the ups and downs of corporate life’ are the basis for this current project, Human-Centric Engineering.