From the moment you learn programming people tell you "don't repeat yourself!"

So what I'm about to suggest might sound odd. But I'm here to say that if you want to ship high-quality software at pace, you should be investing in abstractions that are designed to enable copy-and-paste.

For the last three months we've been building out the incident.io catalog. This project always made me nervious – it would've been easy to build something pretty but useless – but it's ended up game-changingly good.

This post talks about some of the decisions that got us there.

From the evergreen AWS status page to hardcoded 100% uptime, no one fully trusts a status page anymore.

But why is this? Companies often start with good intentions, aiming for full transparency. So why do so many change along the way: what pressures people into an evergreen status page with poorly-reflective uptime numbers?

ULIDs are an alternative to UUIDs that solve several problems, but it's not all plain sailing.

This post shares experience using ULIDs in production, exploring some of the drawbacks in an aim to help others pick an ID format.

This was my first full year at incident.io. So much has happened - 4x'ing the team, our Series A, building loads of product – that it feels much longer.

I'll break this down into reflections on team, product and writing. Only a few aspects of my last year, but themes I like to keep track of.

Most software is simple: you have a codebase, and existing patterns for testing at a unit and integration level. But sometimes you'll face problems that aren't just adding code to an existing project, and don't have an existing test suite to jump into.

This posts shares some problems that required out-of-box thinking to find testing strategies, and gives advice on how you could use those techniques in your code.

Two part series about how we built incident.io workflows.

Part one explains core concepts used across the feature, and look at how code structure makes development easy. Followed by a deep-dive into the Workflow Builder (the configuration UI) showing how the concepts are exposed in APIs, and used to power the frontend.

Part two describes the workflow executor, showing how it listens for workflow triggers and if the conditions match, executes them. Finally, we reflect on whether we succeeded in our efforts to "slow down, to speed up!" in an evaluation of the project.

Research shows start-ups with experienced founders are more likely to succeed, and build more valuable companies too. But if you want to found a company, how do you get that experience?

My experience says the fast-track is joining an existing start-up and riding that wave, taking the opportunities that come with growth. This post explains what you can expect to learn, and why it's so valuable if you ever want to start your own thing.

When it comes to complex systems, you can only go so far with synthetic experiments before you need to try something for real, and test in production.

There's no substitute for it, and you're likely making the wrong decision if you avoid it. But I can say from experience it's not without risks, and this post shares an example of where we got as much as possible from that prework and testing, even if it was a bit of a bumpy ride.

This talk shares my experience leading an SRE team, scaling from three people running all of the company’s infrastructure to a product-centric Platform Engineering team building tools for 200 other engineers.

I’ll explain the challenges we faced at each stage – problems that are common across engineering orgs – and the pragmatic steps we took to solve them, helping us get value before going all-in on an Internal Developer Platform.