Content warning: Some curse words, but hey, it’s an emotional post.
On my first day, 6 years and 7 months ago, I deployed a small change as part of a pair. Then our monitoring broke and we needed to fix some Nagios code.
This, as it turns out, would be the pattern that repeated itself over the next half-decade.
And I don’t really think I could’ve asked for a better environment in which to start my career.
I’ve broken up this piece into 4 parts: Numbers, Regrets, Learnings, and Joy
6.5 Years in Numbers
- 9000+ Hot Fuzz gifs posted in Slack 🚨
- ~3000 Cups of coffee ☕
- ~170 Retrospectives 🤔
- 20+ “IP Request” emails to open-source stuff 📥
- 7 Teams 👥
- 4 Roles ⚒️
- 1 Academic paper published 📓
0 defects introduced 🐛(haha, not even close)
6.5 Years of Regrets
There are a lot of things that I would change given the chance. It’s unfair to judge myself for not having the knowledge or experience I have now, but here are some things I would probably do differently.
Pick your fucking battles
As Sarah likes to say, “Pick your battles. Now put some of them back. Nope, still too many battles”.
Earlier in my career I had a tendency to choose every hill to die on and I should have let a lot of them go. I remember an incident surrounding technology choice in a team I was about to leave. In hindsight it didn’t matter to me, and I shouldn’t have pushed back so hard.
I’ve learned to ask myself: “What’s the most irrevocable thing that could go wrong?”
The cardinality of things that are truly irrevocable (or hard enough to be problematic) is very small, and making mistakes is a valid way to learn. Which leads me to…
Let people make mistakes
I spent a lot of my time at Unruly trying to improve the state of our infrastructure. It wasn’t until I had a team to lead that I realised that I was going about it the wrong way.
The temptation is to drive when you have the expertise. It took a short sharp shock to make me realise that I wasn’t enabling people to learn as well as I could.
I spent the first four to five months of my team lead career forcing myself to sit on my hands so that my team could learn. I wish I’d had this realisation earlier.
Change is the hardest thing to do
There were a number of things that I tried to change or introduce only to fail. I don’t think that I understood the mechanisms of change well enough at those times.
I managed to get as far as extolling the virtues of developing-in-the-open to my team and we have developed quite a few things in this way.
I wish I’d had the energy and wherewithal to push for this change across the wider ProDev team, using the tools I now have at my disposal.
6.5 Years of Learnings
Safety is everything
This is my main takeaway from my time here. I have seen a team of people, who (by their own admission) knew next to nothing about infrastructure, solve every problem that I’ve put in front of them.
Build a team that feels safe to fail, to give each-other feedback (constructive and critical), and to push themselves. That team that will carry you further than you expect.
If it ain’t broke, maybe try fixing it anyway
Reliable systems can hinder progress to better paradigms. An oft-quoted line is “Perfect is the enemy of good enough”. But I’d go further and say that “Good enough is the enemy of change”.
It’s hard to make a case to replace something that is chugging along and not getting in the way.
Then you wake up one morning and a legacy domain model (I’m looking at you, Nagios) has accreted so much inertia that change is painful, expensive, and just plain shitty for everyone involved.
Set time aside, if you can, to just mess around with new things and think about how to get from here to there. It’s good practice for work-slicing even if the work itself never happens.
At a personal level I learn quite well from breaking things. Every codebase that I’ve worked on has either been implemented using TDD or I have tried to retrofit tests onto it.
Good tests are about safety. Safety enables us to refactor and experiment, to make mistakes and learn from them.
(A sub-point: one of my favourite things about being on Shift has been taking the steps from Shell, to tested Shell, to tested Python. Iterative and incremental improvements!)
Treat your code like a garden
Put some deckchairs out and have a cheeky shandy with the lads.
Shift introduced the concept of “gardening” last year. I mentioned it in a previous weeknotes but I’ll write a bigger post on it one day.
The software we write does not simply sit unchanged. The world around it evolves, dependencies go out of date, domain models drift away from reality. It grows unruly (hehehe) and the only way to keep it tame is to be regularly tending it. Much like a garden.
I wish I had an IDE plugin to give me a list of, say, the 10 files edited longest ago. I tried this on our puppet codebase and found absolute swathes of code and assets that could just be deleted.
A piece of code is done in the same way a garden is done - either it has no plants, or they’re all dead.
6.5 Years of Joy
Bringing Mob Programming to Unruly
I’m proud of this one. Benji and I attended a talk by Woody Zuill at JavaOne and we brought it back with us to try. At the time we were rebuilding one of our payments systems to handle load better as we scaled.
Mobbing was the perfect tool in this case. We needed to ensure that everyone working on the system understood the changes we made.
It’s been quite an experience to watch it go from a single team, to adopted by other teams, to full adoption across the department, and back to “we mob when we need to”. Mobbing is a powerful tool in our box but not every problem is suited to it.
Prototyping the system that we pivoted to
I had the opportunity to be the Lead Research Developer on what would become UnrulyX, our real-time ad exchange. This kick-started our transition from managed service into programmatic advertising.
I will never forget the joy I felt for myself, and the team, when we delivered our first non-trivial $0.01 of programmatic revenue.
Bringing into £40-worth of doughnuts after the 2017 General Election
I said before the election that the chance of a non-Conservative victory was so slim that I’d buy a huge cake for everyone. We ended up with a hung parliament so a half-way option was a butt-load of Krispy Kremes.
Let no-one say that Alex Wilson is not a man of his word!
Being supported in trying new things
I would never have attempted to write an academic paper without the support and advice of our then-Agile-Coach Rachel Davies.
Doing new things is hard enough on their own but they’re made significantly easier if you know that you have experience and coaching to back you up. I tried to pay this forward during my time as Team Lead and made the pastoral side of my role a first-class concern.
Growing and nurturing a team
There’s no point in beating around the bush here - I will miss my team the most, and they made the last year and a half of my career an absolute joy.
I’ve definitely made mistakes during my time as Team Lead. But I cannot under-emphasise how easy it is to come to work and be part of a team of smart, motivated, and emotionally intelligent people.
Facilitating their growth into solid infrastructure engineers, and learning so much from them in return, has without a doubt been one of the highlights of my career so far.
That’s All, Folks
I have loved most of my time at Unruly - no workplace is perfect of course, but now feels like as good a time as any to say goodbye. The people I worked with were instrumental in helping me shape my career in the way I wanted to, and for that I thank all of them.
If you’re lucky enough to find a place like I did, then maybe it’s worth sticking around for a few years longer than normal and seeing just how much you can learn.
I guess there’s not much more for me to do now except …