Writing down remediation items is a seductively simple outcome for a post-mortem. It’s satisfying. “Yea, there was an issue but if we do these 3 things, we will be better off”. It’s all wrapped up in a nice bow. Although remediation feels like the right outcome, it’s not the most powerful reason to do a post-mortem. The most valuable part of a post-mortem is the ability to radiate expertise into your organization. #

(A hypothetical dependency graph that led to a systemic failure in AWS us-east-1 from @0xdabbad00) Like many, I was personally affected by the AWS outage last week. I was on-call, and was paged for a couple of reasons. While I was paged, I owe a lot to the infrastructure team I work with. They managed all of the issues I was paged for, and outside of a few spurious pages, I was mostly insulated from the issue. #

Striving to be better, made me. Even though, it almost broke me. Over the last few years, I’ve tried to find a way to balance my daily duties and routines with my drive to be better and do better. Besides being a great time to be with family and friends, for me the time between Thanksgiving and New Years' allows me to burn through my inbox, collect my thoughts, maybe write. #

When it comes to creating a start-up there’s prevailing wisdom. There’s even a school you can go to to learn it. But, for every company that does it “right”, there is one that does it their own way. One that is introspective and honest (ish). That other way is epitomized by Gimlet, the podcast company, at least if their podcast is any representation of how they work. I’ve brought up the podcast a few times with friends and co-workers because it’s entertaining, and it instructive for folks who work in growing businesses. #

In my professional roles the word engineer is in the title somewhere. For instance I’m currently a Principal Engineer at Stitch Fix, but I’ve been a Software Engineer, Front-end Engineer and so fourth over the years. The word engineer isn’t really apt for what I do though. In the last year I found a new promising word: Symmathecist. I learned about it from this post “The Origins of Opera and the Future of Programming” by Jessica Kerr. #

The infrastructure of my productivity is a set of tools that revolve around plain text files. Try as I might it doesn’t work any other way. I’ve tried tools with more “stuff” in them. Often when I try and import my modest1 set of files they grind to a halt. So, I go back to my tried and true tools. I’m thankful they exist and continue to work. It’s a patchwork of folks and tools that keep this stuff running. #

I use Go off and on. I’ve recently had the opportunity to use it again. I feel comfortable now with a handful of languages including Go. More importantly I’ve fought fires in production, developed new services, and tried to refactor balls of mud in a handful of languages. Out of them all no language is more kind to it’s user then Go. That fact is on display in this talk Go at Google: Language Design in the Service of Software Engineering. #

There is a book. Called “In The Beginning Was the Command Line” written by Neal Stephenson. 1 You might know him from such books as Snowcrash or Cryptonomicon, but he’s written some non-fiction as well. It’s hard to describe but it’s about the act of computing and the choices that surround folks who computed, especially in the late 90’s. It’s compelling for many reasons, but I think I can point to at least one reason what I was so fascinated by the command line and by linux. #

I think about this sometimes. Like, people used to punch holes in cards to program. That’s insane to me, but I can only imagine what it will look like in the future. I think the biggest questions is like, will we even write code? Or, will we train, direct, or work with some … thing. Here’s an interesting post that talks about near to far future: “Programming: 50, 100 years from now”. #

I have worked on projects that missed the deadline by years. It’s soul-crushing. Whats worse is that it sounds like it’s endemic. Big projects are failing all over the place. Most IT experts agree that such failures occur far more often than they should. What’s more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. #