Superficial Simplicity

For the last decade I’ve chased and wrestled with the ideal of “simple” software, but I’ve come to see it as a false summit and want to spend some ink on why in the hope that it can lead to a better understanding of simplicity and more intelligent conversations about complexity.

Software working conditions

If you’ve spent any time around a traditional workshop or machine shop, you’ve probably seen signs about how safety is everyone’s responsibility and about keeping the shared space clean. In an environment with sparks, unrated flammables left around are a risk. In an environment with rotating tools like lathes loose clothing that can wrap or snag and pull can lead to injury. Less extreme examples like sweeping up the shop and keeping the fridge clean all fill different parts of the same shared obligation to the other users of a space.

Techdebt Tornado

Techdebt tornado, adj.; pejorative

One who successfully delivers changes with limited or counterproductive regard for architecture.

One who produces work, especially feature work, at the cost of existing architecture and without developing a successor architecture.

The Thirty Million Line Problem

This blog post is a review and musing on a talk of the same title “The Thirty Million Line Problem” (2015) (~1h lecture + 40m q&a).

A Pi cluster parts list

Previously, I talked about some limitations of building RPi clusters generally.

Notes from building Raspberry Pi clusters

A while ago I got it into my head to put a Raspberry Pi cluster together.

More precious than silver

I’ve been doing a lot of reflecting lately on the last project I shipped - what went well, and what didn’t. A while back I tweeted out some halfbaked thoughts. One of which was a reflection that while the entire engineering organization beyond my team was using a tremendously powerful toolset, we still got bogged down.

[2016] Breaking changes considered essential

Version numbers are hard. We as programmers are awful about tracking what constitutes a breaking change compared to what constitutes an invisible bugfix. From a formal semantics perspective, there is no such thing as a bug and every “bugfix” is strictly speaking a breaking change. And yet this notion of “fixing” behavior “broken” by shoddy implementations is central to modern notions of libraries, dependency management and deployment. I’ve previously written about versioning, its semantics and some theories about how we could do it better.

Test post

sorry goose

Automated Publishing with Jekyll

This post is somewhat meta - as it concerns a whole bunch of the automation by which I go about writing on this blog.