It has become a sort of knob to tweak to make life better, an axis on the activity matrix to tinker with to make life better, when it works.

As a concrete example, cooking: It’s the kind of thing that’s easy to resent the presence of, since most people in broadly-western lives need to do so for almost every meal. You gradually have a sort of repertoire of things you can make without too much thought, things you keep the ingredients around for, so you can just make them when you need to eat food in order to not die.¹ It is also easy to get sick of those default meals, and then you have to try to find more stuff again, and so on.

Moving the effort level up then could mean any of these:

• Acquiring/reviewing cook books for new ideas
• Making sketches and plans for dishes made from separate components
• Unusually time-intense preperations (i.e. dry-aging, fermenting, brining)
• Acquiring produce from a different vendor and seeing how it changes things.

Doing that generally changes the experience in a significant way, and often in a good way. It’s novelty in a way that lets you meaningfully improve something routine. I also tend to be able to liberally steal techniques and tricks from very fancy cooking for regular cooking²

Often the main way I want the dial to turn on effort is down, but that tends to make everything quite beige and turns things that are fun into functionalist affairs that do their job, but have had the enjoyment optmised out. Deliberately throwing way more effort than strictly required often lets me enjoy the routine version again, with some more information and a slightly changed perspective.

In short, try tinkering with moving the effort-invested slider up, rather than down. When you do that, try going way up on the effort invested, rather than slightly up, and I think you might learn something about something you were already treating as bland routine.

I kept thinking about that deck of cards long after I finished the documentary. It made it very straightforward for Jerry to work on the map: he’d draw a card, and do what it said. If he didn’t like the effect it had, he’d alter the rules, or the deck. But the next step after was always to draw another card and follow its instructions.

Now, I have struggled for my entire life to tie together the various creative interests I have, from music composition, to visual arts, to woodworking and carpentry, to writing fiction and non-fiction, to cooking and baking. They all feel relatively cohesive to me, in that they’re all trying to create something. The different outputs and types are just differences in methodology.

So, I followed another time-honoured journey of creative people: stealing. I stole the idea behind Jerry’s deck of cards: that it’s a draw-one, self-modifying, self-regulating deck for creating stuff, and decided I’d make my own. I also decided to lean into whimsy and pathos, and so I came up with The Fates.

The Fates

The Fates are a deck of, currently, 15 directives, or Fates. They are cut-together pieces of heavy note-paper, with a reversed Magic: The Gathering card as backing, inside cheap sleeves that I had lying around. Why? Because one of the directives is to shuffle the deck, and M:TG cards shuffle nicely.

This silly deck of cards has been extraordinarily successful for me at making more stuff. It is very straightforward to make more stuff with. It has three rules:

1. To invoke The Fates, draw a card off the top. Follow their instructions.
2. After you have completed said instructions, place the card at the bottom of the pile.
3. When you invoke The Fates, write down which Fate has been bestowed upon you. Then write down what you did to execute it.

And so, when I sit down at my desk with nothing concretely to do, rather than launch a video game of my choice², I Invoke The Fates™. And it has just led to me making a ton of stuff and having altogether better wellbeing than I did prior to trying this out. I’d recommend giving it a shot, if choice-paralysis in the creating of stuff is a thing that affects you.

In closing, here’s a list of my cards, currently:

1. Shuffle.
2. Read a chapter of fiction.
3. Read a chapter of non-fiction.
4. Invoke The Fates(™) and embellish their command (read: Draw on the card.)
5. Meditate about The Fates (what’s working? What isn’t? Am I happy with how this experiment is going?)
6. Meditate about the forefront of your mind (basically: actually run down and finish thinking about what’s in your head, rather than leaving it open and then getting distracted)
7. Add A Fate
8. Invoke The Fates and add a footnote/clarification/exception to it.
9. The World demands maintenance: do a chore.
10. The World demands a visitation: Take a walk. (this was the last initial card of 10, the next 5 have been added via Fate #7)
11. The Fates Demand Cleansing (clean/dust/maintain your workspace/desk)
12. Write about an idea, in private (This takes the form of, usually, a half-page in my logbook and takes surprisingly little time to actually come up with one, they’ve all been pretty good and useful)
13. Process Some Notes (see my old post about what I mean with this)
14. Make a box (This is, roughly, woodworking meditation for me. I make many boxes of varying size. It’s been great)
15. Invent a Location and write about it. (this is basically just a creative writing prompt, a small thing I like doing occasionally since I read Calvino’s Invisible Cities)

In essence, the origin of the problem is that “a file” does not really lend itself to a useful taxonomy for personal writing. You can make it so, by using it as a vague categorization system, but you will inevitably run into the ruin of all rigid categorizations, the edge cases that are two kinds of something. For an illustrative example, I have two files, cooking.org, which houses my cooking recipes, and baking.org, which houses my baking recipes. Smashed cucumber salad? Clearly cooking. Cake? Clearly baking. Soda bread? Savory, but baked, so clearly baking. Now, naan? It’s bread, and all of the other bread is with the baking, but it isn’t baked but instead griddled, does that make it cooking? It’s a question I’ve answered by just adding the recipes to both files to avoid the frustration of opening a file and then having to backtrack after searching, but that now means drift if it were to change.²

The solution would clearly be some sort of tagging system rather than a taxonomy. Naan gets both tags, both searches find it, grand. This would be solvable with org-mode, which supports tagging. But then I’m forced into re-doing all the files and the structure, and eh… Tagging systems outside of things like org-mode are just kind of… bad. They’re usually just kind of barely functioning, really old, or bring way more machinery to the table than I want to for purposes of organizing some text files.

As I was thinking about this, I remembered columnar databases, and how they made additional columns almost free, as well as entity component systems (ECS) that kinda do similar things. Then I was thinking about how this is personal, one-human scale infrastructure, and how that lets me do some things that would never fly in many-humans infrastructure.

The Idea Behind PersonalDB

The core idea is abstracting over “a text file”. There is an entity, or a row, with an ID. An entity can have any number of columns, which are key/value pairs, but the default value is null. This makes any entity, if we squint a bit, a sparse JSON object, when trimmed for null values.

Suppose now that we take all of our recipes of some variety, and turn them into entities that looks like this:

{
    "text": "Delicious, Buttery Naan\n // the text key contains the entirety of the original text file.",
    "cooking_recipe": true,
    "baking recipe": true
}

Given a big list of all entities, finding recipes is now very easy. Attaching metadata is now very easy. I could include a column of contains_gluten at no cost and filter against it when reviewing recipes for what to make if I have a guest with celiac disease.

So far, so “why not just include these in the file and use grep?”. To me, the ‘big trick’ of this is this: This same DB could house all my documents, all my text files, all ad-hoc structured entities I come up with for various reasons, with no loss of functionality, and the same underlying model, and the same tools. Blog posts in this blog could be entities in the same DB, with the recipe column values set to null and a blog_post column being set to true, and it would not impact anything at all, but now I no longer really have to deal with the file system taxonomy for something that to me is fundamentally the same type of thing, a piece of personal or internal writing³.

Because this is also a very simple data structure, it would also allow me to use it for ad-hoc storage of personal tooling, having access to the same abstractions and the same data. Magic: The Gathering deck lists could be a column tag, bibliography citations could be a column tag. It also enables notes on just about everything that is stored here, just by adding a column. Accessing this DB programmatically from a script or other application is trivial, and I probably will write a few libraries just for that.

Inconsistency (what if something is tagged as a M:TG decklist but also as a cooking recipe and it now has two ‘types’?) does not really matter, because there are no by default no not-me consumers of the DB. There’s just me, and I’ll see it unexpectedly, and fix it. This gets a bit more dicey with automated processing via scripts, but honestly, that doesn’t really matter all that much to me.

The Sketch Of A User Interface

The idea is that this is personal-scale software, so I can cut some corners I would never get away with in other places. I’ll use a CLI as illustration, although the exact same interface can be implemented in many ways, since it is quite simple at its core.

There are fundamentally four actions: list, get, write, and delete.

list is the search functionality. It accepts any number of predicates that run against the collection of entities, for example: list baking_recipe=true text=~naan. These predicates are fundamentally AND conjunctions, but OR is possible as well: list either(baking_recipe=true, cooking_recipe=true). The predicate DSL will have some leeway for being pleasant to use, like any or testing for non-null if no value is specified. list also returns the entity ID.

get takes an entity ID, and assembles the full entity JSON object from there. It returns a JSON object, with all non-null columns. Column order is disregarded entirely. There is also an option to pretty-print the keys, and to transform the raw JSON blob into readable text that doesn’t have escaped whitespacing and newlines.

write takes a entity ID and a JSON object, and replaces what the entity with the given entity ID with the object.⁴ If it contains a new column, a new column is created on write.

delete deletes (or alternatively, tombstones) an entity. Columns are checked for whether or not this was the last entity with such a column, and then deleted if so.

The Storage Engine Underneath

With this being a small columnar DB, the easy answer is to throw this to Parquet, and move on with life, and chances aren’t bad that I might just do that.

An alternative I’ve been thinking about that preserves the plain-text origins of this, is rooted in entity component systems, and that is to just turn each column into a separate file, with the entity ID as the key in a big object:

/T/t/personaldb tree .
├── baking_recipe.json
├── cooking_recipe.json
└── text.json

Where then each file contains a sparse ‘list’ of column values:

/T/t/personaldb jq < text.json
{
  "21": "Delicious Buttery Naan\n...",
  "121": "Smashed Cucumber Salad\n..."
}

This makes the management and search of this outside of specialized tooling possible, whereas Parquet would just be a pile of binary blobs that I can’t do anything with outside of the tooling.

A Note On Maintenance

File systems for notes get messy quick, nobody wants to do the house keeping when it’s about doing something, or makings something. Part of the reason why I like this idea so much is that it makes housekeeping very easy, because there are now no longer any folders that are just forgotten in some dusty corner. The same structure houses everything, and reading any note forces you to see all of its set columns. If a column seems old or antiquated, it can be very easily overhauled programmatically, or the column file outright deleted, and that is that.

I think I’ll spend some time in the next few days and weeks building something like this, it seems fun and rewarding for just me.

Well, I try to be a reasonable person, so as mandates strong encouragements from corporate rolled in, issued from on-high, my work life began to be changed by LLMs and related technology, whether I wanted that to happen or not. So, let’s talk about my personal, very specific point of view on LLMs and their effects on software, engineering, and corporate culture.

First, it would be helpful to outline where I am standing, from where I am casting this view. I work as a nebulously labeled “DevOps Engineer” in central Europe, at a medium-sized company I would describe in this case as “solidly an internet-based company, but boring”, a solid C in terms of ‘coolness’ and technological maturity. I say “nebulously labeled”, because in practice it means “tending to infrastructure”, whatever that may be, and it’s better defined as “everything that does not belong to some product team”. This generally involves AWS and AWS-based infrastructure, mostly EC2 machines and EKS clusters.

So, now, from this perspective, what’s the impact the coerced strongly encouraged¹ adoption of LLMs for software engineering as I have seen it?

Impacts On Myself For The Work I Do

Adopting some form of LLM tooling has made some things easier, particularly the writing of better-than-bash scripts for operations purposes and the writing of CRUD APIs to glue together various tools that do not naturally come glued together. This means that I can offload the reading of various API documentation sites that may or may not be accurate, and focus on what I want to accomplish, which I’ll call an improvement.

I do not use LLMs for purposes of writing human-oriented documents, because it takes longer to finagle the beige prose of LLMs into something good than it does to write it myself, and it is much less fun. This is coupled with a lot of people I respect growing increasingly allergic and disparaging (myself included in this) to LLM-generated prose.

I have also derived great benefits from the research mode on various LLMs that allow me to obtain answers to questions of knowledge that is available easily, but usually not indexed in the way I want to ask the question. What I mean by that is that I will ask a question ‘backwards’ from the way it’s usually categorized and presented in the literature, and previously I would have to manually invert my question to obtain these answers. These days, I do not. This is also an improvement.

On the downsides, the amount of text on the internet generated via LLMs these days makes it hard to find worthwhile sources of information, all while tacitly encouraging the use of LLMs to read that information. Needlessly verbose prose can be summed up by an LLM just fine, even if I prefer to simply not read it at all. Discerning which text is worth reading is now an important skill, and I can’t help but wish it was not so.

Impacts On My Team

Most prominent is the effect of code being submitted and merged that is only roughly understood. This usually the case without LLMs, but at least there, somebody wrote it, with some intentions and towards some restrictions to solve a problem. This is not the case with LLMs. It means that if I ask the submitter of the code “Why did you write it this way?”, I will not get an answer that may hint towards a specific opinion or understanding, I will get “this was the output and it seems alright”, at best. This is annoying, because this was the hook of some of the better discussions about implicit understandings in my coworkers I had. This non-understanding of nuance on the side of the LLM is also the cause of many subtle bugs I’ve seen, things that would not happen this way if written without an LLM. This is considerations like “there’s an ETL-based load spike at 3am so it there should be some sort of minimum duration for the alert so it doesn’t trigger every night at precisely 3am for 5 minutes”. This is something that LLMs can’t and don’t account for in any consistent manner. They do sometimes, when they look at the data, but this again then means that there is no real intention or understanding of the patterns in the change.

The “this was the output and it seemed alright” answer has also made the quality of submitted code drop, at least in my context. People do not want to fight the LLM to output code in a different style or that is more appropriate to local idioms and style, and so they accept what the machine spits out, so long as it works. In general, the thinner-spread the team in question is, the more it will drop relative quality, at least in my experience, as people prioritize getting things done over doing them well, because they need to not drown now.

This also has a profound impact on new entrants to the industry, the people who are currently doing the most learning of things they haven’t internalized yet. In my experience, junior engineers take to LLMs very frequently and very intensely, because most of the time, being able to get an explanation now rather than needing to wait for a coworker is immensely valuable for their independence and ability to actually resolve problems, rather than being a net drain on the throughput of the team. I don’t think this is inherently a bad thing, not at all. The issue comes with the self-discipline it takes to only get an explanation, and not a solution. It is simple to go from “what does this error mean?” to the imperative “fix the cause of this error”, and that shortcuts the learning process. Doubly so, if people start dropping the actual explanation step, and go to the resolution directly.

The other impact I want to talk about is impact mitigation and resolution. When things are down, people want to get things up and running again ASAP. More than once have I seen people plug an error or a general description into an LLM interface and give it more and more credentials until the LLM spit out something that may or may not be related to the incident, and may or may not be a relevant factor to the incident.²

Impacts On The Work Itself.

The “subtle bugs introduced by non-understanding of context” is an issue by itself, but the increased speed means that the brains that do have the context become saturated very quickly, unable to meaningfully pick apart the many changes in a way that would allow for the catching of these subtle bugs.

A lot of noise is made in writings about review being the new bottleneck, but I would argue that it always was. Reviews are, to me, not primarily a means of catching bugs, but of spreading context. People who aim to automate the review of changes with LLMs, to me, miss this point entirely. I read 80% of PRs posted by my team, not because I’m required to do so for review purposes, but because I want to understand what people are doing, how they are doing it, and what that leads to. Working on a corpus of code collaboratively means sharing understanding and context, and this is a dynamic disrupted by this.

The bigger problem is that writing code faster does not at all mean that you accomplish your desired outcome faster, but now you have to justify additional cost incurred. Or, somehow worse, you have to justify not adding additional cost, even if it’s the right thing to do if it would not at all help you accomplish additional objectives.

Social Impacts Of The Impacts On The Work Itself.

I have a hypothesis that LLMs have a much bigger benefit to you if you work solo or with one other person on a team. The less understanding and context you need to teach, the faster you can go with the LLM.

Because going fast is the thing that is rewarded most directly as an engineer, it discourages collaboration. Collaboration means going slower, means spreading context. That is not rewarded, see the age-old fight about Glue Work³. The introduction of LLMs has resulted in more PRs being submitted, but fewer than ever being collaborated on, just an engineer and his LLM setup. Unless I actively go out of my way to read PRs others submit, going against my own incentives, it is easy to lose track of what people are doing around me, and to understand it.

Many downsides of using LLMs for code generation can be mitigated by using planning documents, sketching out architectures, discussing structure and intentions. I had hoped that this would encourage people to do this, but it has not. Instead people have simply tried to move past these things, generating them with an LLM, rather than having any specific intention about it. To very little of my surprise, this has not worked very well.

This also has interesting implications specifically on engineering managers that came from the IC track, that long to build things again and not just wrangle people and documents. It’s been my experience that people in EM roles and EM-adjacent roles have the most fun with LLMs, building things and not caring about the code itself too much, so long as it does what they want. They are usually not embedded in a team as a contributor, and this is not their primary role. So they are building things, sometimes to address things they’ve seen be problems in their role as EMs, sometimes just for fun for themselves.

It becomes an issue when they proffer these projects off to the teams they manage, because of the structural power relationship. Rarely are these applications or tools suitable as more than a proof-of-concept, because they have not been built to any sort of standard that may be prevalent in the team, but instead as a fun project at first, that then slowly morphed into a concrete tool.

These things are unceremoniously bumped into production, because hey, it helps with the problems, right? Having this is better than not having it? The structural power relationship here does not help. Telling your boss that his fun side project should be thrown out as a successful proof of concept is the right thing to do, but it’s also the frictionful thing to do. Particularly when you’re already not on the greatest of terms with your manager, accepting this as a small concession is the smoothest path. But now you have a badly engineered project in production, that will invariably have the long tail of bugs any newly-in-production application has, coupled with the usually partially-unknown and subpar code that comes from joyful experimentation with LLM-based programming, and it quickly becomes a small albatross with a lot of touchy politics and optics concerns.⁴

Larger-scale Structural/Social Concerns With LLM-based Programming

My concerns with this boil down to, essentially, Kernighan’s Law:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

LLMs are much more frequently subtly wrong than they are overtly wrong. The LLM-based falsities usually prey on something close to Gell-Mann Amnesia⁵. If you are already proficient in the thing you are using the LLM for, spotting the subtle falsehoods will happen by means of expertise.

In my opinion, one of the most important skills to develop with LLMs is the ability to discern the useful parts of the output. The output being fully correct and useful happens so rarely that on an absolute evaluation, LLMs would be close to useless. The part that makes them useful is that you can pick out bits and pieces that are indeed very useful, and assemble your desired result from those.

This is harder when you are not able to spot the subtle falsehoods, or know little enough of the target domain that you have trouble picking apart the useful parts of the output. However, this is where people are drawn to LLMs the most - for things they do not feel like learning, where they want a throwaway script or placeholder. Here, the subtle offness matters less, because all you really care about is the output. This is fine and good, and would not pose a problem if things that are intended to be throw-away would not have a habit of not staying that way, fairly regularly, and then things start off built on sand, getting worse from there.

In this, LLMs encourage not only the writing of code by means of an LLM, but also the reading of it. Especially when you do not have the developed skills to read the output code correctly or completely, as is the case for junior engineers sometimes, mediating understanding with an LLM is tempting. This undercuts the learning process significantly, if no active learning process is taking place. This is a process that can be beneficial, in that it allows people to understand code and documents they would previously have bounced off of entirely. It can be made to work as a learning tool that is gradually discarded, but that is actively inviting friction and difficulty into the process, that people in new jobs in the current state of the tech industry will likely feel hesitant about.

The main reason I am not concerned about this on an existential level is that LLMs are quickly becoming a commodity that will be priced on a narrow margin over hardware costs. Open-weights models like DeepSeek V4 having enough usefulness while being able to be run by anyone with a bunch of GPUs and access to cheap electricity, so LLMs as a thing in programming will not magically vanish.

A Note To Things Not Mentioned So Far

An issue I’ve sidestepped here is all of the ethical quandries LLMs have inherently. They’re built on, essentially, colonialising the internet commons at large, and that is hard to ignore, even if I am on some level required to. Thanks to ubiquitous LLM access and promotion, things that used to be abstractly trustworthy (someone put in sufficient effort to write something) has now broken down entirely, and the open internet that is accessible via search engines is now essentially a landfill you have to look carefully at to extract valuable information from.

Worse, it’s a breakdown in the contract of the internet commons that is visible to the people involved with the technology, but not the public at large, although it is becoming more widely understood. I’m about as worried about the larger social impacts of this as I am powerless to do much about it. “You can now trust random writings on the internet even less than you did before” is not an actionable statement. In this particular way, the dystopia is already here, unevenly distributed.

The name is a riff on Dandân, the name of the eponymous card in the (relatively) famous deck/mini-game originally called The Forgetful Fish. You can find an overview of Dandân here. Long story short, it’s a single deck that is used by both people, along with a shared graveyard.

Initially I built this as a one-off idea, and it gradually has morphed into one of my favorite ways to play Magic with a friend. A big difference from Dandân is that there is no one singular DredgeDredge deck, and it’s instead something you can build different versions of. The other use of it is as a little game you can bring to a draft or similar and play it in the downtime between rounds.

The Rules Of DredgeDredge

DredgeDredge is mostly regular boring Magic, with a small list of conceits that make it different:

• A 100 card deck shared between both players, in singleton format (as in, there are no duplicates of any cards except for basic lands)
• A shared graveyard.
• An emblem on the table that says “Discard a card: Target card in graveyard gains ‘Dredge X, where X is the mana value of the card’ until end of turn.” This is the main conceit of the format.
• I’ve been experimenting with a rule that says to have an additional draw phase. This means that if it’s the first turn of the game, you draw one card, otherwise you draw two. This makes the game a lot smoother, and makes games longer. Drawing one card leads to shorter, swingier games. I’ve also found that some decklists really rely on either mode, and have a hard time switching between them. You should experiment with this, if you build a list.

Okay sure, but for the people that aren’t familiar with the precise rules of Magic, what does that mean? Dredge is an old mechanic that works like this: Whenever you would draw a card, you can instead choose to take a card with Dredge X from the graveyard to your hand, and then take X cards from the top of your library and move them to the graveyard. The implication here is that you can get something out of the graveyard, but in the process of doing so, you might put something worse than what you got from it into the graveyard via milling.

It also means that card advantage is much, much bigger than it would otherwise be, and also that instant-speed card draw can be used to steal your opponent’s dredging target, after they already have discarded a card. You can similarly exchange a card in your hand for a land in the graveyard during your draw step, allowing you to work around land starvation. (since lands have a mana value of 0, you technically dredge them from the graveyard rather than drawing a card, then milling 0 cards)

It plays a lot like Limited, in a way. An interesting change to regular gameplay is that you and your opponent have similar gameplans and strategies, so you can judge how bad a card would be to give to your opponent relatively easily. The rest depends on your specific deck.

How to build a DredgeDredge list.

The format I recommend is 60 singleton cards and 40 lands. Here’s some guidelines for how to pick cards:

• I generally prefer a lower power level in DredgeDredge, which makes your own bulk collection the perfect and likely only place to search. Lower power level also makes for games with more comeback potential, because you aren’t immediately killed when your opponent hits some cards with synergy.
• I prefer to make lifegain hard to come by, because it means that gradual life loss will prove fatal, and HP is a precious resource. The game has to end at some point, too, and making life easy to come by risks stalling the game.
• Be careful with instant-speed card draw. Having some of it is good and fun, having a lot of it means nobody will engage with the mechanic that’s the ostensible center point, as everything they discard a card to dredge will get yoinked from under them.
• Bounce effects, while generally fun, are worded in a way that means you can bounce an opponents creature to your hand, making them card draw and powerful removal at the same time. I’ve found them to be gamewarping in the bad way, in that the bounce card will be played, then immediately dredged by the opposing player, then dredged again, until someone manages to exile it.
• You should have 3-6 cards that exile things from the graveyard. A very fun group of sets that has that as a mechanic while also being appropriate in power level is the Theros block, with it’s Escape keyword mechanic. Tizerus Charger is a mainstay in the original DredgeDredge list. This ensures things don’t become stale repetitions of the same gameplay moves.
• I’ve found that going heavy on the creatures makes for a very fun play experience, as games (especially in draw-two) become long value-oriented slugfests. Sorceries and Instants on the other hand make the game faster and more volatile, which is also fun but I’ve found harder to make feel balanced.

Part of the fun of the format is, at least to me, the building and tinkering of the list in response to how it feels to play. With it making use of mostly bulk cards, nearly any card you come into possession of can potentially find a home in a DredgeDredge list, and it feels really fun to see cards you would otherwise see not even in Draft or Sealed shine because the usual rules of “what is a good card” don’t fully apply.

My Two DredgeDredge Lists, and A Small Request.

I’ve built two lists for DredgeDredge, one that is relatively interaction heavy and about 50% blue, with relatively-large splashes of White, Black and Green, and one that is in Green, Red and Blue focused on being a no-holds-barred melee beatdown focused on the EOE Lander mechanic as the tension to pure aggression.

Here’s a link to the OG list and here’s a link to the Temur list.

I hope you find this format as fun as I do, if you do build a list for it. My one small request is that if you do build one, tell me what you think! Good, bad, whatever, but I do want to know how other people like it, and what they find to be good/bad rules of thumb, as well as the lists others build. Thanks :D

There is, intentionally, no ceremony or process around this. If I had to gave some “rules” around this, it would be something like this:

1. There’s no pressure to either come, or stay for a certain amount of time. If someone wants to show up, say hi, get a hug and a plate of food to eat in silence and then leave, that is explicitly fine.¹
2. The food is going to be made anyway, if someone flakes last minute because something comes up, they feel terrible, or they just don’t want to be seen by the outside world, they just… don’t show up. More leftovers for me means I have to cook less the rest of the week.
3. Similarly, there is no RSVP/notice required to show up. If someone has their plans fall through last minute, they are welcome to stop by.
4. Nobody has to bring anything except their sparkling company, this is not a potluck. You show up and food will be provided.

All of this mainly relies on my friends and family being close enough to have “showing up” be not a big deal to be planned around, but that is luckily the case for me. As with so many things, all of the explicitly low expectations usually lead to the opposite, people come and hang out during the afternoon, it goes into calendars for people to remember, people bring dessert or sides.

I’ve been having a great time doing this every other Sunday, and by the sounds of it, my attendees have been enjoying it as well. Maybe this is also something for you to do, if having people around Sunday afternoon sounds nice.

The Engineering Mindset Or Thought Disease

The core element of engineering can be summed up as ‘constrained problem-solving’. You have the problem to be solved, but that solution is placed under multiple constraints in many different ways. Usually at least cost, often also space and time. It’s not entirely about merely solving the problem in an effective way, but doing so in a way that breaks none of the (usually at least partially arbitrary) constraints you were given. A bridge that may not cost more than this much, take this long to build, must consist of these materials and be done by this date, and should also be the best bridge possible under those constraints.

The ‘disease’ bit comes from the detail that ‘constrained problem-solving’ describes an awful lot of every-day life. You do constrained problem-solving at basically any point in the day, in some form, buying groceries, planning to hang out with your friends, buying cinema tickets.

This view propagates from projects are very clearly ‘engineering’ (drafting plans for bridges and building software) to everywhere else in life. The finding of constraints and goals as main point of view becomes natural, a grocery run is analysed in terms of what you must buy and what you absolutely need, and then optimised for being cheap and being quick to do. Shelves are analysed for storage space and cost, ease of sourcing and relative consistency, ease of assembly and so on, purely functional characteristics are often put front and center.

What is often optimised out is the personal expression, the desire to do things differently just because it is pleasing to do so, either because you enjoy the process or the aesthetics or the end result being a certain way. In another word, what is often optimised and engineered out is art. When it is explicitly included as goal, it is often first to go, as it is the most subjective and the most variable in terms of costs. This is fine in a professional context, the average bridge does not need to win design awards and the average grocery-trip need not be a dance choreography. Again, the issue comes from scale: When everything you do is seen at least a bit as an engineering project, and is approached like an engineering project, then art is optimised out in everything you do, at least a little bit.

This is… dull. Or, at least, dulling. Art and self-expression are not things that people should disqualify themselves from, that tends to come at great cost in a way I can’t exactly qualify and point out.¹ All work and no play makes Jack a dull boy, and all that.

Music As Antidote To The Engineering Mindset

Music in its common form and impression has the same problem anything that mainly is done by specialised professionals has: it looks entirely unapproachable. You know how popular music sounds, but you probably do not have a single clue as to how to approach making anything like it. This, again, is a prompt for the engineering mindset, there’s a goal and some constraints. Not least because of this I decided to give it a try, and here’s where the surprising bit happens.

There is no success criteria for making music. Or, well, there is one, but it is that you, the person making it, like what you’re hearing.

Sure, you can tie it to external forms of success, but that comes down the line. With most crafts, you can check your work. Your woodworking join either fits, or it does not. Your cake either rises and looks like the recipe picture, or it does not. Your seam holds, or it does not.

With music, and other forms of artistic expression? All you have is whether you like it or not, as a check on whether to proceed down this lane.

Similarly, it is different from other forms of artistic pursuit that also have a similar lack of constraints, in that it is relatively difficult to directly ‘fail’ - in painting or drawing, it is fairly obvious if your artwork looks like the object you intended, or not. Music does not quite work that way. There can and will be a discrepancy between what you tried to make and what you made, but it’s less obvious and less destructive to the overall effect than in other artistic media. More often than not your failure to do what you intended will result in happy accidents that are still good, just not what you intended them to be.

The same lack of immediate, overt failure also makes it more amenable to external support. An concrete, ‘classical’ instrument has a hard requirement for skill to make something musical, but creating music is uniquely amenable to having technology help. If you have instrument-skill troubles, a DAW with MIDI sequencing still allows you to create music.² If you, for example, ‘merely’ have trouble with keeping rhythm, quantisation will help you and move things played too fast or too slow to the right place. Piano rolls and modern DAWs help you iterate and move things to the right place without being immediately roadblocked by your own skill, or encountering the “must be this good to have fun” wall.

It is also uniquely accessible for an artform: nearly everything is accomplishable inside of a modern, average laptop. While actual hardware synthesizers tend to be prohibitively expensive and space-consuming, on a purely results level, a laptop can fill in for nearly everything else. The ubiquity of piracy in the music software space also removes the other entry barriers: dedicated instruments and gear.³

In this vein, I would anyone that feels some kind of way about what I’d call engineer’s disease to give making music a shot as a sort of self-therapy hobby. It has a low barrier to entry, a limitless ceiling, and as long as you have fun with any part of the process, a wonderful creative outlet.

Postscript: Some Notes About Getting Started

Especially in the beginning, forget about songs and albums, and think much smaller: 20-30 second loops and chunks. They can be put together much quickly, allow you to explore and iterate faster.

And that, to me, is kind of the crux of it: If you don’t like what you’re hearing, do something different. Pick a track you like a lot, and try to draw some inspiration from it without copying it.

Some actual, concrete starting points: You’ll want a Digital Audio Workstation, or DAW. Nearly all the big ones have trials long enough to figure out if this is something you’ll want to put non-zero money into and buy a DAW, or non-zero effort to figure out how to pirate it.

The most common ones I’ve seen used as of late are Ableton Live, FL Studio and Bitwig Studio. Particularly if you have never done anything in this area before, I’d say that Ableton and Bitwig are more streamlined and have a more ‘obvious’ workflow. FL Studio is frequently described as a “toolbox” and you can make your own workflow with what it has, but it will not point you to adopt a happy path, as the other two do.

A lot of online content in this space is in video form, in part because it is genuinely well-suited to this domain. My favorite channel here is Benn Jordan, who’s also a treasure trove of inspiration.

Niklas Luhmann was a German sociologist, best known for two² things: Being very influential to sociology at large (notably not as much in the English-speaking world, but Europe and Russia, his ideas came to the anglosphere later and more slowly.) and, to be polite, making full use of the German language.³

To me, some of his most interesting work and what I want to talk about here is his model and conceptualisation of influence, selection, complexity and how organisations fit into that. All models are wrong, including this one, but this one is useful in providing insight into how complexity is managed across organisations, how coping with complexity happens, and how decisions are transferred and transformed.

Let’s start bottom-up, and go from simpler and more elementary definitions and relationships to more complex and emergent ones.

What’s A System?

Luhmann defines a system in a characteristically terse way, namely that “a system is defined by its boundary between itself and the environment”. This is as broad of a definition as a useful one, a system in this notion is formed any time someone tries to make a distinction between inside and outside. Inside the system, the level of complexity is reduced compared to the outside, mostly by means of agreements and influence (more on this below) as to what to do, and what the priorities are. This can be as loose as “shared terminology”, i.e. when a group of experts agree to name a common object⁴, and as specific as an employment contract.

Systems are often loose and overlapping, and like in more classically-known systems theory (referring here to the MIT branch of Donella Meadows and Jay Forrester), the main use of defining them is to define the unit of analysis.

Inside the system, the complexity of the world is reduced by there being agreed-upon, shared definitions, goals and values, compared to outside of the system, where they are not.

What’s Complexity?

Complexity, in Luhmann’s model, is the amount of aspects or concerns that have to be considered for potential actions any one actor could take at any one point. This generally is considered infinite outside of the system, and the whole point of the system boundary is to define a space where it is manageable, by reducing the amount of actions possible to a point where it is possible to act.

This is generally done by agreements on goals, values, functions, delegation, and so on: If we agree that I’m cooking dinner tonight, the number of potential actions for what I’m doing this evening are now much smaller, and most of them should include cooking dinner.

It’s important here that complexity inside a system is variable and influenceable, you can choose how complex the inside of your system is. You can make it very simple and the next action is always very clear, the trade-off is that it can’t represent the environment/rest of the world very well, you have disregarded many dimensions and aspects of the environment to get to your simple system.⁵

The reward for taking on more complexity is being closer aligned with the environment and therefore being able to react to changes in the environment (i.e. having less adaptation problems), the reward for taking on less complexity is being able to decide on a reasoned course of action.⁶

To use an example: If I’m cooking dinner, I can choose to care or not care about dietary preferences my guests have. Doing so increases complexity (Now if vegetarians are present, I may need to cook a second main course), but reflects the world better: some guests might still be vegetarian, no matter if I choose to care about it, or not. Choosing to not care might lead me to being surprised by the outcome of my actions, but it makes choosing that action easier.

Why Do People Want To Reduce Complexity?

Because, in brief, they are bad at dealing with it. If you give someone a large number of potential options and ask them to pick the best one for them to do by a reasoned process (i.e. not just picking one at random, based on aesthetics, and so on), the amount of complexity they can successfully do that with is quite low.

People can adapt to deal with this complexity, but the trade-off is time and cognitive load. Adding complexity means that the process of deciding what to do is slower, as people’s intuition-based capability for making off-the-cuff decisions is exceeded, and they have to use slower, more deliberate processes to decide on just exactly what to do, much less actually doing it.

To illustrate further, consider asking someone that’s a reasonably good cook to cook dinner. They will most likely use a certain amount of assumptions (you two are the two people eating, it will be one course, dietary preferences and allergies are known, what they have in the fridge) to arrive at an answer for what they are going to do to fulfil what they agreed to do, likely a spontaneous outcome of mentally going through options and satisficing until a result was found.

Now, insist the meal be three courses. The answer will take longer to arrive at, and will now include acquiring additional information and external planning. Additionally add that you invited 2-5 friends, but all of them are flaky and may or may not come. Unless you have an extremely patient friend, it is at this point that you will likely face a demand for additional constraints to make the process of arriving at a workable and possible course of actions feasible.

What’s Selection Force/Selectivity? (“Selektionskraft”)

Luhmann dubs the compound force that reduces the infinite amount of choice in the environment to an actionable amount the “selection force” (or Selektionskraft), as in: It’s the strength of the process of selection (of the possible actions you could take) that can vary, and so the amount of complexity you can deal with inside the system also varies.

A constraint on your actions increases the selection force, because a whole dimension of complexity now has a fixed value. The space of possible solutions just got smaller.

This is separated out from the notion of “complexity”, because the complexity in the environment does not vanish when the systems becomes more sophisticated, it just shifts. As a system becomes more complex to address more complex problems, its problems also shift: From being overwhelmed by the environment and not being able to cope with the demands placed upon it from the outside, to straining under its own complexity and size.

Complexity can’t be reduced globally, but you can choose where it goes. Complex problems demand complex systems to address them, complex systems demand high levels of coordination and resources. A complex system made to solve a complex problem directs its selection force to solving the problem, and puts the complexity outside of that path. Aviation achieves safety in highly complex domains by shifting complexity to verification, maintenance, construction and training, allowing for the complex problem of operations to be solved well and extensively.

This is the point where Luhmann’s model goes from an interesting framing of complexity and systems to a model capable of generating new insights: Much of all human behaviour manipulates selection force in some form or shape, but most of the time, interpersonal social dynamics are the chief way that is done.

Luhmann generalises this to the very specific and not-at-all overloaded term Influence. Remember that in this model, all complexity and all selection force is viewed from the point of a single actor. You can aggregate this to the system level, but practically, the thresholds for what is actionable and what is unactionable amounts of complexity happen on the actor level.

What’s Influence?

Influence is therefore also seen on the actor level, as communication between two people. One person can make sensible decisions over more dimensions of input if another person processes some of them, makes partial or complete selections, and then passes that on. The first person can then choose to either accept or discard the selection performed by someone else. If they accept the decisions made, Luhmann terms that to be accepting the influence of someone else.

This happens in a great many situations and circumstances. Most straight-forward, your boss tells you to research something, you come back with constraints. This is first your boss influencing you (by constraining your next action), then you influencing your boss (by choosing what constraints to report on, how to present them, etc).

Specifically, this happens all the time and is impossible to avoid. The explanation and definition chosen by Luhmann is deliberately a very nuts-and-bolts framing, applicable to basically all situations that involves at least one person that has encountered another person at some point in their life.

The generalisation of influence is the ability to have an expectation of someone influencing you, that you can expect someone to perform selection for you. With this expectation, single actors in complex systems become able to collectively solve complex problems. When you go to work, you expect, in some sense, that your boss is going to point you in a certain direction for what you will do. How this fits into the larger picture is your boss’ job to worry about, you rely on his influence on you to do your job to the expectations that have been communicated to you.

Why Is This Model Useful?

By framing it around dimensions of input to a system and interpersonal influence, actions are seen inside the system around the influence they create, i.e., for whom they perform selection. The amorphous social phenomenon known as power⁷ is also a generalisation of influence, people with more power in a system have others in the system accept their decisions and selections more often. Computers can be said to have influence on actors by framing events, omitting or including information, causing the actor to choose one action over another.

This definition of complexity also provides a quite simple answer to the “I could build that in a weekend!”⁸ phenomenon programmers are prone to experiencing, namely: Those companies often choose to accept substantially more dimensions of input than those saying that can see, in choosing to accept that complexity into the system, it now has to be accounted for and actions have to be differentiated.

In general, it allows us to rephrase the question of “Why would they do that?” to “Who are they accepting, or not accepting, decisions from, and for what reason?” that accepts and builds on top of the local rationality principle⁹, while also centreing the social dynamics.

Looking for where and how selection of possibilities is performed, where possibilities are eliminated, and where and how that is propagated to other people shines light on the underlying social processes in complex systems.

When a measure becomes a target, it ceases to be a good measure.

And this is a useful, pithy, and very relevant-to-the-current-times statement.

However, the original quote that eventually became Goodhart’s Law, is a good bit more interesting, in my opinion:

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.¹

This can reduce to the same form as above, but is more broad, and with this, also more applicable. A statistical regularity does not necessarily have to be a measure in the common sense.². Someone acting on a subjectively-felt frequency of an event, in order to control that event is going to fall under this as much as an someone being explicitly measured quarter targets and then finding ways to count various unrelated things against that target.

Similarly, it also does not say that the intended observation of it is subverted, but instead that the regularity goes away, and now what used to be a continuity that could be relied upon is now what is irregular. This is also a a broader thing, as what once was a continuous, expectable progression (the regularity) is now no longer smooth and instead has jumps and slopes. Some controls can work absolutely fine with that, though the originally intended behaviour will change.

Third: Talking about “pressure” means also that there are various control measures that impose more or less pressure, and that there is a spectrum here: Controls can be light-weight and not cause the regularity to collapse nearly as fast as making it the core measure of someone’s worth as, say, an employee. By changing the exact purpose for which the regularity is used also makes it collapse more slowly, i.e., by not exclusively and immediately using it in a transparent manner for behaviour change, it can be preserved.

This is also where diagnostic metrics vs accountability metrics³ come in, not all control has to inspire a change of behaviour that makes the regularity collapse.

There’s a great deal more nuance and also opportunity in the original quote from Goodhart that is lost when condensed. That’s usually fine, but I think that nuance can be very useful when trying to navigate well, nuanced situations.

You can see already how this can (and did) go severely wrong. What was supposed to be objective good, proven by science and brought forth by the state, was in fact neither objective, nor good. To give a concrete example, agrarian reforms failed, and millions starved, because the plans for them were cooked up in a Chicago hotel bedroom², and failed to account for much of the reality on the ground. Plans and ideas, schematics and processes that had been vetted thoroughly in… an environment entirely different from where it was supposed to be applied. With violated assumptions, a plan that barely worked to begin with stopped working entirely. Many, many people starved in the process of collectivisation.

But whenever this inconvenient truth was pointed out to those that had put together the plan of collectivisation, the fault was instead pushed to those working on the collectivised farms. The plan was correct, but the execution was the downfall. If only they did things right, followed the genius plan, then nobody would starve and everyone would get to share the fruits of an ideal, science-driven and empirically tested society. But until they would see that, they would have to be forced to do what they needed to do. And so, even the seed grain was confiscated, as those on the farms were ‘hiding’ the outputs they were supposed to send back (because, you see, the plan worked all along).

And this is, in my opinion, the greatest fault of authoritarian high modernism. It is so damned certain of what is the right thing to do, even when that is in flat contradiction to what is happening, and what they can see happening. They have arrived at The Truth™, and now that they have found what is true, only what is untrue and irrelevant remains.

Anyways, I think I may have been subjecting myself to an analogue of this, just instead of millions of people being affected, it’s myself, doing much the same to also myself.

When you mostly work with your head, trying to piece together how certain things behave and change over time, optimising processes and their applications, it’s not a big leap to also apply a similar process to yourself, as another process and application to optimise. You figure out that there are some ways of doing things that are better than others, you remove the less effective ones, and have gained a bunch of resources and time. You make a plan for how to prepare for a party, and you execute that. The making of the plan took a bunch of work off your shoulders in remembering and accounting for various problems.

This leads to two things, one is more energy and free time (because you’re doing less work, because you are using more effective processes) and the other is an increased belief in the process as being good and leading to good outcomes. After all, the empirical method is on your side here. You tried something, the results were good, you tried more of it, the results continued to be good.

The continued build-up of belief that various processes of planning and execution leads in part, to tool fetishisation, where people are much less focused on what they originally intended to do with these tools (accomplish concrete goals), and instead focus more on the tools themselves. In the past this has been affectionately labelled “productivity pr0n”³, today that more takes forms of people spending endless amounts of time customising their Personal Knowledge Bases™ and writing about the practices of note-taking over actually doing much with them.

The free time and energy that is saved by use of more effective processes is, of course, in part used to accomplish more of the things we want to accomplish. This leads, ideally and partially, to an increased enjoyment of life. Probably more social recognition, maybe more monetary means. This, again, reinforces the notion that this meta-process of treating oneself as a process to be optimised is a good idea, it has brought you all of this extra time and energy you can now use to do more projects and realise more ideas!

Until something, for some reason, causes a drop in your energy levels. Maybe you got sick, maybe the seasons changed and your sleep is worse, maybe a relationship isn’t going super well and it sits in your head, maybe you suffer from depression. The execution of plans becomes harder, but remains doable. The application of new tools and processes has stopped providing big leaps and improvements, as their adaptation costs energy and the differences are no longer as big as “no tools” to “a decent tool”. Life becomes more strenuous. While improved processes minus less energy averages out to approximately the before-tools state, there are now more projects. You fight through, and end up coping alright.

If there is now the misfortune of energy or time levels dropping further, things start getting a bit dicey. With a sudden loss of free time, that’s something where you can adjust for it, mentally: You see that there is now a bunch of time taken up on your calendar, and obviously you can’t do things then, so proportionally reduced output is to be expected.⁴ Energy drops are more tricky, in that they have less objective traces. You just kinda feel worse.

When that change is large enough, there is now a problem. We have, on the one hand, the process we know is good. We have tried and succeeded in plenty of projects using the process. On the other hand, we have declining results. Depending on how hard you believe in the importance of tools and process⁵, and good you are at self-reflection and introspection, you can either come to the conclusion that, #1, there is something you missed, because what used to add up isn’t anymore, or #2, that if you just executed the plan better, the problems would go away.

In my anecdotal experience, people that have arrived at “tools and processes are important and considerable time should be invested into them”, and also “applying those to myself is a good thing”, rarely end up at option #1. Instead, a common thread tends to be that we are somehow lying to ourselves about what we can and can’t do, about what we should be able to do. Plans thrown together quickly are assumed to be good, because the plans were always good.⁶ Instead we are the problem, our execution is the problem. We are certain of what’s correct and true, so whatever’s left must contain the problem. Unfortunately, what’s left and contains the problem is ourselves.

In the quest for making the tools work through execution, we optimise further, and frequently, we optimise the joy and fun out of execution. Much like a city isn’t a tree⁷, a human isn’t a computer that doesn’t mind having unnecessary tasks removed. In our quest for output, we often force ourselves to act like computers, and end up miserable, and still feeling guilty and ashamed that we aren’t doing ‘enough’.

That is, in a nutshell, what I think I’ve been doing to myself, in at least parts. I used to be far worse about it, but still, even the reduced form of it has left its marks, and I’m tired. Yet, my lists for today show me that I still need to make dinner, because I need to eat, and prepare the flat for tomorrow, where I will go back to work and optimise processes and applications.