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
managers.
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.
Read More...
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.
Read More...
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
Renovate for
Google’s BigQuery Python API library. The failure
was in 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.
Read More...
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.
Read More...
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
handled carefully.
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.
Read More...