Links

Ideas that resonate with me and are worth sharing. Inspired by matklad's links.

Functional core, imperative shell

https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell

...testing the functional pieces is very easy, and it often naturally allows isolated testing with no test doubles. It also leads to an imperative shell with few conditionals, making reasoning about the program's state over time much easier.

Plan-execute pattern

https://mmapped.blog/posts/29-plan-execute

The planning stage takes the inputs and produces a plan: a data structure encapsulating all the decisions the algorithm should make. The execution stage realizes the plan.

This approach allows for more comprehensive testing of the decision-making part. It also extends the system’s debugging capabilities: since the plan is a data structure, humans can inspect it to understand what the system is about to do without causing side effects.

Parse, don't validate

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

...validation-based approaches make it extremely difficult or impossible to determine if everything was actually validated up front or if some of those so-called “impossible” cases might actually happen. The entire program must assume that raising an exception anywhere is not only possible, it’s regularly necessary.

Parsing avoids this problem by stratifying the program into two phases—parsing and execution—where failure due to invalid input can only happen in the first phase.

"Not rocket science" rule of software engineering

https://graydon2.dreamwidth.org/1597.html

Automatically maintain a repository of code that always passes all the tests.

Erase your darlings

https://grahamc.com/blog/erase-your-darlings/

Over time, a system collects state on its root partition ... [it] represents every under-documented or out-of-order step in bringing up the services.

The nugget here is the regular and indiscriminate removal of system state. Destroying the whole server doesn’t leave you much room to forget the little tweaks you made along the way.

Boundary tokens

https://blog.glyph.im/2024/07/against-innovation-tokens.html

When selecting a technology, you should consider its ease of operation more than its ease of development. If your team is successful, they will be operating and maintaining it far longer than they are initially integrating and deploying it.

A better way to think about the problem of managing operational overhead is, rather than 'innovation tokens', consider 'boundary tokens'. That is to say, rather than evaluating the general sense of weird vibes from your architecture, consider the consistency of that architecture.