DevOps, at least as I understand it, is about delivering value. It sounds simple, but delivering that value happens via a pipeline. The stages of that pipeline often represent whole groupes of people. Ofthen those groups can have competing priorities. Thus increasing friction in the pipeline and slowing down the deliver of value. That’s where DevOps comes to the rescue. By working with everyone in the pipeline and building a shared vision of how to deliver value, you can get everyone to optimize for the shared global goal of value delivery. #

The biggest irony in dev work is that we all want to build easy to use systems, but that’s hard to impossible to do. Easy is hard. Rich Hickey in his talk “Simple Made Easy” walks us through this irony and why its so important that we continue to try and build easy to use systems. 1 Here is a transcript of the talk as well. ↩︎

It’s not often that anyone can take up basic linux literacy and make it interesting, but Julia Evans1 does it with style. Here is her zine on pipes2: She doesn’t just illuminate linux, she will often bring that same clarity to more advanced topics such as service discovery. Here is a zine from a blog post 3 she wrote on Stripes engineering blog. So, checkout the zines, or one of her many posts on kubernetes or networking and learn something. #

When I design a new service, I want it to be efficient. Mostly, for any humans involved, but also for the technical components. Why make two HTTP calls when you can make 1. When thinking about tradeoffs it can be helpful to consider how long common operations take. Not surprisingly, lists have been made of these common operations. As far as I can tell starting with Peter Norvig, and then re-popularised by Jeff Dean. #

Given I don’t know what I don’t know, but I want to find out. This taxonomy of ignorance and interesting thought experiment. The Five Orders of Ignorance 1 Lack of Ignorance. Lack of Knowledge. Lack of Awareness Lack of Process. Meta Ignorance http://losangeles.acm.org/Archives/laacm0512-Article%2002%20The%205%20Orders%20of%20Ignorance%20OCT%202000.pdf ↩︎

We don’t know what we don’t know. Clearly. But, sometimes the keys to a project exist in the unknown. Yet many of our project planning and execution tools don’t take this into account. If you just do the same thing over and over again, you will probably get better at performing that sequence, but you won’t learn anything new. That’s a quote from “Introducing Deliberate Discovery” by Dan North 1. #

There will be commit messages. Many. Of. Them. Your team will read them. Your boss will read them. Strangers will read them. You will read them. Future self is skeptical of present self. You owe it to everyone to try and write better commit messages. I’m not suggesting that I always do, it’s a lofty goal, but here is some help: Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do not end the subject line with a period Use the imperative mood in the subject lineWrap the body at 72 characters Use the body to explain what and why vs. #

I am a fan of tests, but my testing journey was long and fraught. One of the hardest ideas for me to understand was where do you draw the line. How much is enough? I tried many different ways to understand this, but it wasn’t until I read this quote from Kent Beck that a key idea crystalized. I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence 1 #

During the course of my work I find my self rubberbanding between two extremes - universal truth and exacting, excruciating detail at a specific moment in time. Those many not seem like they are on the same continuum, but that’s where todays suggesting reading comes into play: The Three Ways by Gene Kim 1. I’m a sucker for bit of wisdom that is seemingly inscrutable, but reveals it self to be universal. #

But, how do they work? 1 Platforms are about leverage. When done well they increase value superlinear rate compared to the amount of resources available. They are also hard to define, hard to see, and hard to build. Today, I’ve got a one two punch. First an article from Frank Chimero, “Platforms as Tables, Tables as Platforms” 2. In it Chimero finds that Design and Jazz are both platforms, but also: #