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.

Asked for my most impactful code contribution, I discuss a small change that had short and long-lasting impact, far beyond what I originally intended.

Go doesn't have sum types, but generics get us one step closer to a useful polyfill. If you've ever wanted exhaustive case statements, this post is for you.

Using a sync cutoff when building our dbt models helped fix our flaky tests, making our CI much more reliable and exposing latent bugs.

Data should be a commodity, and accessible to everyone in a company. We've picked a data stack for tools that make this possible- here's what we use, how it's configured, and why we picked it.

Tie together backend and frontend using type-safe API clients, allowing the TypeScript and Go compilers to prevent typos and developer errors.