About / Josh Caffey
The code was only part of the problem.
I’ve built software professionally for nearly two decades. I started as a web application engineer, then moved into platform engineering and architecture: Senior Software Engineer, Platform Engineer, Head of Platform.
That changed how I think. I still care about code. But the problems that cost organizations the most rarely live in one function or one service. They live between things: between teams and tools, between a design and the people who have to build it, between what a system does and what anyone can see it doing.
01 / The whole system
Software is a system, not just code.
An engineering organization is a system too. Architecture, build and deploy tooling, developer environments, infrastructure, and operational visibility all decide how fast a team can change its software, and how safely.
When something is hard, it’s usually hard because of how those pieces fit together. So I start with questions about the system.
- Where is the same complexity being solved again and again?
- Which constraints are real, and which are accidental?
- What should become a platform capability, and what should stay with the team?
Sometimes the answer is a new platform capability. Sometimes it’s deleting something. Adding another layer is the last thing I reach for.
02 / Attention
Developer attention is expensive.
Good engineers get very good at whatever they’re forced to deal with. Hand them a pile of infrastructure and framework problems and they’ll solve them, and solve them well. That doesn’t mean they should have to.
At Volt, creating a new service meant starting from scratch. The team got strong at the technical details, and the messaging domain they were building for got less of their attention. I built Ground, a Rust framework and CLI, and automated workstation setup so that work moved into the platform. The application developer owned the business logic. Everything beneath it was the platform’s job.
Good platforms don’t make engineers less capable. They remove machinery that teaches nobody anything about the business, so attention goes to the problem the company actually has.
03 / Implementation
Architecture should survive contact with implementation.
I like a whiteboard. It’s the best place to find a design. But a diagram doesn’t have to be built, deployed, debugged at 2 a.m., or changed by someone new. So I test designs against the work.
- What will an engineer actually have to write?
- How will it be deployed, and what does it look like when it breaks?
- Who has to change it in a year, without me in the room?
If I can’t answer those, the design isn’t finished. Often the fastest way to answer is to build the thin version: a prototype, a CLI, a working pipeline.
That’s why I stay in the implementation. I’ve designed and built internal developer platforms, cloud architecture, developer environments, delivery pipelines, observability, and the APIs and services on top of them. I’m as comfortable in the code as I am in the diagram, and I’ll go where the design needs me.
04 / Craft
The craft still matters.
My scope got larger. My interest in programming didn’t get smaller. I still care about a clear API, an abstraction that earns its place, and a system simple enough to hold in your head. I still love terminals, and I still build the command-line tools I’d want to use.
Experience mostly changed what I ask of the code. Early on, a clever solution or an interesting technology was reason enough. Now I ask who will run it, who will change it, and what it costs to own. Sometimes the answer is still something sophisticated. It has to earn its place. Often the answer is Postgres.
What I do now
Make good engineering easier.
I help organizations find where architecture, platforms, and developer experience can remove complexity nobody needs. Then I help build it, or help your team build it.
If your engineers are spending attention on things that don’t teach them about your business, I’d like to hear about it.