Office Based Osmosis

Recently my collegue Chris Sheldon posted an article titled “Under Pressure”. It’s excellent so please take a few minutes to have a read of it.

Ok, are you back? Great. Chris talks in part about feeling like he misses absorbing knowledge through osmosis in an office.

Osmosis, in case you’ve forgotten your biology lessons, is the spontaneous passage of something through a semipermeable membrane. In this case, we’re talking about knowledge entering your head without you needing to consciously do anything about it.

Ownership and High Performing Teams

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.

Anti-Consumer Electric Car Charging

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.

Deriving From Untypable Classes

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.

Writing A DevOps Vision

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.