While preparing for my first week at Chainguard, the CEO mentioned that I should order my own laptop. As a ~15 person startup, there isn't an IT department to handle these sorts of things.
In 2022, the default laptop of choice for a software engineer working on cloud infrastructure is the Apple M1 Powerbook. They hit nearly all the checkboxes: a great screen, powerful CPUs, and battery life that is the envy of any laptop in their class. The arm64 based Macs are fantastic: in fact, I'm typing this from my personal M1 MacBook Air. Ever the contrarian, I however felt that:
What if you could easily reduce the length of outages by 3X?
According to the SRE book, “recording the best practices ahead of time in a playbook produces roughly a 3x improvement in MTTR”. This improvement mirrors my experience with well-written playbooks.
In my experience as a software engineer and a software engineering manager, I’ve found that the best way to motivate software engineers is with empathy, purpose, and a sense of craftsmanship. Conversely, the most effective way to demotivate a software engineering team over the long term is with excessive process and deadlines.
Let’s dive a little bit deeper into the levers I’ve found that work in motivating software engineers into doing their best work:
Ever wanted to run Docker on an unmanned macOS machine, where all users could have access to a working Docker command-line?
First, be aware that docker is not designed to be securely shared among multiple users. As with Linux, Please assume that anyone who has access to docker is effectively equivalent to `root'.
I wanted to get my feet wet with understanding Kaniko, an open-source in-cluster builder for Docker images. I happen to work with one of the maintainers, Tejal, and I asked her if there was any interesting UNIX-internals sort of bugs that might be interesting.
Here's the mystery issue: “The USER command does not set the correct gids, so extra groups are dropped”. Here's an example to reproduce it:
