Small Platform

Trial and Error Driven Development

One of the things that I learned (fortunately) relatively early on in my career is that it’s actually important to understand how things work.

I remember in college working on assignments where we would receive some framework code to work with. It wouldn’t compile. I would bash against each compiler error until I would finally get it to compile. Then I’d add my changes. More bashing to get that to compile. I’d run it. It wouldn’t give the right output. More changing things. More bashing. More running. Finally I’d get it to output the “happy path” result for the assignment. Then I’d turn it in and get a good grade. But I didn’t really understand 90% of how the thing worked. I had mostly brute forced the assignment.

Robust Software, Clear Thinking, and Production Excellence in Release It!

I recently ran a book club at Seeq for the book Release It! by Michael T. Nygard. It’s a new entry on my list of recommended books for all software engineers - platform engineers included. There are a bunch of great, practical insights to be harvested. Throughout the book, I found myself reflecting on the systems I work on at Seeq or even checking code to verify some detail that Nygard had brought to mind.

Speed? Stability? or Making 💰? How to clarify software priorities

In The Principle of Production Purpose (PPP), I described a principle that encourages applying common sense to software. That common sense can have some pretty far-reaching implications. In the article, I gave the application of the principle unfortunately brief treatment. After some correspondence and chatting with readers about it, I think it’s time to further flesh out how the principle of production purpose can be applied to your work. As a reminder the principle states,

Conquer Your Main Quest

v0.0.1

In the last article, I wrote about how I was selected to lead a new team at my company, Seeq, that would be responsible for infrastructure, developer experience, software delivery, production observability, and operations tooling. What I didn’t mention is that our product (also called Seeq) was primarily deployed on-premise at the time. Seeq started out as an on-premise web application. Each customer had to install it on one of their own servers on their own network. But in late 2020, things were starting to change. A couple of enterprising site reliability engineers (SREs), with the support of some other customer-facing roles, had taken our on-premise product, installed it in the cloud, and made it available to a few of our first, brave Software as a service (SaaS) customers.

The Principle of Production Purpose

“We want you to be the manager,” my VP of engineering told me.

“Oh… ok,” I responded.

Earlier that week I had volunteered to be part of a newly forming infrastructure team - also responsible for developer experience, software delivery, production observability, and operations tooling - at my company, Seeq.

I was very interested in this new team for a couple of reasons. First, I had always been curious about how systems I worked on functioned from end to end. Rather than being satisfied with pushing some code and trusting the deploy pipeline to take it from there, I wanted to inspect the nodes, network connections, and other components of the production system. Second, I saw big opportunities for Seeq in particular for improved productivity via more automation of our deployments, faster builds, better observability of the system, etc.