Entropy is concerned with the amount of thermal energy that is available for work. The higher the entropy, the less the available energy for work. And vice versa. The second law of thermodynamics states entropy will increase over time in a closed system until it reaches equilibrium. All the available energy will level out eventually as entropy increases. I recently wrote about the idea of understanding the complexity of a schema by measuring its entropy.

I’ve been tinkering with an idea I called an API Design System. It tries to take the thinking behind Design System patterns and apply them to APIs. You can read the overview on the site to get the idea behind it. I’ll share details behind why I’ve been working on this. What we lose writing style guides in text I’ve worked at places where we tried to come up with an API style guide.

I mentioned before my habit of tinkering on my site’s code without end. This kept me from writing. So I started over. I wanted to set myself up for writing more frequently, and starting over felt like the best move. I also wanted to keep a lookout for other areas that created friction. One I quickly saw was using Git. It’s not great for the writing process. I’d create a file, stage it, commit it, then push it.

I traveled to Alabama this week for a golf trip with some friends from my college years. We played at Gunter’s Landing and Hampton Cove. We played almost 12 hours of golf the first day and probably 10 the next—that’s a lot of golf. But it was fun and the team I was on won our friendly tournament. All the practice over the last couple of months paid off. Thankfully, my back healed up enough to let me play.

I remember hearing Seth Godin say on a podcast that he thinks everyone should start a blog and write on it every day. In 2017 he wrote his 7,000th post, which he said added up to 37 full-length books. When asked for advice on becoming a better designer, he said to write every day. Last year I got on a kick of reading Annie Dillard. I enjoyed her style. She would take her observations and weave them in throughout her essays.

When we design an API—among many things—we’re designing how we think the API will change. We often reach for versioning to handle this, but versioning is a small part of the change discussion. For instance, will the versions be for the entire API or for individual resources? Will we support each version forever, or will we deprecate and sunset all or parts of versions? And at what point do we switch to a new version?

One of my favorite practices I’ve adopted in my professional career is to write about everything I’m working on or thinking about in a place coworkers could see. I thought I’d share the ways I’ve made this work for me. Make your own space The goal of having your own space is so you don’t have to think about or care about making a new page. Without it, you feel like you have to find the official place to write something authoritative about an official topic.

I started out writing these weeknotes on HEY World. I liked how easy it was to write there—just send an email to world@hey.com, and it would create a post for you at https://world.hey.com. It also supported an email subscription feature. However, I set this goal a few weeks ago to start writing more, both for fun and professionally, and just this week I started from scratch on this site with Hugo.

Fine, I’ll start a blog. Or I should say restart a blog. I started writing on this site several years ago. I was wanting to write more professional content around my work. I picked Middleman as a build tool for the blog and off I went. I wrote a few posts on it. Five or six over the course of a couple of years maybe? After some time, I converted the site over to Jekyll because GitHub would build, deploy, and host your site for free.

I’m working on a personal project with the goal of giving insights into the complexity of an API design. We don’t have many ways or tools for looking at complexity, and the ones we do require experience and knowledge of API design. I’m hoping to find ways to look at complexity through a different lens. One way I’m working on now is what I call schema entropy. An intro to the idea of schema entropy Schema entropy is a way to look at the complexity of an API schema by determining how many variations of the schema are possible.