James Socol

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

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—

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

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.

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

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

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

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

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

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

Remembering TodaysMeet

Nearly 10 years ago, I launched a small chat tool [https://todaysmeet.com]. Somehow, through a lot of luck, and a bunch of hard work, it managed to become popular among classroom teachers as a way to enable new kinds of conversations. Now it's time to say goodbye and move

PIEfection Slides Up

I put the slides for my ManhattanJS talk, "PIEfection" [https://github.com/jsocol/talks/tree/master/2016-01-13-manhattanjs-pie] up on GitHub the other day (sans images, but there are links in the source for all of those). I completely neglected to talk about the Maillard reaction [https://en.wikipedia.org/wiki/

conde-nast

New Year, New Role

Yesterday was my last day at the job I’ve been in for most of 2015. Later this month I’ll be joining the digital team at Condé Nast! I’ve been interested in media, publishing, and journalism since I was a kid, growing up in the office of a

Code

Open Source Update: Waffle

I just pushed version 0.11 of Waffle [https://pypi.python.org/pypi/django-waffle/0.11], the feature flipper for Django [https://www.djangoproject.com/]. It contains a number of code and documentation fixes [https://github.com/jsocol/django-waffle/compare/v0.10.1...v0.11] which you can also see

Open Source Update: Jingo

Update: Jingo is no longer supported as was deprecated in favor of django-jinja at the end of May 2016. As part of shuffling around open source responsibilities [https://coffeeonthekeyboard.com/open-source-update-bleach-1359/], I’m going back to being the sole maintainer of Jingo [https://github.com/jbalogh/jingo] for now. I