05 Nov 2021
Imagine you’re making a change to a codebase you don’t like. Testing is difficult and you don’t have a
good understanding of how all the parts of the system fit together. It’s tempting to just do a bit
of cursory testing, deploy it to production and keep your fingers crossed. This is not a pleasant
situation to be in, and will inevitably lead to production incidents, sad developers and cross
As a manager, if you encounter a situation like this you’ve got a choice to make about how to fix it.
Instinctively you might want to put more processes in place around deployment and testing. Maybe kick
off a project to refactor the code base and make testing easier.
Maybe you can reduce failed deployments, but at what cost? Slower development caused by extra
bureaucracy and more policies to follow is going increase friction, delay releases and
eventually lead to an unhappier team.
The underlying problem is that the team feels disconnected from their software. They might own it
according to your org chart, but they don’t feel ownership of it. This lack of ownership can
manifest itself in many ways, but principally it results in a “good enough” attitude and a lack of
interest in the negative effects that a deployment might cause, or future issues caused by the
So, rather than adding more policies how do you encourage the team to feel more like the owners
of the software they are responsible for? There’s no one answer to this, but you can start
by looking at how detailed their future technical plans for the software are. A team that feels
a high degree of ownership will likely know exactly what technical changes they want to make over
the coming months or years. A team that doesn’t will be content with just tinkering around the edges,
or maybe they have some plans but talk about them in a jokey, “we’ll never get around to this” kind
If the team doesn’t know what they want to do with their software then you as a leader can help by taking
them through a process of working out what changes they do want to make. These need to be practical
and realistic, this is no time for pie-in-the-sky “let’s just start from scratch” ideas. If the team
is already in difficultly then you need to start small, and incrementally make improvements.
Begin by assessing where the biggest pain points are. Once you’ve identified the area come up with some
easy wins, and create time for the team to work on them. By starting small and getting something
done you can help the team feel a sense of achievement. It won’t happen overnight, but once the team
feels like they are making progress they will start to feel a sense of ownership.
Another aspect of feeling ownership is a connection to your clients. How easy this depends strongly
on what type of business you’re in, but it’s worth fostering this connection if you can. Maybe people
can spend a day shadowing a client? If you run user experience research then developers sitting in on
a few sessions will help build that connection. Developers don’t need to build as complete a picture as a
product manager or UX researcher needs to, but if you’re building something that it’s not possible to
dog food then gaining some first-hand connection with a subset of users will help people to think about
them in less abstract terms.
To try and build an understanding of your clients you might be able to get one to attend a town hall
or other meeting and talk about what impact your changes have had on them, what their priorities are,
or a recent success that your software has enabled. Hearing directly from a client, and putting a face
and a voice to them is hard to beat as a way to build empathy and understanding of your users.
If you’ve been successful you should start to notice a change in the behaviour of the team. They might be more proactive
about suggesting improvement projects and be keener to iteratively improve on what will still be a
“bad” codebase. Hopefully, you’ll notice a keenness to resolve issues more quickly, and more attention to
detail when preparing and executing changes in production. If a company’s users become the team’s users
then they will feel a personal responsibility for their experience, and for the success of your product
that can only be a good thing.
14 Oct 2021
Recently I went on holiday to the island of Jersey in the Channel Islands. As an electric car owner this
currently requires more planning than I would like. Inevitably, running an electric car on holiday is not
quite as convenient as being able to charge your car up at home, or being able to pop into a petrol station
and fill up in a couple of minutes. There are three 50kw chargers on the island, which can get me from
20% to 90%+ in just under an hour. Given the size of the island a full battery will last for five or six
days, so we expected this to be ok.
Although we’ve owned a Tesla for around nine months at this point our only drive longer than the range of
the car was to Northern Ireland and back, which necessitated a single stop in each direction at a Tesla
Supercharger and was quick and easy, exactly what you’d hope for. While we were there we were able to charge
using a three-pin plug where we were staying, so charge was not an issue. Unfortunately, the rented accommodation
we were staying in on Jersey didn’t have a plug near the car park, so charging overnight was not an option.
On our first day we happened to park in a car park with some 7kw chargers. We thought why not get a top-up while
we buy some food, so we plugged in and tried to work out how to start a charge. Most chargers on
the island are run by Charge Your Car so I had already downloaded the app.
First impressions of the app are not good - it hasn’t even been updated to support a modern iPhone’s aspect
ratio. Still, it was fairly easy to navigate to the right charge point on the map and click the “start charge”
button. This then directed us to add a card to the app so we could pay. The first stage worked fine, but then you
need to add the CVV number and the app returned a 404 Not Found error and that was it - there was no way to start
the charge. After 20 minutes on hold to their helpline, we gave up and left.
The next day I went to the nearest 50kw charger which while also run by Charge Your Car supported contactless
payment. It worked perfectly, so I could focus on my holiday.
After running the car down to about 15% I went back to the charger, only this time it refused to detect that
our car was connected. While I was on hold to the helpline a nice man from Jersey Electric happened to be
passing and he tried to help. He wasn’t able to fix the fast charger so he directed me to a nearby 22kw AC charger.
Sadly this was limited to 11kw due to the Model 3’s onboard charger. It was also managed by Charge Your Car so
the helpful Jersey Electric man lent me his RFID card to so I could top up. After waiting an hour (which at 11kw
only gained me 18%) I decided to risk a different 50kw charger.
After some difficultly finding and then parking at the charger as it was in a very tight hotel car park I was eventually
able to connect and set about trying to work out how to start the charge. This charger didn’t support contactless and was
run by BP Pulse. Downloading the app and registering was reasonably straightforward,
but instead of registering my card, I needed to top up a minimum of £10. Once this was done the charge started and I
sat back to enjoy my book. Unfortunately, after less than 10 minutes the charger crashed and rebooted. When it came back
it refused to start the charge again. Having wasted most of my morning and now on 50% charge, I headed off to enjoy
the rest of my holiday.
Fortunately, for the other two times I used the Charge Your Car rapid charger it worked flawlessly and as expected
the Tesla Supercharger on the return journey was perfect. Sadly this experience added more stress than I would like
to an otherwise enjoyable holiday. The UK is definitely not ready for the EV revolution, unless you are able to
charge at home, or only travel within the Tesla network’s range.
What suprised me most was just how anticonsumer the two charging companies I had to use were. Charge Your Car appears
to have been abandoned - an app that’s only had two minor updates in two years, and currently fails in its primary
purposed - to let you start a charge at their charge points. We also spent over two hours on hold, and the phone
was never picked up. BP Pulse was better, but only marginally. I did manage to start a charge, but the unreliability
of the charge prevented it from successfully completing. They also required me to top up a minimum of £10, so I now
have over £8 trapped in their app with no obvious way of getting a refund.
Can you imagine if petrol stations worked this way? You needed to download an app for each brand of station, and they
forced you to top a minimum of £100 before you could fill up. Half way through filling up it gives up and refuses to
add any more petrol. Cars would never have taken off and we’d still be using horse and carts.
As a smug Telsa driver with access to the Supercharger network it would be easy to think that I’m ok. That’s only
the case when a Supercharge is en-route though, and while widespread there aren’t charges everywhere and enivatably
I’ll need to use third party chargers occasionally.
The UK government seems to be aware of these issues, which is a nice change. They recently published a
which among other things highlights the reliability issues, and the consumer unfriendlyness of requiring app downloads
or subscriptions to be able to charge.
In a related move the Competitions and Markets Authority have opened
into a couple of charging companies who have signed exclusive deals with the main providers of motorway service stations.
They don’t mention Tesla, but given the exclusivity of the Super Charger network it wouldn’t surprise if they
were forced to open it to other users. This is something that has been rumoured for a while, but might be taken out of Tesla’s hands.
In general being an electric car owner is great, but I hope the market and governments pressure charging companies
to stop being so anti-consumer, or it really will set the revolution back by years.
06 Aug 2021
There’s going to be a bit of a change of pace this week, compared to my more recent posts. This time we’re
going to be getting deep into the weeds of Python typing.
One of the biggest recent changes to Python has been the introduction of type annotations. Back in the dim and
distant past I did my third-year university project on type inference in Python, around the time of Python
2.3. Now though, it’s a much more mainstream part of the Python ecosystem. Alongside tools like
black and pylint, the type
checker mypy is a core part of my standard Python set-up.
Adding type annotations to your code, and integrating a type checker into your CI pipeline gives you many
of the benefits of a statically typed language, while retaining most the speed of development that
is associated with Python. The dynamic nature of Python, and the fact that type annotations haven’t been widely
adopted by libraries that you might depend on, means that type checking has its limitations and sadly this means
it might not be obvious when the type checker has exceeded its abilities to detect errors.
Recently I was investigating a CI pipeline failure for a merge request opened by
Google’s BigQuery Python API library. The failure
pylint, saying that a type didn’t have the attribute name we were using. At first, this seemed
like a simple failure, but after more investigation, I noticed something odd about it.
09 Jul 2021
DevOps as a concept has been around since around 2010, but implementing the ideas behind it,
particularly when you’re in a team that is supporting old monolithic codebases is challenging.
For several years we had engineers fulfilling the role of a “DevOps Engineer”. However, we
always knew that having a specific person working on DevOps is a bit antithetical to the
DevOps concept - it’s supposed to be a state of mind and a set of practices rather than a job role.
The aim was always to have that engineer act as a source of expert knowledge and an enabler. Teams
were still supposed to own their code, processes and deployments, but in reality, DevOps related
work was often thrown over the wall to that engineer with the expectation that it was their
problem, and not the team’s problem.
We ended up in a situation where we had to make a choice - hire a new engineer into the same role,
or attempt to spread the work across all engineers. We chose the second option, but that then poses
the question of how to change team culture across a department, so that DevOps becomes a standard part
of the team’s process, much like Kanban, Scrum or any of the other ways the team organises themselves.
18 Jun 2021
Using metrics and dashboards is a well-understood tool when monitoring the health and performance
of software, or your profitability or other key business metrics. What is less common is using
the same tools and techniques to monitor the health and performance of the team behind the
software. I’m not suggesting using dashboards to report on individual developers, but as a tool
to help the team focus on improving their own processes, it can be very useful, provide it’s
My own journey started when I was promoted from a team leader to an engineering manager, responsible
for five teams. The change in level resulted in a significantly different view, but also great
difficulty in knowing where to focus my efforts. When you’re a team leader you are so close to
the team that you hear and feel every change in mood, and have intimate knowledge of all projects
and their current state. Suddenly being responsible for five teams gives you a great view to take
advantage of areas of collaboration between teams, and removes you from the noise of day to day
life so you can focus on the biggest issues. However, it also removes you from the firehose of
raw information so it can be hard to know where you should spend your time to get the best return
on your energy.