Software is Creative Work
Why you’ll get so much out of a book by a record producer…
Yesterday I wrote an article on how focussing on the continuous delivery of high quality outcomes and impact as a software engineer trumps any focus on how busy people are, unless they are harmfully busy. Today I want to take that a little further into what software engineering and development is: creative work.
Ever woken up in the night and gone “Ah ha!” with a solution? What seemed impenetrably in the cold light of day, or under the fluorescent lights of a beige London office, pops ready-made into your mind? Ever wondered why estimation is so hard early in the development work, and why Taylorism-inspired management practices grate so hard and are so anathema to your software development work? Ever been surprised to find solutions present themselves in the shower, on a walk, not necessarily when you are pair programming, standing at a whiteboard, or staring at a screen?
If any of this sounds vaguely familiar you have a small taste of the core of what this article is about. During just my career software development has been characterise as everything from artisanal pursuit to factory floor, and none of those metaphors have worked particularly well. That’s because it is neither of those things; it is both, and it is so much more.
Software engineering is ideas, it is craft, it can be construction, it can be factory assembly. It is what all those activities have in common, it is creating something and, for that reason, I don’t flinch a bit when I say it is art.
NB: Any hard-nosed, MBA hugging readers might balk at that, and that’s ok. Software is also business. Of course it is! Anything of value can become business. That doesn’t mean however that it is essentially a business. Business is one of the benefactors of software development, sometimes a crucial one, but it is not the rasion d’etre of the exercise, sorry!
Software development is a creative endeavour, and there’s a lot we can learn from how creative work is done. We’re not just turning out another standard widget, or artisanal custom pieces, we can be doing both and more in between. But how and what is less important than why and what we are trying to achieve. As great software developers we are trying to create great work, work we can be proud of. That motivation is one of the few things I see shared amongst the best software developers I’ve ever worked with.
While there are many great books out there on software development (I’ll be reviewing some in the coming days and weeks I’m sure), the most inspirational tome I’ve found recently that doesn’t just chime, it CLANGS in harmony with this idea is a book from, of all things, a music producer. But not just any music producer. This is Rick Rubin and the book is “The Creative Act: A Way of Being” (in hardback and, my personal favourite, audiobook).
I’m a huge Rick Rubin fan. His work is amazing, and his sequence of Johnny Cash LPs are my go-to almost every day for my “Close of the day LP” habit (I end my day with a small ceremony of leaving the screen or notebook, popping on a physical LP and settling back for ~20 minutes of just sitting with some music).
But, more than Rick’s work, it is Rick’s approach to the work that resonates with me when it comes to my own passions: writing and software development.
“Every great engineer I’ve worked with has their own style, but they also have a shared understanding of what we try to do. They all seem to care about the same thing at the end of the day: that they produce great work.”
This morning I found myself explaining what software engineering is, and why measurements of productivity and time efficiency don’t help much with the work. I shared how some of the best engineers I’ve ever worked with had wildly different styles of designing (from lone walks to massive, heated arguments — notice no need for a whiteboard necessarily…), to coding (chaotic, hugely confident coding resting on the confident baseline practice of TDD, through to very carefully considered single-perfect-line-of-code crafting), to operational activities. Every great engineer I’ve worked with has their own style, but they also have a shared understanding of what we try to do. They all seem to care about the same thing at the end of the day: that they produce great work.
The ways that different great engineers spend their time vary enormously. Some optimise their keyboard skills, some couldn’t care less for their keybourd fu. Some do 2–3 hours of focussed work in a day, others have to pry their hands away from the keyboard in the wee hours. As long as their choices are healthy to their body and mind, then all is on the table when it comes to how they work.
The common ground amongst great engineers is in why they do their work. What they get out of it. What they aim for.
They all aim to produce work they’re proud of. Creative work that is never “done”, but done for now. They aim to produce great solutions, not just code. There is love and attention in their work. They are creative and treat the collaborative work of engineering a solution as a creative act. They are very aware of who else will need to work with their work, on the need to communicate through their code with other people first and the machine second. They use tools like Test Driven Development to help with that collaboration, as it is as much a useful tool for themselves as it is their code’s design. Ultimately the work matters, in and of itself. It is a piece of work, crafted, honed, high quality and useful. It is art, and they are artists.
From this perspective the book “The Creative Act: A Way of Being” could as authentically be describing great software engineering as it is the making of any work of art.
That might sound awfully pompous but, when you read this book, you realise that it is only the artifices of the art industry that have made art seem out of reach. Art, any creative work, is within the reach of anyone. Anyone who cares about the work (noun and verb) deeply. Writers and painters through to coders, in this wonderfully democratic re-framing we all enjoy the position of artist.
But beyond the review, this work is so much more than that.
This book from Rick doesn’t just democratise, it encourages, even imploresyou to consider the art you could make. No ceremonies required, just patience and developing the sensitivity to hear your calling when it comes. I recommend this to everyone from junior software developers to CTOs, fellow writers to home decorators. To become great in your work, whatever it is, the perspective and advice here is transferable to any of the creative arts, software engineering very much included.
This book is the reminder of what we are first: Creators, even Artists. Go read it, and thank me later.