Weeknotes 2022 W38: DevOps is not DevOps

Bad sleep this week has made me fairly grumpy. I absolutely need this weekend to get my energy back and bring my mood up.

I’ve had some trouble disconnecting from work. This is both good and bad: good because I’m working on stuff that is exciting yet challenging, and bad because the work inadvertently seeps deeply into my spare time. I need to figure out better ways to disconnect.

I made bread earlier this week, but it somehow did not turn out well. The bread looks fine, but the taste is definitely off. Acidic, I think. I’ve been toasting the slices — I feel like that’s the only way I can eat it now.

Even though the hydration was fairly low, the dough remained sticky, and I had trouble getting it out of the banneton. I am unsure whether this is related.

I’ll probably re-create my sourdough starter from a tiny fraction of my current starter, and hope that the new starter behaves better.

I’ve spent some time on Nanoc maintenance this week, and I regretfully have to admit that I feel burned out by it. In particular, two things made this week’s maintenance work frustrating:

• The new version 4.0.5 of Psych, Ruby’s YAML parser, created an incompatibility with Timecop, a Ruby gem for mocking the current date and time. This causes the YAML input created_on: 2022-09-24 to be parsed incorrectly as {"created_on" => "2022-09-24"}: the value is parsed as a String, but should be a Date instance. I spent quite some time figuring out where that error comes from, but couldn’t figure out a fix.

• Haml version 6 is out, with an API that is drastically different, and undocumented as far as I can tell. I couldn’t figure out how to make it work properly with Nanoc. The web site has not been updated for version 6 yet. (The Haml blog hasn’t been updated since version 4, released in 2013.)

The time I spend on Nanoc is work, which comes on top of a full-time job.

The term “DevOps” continues to cause plenty of confusion.

At my employer, the term “DevOps” refers to the work that the infrastructure team does. (This team is called the “DevOps team”.) The engineering department’s goal is to have zero DevOps in day-to-day engineering, by which they mean having no dependency on the infrastructure team, and giving developers the responsibility to deploy, roll back, make changes the production configuration, etc. This is DevOps.

The term “DevOps” has become so twisted that it now means its own opposite.

My current employer is by far no exception. In the job interviews I’ve done in the last several years, I’ve asked about DevOps practices. Many companies (all based in Germany) said they had a dedicated team for DevOps, and that regular engineers wouldn’t be involved in DevOps.

How can it be that so many engineering departments thoroughly misunderstand the term “DevOps”? Such misconceptions about DevOps are prevalent, yet the DevOps Wikipedia page mentions nothing of this change in meaning. What is happening?!

(The term “DevOps” isn’t the only one that has problems. The terms “Agile” and especially “CI” have taken on vastly different meanings, too. But I’m saving that discussion for another time.)

At the request of a coworker, I started writing up some smaller project ideas. The first one is Project idea: Captain’s log: a tool for tracking changes to production environments.

These projects are small enough to pick up by junior engineers, and should provide a nice amount of experience with building and shipping a product from scratch.

I’ve got some other ideas that I need to write down in more detail.

My web site listing vintage Apple hardware to give away is becoming more and more complete, though about 50% of the work remains.

I’m hosting the web site on Fastmail, which seems to struggle to load all the images at the same time. On the initial page load, some images don’t load and show up broken instead. I’ve set up lazy-loading for now, which should help. Fastmail isn’t the best web hosting provider, but then again, they’re not called Fastweb, are they?

Entertainment:

• I finished Bosch season 1. It’s good, but not great. I like it because I’m a fan of suspenseful TV shows, I suppose.

• The more I keep watching The Lord of the Rings: The Rings of Power, the more I feel I’ll be in for a long and slow ride. Each episode advances the story a frustratingly small amount.

• I spent a couple of minutes in the Halo: CE remake, and it’s wild how much better it looks than the original Halo: CE. The original is from 2001, and the remake is from 2011, which makes the remake also rather old by this point. Being able to switch between old and new graphics on the fly is amazing, too (though maybe not very useful).

Links:

• 11 Laws of Software Estimation for Complex Work (Maarten Dalmijn): I’m of the opinion that estimates are not very useful, and this article offers a good explanation why.

• Moving With Prototypes (Jim Nielsen): Another good argument for prototyping. It’s so much more valuable to build something rather than having meetings and discussions about what to build and how to build it in the first place.

• Leaking Screen Information on Zoom Calls through Reflections in Eyeglasses (Bruce Schneier): In hindsight, of course people would be researching this.

• Entitlement in Open Source (Mike McQuaid): Hear hear. I maintain a few open-source packages, and this article is relatable.

• MKUltra: The CIA’s Dark History of Mind Control (Philion)