About

I started Constant Variable in September 2011 in Winter Park, Florida. The name comes from programming, where it’s a contradiction: a constant never changes, and a variable never sits still. Software has to be a bit of both, and so do most things worth keeping around. A few months later I wrote a little manifesto about it late one night and read it into a microphone. It still comes back to me more often than I’d like to admit.

Winter Park, 2011

At first it was an umbrella for side projects and client work, like the ones on this page. It gave a name to whatever I was making at the time, and that was about it.

Now

I want it to mean something more specific now. Most of what I’ve built since has the same shape: something keeps changing, and people need a way to keep up with it. Keep a Changelog exists because git log dumps are useless to the people upgrading your software. Shields exists because I got annoyed at how inconsistent README badges looked. Indigene tells you which plants belong in the spot you’re standing on, and Maison keeps track of everything your house needs.

I build things in two very different settings, and I think the same ideas apply to both.

In the open

Open source taught me that you can’t force a convention on anyone. Keep a Changelog spread because people found it useful, not because anyone had to follow it. I think the same habits work inside companies too (people call that InnerSource): work in the open, write decisions down where your colleagues can find them, and treat other teams like users who deserve a changelog.

In private

Product teams and startups deal with the same problem under a lot more pressure. You still owe people an account of what changed. It’s just that the people are closer: your teammates, your users reading release notes, and you in six months. Shipping matters more than polishing, but if nobody knows what you shipped, you’re only halfway done.

I’ll be writing more about both on the blog.