You want to get hard things done, and you want to tackle progressively bigger things. We all do. If you are reading this you chose to do a hard thing. You probably use hard work and elbow grease to do the job. While that kind of work is valuable, at a certain level of complexity, those tools loose their usefulness. And yet, you still want to do the hard thing. This is a good news/bad news deal. #

Once you’ve decided to adopt a new view of safety, and want to help an organization change, how do you know if you are changing anything? How do you know if you are successful? Especially considering the total organization overhaul you hope to achieve. It can be useful to identify some markers somewhere between nothing, and total success. What are some markers that demonstrate we are on our way? A recent incident, which involved a system I am partially accountable/responsible for, left me with a morbid sense of pride. #

From my tiny West Berkeley apartment, with my family asleep upstairs, I typed into the search box: “python Berkeley”. It was 2015 and for the past 6 years, I commuted hours a day all over the Bay Area. My goal was eventually to create a startup. But, My latest gig had imploded and I was tired and mis-wanting to be a startup founder was reason number one . While I still enjoyed programming, I needed a refuge from the hustle, if possible a job I could walk to. #

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. #