Introducing SPIFFE AuthZ Proxy

I made a tool to learn more about the SPIFFE and Spire libraries and APIs. And to make it faster and easier to adopt SPIFFE-based MTLS Authentication (AuthN) and Authorization (AuthZ) into older HTTP server applications, especially those built in languages or frameworks where handling short-lived certificates could be a

llm

LLMs are not neutral tools, using them harms people today

I realize by saying this publicly I might be putting my own career and future opportunities at risk. I am saying it, anyway, because it is important to say. I am a vim user. Not even NeoVim, just vim. So I like to think I have a good sense of

teams

Using Risk Taxonomies to Speed Up Development and Avoid Churn

We've all been there: the project is nearly complete, there's a deadline, and someone comes to a status meeting with a problem. A big problem. Something that puts the whole project at risk and means we have to delay, and maybe even rethink our approach. And

Design

Learn to never have a good idea

At StaffPlus this week, I was talking with some other senior technology folks about the risks that come with the weight of our opinions ("never think out loud, people will think it's an actual plan") and the sense of pressure to get it right when talking

leadership

Discomfort Needs Safety

Growth requires discomfort. Whether that's growing pains as a child, or uncomfortable conversations and feedback, we have to confront and address an existing, comfortable reality, and explore something beyond it. By definition, going out of our comfort zone is, well, uncomfortable. So if you want growth, you need

architecture

Zero-cost Future Proofing: Meaningful Namespaces

Sandi Metz famously said "duplication is far cheaper than the wrong abstraction," and my experience has been that following that advice has usually worked out well. You can't future-proof well until you know what you need to future-proof against. A trade-off that makes thing A easier

impact

Have More Impact by Doing the Right Work

Writing code—no matter how much, how fast, or how challenging—is not the same thing as having impact on a business. As engineers, we're rarely taught how to think about and describe the work we do in terms of its impact or effects. We're left

architecture

Data Sinks and Logic Floats

In effective layered architectures, data sinks to the bottom, and logic floats to the top. The more narrowly-scoped the logic, the higher it floats. The more permanent the data, the deeper it sinks.

safety-ii

Advanced Blamelessness is Owning Mistakes without Fear

Blame happens when we stop our investigation with operator error. Then James restarted the server, which broke everything. The first step towards a blameless culture is to stop blaming people for things going wrong. (Assuming no malicious actors.) Then I restarted the server, which I should've known was

culture

What do you mean by "bad" software?

(Before I get started, a moment to appreciate this header image and whatever was the genesis of it.) Engineers will often describe software as "bad"—often with words like "terrible" or "shitty." This invective is hurled at languages like PHP and JavaScript, at frameworks

teams

Distributed Teams Need Face Time

There's a genre of post I've seen on LinkedIn and the fediverse recently that goes something like "I worked with people in person again and forgot how great it felt!" In the warming discourse about remote work and Return To Office (RTO) policies, I

ip

There's a Difference between "Publicly Available" and "Free as in Speech"

A couple weeks ago, the Wall Street Journal published 10-minute interview with Mira Murati, CTO of OpenAI, in which Murati said that their new "Sora" video generator model was trained on "publicly available or licensed data" (emphasis added by Ed Zitron). Ed wrote a longer piece

stuff i read

Stuff I've Been Reading - March 1, 2024

This is a collection of some of the articles, blog posts, podcasts, etc, that I've read in the past couple of weeks. I'm hoping to make this more of a weekly post on Fridays. We'll see! I'm immediately going to break the

planning

Debt, Depreciation, and Sustaining Engineering Work

Calling rearchitecture "tech debt" is a dangerous lie: it misrepresents the level of effort and retroactively makes our decisions into mistakes.

architecture

Starring our Monolith in the Role of...

Stop me if you've heard this one before. As a small, early stage start-up, we built an application in [Rails / Django / Express / Gin] because we were able to lean on the framework and ecosystem for a lot of the boring stuff, and focus on our unique value. Now,

Code

Introducing API Boundaries to Prepare for Bigger Changes

Alternatively: API Boundaries for Fun and Profit I routinely misquote Kent Beck, who said "for each desired change, make the change easy (warning: this may be hard), then make the easy change." He said this on Twitter (RIP) so I won't be linking to it, but

continuous deployment

When to use Feature Flags: Extra-Ordinary Unconfidence

Feature flags are a sine qua non for effective Continuous Deployment (CD)—and yet, they aren't always necessary. Nearly every sprint I've observed for the past 10 years has included the question "should this be feature-flagged?" at least once. Such a common question deserves

Code

Code is Knowledge

In the mid-2000s (so, in ancient history) a friend of mine went to an interview at a big tech company and was asked to write the JPEG compression algorithm on a whiteboard. He didn't know that algorithm off the top of his head, which he admitted, and then

programming

Using Timers to Learn

When I'm trying to learn a new language or environment, one of the first things that I try to do is implement a timer: code that can be used to instrument other code and print out how long it took to run. A long time ago, early on

go

Go Interfaces as Requirements, not Capabilities

This is a hard-won lesson that's taken me many years to learn, and I have seen others follow a similar path, so I'm writing it down in hopes that maybe some people will find a shortcut. Go's type system is, in my experience, fairly

Design

Changing the Meaning: Breaking Semantic Changes

The subtlest kind of breaking change is the kind that doesn't affect a value's type but instead affects what that value means. These changes can be hard to notice when you're making them, and even harder to debug when they happen. They can lead

Design

Three Models of Value

In product development, we often think of "value" in large, discrete units: the value of project A vs project B; the value of a feature; the value of a refactor or architecture change. When we're deploying continuously, we have an opportunity to replace this mental model

Database

Constrain Your Data Access for Fun and Scale

ActiveRecord-style ORMs can be huge time-savers, but also blur boundaries within a system, which leads to bad assumptions and habits

data

Conceptual, Logical and Physical Data Models

Conceptual, logical, and physical data models has proven to be one of the most valuable things I've learned recently

Code

Building Extensibility into APIs from the Start

Making the right design decisions early in a project can have a huge impact on the ability to safely improve and evolve it over time.