Blog/2026-04-26/Outsourced Intuition

When you learn from others you get both their wisdom and their misconceptions. Software engineering is my primary skill, so I'll describe it with negative examples of misconceptions that stuck with me.

In or Out

When I was young, in the early 2000s, we had a computer lab at school and one of the languages we learned was C++ but in a formulaic sense. We learned in the Visual C++ 6 or Turbo C++ IDEs which would accept programs written in a style that is not recognizable as modern C++. Here's an example:

#include <iostream.h>

void main() {
  cout << "Hello, world!" << endl;
}

Anyone who writes C++ will recognize the oddity of no namespacing and the return value of main. Regardless, that was what it was as I recall. Anyway, one day we were to learn File I/O and the teacher explained to us that while file I/O was confusing we just had to flip the directions we expected and it would make sense. The intuition he was trying to explain was that a file input stream paradoxically was used to get things out of the computer and a file output stream was used to get things into the computer. At the time, this didn't make sense to me at all, and the "flip the natural thing" mnemonic always failed me and confused me. This was obviously because it is not actually that intuitive or useful a model to imagine ofstream and ifstream from the perspective of the disk as it is to imagine them from the perspective of the computer. Once I abandoned that misconception, things were obviously much easier to do.

Git Reverts Don't Work

When I went to NC State University, I was introduced to their Github Enterprise installation and git. When I went to LiveRamp, I was introduced to using it in a multi-developer environment. I loved the tool. It was super cool. You could have your code merged with others and it wouldn't just overwrite changes. Mind-blowing to the 25 year old me at the time since I discovered this style of revision control late. I only knew Version History in Microsoft Office products.

Anyway, this new tool was very interesting to me, and I went around to find out about the data model. Either the git book wasn't easily available at the time or wasn't written, but I ended up on some old-timer's website where he explained the data model of git as (in my memory) commits having trees and parents, with trees having blobs, and everything being content-addressable. Fine, good enough. Then I played this online game that visually moved the pointers around and displayed merges and so on.

Then, when I went online on social networks, I found that almost everyone found git confusing. It can be because of the sophistication of options and commands, but the most inexplicable thing was that the confusion was quite straightforward: it regarded commits and their reverts. The sequence described was:

1. You commit C to a branch, A
2. You branch B off A
3. You revert C on B
4. You merge B into main
5. You merge A into main
6. You are astonished at the fact that the changes in C are missing

Anyway, this was often described online at the time as a footgun. By now, everyone is familiar with the data model, and this doesn't appear strange but natural. The second merge does nothing of significance, and both your commit and the revert are in main and you need to revert the reversion to get it back. But the fact that everyone said it was a footgun made me nervous about reverts till I realized the online people had some other confused model. Reverts are intuitive. Merges are intuitive. Both make sense as they are. Well to some degree.

Kubernetes Makes No Sense

A third time this happened is that people would often describe Kubernetes as an arm with too many hinges. I understand what they mean and that Kubernetes is often not the right tool for the job. Heck, this blog is not on Kubernetes but on a systemd quadlet and connects to a DB in a different quadlet so I'm not a stranger to that idea. But it's ultimately a fairly intuitive set of primitives that compose well to do fairly complex things. A friend introduced to it used a deployment of a single pod to act as a Wireguard exit node for a site-to-site VPN and I probably wouldn't do something like that, but for running k copies of a workload, I think it's quite elegant and easily managed with k3s.

When I first encountered its use, it was from experienced practitioners who are generally quite intelligent people. But they had difficulty describing its concepts, frequently dipping into implementation details as opposed to design, and consequently overcomplicating the notion of something as simple as:

• Containers are pretty much docker containers
• Pods are one or more containers grouped to form some application functionality
• ReplicaSets ensure one or more identical Pods are running
• Deployments manage replicasets to manage updates and so on

But a frequently expressed view from the experts was that we should understand that Pods Are Not Machines - they aren't VMs and don't have memory and CPUs. This is true but also useless information because the universe of not machines is very large, and the statement implies that pods must be like machines in some way so as to require distinction from them. They are in a very loose sense, and that distinction doesn't really add anything to understanding them (a container is also not a machine, and neither is a replicaset or a deployment). As I learned the fundamental concepts of Kubernetes, the above pod and so on, and the notions of services and ingresses and the like, I kept coming back to the idea of why someone would think a pod is a hardware device. Was the significance of the memory and CPU requirements you specify that it made them machine-like in some way?

The truth is that they'd simply been speaking to people who were talking in terms of virtual machines and so decided that this was a useful thing to transmit. But it made no sense to someone who wasn't thinking a pod was a virtual machine.

Making Tens

Primacy of device over concept

On the Internet, a long time ago, I found a photograph that purports to be a student's homework. They're being graded on how they can "make ten". The argument on the Internet seems to be on whether $8+5$ can yield $10$ countered by whether "making tens" is a valid pedagogical technique to teach addition. In my childhood, the place value and decimal systems were described as what they were and while we might use tricks like going to ten and then adding up the leftover and so on. Once the fundamental base concept of these systems are taught, people naturally come up with these ideas of rapid calculation and so on. To say nothing of the fact that a sum like $27+36$ being decomposed as $27+3+33$ and so on is harder than what a childhood me would have been taught which is to decompose to $20+30+13$ (with 13 being memorized to be 7 + 6). The former even requires subtraction to get to the $10$.

The whole structure of this technique seems overly to be based on whatever trick the educator used to perform arithmetic rather than some fundamental property of base-10 arithmetic. If this were the only efficient way to do something (the way integration-by-parts is) then this would make sense but to test on mastery of a specific technique which is not particularly better than another is wholly a bias of educators towards their own mental tricks.

Conclusion

All told, this is just a problem with communication, but I've found that the best way to actually learn things is from the source and from the use of the thing by myself or observing the use by others. When people describe how they solve problems, their advice usually carries quirks and misconceptions and misconception-avoidance quirks that are formed from their mental model of the problem and the world. When I took along these misconception-avoidance quirks I found that they were not useful because often my mental model was not theirs. To many, perhaps this blog post itself will seem like one such thing.

Doubtless I have done this to other people as many times as I've been on the receiving end, but the very structure of it means I'd be blind to it. Julie has definitely complained about it before, so I know I am not free of this curse. These days I try to avoid it by saying "One trick I use". This naturally immunizes me to any complaints.