Logic Fault

Reversibility is the most important quality of good software decisionmaking.

Here’s a cute Python trick I just discovered.

Your data lake probably looks like this and your data lakehouse will probably look like this.

This post is a lengthy narration of some debugging/resolution I did involving MacOS, dtrace, Rust, and cross-architecture binary execution.

Ownership # “If it has multiple owners, it has no owner” indicates a failure of accountability, not a failure in the ownership model.

An overengineer once said: There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Things to do proactively in advance of anticipated need: Pee Save money Be kind Things not to do proactively in advance of anticipated need: Stockpile nuclear weapons Purchase cryptocurrency Extract code into a microservice

So.

A hypothetical intern or very junior/first-time programmer comes up a lot in discussion of design patterns.

Code is read more than it is written.

Let’s talk about modularity/swappability, sometimes called “abstraction” (v.).

Writing the most valuable code for your team and customers is a lot less fun than most people think it is.

Many teams who “successfully” apply design patterns to a codebase feel that they were successful because changes are now much easier for them to make.

Class hierarchy is inferior to if/else as a way of modelling conditional behaviour.

If you have to choose between tortured, hard-to-read production code and tortured, hard-to-read tests for that code, it is better to have bad tests than bad prod code.

It is easier to feel good about reading SOLID-factored code, but it is easier to read and understand under-abstracted code quickly.

Lots of the things on this blog talk in terms of “it is better to do good-thing-X than good-thing-Y”.

Refactoring/Abstracting Code Reactively # A lot of the content under “design patterns” here has a punchline of “do so-and-so-practice reactively”.

What is this place?