Coffee on the Keyboard

A software engineer, right, looking at a 3-monitor setup while working.

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.

Top-down photograph of a large, thin rock at the seashore casting a long shadow.

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, as our

Photo of a path to an ocean beach with a temporary barrier that says "beach closed"

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 at least for now

Photo of colorful papel picado banners strung between two buildings with a partly cloudy sky behind.

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 some framework for answering. Start with

Photo of a woman who has drawn on a whiteboard speaking to another woman, foreground, facing away from the camera.

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 made up

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 in my

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 unique. There's a family of object-oriented

A zoomed out photo of a dictionary open to a random page. The text is mostly blurred.

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 to downstream effects like broken reports—

A graph in the positive quadrant showing y=x, y=x^p where p>1, and y=x^p where p<1.

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 with a more continuous

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

A finger pointing to one of several empty boxes in a diagram on a chalk board.

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

A close up of wires plugged into a sound board.

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.

See the description. Dang blogging platform won't let me put this in the alt text.

testing

In defense of unit tests

A few years back, Guillermo Rauch—now the CEO of Vercel—tweeted a pithy assessment of automated testing: Write tests. Not too many. Mostly integration. — Guillermo Rauch (@rauchg) December 10, 2016 This inspired Kent C. Dodds to write that: Integration tests strike a great balance on the trade-offs between confidence

A photo of an older, wooden sliding garage door made of four panels, with windows near the top.

continuous deployment

Sliding Windows of Compatibility

Writing software professionally means constantly changing, evolving, and migrating applications. All-new "greenfield" projects are a rare treat, but not the norm. Constant change means we have to be comfortable making big changes applications that are running in production environments, usually with customers using them, and do it safely, without downtime

Photograph of a red carpet partly rolled out on grass.

programming

Caller-controlled Rollouts

Slightly warm take warning: not everything needs to be feature-flagged. New APIs or API endpoints, for example, that have no callers yet, don't benefit from the ability to toggle them off. If nothing is executing this code, then there's no behavior to disable. Let's say we have an API for

zero

The Creative Power of Zero

Yesterday, I wrote about how a three-legged deploy process enables migrations in continuous deployment (CD). Today I want to talk about the creativity that hides in the gap between "a little" and "zero." One way to look for opportunities—I think attributable to Marty Cagan—to innovate is to take

continuous deployment

Zero Downtime and the Art of Continuous Deployment

I've been thinking a lot about the relationship between availability and continuous deployment (when I say "CD," I usually mean "deployment," all the way to production). One of the primary concerns people raise about CD is the perceived risk to availability or uptime. But there are patterns we can adopt

A photo of the word Debt spraypainted on a brick wall: multicolor shading, bubble letters.

tech debt

Tech Debt, Depreciation, and Features

There was some discourse on Twitter (yes, it's still there, for now) yesterday about the nature of Technical Debt and how effective it is as a metaphor. The real seed was the new boss arguing with—and eventually firing—one of the few remaining engineers on the Android team. But

human factors

Root Cause, Proximal Cause, or Least Effort to Remediate

I am no fan of "Root Cause Analysis." It's one of the many terms or concepts that software has borrowed from manufacturing—while ignoring the subsequent 70 years of research into human factors and resilience engineering. However, like Lorin, I admit that it has some value during incident response. It's

A woman in a white shirt points to Central Park on a subway map in a station, giving directions to a man in green

open source

Open Source Subway Map

If you don't actually want to read this whole post (no shame at all) the tl;dr is that I'm going to try using a GitHub project to organize and hold myself accountable for open source maintenance. Mental health is a weird thing, sometimes. Like, oh I don't know, everyone,

metrics

Naming metrics, or why my statsd client doesn't support tags

It may not be a popular claim, but I still think logs and metrics serve an important role in modern observability along with tools like tracing. And there are a number of tools for collecting metrics, like Etsy's StatsD and other implementations, Datadog, Promethus, the ELK stack, and others. One

A used car lot from the 1950s, named Parker-Robb Chevrolet, and featuring a number of classic Chevys.

technical

What is "Tech Depreciation?"

As soon as you drive that software off the lot, its value will start going down. "Tech debt" is a well-known and useful metaphor, but I've found it doesn't describe the whole picture. Technical debt is a choice, a trade-off—sometimes made well—that can be paid down. It describes

So you want to depend on something?

I was chatting with a friend recently about a potential refactor they were considering that would've reduced overall lines of code. I realized we were talking about a very concrete opportunity to apply dependency inversion. I typed up a quick note and decided to expand it here. These examples are

The Triforce of Deployment

Continuous delivery is great. Fortunately, so are all the tools you need to get there. I've talked [https://github.com/jsocol/talks/tree/master/2013-06-13-firstmark-cd] about this [https://github.com/jsocol/talks/tree/master/2017-05-03-queensjs-cd] a number of times [https://jamessocol.com/speaker.html]—including recently on Software Engineering Radio

teams

Unclear Asks are Killing your Team

We've all been in a meeting, wondering what the goal was, and why we were invited. Some of us have even gotten up, said something, and left. The truly bold may have suggested ending the entire meeting and reconvening with a plan. We've also all gotten an email addressed to