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:

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)

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.

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:

You have a static website in an S3 bucket. You want to put CloudFront in front of that bucket site, for caching, SSL with a custom domain, etc. You want to use CloudFormation because Infrastructure as Code for the win, and artisanally hand-crafted systems for the lose.

In short, this is the magic you want in your CloudFormation template, with thanks to Eric Hammond and Ryan Brown:

I’m rarely without my shoulder bag, a habit that’s persisted since my school years.

Here’s a selection of what it contains, as a reminder/inventory for myself, for potential interest to others, and because I have an Amazon referral account.

I feel like there’s two very different kinds of software that label themselves as “CI servers” and that picking the right one matters.

You can roughly divide most things up based on whether their primary object, the primary entity on which they operate, is a code repository or a more generic “task”/”job”

Are you using ShellCheck on your shell scripts? If not, you probably want to.

Are you using CircleCI to run your tests etc.? Then you may have already noticed that you can’t just apt-get install shellcheck.

Instead, you’ll probably want something like the following in your circle.yml:

Rich Mironov has put together Four Laws Of Software Economics and I think they’re absolutely on point.

Here’s a brief summary in the form of some of my favourite quotes:

This is not new, this is not original, and other people have certainly written better and more eloquently about this. This is about me avoiding self-repetition

Some people, including some who are not male, have no problem being referred to as “guys”

Some people, some of whom may not be male, dislike being referred to as “guys”.

It feels like there’s two choices at this point when addressing mixed groups. One of which I understand, one of which I don’t.