In my book, I talk about making technical decisions and, in particular, understanding the priorities of everyone involved in the decision-making. A more powerful way to lead teams to execution is to clearly articulate a vision of what you are trying to achieve. It’s also much more difficult.

Westworld is a show on HBO about a theme park where human Guests interact with lifelike robotic Hosts. The Guests can basically do whatever they want to the Hosts. The show is deep, and some of the best sci-fi television you can find. But, it also contains many important lessons we can apply to DevOps.

Spoilers Ahead

Learning to write is one of the best skills you can learn as a developer. It takes up an entire chapter in my book on being a great software engineer. Writing is a specific way to communicate ideas, but diagramming is a powerful tool as well, often moreso.

Being able to quickly create a diagram can make all the difference in expressing yourself clearly. And Graphviz is a great tool to have in your pocket to do so.

There was a conversation on Twitter about developers being on call, started (I think) from this tweet (in reaction to a series of tweets that, thusfar, starts with this great blog post by Alice Goldfuss):

Put your developers on-call. You’ll be surprised what stops breaking.— Aaron

אהרן (@as_w)

I 100% agree with this (for a particular interpretation of “put”—see below).

In exploring the modern front-end ecosystem for my new book, I’ve gotten to experience some truly difficult configuration formats (Webpack) and to work around aspects of Rails that aren’t configurable (Sprockets). Configuration is hard, and it’s an overlooked part of the user experience often designed to make the software library author’s job easier at the expense of ease-of-use.

It doesn’t have to be this way.

Craig Kerstiens wrote a great short blog post about writing more legible SQL. It’s a great read on an important topic—SQL can be very hard to read and modify—but I don’t think he goes far enough about “one thing per line”, so I’d like to show how I write SQL.

This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.

In this one, we’ll explore why I think having explicit support for creating non-model service objects would be a good thing.