When I look at my career trajectory, it’s a bit like a misfiring rocket. I started as a passionate techie, then became a stone-cold contractor, an Open-Source Warrior, a justified team lead, a passionate Product Owner, an unconvincing consultant, and then a confused manager. Now, I’m a contented DevOps engineer and author.
So how did I get from there to here, and why did I write a novel about software engineering?
Reading
When I was learning the trade I did a lot of reading. Books like The Tao of Programming and Hitchhiker’s Guide to the Internet, along with the books about organisation like The Mythical Man Month and Peters and Waterman. It didn’t take long for me to see what was happening in practice. When you read The Mythical Man Month at university and then go into your summer placement in a telecoms company to see software engineers being siloed and corralled and treated as resources, just like in the book, it’s going to mess with your head a little. I started thinking, is this what I have to look forward to?
I came into work with a fire in my belly, worked hard at being a professional software developer, and I loved it. The problem was, I couldn’t turn it off.
Burnout #1
Thinking back to my first job, I was so passionate for software that I would work on it all day, and then I would do Open Source (OSS) software in the evening. I’d go to the pub in the evening and talk to my friends (all software engineers) about software engineering. My life was often consumed by software engineering to the exclusion of partners and friends. I wrote C and C++, and I wrote KDE/Qt apps for Linux, used my shell scripting skills to automate things, taught myself perl, I learned enough about databases and networks. I was a superstar in most of the places I worked, totally dedicated to the job, always able to fix the problem at hand.
But then I started having the physical symptoms of burnout. Panic attacks, heart palpitations. I tried to push it down with alcohol, with drugs. Nothing really gave me respite until I discovered how I could earn more money by freelancing and then also take time away from my job to follow my other passions like music, like writing. So I started freelancing. I earned more money, I had less responsibility, and could also save cash for a rainy day. When it became too much, I could simply quit my job and take time off. In the late 90s and early 2000s in London, there were plenty of contract jobs, so it was easy to do this. I had no responsibilities; life was easy if a little unpredictable but that too was part of the attraction.
Not Reading
However, this was itself a trap. The problem with not taking your job seriously is that you no longer take yourself seriously. I stopped reading the trade literature, the programming books, and I didn’t look ahead to the next phase. In fact, I stopped thinking I could contribute to the professional development of software engineering. I basically checked out of the union.
What I did, however, was to continue devoting a significant amount of time and energy to open-source projects, products, and activism. I participated in Linux Expos, wrote for Linux magazines, and tried to make that work as an alternative lifestyle. But time was moving on. The truth was that I had become disconnected from the professional world of software development and was merely coasting on the fumes of my youthful passion without a clue where it should go next.
Fatherhood
When a man becomes a father, it does strange things to him. Makes him drive home really slowly from the hospital, it makes him worry for the future, it makes him also at once bolder and more protective. From 2005, I raised a family. I took it seriously. I didn’t always do it well, but I tried hard and tried to provide. To do that, I worked at a series of jobs in banks and insurers, energy companies. I moved from the UK to the Netherlands. We set up a new life and I tried, in some small way, to rediscover my passion for software. I did things in the evenings and weekends, side projects. I built mobile apps, games, I learned node, npm, javascript, I learned AWS. But I knew deep down that coding wasn’t the answer. In truth, I was done with it. I consulted for a while as a DevOps Coach but didn’t enjoy it. Then I landed a job as a manager, and I became even more miserable. I was pretty relieved when COVID came along and forced something of a realisation.
Burnout #2
By late 2021, I was going through a bit of a downturn. I’d just left a job that I really hadn’t enjoyed, but stuck out during COVID-19. Like the rest of us, I’d embraced the uncertainty of those times with fear and uncertainty and not a little trepidation for the future. To be frank, I was probably burned out after trying very hard for ten years to be someone I wasn’t. I’d done many different things trying to find the spark that would reignite my passion for engineering, but what I hadn’t realised is that it had never really gone away. It was just hiding where I’d left it, not in the code but in the interactions. In the people.
I thought that being a manager, being a coach, being a leader in an organisation was what I needed to do as the next stage. What I hadn’t realised is that leadership takes many forms, and I had already been doing it throughout my career. I just wasn’t aware of what leadership meant.
I’d stopped looking around at how the industry had become. I had moved on from being a builder, an architect, a problem solver, to a systems thinker and organiser. I was obsessed with groups of people and organisations of teams, but I hadn’t noticed that a whole science behind this, behind motivation, and behind organisation had appeared. What I hadn’t realised is that I didn’t have to do this hard work alone.
Reading Again
By 2022, I’d been watching and following Dave Farley’s Continuous Delivery channel on YouTube for a while and having read his book, Modern Software Engineering, I really couldn’t disagree with anything he said. But the real lightning bolt moment was when I read three books in quick succession, firstly Team Topologies and then The Unicorn Project followed by The Phoenix Project. Following that, I read Daniel Pink’s Drive and delved into a bit of exploration of my own about Self-Determination Theory.
The first thing that struck me was how Conway’s Law was real, and I’d been living it all this time. I’d seen the organisations I’d been in effectively forcing our hand as architects without even realising. I’d felt the impact of poorly defined team boundaries and responsibilities. I recognised the anti-patterns that DevOps organisations fall into.
Organising
What Team Topologies showed me was a way to be more humane at work through our organisation and our team’s logical interaction, but I knew deep down that by itself wouldn’t be enough. There could be a way to avoid burnout by reducing cognitive load and organising ourselves better. I also realised that a large part of what motivated me and others to do the work had to come from within; while we had to fit together to realise our team and organisational goals, we mainly had to take personal responsibility for how we wanted to approach our work. So while we could organised well or badly, our interactions at a personal level were even more important.
This is where the Phoenix Project and the Unicorn Project really stood out for me. Because through stories, they showed a much closer view of how our industry actually is. The late nights, the early starts, the stress, the tension and the failures and successes. I wanted to connect the dots between software and organisation, but do it in a more realistic, gritty, yet hopeful way.
The only way I could think of doing it was to write something that wasn’t a manual, not an industry book at all, in many ways an anti-industry book, but one with a heart that highlighted a particular lesson for us all. In many ways, this is a call back to the Mythical Man Month. We don’t have to work the way we’re told to work.
That’s where the idea for Human Software originated. A novel, a fantasy, a hopeful look at what it means to be a software engineer in a software engineer’s world. Where individuals can maintain their dignity and professionalism.
From Then To Now
In the mid-90s, at the end of my Master’s placement, I remember telling my industry mentor that this wasn’t the type of business I wanted to be a part of… and yet, thirty years later, what has really changed and how come I’m still in it? It certainly has a power, an attraction for us all.
From my perspective, we have become a kinder, more open, and inclusive industry. There are far more women and minorities in our profession. It’s much more globally based, and we’re used to dealing with global firms as partners and vendors in our day-to-day operations. But while we’re less segregated and less middle-class white-guy oriented, there is still a long way to go.
Every day I see examples of sexism, ableism and questionable or restrictive language being used, which restricts the chances and choices for certain people. I can see how challenging it is for well-meaning, energetic young people to advance in lethargic and stagnant corporate structures. And outside of corporate, still anything goes, long hours, poor wages, manipulative and coercive bosses.
So, when I wrote Human Software, I wanted to remind us all, as engineers, that we always have a choice about what we do and how we interact with each other. We always have a choice, and sometimes you have to follow your heart.