Kristian Glass - Do I Smell Burning?

Mostly technical things

Words of Estimative Probability

Uncertainties are common, from “we’re almost certain this is the cause of the outage”, to “project X probably won’t finish before we need to start project Y”, and “the train will almost certainly be on time tomorrow”.

Broadly speaking, decision making consists of “get information, do a thing”, whether a structured framework like OODA (Observe/Orient vs Decide/Act) or “let’s get lunch – where’s good?”

Often, this involves multiple people – the person making a decision will rely on information and analysis from others. During an outage, an Incident Commander will be making decisions based on observations by Subject Matter Experts; a Project Owner is best placed to speak about the timeline of their project but resource allocation is done elsewhere; I am familiar with local public transport and my houseguests would like to know so that they can make plans.

From Wikipedia’s “Words of Estimative Probability”:

2016

At the end of every year, I find myself looking back going “wow that was over fast, what on earth did I do with all that time, aargh!”

Thus in the spirit of one of my favourite articles, Always Improve, Never Stop, Never Pause, Never Appreciate, here’s some of what I did in 2016. Not necessarily “achievements”, not necessarily endorsements, but things I did that made me happy.

So, in no particular order:

Testing Out My Torches

Night time sharpens, heightens each sensation…

Yesterday at 1500 the power went out. Fortunately the turkey I was cooking came out of the oven an hour before, so the only real impact was a lack of Yorkshire puddings! After 14 hours, the fantastic team at UK Power Networks had us back up and running. Meanwhile, I got a chance to really test out the assorted battery-powered lights I keep around the house!

What I Want From a Hiring Take-Home Test

We’re doing a bunch of hiring right now. This process deliberately doesn’t include any kind of “take-home” exercise, no “go away and write some code and send it to us when you’re done”, no “programming challenge” or similar. Instead we use a pair programming exercise to try to assess technical ability.

Why? Because building a good take-home exercise is hard, building a bad take-home exercise is easy, and we’ve not yet come up with something that feels right.

Here’s a couple of properties I feel are absolutely critical and often missed:

Metabase - Data Exploration and Visualisation Made Easy

It’s been a while since a piece of software left me feeling as genuinely excited and happy as getting started with Metabase did. It’s some of the nicest tooling for internal “analytics” / “business intelligence” / “data introspection” I’ve come across.

(Disclaimer: I have no affiliation with Metabase, I’m just enthusiastic about it)

Travel Tips

My team is completely distributed, but we meet up in Munich periodically. Here’s a couple of things I’ve learnt to do to make the travel easier for me.

When You Do X

My friend L taught me about a brilliant feedback framework (apparently originally from McKinsey) and it looks roughly like this:

When you do X, it makes me feel Y. [Optionally] In future I’d appreciate it if you could Z

I find this incredibly useful, thanks to a bunch of different properties it exhibits: