How to run a fair pay review process

I had a conversation with a friend today who is fairly new to engineering management, and struggling with the usual set of problems. One thing he mentioned in particular was "it's hard for me to make space in our delivery cycle for us to deliver technical improvements".

I'm not an expert here by any means, but I think we do this pretty well at CarbonRe.

There are three sub-problems here: who gets to decide what work is delivered, how do we define technical work in the first place, and how do we effectively prioritise when there's too much stuff to do.

Architecture katas are a way for us to practice our design skills. I often use them with mentees who express an interest in software design. The idea is that we are given a problem statement, and we need to propose a system design to suit. This is also great practice for a system design interview, though I've had mixed results with those in the past, and tend not to use them myself.

Last year I attended the awesome AWS Community Summit where I gave this talk on one of the fundamental questions of software architecture: how do we define the boundaries of things?

A lot of people I talk to are confused about how serverless applications change the way we design stuff, but my answer is that the basics are exactly the same, and even more important.

Whenever I'm designing systems, there are three things to consider: the functional requirements, ie. the stuff that the system does; the constraints, ie, the time, money, and knowledge factors; and the architectural qualities - the non-functional requirements against which we test our design.

For the architecure qualities, or -ilities, I use a handy mnemonic: MUSTAPO.

Chances are that if you're building software in 2022, you're building some kind of distributed system. The success of a distributed system depends on the careful design of the interfaces between parts. For about a decade, I've been using what I call "Documentation Driven Development" (the other DDD). You can sum this up in one sentence: write the documentation first.

I've just uploaded my second ever Youtube video! I've been procrastinating on this for over a month, but this is a video of me tackling the Mars Rover Kata in Typescript. Most versions of this I've seen use an outside-in style, but instead I'm using a bottom-up approach. I'd love feedback, on Youtube or Twitter. If people are interested, I've got two more parts to edit and upload.

It took me an hour or so to work this one out this morning. If you're running Magit Forge under Emacs and you want to store a personal access token on a recent Linux desktop environment, then you might want to use the Freedesktop secrets api.

Approval testing is a powerful technique for working with legacy systems. When refactoring, it's important that we have tests to tell us if we've changed behaviour, but sometimes code can be smelly enough that writing unit tests is hard. Approval tests fill this gap. Instead of writing behavioural unit tests, we capture the output of the system - usually as text - and run a diff tool to check for changes in the output as we change the code.

I've previously struggled to set up approval tests with the common tools and libraries, but I realised today that Jest Snapshots solve exactly the same problem, and are easy to use.

While spelunking through some code at work, I found a neat little programming problem that I've cleaned up a little and decided to publish as a TDD Kata.

In the Cake Shop Kata we're asked to write some code that can calculate the delivery date for different types of cakes, taking into account the skills and working patterns of the bakers.

Generally when deploying Lambda functions, I use the Serverless Framework. This is a wrapper around AWS Cloudformation that makes it easier for engineers to author and deploy code. It's much easier to get started when using an abstraction like this, but sometimes we need to drop down and work at a lower-level.

I recently needed to deploy a Lambda function with a large number of triggers, and the Cloudformation template generated by the serverless framework was too large to deploy. Instead I ended up configuring everything in plain Terraform. There are more moving pieces to understand, but in return for that overhead, we gain a lot of flexibility. In this post I want to show you how to configure and deploy a simple Lambda function, configuring everything ourselves in Terraform so we can see how it all fits together.

Kinesis Firehose writes concatenated JSON objects to S3. Most python solutions to reading the data rely on pre-processing with a lambda, or struggle to deal with large files. A better solution is to use a streaming parser. Luckily, I have just the thing.

In this short blog series, we build our own web analytics solution from scratch using serverless technologies, just because we can.

I spend a lot of time teaching TDD to engineers. Some of my most rewarding sessions are spent with first-time TDD practitioners. When we're starting out, I'll choose a simple TDD kata, and we'll pair to solve it together.

Once I've introduced myself and the exercise, I always ask the same opening question: "What's the first test we should write?"

The answers are always interesting, because they tell me how the candidate thinks about TDD. If they have misconceptions, it's best to tackle them at the beginning. In my experience there are three common ways that people go wrong when choosing the first test.

I've recently started a new role as an engineering coach, and I've been working through some katas to remember how to write code.

I'm a huge fan of Emily Bache's work, and was particularly interested in the Delivery Service refactoring kata because it neatly captures some of the challenges of working with legacy codebases.

I'm going to walk through the process I followed when solving the kata, and I'll include links to each commit in the Github repository so you can see the full code as we go.