The word “quality” is not mentioned in the Universal Declaration of Human Rights, but it is not hard to see why increasing quality makes life generally better. 

As consumers, we want our food to be fresh, nutritious and tasty. The cars we drive should be reliable, safe and comfortable. We want the new coffee machine to last long, be easy to use and grind quietly.

As workers, we take pride in producing quality results. When the things we create do what they are supposed to do and our bosses and clients are happy, we gain satisfaction.

There are also downsides to quality, though. Quality products take more time and effort to produce, have a higher risk of economic failure (which can motivate producers to cheat or take shortcuts). A high quality goal may not be achievable or realistic, which can be frustrating.

Still, although quality has a cost, neglecting to consider quality requirements will, in most cases, have negative long-term consequences.

I already mentioned some quality attributes. Fresh, reliable, safe, quiet and so on. The list is endless. The Wikipedia article about software quality attributes1 mentions only "notable attributes" and still arrives at over 50 entries.

Picking desirable attributes is easy. The more the better one may think. The problem is that every attribute has an opposing counter-part. Optimizing one attribute always means clashing with another one. If we equally value two opposing attributes, we are in a predicament. Which leads to the unfortunate fact of life that there is no escape from having to make trade-offs.

Why are there always trade-offs?

Have you wondered why that is, actually? Why is there not one quality aspect that we can optimize without any downsides?

There are two reasons:

1. Resources are limited

2. Inherent logical constraints

Resources are limited

The most fundamental resources are time and money. If you want to develop lots of features: it will take more time (and/or more money). If you want something developed faster: it will cost more (and/or take longer). Scope, time and cost create a *triangle* that bounds every project we undertake. In this triangle, we can optimize two but never all three attributes:

• More features & faster => that costs more

• Cheaper & faster => we have to drop features

• Cheaper & more features => that requires more time

We can not escape this limitation.

What if we lived in a parallel universe?

Let's imagine a world where automation can produce anything instantly. Then we can keep making things cheaper while continue to add more features (this is what, to a certain degree, progress of the modern world is all about).

If we can in addition imagine that in this world resources are also unlimited and free to produce: then yes, we can simply add more and more features without requiring more time or more money.

Yet, even in this imaginary fantastic world, we would still not be free of having to make trade-offs.

Logical constraints

Just because we can produce anything immediately and at no cost, we are still bound by this other, nasty unescapable condition called complexity.

Let's say you want simplicity and flexibility at the same time. You want your coffee machine to be as easy to use as possible. So you give it exactly one button. Put your mug, press the button. That's it. However, if you also want to be able to configure your coffee to your many tastes (foam-strength, roast intensity, amount of water), that's not going to work with just one button. You will need many buttons (or other types of widgets).

What about if in the future we have computer brain interfaces, where I can just think of a "cappuccino, extra hot, half milk, strong roast"? I wouldn't need any dial at all and yet can configure whatever coffee I can imagine. Have we escaped the trade-off?

No. All we have done is move the problem from the interface of the coffee machine to the interface of your computer-brain-chip. Instead of your fingers, you will use your brain waves to interact with the machine. Now you want a chip that works for all "brain types". How many nerves contacts does the chip require? Simple to implant versus high "brain compatibility" (you may be surprised, but I am actually not a brain surgeon, so I am entirely making things up here).

The thing is: complexity can only be shifted, it can't be reduced2.

Similarly to the limitation of resources, there is a boundary of complexity that we can't escape.

We also have complexity constraint triangles. Consider a classic software architecture triangle3.

You want high cohesion with low coupling - every function does one thing, there are little to no dependencies - but now you need to duplicate functionality across your system so you wont be able to achieve clean modularity.

Similar is true for high modularity with low coupling - clean modules with little dependency on each other - now your modules need to have multiple responsibilities.

High modularity with high cohesion - cleanly separated modules, and they do one or only a few things well - now you will have lots of cross-references and dependencies between the modules, they will be tightly coupled.

Pick your attributes well

As we can see now, it is important to choose your quality goals well. Otherwise, you may have to explain to your client that they can't have it both ways. This should be the first thing to figure out with stakeholders and everyone interested in what you want to design and deliver: what are the trade-offs to make and where do we plant our goal post between competing quality requirements?

We already said there are many attributes to choose from resulting in all sorts of trade-offs. Where do we start? That's what quality frameworks are for.

There are many to choose from (ISO-25010 etc). I want to introduce briefly the Arc42 Quality Model because it is nicely condensed and intuitive. Instead of considering all possible attributes (which go into hundreds in some models), it lists eight key system properties that connect to everything else.

The properties are (diagram taken from their website):

I like to take these properties and think about priorities. The main goal of quality frameworks is to describe the complete landscape of all possible attributes, to ensure every angle of a system has been considered. But before thinking about completeness, we need to decide what to build first and what to focus on (especially in agile settings). This is useful for any project and can help steer the discussion between stakeholders and those who implement the solution.

If you could choose exactly one goal of any project, which one would that be? I think it is this: the most important objective is that we deliver what the client had asked us to build.

There is no point in shipping something highly performant if it doesn't solve the clients problem. If your employer asks you to build a shopping website, and you deliver a banking software, it simply does not matter that it is the fastest, most secure piece of software ever conceived.

Arc42 calls this property suitable, and I think it should be the first thing to think about. Suitability is where function requirements meet non-functional quality attributes. As with every system property, suitable means something different depending on the role someone has. Suitable code for a developer means something entirely different than suitable application for a user. It depends what matters to the client, but in general, we need to first make sure we understand what is means to build the "right" solution.

Next, the solution we deliver should be reliable. Delivering exactly what the client needs is great, but it does not matter much if the product does not work reliably. As with every attribute, there is a range. Reliable can mean performance, up-time, correctness etc. In the beginning, it may be fine for the client if the solution does not work all the time, for example, in a proof-of-concept project. As long as everyone agrees on what the expectations are.

Two properties can be equally important to reliability. Those are secure and safe. They are often inherently important, but given their high value (or risk of damage) it is particularly important to specify them.

What is the difference? It is "safe to use" versus "secure from mis-use". If there is any potential personal harm for a user, safety is even more important than reliability. If all we deliver is a website that shows public data, it may be acceptable to deliver a website without any user authentication.

Next I see equally important properties of operable and usable. So far, we are building a product that does what it should, that is secure and safe, now we need to consider its operation and use. In terms of requirements, this is where MVPs often neglect operability and usability in favor of speed and cost. A product that solves an urgent need may not to be the most usable tool. It may also be difficult to operate or deploy, but as long as we are able to get it out there and receive feedback we can be fine with little automation and manual lifting.

As the remaining two properties deal more with future requirements, they have lower priority. After a successful launch and once our application has proven to create demand, we want it to be efficient. Running software consumes resources that if, not done efficiently, may cause the business to fail when costs outweigh profits (the fate of many cloud apps).

Finally, our solution is working in full swing and new requirements come in regularly. Hopefully we have built something that is flexible, our final attribute. How well can we extend or adjust the product and evolve over time?

If you consider those eight properties together, you cover a lot of ground.

The resulting map looks like this:

Large Language Models are at a pivotal point. On one hand, we still don't understand how they work or why they work so well - could human thought be nothing more than a pattern that these models have somehow uncovered? On the other hand, there's growing concern that LLMs are hitting a wall1, that current approaches (i.e. throwing ever more money and computation on training) won't fix its biggest shortcomings (e.g. hallucinations), and that the alarmingly high valuations and expectations may come crushing down soon.

But whatever the future holds, as of early 2025, LLMs have demonstrated their usefulness in various ways. One specific use case - this blog's hobby horse - is using language models as a learning companion.

When the student is ready, the master will appear

What would an ideal teacher look like? Imagine the perfect mentor on your side. Someone who is vastly more knowledgeable than you, but capable of speaking in a language you understand. Someone who knows your strengths and weaknesses, and can support or challenge you in just the right way. Above all, someone who is always available, endlessly patient and never gets tired.

How do chatbots compare to these ideal traits?

• Endless patience. This is an undeniable match. Your favorite chatbot is always available, never gets tired, is always nice and never offended (unless you somehow get beyond their guardrails). That is the unbeatable advantage of a machine.

• Speaking your language. This is possible to accomplish, more or less, depending on how hard you try. Ask the chatbot to talk "as if to a child" and similar prompts can adjust the language to a level you understand.

• Vast knowledge. True and false, depending on your level of expertise. While LLMs are surpassing any single human's knowledge after having devoured the entire internet (and running out of training data), they are also prone to hallucinations, which make them highly unreliable.

• Understanding your strengths and weaknesses. LLMs don't know you, and have no agency to care for or plan your progress. However, with the right prompts and sufficient persistence, we can get them to emulate a useful mentor, as I explain below.

LLM-based chatbots are comparable to highly capable interns with endless ambition and energy, who are extremely well-read, but have no life or work experience and demonstrate a dangerous lack of common sense. They are helpful hands but require constant supervision.

They do bring something new, however - something that computers could not achieve before: the ability to adapt to any written input. Until recently, human-computer-interfaces have mostly been static. Input was limited to a predefined set of controls, and the same input lead to the same output. Two different people get the same Wikipedia page and search engine results (except where advertisement may skew what is presented). Variations in output, such as in computer games, have mostly been random, not tailored to the individual player.

LLMs are way more malleable than other systems. While randomness still exists, the key difference lies in their quantum leap in understanding of written input. The ability to describe the context of my question in my own words - and have the system adjust to even subtle changes in how I express my intent - opens up entirely new possibilities for merging my mental model with new knowledge. That is, if we use these tools the right way.

Every thought is a mental model

In the book "Why Don't Students Like School?"2, author Daniel T. Willingham describes the learning process in a beautiful way: "Understanding is remembering in disguise". We learn new ideas by comparing them to old ideas. However, not just any old ideas. Learning occurs if we are able to pull up the right existing ideas from long-term storage, bring them into working memory, and arrange them in a way such that new ideas fit in.

The act of “loading old ideas” into working memory is crucial process, one that we can make more efficient by deliberately describing, testing and extending our existing mental model. The best thing about LLMs is that we can do all that directly at the prompt. This not only leverages what makes chatbots so useful3 but also makes our learning efforts significantly more productive.

For example, if two users ask, "What is Kubernetes?", the chatbot will likely provide both users with similar responses. Using a language model that way, all we get is, at best, a better search engine.

However, if I begin with my personal mental model of Kubernetes—whatever it may be (and we always have a mental model) - I can engage with the chatbot building on what I already know. This makes the responses more useful.

For example, I may provide the following prompt:

I want to learn about Kubernetes. Here is what I believe.

Kubernetes is a framework to manage containerized applications. Kubernetes are built on top of containerization software like Docker. Kubernetes can use any kind of container run-time, but let us assume we are using Docker. Kubernetes extends Docker with new ways to define and manage applications.

On a high-level, Kubernetes creates two applications inside Docker: a control node and data nodes. The control node delivers the Kubernetes API and is the entry point to any Kubernetes cluster. The data nodes contain the application. There is at least one data node, but there can be more in case the application needs to scale up.

What I don't understand is how nodes are created and how Kubernetes uses Docker. Evaluate my understanding and explain what I don't know.

(I have added a sample response below).

This way of prompting achieves two things:

1) I am describing my existing mental model to the chatbot - and to myself. (It is my model - you may not understand at all what I say, find it trivial or completely wrong, depending where you are on your journey). This activity alone is immensely valuable. Even if I don't press send, the act of articulating my thoughts helps clarify my doubts and enabling me to engage more actively with the subject.

2) I provide the LLM with a more detailed context, allowing it to generate a response tailored specifically to my problem.

Of course, you can start with the Wikipedia-style question and answer and go from there. They key is to drill down to your specific areas where you need clarification.

Where the bug is the feature: an exercise in critical thinking

Like any powerful tool, AIs can be either a boon or a bane, depending on how they are used. While I've discussed advantages of LLMs, it's equally important to address the caveats.

LLMs are designed to write well and please the user, which can easily create a misleading impression of authority. They are prone to errors, or worse, to fabricating completely false information. This inherent unreliability may never allow us to fully trust their output. In many fields, this poses a significant problem that could hinder widespread adoption.

In our situation, however, we can turn this flaw into an advantage.

Like an unreliable narrator in fiction, who keeps us on our toes and makes us question the story in front of us, knowing that LLMs are flawed means we must always be ready to doubt their output. The first grave mistake to avoid, therefore, is to blindly trust any AI generated text, no matter how well articulated or convincing it may seem.

This is also called critical thinking, a basic skill useful in any context. By questioning and verifying the output, we are compelled to actively engage with the subject and continuously test our mental models. LLMs are particularly useful in areas that have verifiable truthiness. Engineering, for instance, is a suitable subject, because often it becomes immediately apparent if something works or not.

The unreliability of LLMs also prevent us from making the second grave mistake when using these new tools: outsource all our thinking to an AI. A chatbot may spit out the correct answer for you and fix your problem, but if your goal is to learn and grow intellectually, letting an AI do all thinking for you would achieve the opposite. It’s like saying, “Cars can get me from A to B much faster, so what's the point of exercising.”

Instead, we need to figure out what parts of the thinking process to automate and where to do the heavy lifting ourselves. For example, if you are an experienced developer, using a coding AI to generate boilerplate code can be helpful, allowing you to focus on more complex and valuable tasks.

What about surrendering the ability to read maps by relying solely on GPS? I am not sure about this. I would not deliberately turn off route guidance ("real men don't need GPS") but I believe that we may lose something deeper if we are not able to read maps anymore and orient ourselves in the world like generations before.

However, completely giving up on solving problems yourself and simply copying and pastings answers from an AI is a terrible idea. After all, if you stop thinking critically and let a machine do it for you, what's to stop someone replacing you with this machine?

Instead, use the LLM as a sparring partner. Let it generate ideas to spark your thinking and use it as a tool to find and fill gaps in your knowledge. Let it help you become smarter and focus on what is valuable and can not be automated.

Even if AIs were to become fully reliable, the third and ultimate mistake would be to replace human interaction with chatting to a bot. Humans are flawed, emotional, have hidden agendas, but the richness of human connection remains far beyond the reach of machines - and I doubt they'll ever come close (well, that's a topic for novelists to explore). A good human teacher connects with their students on multiple levels, offering a depth of engagement that no AI can replicate.

However, the LLM at your side can boost your efforts - for example, by helping you prepare a meeting with another human or by refining your writing to communicate more clearly (as it did for this post - thanks, dear AI editor).

Appendix: A sample response to my mental model

Your understanding of Kubernetes is generally correct, but there are a few nuances and details that need clarification to give you a more complete picture. Let’s break it down:

What You've Got Right:

1. Kubernetes and Containerized Applications: Kubernetes ... provides the orchestration needed to deploy, scale, and manage containerized applications.

2. Kubernetes and Docker: Kubernetes ... can work with other container runtimes as well, like containerd or CRI-O. Docker was historically the default container runtime for Kubernetes, though it's no longer the default in recent Kubernetes versions.

3. Control Plane and Worker Nodes: Your description of the control plane (which you referred to as the "control node") and worker nodes (which you called "data nodes") is broadly correct. The control plane is responsible for managing the cluster, including scheduling applications (pods), maintaining the desired state, and exposing the Kubernetes API. Worker nodes run the actual containerized applications.

4. Scaling: ... Kubernetes allows applications to scale by adding more worker nodes.

What Needs Clarification:

1. Nodes and Their Creation:

2. Node Types: Kubernetes clusters consist of two types of nodes: the control plane nodes and worker nodes (not just one control node). The control plane typically consists of multiple nodes (for high availability), which collectively manage the cluster.

3. Node Creation: Nodes are typically physical or virtual machines (VMs) that you add to the Kubernetes cluster. These machines are prepared (or “provisioned”) and then registered with the Kubernetes control plane. Kubernetes doesn’t create these nodes by itself; they are provisioned through external systems or cloud providers like AWS, GCP, or Azure, which can automate the creation and addition of these nodes to the cluster.

4. How Kubernetes Uses Docker:

5. Docker and Kubernetes: When using Docker as the container runtime, Docker is responsible for running the containers, but it does so under the orchestration and management of Kubernetes.

6. Kubernetes Components and Docker: The Kubernetes control plane manages everything. When a new application (or “pod”) is scheduled on a worker node, the kubelet (a Kubernetes component that runs on each node) instructs Docker to pull the necessary container image and start the container. The kubelet then continuously monitors these containers and reports back to the control plane.

7. Pods and Containers: Kubernetes doesn’t directly create Docker containers; it creates pods. A pod is the smallest deployable unit in Kubernetes and can contain one or more containers. When Kubernetes schedules a pod, Docker (or the container runtime) runs the containers inside the pod. Thus, Kubernetes abstracts away the direct handling of Docker containers and instead manages pods.

8. Control Plane Details:

9. The control plane consists of multiple components, including the API server (which exposes the Kubernetes API), the etcd database (which stores the cluster state), the scheduler (which decides which node runs a new pod), and the controller manager (which enforces the desired state of the cluster).

10. Worker Nodes:

11. Worker nodes run a kubelet, which communicates with the control plane, and a container runtime (e.g., Docker) to run the containers. They also have a kube-proxy component that manages networking for the pods.

What You Don't Know (Based on Your Description):

1. Node Provisioning: Nodes are not automatically created by Kubernetes; they need to be provisioned and added to the cluster through an external process. Kubernetes then manages these nodes once they are part of the cluster.

2. Pods vs. Containers: Kubernetes doesn’t manage individual containers directly; it manages pods, which can contain one or more tightly coupled containers. The concept of a pod is central to Kubernetes and is a layer of abstraction above containers.

3. Control Plane Components: The control plane is not a single application or node but a set of components working together across potentially multiple nodes to manage the entire cluster.

In Summary:

You have a good foundational understanding of Kubernetes, ... However, to fully grasp Kubernetes, it's essential to understand the concepts of nodes (control plane and worker nodes), pods as the basic unit of work, the interaction between Kubernetes and Docker, and the broader architecture involving multiple components working together to manage the cluster.

The AI Service Provider

An AI service provides intelligent capabilities that developers can integrate into their applications.

The depth and breadth of these capabilities depend on two things: 1) the quality of the models the service uses, and 2) how well developers can tap into those models (via an API).

Using OpenAI (https://platform.openai.com/docs/) as an example, let’s examine each of the three components: models, capabilities, and the API, and learn the fundamentals of generative AI in the process.

Models

Generative AI has grown out of deep learning (with the help of a few milestone inventions, namely, Generative Adversarial Networks (GANs), Variational Autoencoders (VAEs), and Transformer Models), where vast neural networks are trained on large datasets to produce models that are used to accomplish intelligent tasks. What a model can perform is determined by the type of data used to train it and how much fine-tuning went into it.

Models and Training

Models trained on images, for example, produce images, models trained on images + text, produce images based on text and so on.

The first thing to do when examining an AI service is, therefore, to look at the models they offer.

OpenAI's models are listed here: https://platform.openai.com/docs/models/overview

They include:

• GPTs for generating natural language

• DALL-E for generating images

• Whisper for converting audio into text

• and many more.

But what is a model, actually? A model is nothing other than a set of parameters (that represent the weights of the neural network that came out of the training). When you install, for example, an open-source large-language-model like Llama-2 on your computer, you will find a 100s GB large file on your drive that captures exactly those parameters (plus another file that handles the user interaction - see a video by Karpathy1 for an excellent introduction).

One more thing to know about models is that they are trained during (at least) two phases:

• the base training uses a massive amount of data (e.g. large chunks of the internet) to produce a general model that is not yet that useful for the end user

• followed by a fine-tuning phase that turns the base model into something better, like a question-and-answering assistant (e.g. ChatGPT)

Fine-tuning doesn’t stop here.

A model can further be fine-tuned by the user. Either through more training or directly on the prompt by including the sample data in the chat (so-called "few-shot prompting"2)

Capabilities

Let's look at OpenAI's capabilities. A few we have already mentioned.

Model capabilities

• Text generation: The key function of large language models is to generate text based on text input provided by the user (also called "prompts"). LLMs have been trained to understand language and behave in a question-and-answer manner.

• Image generation: Takes text or images to produce new images.

• Vision: Takes an image and allows to ask questions about it.

• Text-to-speech and Speech-to-text: Can be used to transcribe voice or produce audio based on text.

• Moderation: Takes text as input and flags the content for potential policy violations. Can be used to filter user input.

• Function-calling: Allows to connect a model with external tools provided by the user.

• Embeddings: An embedding is a numerical representation of text, allowing efficient handling of text search and other use cases.

• Fine-tuning: Creates a new model based on custom training data and default instructions. Useful for repetitive tasks that require additional training, complex prompts or rules. After fine-tuning, the customisation is integrated into the new model.

• Some capabilities provide immediate value (e.g., text generation), while others are only useful in combination with other tools (e.g., function calling).

The remaining question now is to figure out how to access those capabilities. OpenAI offers two APIs: endpoints and assistants.

API

Endpoints

Here are again the capabilities, but this time we include the endpoints.

Endpoints and capabilities

As we can see, some capabilities can be accessed directly from an endpoint, while others are only available indirectly through a generic endpoint (Chat and Audio).

Chat is the most capable endpoint, resembling a chat with ChatGPT. Previously called "chat completion," it works by sending a question to the endpoint and, depending on the question asked, returning more or less complex answers. It combines text completion, image recognition and function calling. Audio is the access point to create speech from text and vice versa. The remaining capabilities have their own endpoint.

Assistants API

The endpoints we have mentioned so far directly tap into a capability. The Assistants API offers a more sophisticated experience.

Assistants API

You can think of it as the Chat endpoint but with more features. Mainly, conversations with an assistant are captured with Threads and Runs, making it possible to have several ongoing chat sessions. Also, assistants make it possible to provide files to the AI (to ask questions about them, or for "Knowledge Retrieval", see below).

Assistants have access to so-called "Tools," which are additional capabilities, only available through the Assistants API (except for function-calling, which is possible with the Chat endpoint). Code Interpreter "allows the Assistants API to write and run Python code in a sandboxed execution environment". Knowledge Retrieval gives the Assistant access to your own documents. It works by uploading a File to Open AI, which then automatically chunks, indexes and stores the embeddings so that the assistant can search and retrieve the document's content.

Tokens, Embeddings, Prompt Engineering

There are a few more things left worth mentioning:

• Tokens: models process text in chunks called tokens3. The details don't matter much when using an LLM, except that the cost of using a service is based on the amount of tokens that have been used.

• Embeddings: we have already mentioned that they are a numerical representation of text in the form of a vector, which makes it possible to compare the similarity between documents by comparing the vectors mathematically.

• Prompt Engineering: working with LLMs is vastly different from how humans have interacted with computers so far. In the past, a computer required *exact* instructions, that would produce the same outcome with every execution. A slight mistake in the input could produce a useless result. LLMs are often capable of handling faulty or incomplete input (e.g. spelling mistakes), but they can make mistakes no matter how well the input was conceived. Also, the ability of LLMs to be "creative" leads to producing a different answer every time you ask the same question. This new approach to human-machine interaction is called "prompt engineering," and it is very worthwhile to invest time studying to make the best out of the new tools.

Thanks for reading. Please reach out for comments, questions, or suggestions.

If you haven’t thought about scalability before, this short video provides you with the basic concept of scaling.

It also prepares you well to read the (highly-recommended) book “Designing Data-Intensive Applications” (https://dataintensive.net/), in particular, the first chapter.

Have you ever tried playing chess against yourself? Unless you are a chess purist or have a split personality, it is not much fun.

The pleasure of engaging in a game like chess comes from challenging another mind (human or otherwise). From not knowing what the other is planning and the uncertainty that comes with it. When two opponents share the same brain, there are no secrets or surprises.

Another player makes the game “real.” When you have found a weakness in the opposing position and hatch a plan to exploit it, your opponent will prove your plot right or wrong. The stronger the rival, the harder your ideas will be tested. Left alone, that “clash with reality” can’t occur. You can try hard to emulate both separate sides, but as the two are coming from the same mind, all you do is evaluate yourself, which has limited value.

We are in a similar predicament every time we are trying to understand something or come up with an explanation. Because we are the creator of our thoughts as well as their recipient, we are biting our own tails whenever we try to figure out if what we think is correct or not.

To overcome the lack of outside perspective, we intend to look at a problem from all angles. The trouble is that not only is seeing the forest from the trees difficult, but that thinking itself is flawed. The mind’s default operational mode is not rationality, and it has no incentive to spot inconsistencies. Instead, it happily paints over blind spots, leaving us unaware of our imperfections.

Why is this so? Wouldn’t it be beneficial to our species to ensure that our thinking is consistent and flawless? The short answer is no. The mind is not designed to think.1 From an evolutionary point of view, it is more beneficial for our survival to automate thinking as much as possible. Active, hard pondering of problems consumes valuable energy that would be better spent on spotting danger or other life-preserving activities.

The brain is arguably the most wonderful thing in the universe (as far as we know, that is). It can do marvelous things like seeing, hearing, memorizing, beating a heart, all at the same time and while giving birth to consciousness. But when it comes to learning and rational reasoning, the organ inside our skull is a broken tool, like a water bucket with holes.

Without a clear picture of what we actually think (rather than what we believe to think), efficient learning is difficult. It is essential to shine a bright light on the gaps in our reasoning and bring them out into the open. Learning is as much about gaining new insights as it is about getting rid of false beliefs.

What can we do?

Ideally, you’d have a few like-minded people at your disposal interested in your stuff who could challenge and inspire you (could this be an AI in the future? That would be tremendous).

Lacking such a sophisticated support group, the next best thing to do is to break the mind’s self-evaluation-loop by putting distance between the moment we generate an idea and the time we evaluate it.

Humanity has invented a tool for exactly that problem - pen and paper. Writing helps us capture our fuzzy thoughts and make them explicit and observable. The problem is it can be a laborious word-wrangling exercise to express ourselves. Luckily, for our purposes, we can skip most of the arduous parts of translating our intentions into sentences and simply transpose our raw thoughts onto paper. This can be done much easier and faster by making a list.

The difference between a list and “normal” writing is the intended audience. Usually, we write for others, which makes it so hard because the reader does not know anything about us. We need to give as much context and be exact as possible to avoid ambiguity. The list, on the other hand, is only meant to be read by the author. No need to explain where we are coming from; we can be as esoteric in our descriptions as we like.

There is one non-negotiable requirement, though: Everything on the list has to be written using our very own words. This is crucial to make the list fulfill its purpose.

Looking up answers and copying-pasting them into our list does not help at all - rather the opposite, it only strengthens the gaps in our understanding because it creates the illusion of knowledge. We may write down correct facts, but they are not coming from us.

This is one reason why highlighting passages in a book does very little to increase comprehension of a text. It looks like learning because the passages are important, but they are not our words, they are expressions of someone else’s thinking (underlining text passages can still be a useful activity, but the highlights are merely bookmarks, helping navigate a large amount of information).

Definitions, buzzwords, or concepts we don’t fully grasp don’t belong on the list. Unless we write down precisely this - that we don’t understand those terms (e.g., “Technology X is a distributed-self-contained management system - what the heck does that mean?”)

We list what we know (or believe to know) and what we don’t know or understand. This is a fast and fluent exercise. It does not require much thinking. Then, very soon, we will have exhausted what’s on our mind.

I love making lists. Whenever I am stuck, I start listing my thoughts. This post here started as a list (as all others have) that I then successively transformed into full sentences. The moment I got stuck, I switched back into list mode, and so forth. I’m always shifting modes. From slow and exact writing, building up a single line of argument, to the immediate and quick jotting down of multiple strands of thoughts (there are other modes, but that’s a subject for another post).

When I begin a new task, I start with a list. To clarify my intentions and beliefs and to prepare myself for the work ahead by bringing into focus the things I’m sure about and those I’m not. This way, I prime my mind to find answers for the gaps I have and to look for confirmation of what I assume to be true.

Lists are helpful for any kind of mental task. They expand our short-term memory. They force us to think sequentially and turn vagueness into explicitness. And list-making is a fun activity, even relaxing, similar to meditation with its benefits, where we step back from being mindlessly captured by thoughts and instead gain control through observing our mental states.

What do we value most in life? Health is an obvious choice, next to love and meaningful friendships. Money is certainly on the list too, but controversial, at least when pursued narrowly at the cost of everything else (though few would dispute that a good life depends on owning a sufficient amount of it).

Uncontroversial is the value of another item: knowledge. Our post-industrial society increasingly depends on the creation and transfer of know-how and technical expertise. We usually consider knowledgeable people as intelligent, which often correlates with higher social status and financial reward.

But what is knowledge? It is surprisingly hard to define. Does memorization of a lot of facts (e.g historical dates) count as knowledge? Then your internet-connected computer would be the most knowledgeable entity ever created. Facts are data points. Taken by themselves, they have limited value if we can't explain their existence and are unable to predict future facts. In other words, we lack understanding.
Furthermore, the value of knowledge depends on its usefulness to solve a problem. In particular, to solve my problem. Ask "How much do you know about X?" and I would reply "to accomplish what?" (which is nicer than an engineer's favorite retort of "it depends..."). I know that a combustion engine needs oil and gas to function and have a dim idea about gears. Enough knowledge for me to drive a car, understand the meaning of warning lights and abstain from shifting into reverse while the car is moving forward. If you ask me, I know all there is about cars. However, if tomorrow I wanted to start a new career as an auto mechanic, I would immediately find out that I know very little.

Figuring out the purpose of knowledge not only affects how we think about it but also fundamentally changes how we teach and learn. By asking about the reason for knowledge we move from passive consumption of facts to an active inquiry about the why, how, how well and so on.

How purpose and knowledge relate to each is the subject of the fascinating book “Knowledge as Design" by D.N. Perkins. As the title suggests, the author considers knowledge not something that is out there, given to be consumed without critical analysis (he calls this "truth mongering") but something that has a purpose, or, in a broader sense, a design.

The first thing to note is that the word design may be misleading. If you, like me, haven't thought much about design before you may equate it with style (fashion, brands, websites) or a blueprint to build something (design of a house). The author takes a wider look and defines design more accurately:

Design is the human endeavor of shaping objects to purposes

Almost everything is a design. A knife is an object adapted to the purpose of cutting things. Academic knowledge is also designed - Newton's laws are a mathematical tool to explain the motion of bodies. So are processes, claims, and even historic dates as a part of a larger story (for example, the year 1492 marks a milestone in western civilization). There are only a few things that are not designs (like natural phenomena).
So how does thinking about design help us with acquiring knowledge? Knowing the purpose of a design is crucial, but purpose alone only explains the reason a design exists, it does not say anything about how it solves a problem.

The four design questions

The author gives us a tool to examine designs by formulating four design questions that make up the heart of the book.
The questions to ask about a design are the following:

1. What is its purpose?

2. What is its structure?

3. What are the model cases of it?

4. What are the arguments for and against its usefulness?

"Purpose" we have already discussed. The structure of a design deals with the parts, components, materials, relations, and so forth of the object in question. A knife has a cutting edge attached to a handle.

Model cases are examples of the object or knowledge (imagine photos of different types of knives). Model cases are in some sense mental models, but in a much narrower way (I come back to this later).

Arguments, the last of the four questions, evaluate a design. How well does it do its job? Given the purpose, is the design well-thought-out or could it be better? While the former three questions could be answered without much context, here we depend on our subjective understanding of the object at hand. I can't say anything about the effectiveness of a design if I don't understand what it does or how it differs from other solutions.

The book discusses at length how the four questions can be applied to practically everything. It turns out that looking at the world through design glasses is tremendously useful. Be it how to write an essay, how to come up with new insights or how to improve learning and teaching in general.
Since knowledge plays such an important role in our life, it is worth looking at how this new way of thinking about knowledge (as design) compares to our default way (as information).

We shift from the left to the right, from the passive to the active, by connecting what we learn to each of the four design questions.

So how does all this help us with our mental models? Is one better than the other?

How do software mental models (SMM) compare with the four design questions (4DQ)?

The short answer is that 4DQs are a tool to evaluate the subject at hand that leads to a conclusion, while SMMs are a process that keeps evolving. There is overlap between the two but also significant differences. Let's have a look at each of the four questions.

Model cases

We start with likely the most confusing part. Aren't mental models the same as model cases? Not really. Mental models, at least the way I use them, are internal representations of reality, that can differ significantly from the actual object. Model cases are examples (of object types, procedures, formulas, etc). In contrast, mental models are simplifications that are (hopefully) so useful that they can explain complex processes with a few elegant analogies. Coming back to the simple example of a knife, model cases would present all the different types of knives (we could, for example, present their evolution from the stone age until today), whereas the mental model of a knife depends on what goal I have. In my case, I mostly think about knives in the context of a kitchen, so I have mental models about how the sharp side of a blade works and what knife to use for certain materials (e.g. bread versus meat). A chef has vastly more complex internal representations of knives. She might think about angles, handles, all kinds of materials, cutting techniques, and so on.

Structure

The structure of a design describes the elements and parts of the object or knowledge. Mental models include structure, too, but only those parts that are useful for achieving the goal. When learning something new, the structure of a model will be similar to a structure of a design. The more advanced the models get, the more abstract they become until they may have nothing in common anymore with the actual object.

Purpose

The purpose of a design is similar to what I consider the goal of a mental model. However, in the case of SMMs, the goal is deeply personal, whereas the purpose of a design is meant to be independent of the learner.
The goal of a mental model gives clarity about what is important and what I can leave out. The goal evolves. In a design, the purpose is fixed - the reason the design exist stems from the purpose.
In reality, the purpose of a design is still to some degree subjective, because it depends on the knowledge of the learner. A physics beginner in school will come up with a different, simpler purpose for Newton's laws than a university graduate.

Arguments

Arguably, arguments are the most important of the four questions because they require the learner to conclude based entirely on their understanding and experience. Purpose, structure, and model cases lay the foundation upon which arguments are built.

SMMs don't have arguments at all. If they are so important, how can this be?

The reason can be found in the fact that SMMs are a process. Arguments and purpose are two sides of a coin. The argument describes how well a design accomplishes its purpose with the outcome of an evaluation. SMMs don't have a final step. Instead, we evaluate models during the test phase, where we figure out where the models are inaccurate. Instead of giving a judgment, however, we correct the model and make it better during the refinement phase (or replace it with a better model if necessary). The argument is ingrained in the process.

In summary, we can say that SMMs are the agile version of 4DQ.

The 4DQs are a very useful tool to structure thinking, learning, and writing. The book can be repetitive at times as it goes through the many possible applications of the theory, but once the main ideas are understood it is easy to skip content and focus on the parts that interest you. They are certainly useful for developing SMMs.

Can you spot the 4DQ in this post?

Writing an essay is among the use cases of the theory. Can you spot where in this post I have used the four questions?

Answer:

• The first half of this post explains the purpose and structure of the 4DQs. First I made claims about the importance of knowledge, and in particular, the value of looking at the purpose of knowledge

• Then I described the structure of the 4DQs, describing each question.

• I finished the first half by completing my description of the purpose of the 4DQ by demonstrating the value of moving from seeing knowledge as information to considering knowledge as design.

• I use model cases of 4DQs throughout the post, most of the time using the example of a knife. And, to go fully recursive, this answer is another model case of the 4DQs.

• In the second half I give arguments by comparing in detail the 4DQs with SMMs, with the conclusion that while there's overlap between the two ideas, SMMs fundamentally differ from 4DQs by being an ongoing process instead of a final evaluation of an object or piece of knowledge.

Programming is a marvellous activity. By typing on a keyboard and feeding code to a computer, a programmer can create entirely new (virtual) worlds out of nothing. There are few constraints on what a program could be - the only limitations are memory and a CPU's processing power. Whatever you can think of, you could, in theory, bring into existence on a computer. 

But since virtual worlds are created in the mind of a developer and not based on physical reality, it can be difficult to talk about what they are or how they work. There is no immediate language to refer to. To overcome this lack of terminology, engineers often use analogies from the real world to describe what software does.

Docker is no exception. At its centre stands the "container", the main building block of what Docker calls a "standard of shipping software". One can't help but see container ships towing heavy loads over oceans. Even the logo depicts the main idea:

 Containers and shipping software

When we learn about new technology with strong ties to another technology, we immediately apply our existing knowledge of the substitute technology to fill gaps in our understanding. This "replacement reasoning" can be helpful or misleading, depending on how accurate the analogy turns out to be. Therefore, to avoid misconceptions, it is beneficial to evaluate existing mental models first, as they are the ground on which we build our individual models. 

In the case of Docker, we want to know how helpful the idea of "container shipping" is and how far we can take the analogy.

It turns out that there are many parallels between real and virtual containers and that the properties of container shipping cover quite a lot of concepts of Docker. 

Containers (those made from steel)

Shipping containers revolutionized international trade by making it possible to move freight between different modes of transport without the need to re-package goods. Due to standardization and a complex system of docking ports, the cost and time it takes to ship goods worldwide have been significantly reduced. 

What makes containers so valuable is that they can be stacked neatly on top of each other, thanks to their standardized dimensions. They can also carry nearly any kind of goods and can be used interchangeably.

Docker Containers

Like shipping containers, Docker containers also increased efficiency. Most applications run on Webservers. In the past, it was not possible to execute more than one application per server. Not only was managing a fleet of individual servers difficult, but it also lead to a waste of resources, as applications can vary significantly in their requirements that change over time (servers needed to keep a capacity reserve). 

Then a company called VMWare came along and invented the virtual machine. I mentioned in the intro that computers create virtual worlds. They can also create worlds inside worlds. A virtual machine is an emulation of hardware. Each emulated hardware is a new virtual computer (creating computers inside a computer), making it possible to run multiple applications side by side on the same server. 

One OS per VM (Source: "Docker Deep Dive" 1)

This makes deploying applications much more efficient. Applications run inside their own virtual machine (VM), and hardware resources can be individually distributed to meet the requirements of each application. 

But VMs are big. Virtualizing the hardware requires each virtual machine to include an entire operating system. 

Docker takes a different approach. Instead of virtualizing the hardware, it aims higher and abstracts away the operating system. Docker containers share the same OS resources, making them more lightweight 2.

Docker containers are smaller (Source: Docker Deep Dive)

We talked about why Docker exists, but we still haven't said what a container actually is.

How do Docker containers compare to physical containers?

The physical container is an enclosing made of steel that carries goods. Similarly, a Docker container provides applications with an isolated environment (the virtual equivalent of an enclosing). 

Actual containers are filled with goods. A Docker container runs an application. To understand how the application ends up on a Docker container (and how that is done efficiently), we need to understand three basic concepts: 

• Docker engine

• Docker image

• Containerizing an app

Docker Engine

The word "Docker" can mean two things.

First, there is Docker, the company. They develop the tools and libraries required to run Docker and maintain the Docker hub, a central repository. 

Then there is Docker, the technology. There are three main components 3:

• The runtime provides low-level libraries and components to run containers.

• The engine (or Daemon) provides higher-level functionality, most of all the interface for Docker commands.

• A Client is an application that talks to the Docker Daemon (e.g. the docker or docker-compose commands)

When someone learns Docker, they will spend most of their time understanding the interactions of a Docker client with the Docker daemon. 

Actual containers are made out of steel. Similarly, the Docker engine + runtime are "the fabric of Docker containers".

Docker image

The Docker glossary describes containers as a "runtime instance of an image" 4. An image is a collection of files that are executed when a container runs. They are, we could say, the "content" of a container - in other words, the application. 

Images are constructed in layers, where each layer corresponds to a set of files of a container. More precisely, each layer is a set of file changes. When an image is built, layers are executed sequentially, possibly overriding files of a previous stage.

Image layers, overriding changes (source: "Docker Deep Dive" 1)

Layers can be cached. That makes building images efficient because every time an image changes, we only need to update those layers that have changed. 

Containerizing an application

The final piece of the Docker puzzle is the so-called process of "containerizing an application". Or in other words, how do we turn an application into an image that we can then execute on a container? 

This is done via a Docker file. In the container shipping model analogy, a Docker file is similar to a list of items that describe the content of a container. Except that it not only lists the files but also describes the order of their occurrence or modification.

Side-by-side comparison of container shipping and Docker

Finally, we get to the fun part! How far can we take the analogy of container shipping to create a mental model of Docker? 

Container shipping is straightforward to visualize - starting with containers loaded with goods to the cranes lifting them onto ships and so forth until they reach their destination. For every step in the journey of a container, we can find a similar action in the Docker world.

Let's compare them side-by-side.

(sorry for the suboptimal formatting using images - substack please make it possible to insert tables! You can read the post here as well with better rendering)

We can even create a little diagram that compares both worlds:

• Think of a Docker container as a vessel for applications.

• The Docker engine (and runtime) provides the enclosing for goods, similar to steel used to fabricate a physical container.

• The Dockerfile is like a description of the contents of a container.

• The image provides the content of a container, each file (change) is like a single good.

• Building and uploading an image prepares the content of a container.

• Downloading an image and creating a container is like a crane lifting a container onto a ship.

• Running the container can be compared to a ship transporting containers over the ocean.

• Stopping a container, destroying it and deleting an image is similar to a crane lifting a container off a ship, taking out the goods and scraping the empty container.

We make sense of the world through models we create in our minds. How well we understand reality depends on the accuracy of those models. However, we are often not aware that our internal representation can be inaccurate or, worse, we may not even realise that we use mental models at all. By bringing our thought processes into the open, we can shed light on the gaps in our understanding and learn more efficiently.

I have written about the role of mental models in software engineering. I recommend reading that first if you haven’t done so, as it explains the main idea. In this post (and more to follow), I take an existing tool, framework or subject and look at it through the lenses of mental models.

Today’s example is Git. It assumes little or no prior knowledge. If you are already well-versed in Git, I encourage you to keep reading nonetheless. The goal of this series is as much teaching a specific subject as it is about exploring how to construct good mental models in general. There is no shortcut to achieving accurate understanding. As good as an existing mental model may be, we still have to absorb and make it our own; we can’t just copy and paste it into our brains (unfortunately).

What is Git?

The official definition says this:

Git is a distributed version control system.

Does reading this sentence evoke any mental images for you? In my case, the word “distributed” brings to mind several computers running in distant locations. “Version control system” lets me see software that stores copies of documents in an orderly fashion.

This is rather vague. A better way to understand something is not to ask “what” it is, but “why” does it exist - what is its purpose?

What is the purpose of Git?

There are primarily two problems Git is trying to solve:

1. How can multiple people work in parallel on the same documents without stepping on each other’s toes?

2. How can we provide a safe environment for making changes without worrying about losing previous work?

2) is part of the solution for 1). However, it is also possible to only take advantage of 2) while ignoring 1) (if you use Git solely as a local version tracker, which is a legitimate use case).

1 - How can multiple people work on the same documents at the same time?

Let’s think about 1) - there is a group of people who want to work on the same set of documents simultaneously. How can they do that? Pose that question to yourself, and your brain will immediately start generating possible answers.

Depending on how much experience you have with a given problem, the solution you come up with can be complex or straightforward. A natural way to find a solution to a problem is to search in our memory for a similar situation that we can apply to the new challenge. How do people typically collaborate?

I see an office where several people are sitting around a table, with paper documents spread out in front of them. They pass files around, discuss changes, use pencil and eraser (or scissors and tape) to make changes.

Something like this:

Although this model describes collaboration, the participants can’t work in parallel, as they need to take turns to change a document. Let’s refine our model by having everyone work on copies instead of the original documents. To reflect that Git is a distributed system, we also let each worker have their own table.

Our new model looks like this:

How would that work? The table in the middle (let’s call it the “origin” table) contains the original documents. If I want to work on them, I first make copies of the documents and then grab one of the tables and go about making changes as I please. Then comes the moment to update the originals. I go back to the origin table and replace the sources with my edited copies.

There’s just one problem: what if someone else has already changed the originals? If I swap the documents, their changes will get lost.

So instead of swapping out entire documents, I need to “merge” my changes with whatever is on the origin table. This works most of the time, except when my change and someone else’s change are in “conflict”. For example, in a design document, someone changed the color of a button from red to green, but I changed it from red to yellow. Who’s change should persist?

A conflict:

I want to keep my version, but what if I change my mind later (because it turns out my colleague was right)? That is the second problem Git solves: as long as we track changes and can revert back to a previous state, we are safe to make changes.

How does Git make that possible?

Assume I have no spontaneous idea. We are then at a typical state during the learning process. We have exhausted fleshing out our mental model (or don’t want to speculate anymore), and we encountered a few areas where we can’t satisfyingly figure out how things work in reality.

This is a good moment to do some research and consult a book or a manual.

Sidenote: why start with the mental model?

You may ask why we didn’t start reading the book before building our model. Aren’t we wasting our time trying to come up with an explanation of how things work without having done research first? I disagree. By having made our current knowledge visible, the subsequent research becomes more targeted. We can locate gaps more quickly, know what kind of information we need or don’t need, and have a map to place new information.

2 - Keeping a log of changes

So how does Git keep a log of changes?

I use Pro Git as reference documentation. A good chapter to start is What is Git?, you may want to read it now.

The main point from that chapter leads us to the answer to our question:

Git maintains snapshots of changes, not diffs

In other words, every change in Git is stored as a snapshot of all files. Note that the word “snapshot” is another mental construct. Like a camera that catches a scene at a specific moment, a snapshot in computing is a copy of an entire state of a system at a certain time. We can use that information to extend our mental model.

Besides working on our copies of the original documents, we create additional copies of the copies and put them in boxes. Each box reflects a document change. To keep a log of changes, each box links to the previous box.

It looks like this:

Those boxes are uniquely labelled. As you may have read in the book, Git creates so-called hashes of documents (you’ll find hashes everywhere in Git). A hash is a string of symbols that is unique for any possible state of documents.

Sidenote: focus on information to fill the most important gaps, ignore the rest

You may want to dig deeper to understand how hashing works under the hood. Or not? That is another common stage of any learning process. The question is this: should I figure out the inner workings of hashes, or should I just accept that they work in some way and move on?

Your mental model can guide you here as well. At this point, knowing how hashes work won’t help you with your understanding of Git. It won’t increase the accuracy of your model at this stage (being a beginner). It is the wrong rabbit hole to go down. Instead, for the sake of simplicity, we accept this gap in our understanding.

Good mental models strive for simplicity by conveying just enough details that are required to reliably predict the behaviour of the thing you are investigating. Any additional information will slow down progress (more about this at the end).

Log a change - but when?

Back to Git. Another question remains: when do we take a snapshot? Could we store every change? That would create an insurmountable amount of data and not be feasible.

Instead, what seems practical is that the author decides when to store a snapshot. Only they know when changes have reached a meaningful state that should be preserved.

How does Git make that possible?

The same Pro Git chapter mentioned above answers that question. The relevant paragraph is called “the three states”.

Three states

A file in a Git repository can have three different states: it is either “untracked”, “staged”, or “committed”. Untracked files (or modifications) are not recorded yet. When files are “staged”, that’s the moment when we intend to take a snapshot (but we haven’t registered the change yet). Committing files is the final step of storing the snapshot.

The three states:

Coming back to the question of when to take a snapshot, the answer is that it is up to the user to make that decision.

By the way, Git introduces three states, although two would have been sufficient (e.g. committed - or not committed). The intermediate staging step makes preparing a snapshot easier, as we can add or remove files and change our minds before creating the record.

Testing our model

We have developed a set of mental models that cover the basics of Git. It is time to test the usefulness of those models by asking ourselves if they can sufficiently explain how things work for our purposes.

Branching

What is a branch? The word is already evoking a mental model of a real tree, with its main trunk and branches diverging into new directions.

You can read in detail about Git branches in Pro Git, but we can already explain how branches work in principle. As discussed above, “how Git creates a log of changes”, a branch is nothing other than a series of snapshots that is different from the main development flow. Internally, Git uses pointers to make that work, but all we need to understand now is that changes are stored as snapshots and that each snapshot has a unique label (hash) attached to it. If you want to know if two branches are the same, all you have to do is compare the hashes.

Git commands

We test our model by looking at basic Git commands that you will likely have encountered when you first learned about Git.

git clone
git add
git commit 
git push
git pull

If you are new to Git, I recommend running git COMMAND --help and start reading through the first paragraphs to see if the explanation fits our mental models.

git clone --help

Clones a repository into a newly-created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch –remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.

We may not fully understand every detail, but the overall idea fits our distributed tables model of making copies and branches.

git add --help

This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.

We don’t know yet what an index is but can explain most of what is said here with the three stages model. And we learn that git add moves changes from “untracked” to “staged”.

git commit --help

Create a new commit containing the current contents of the index and the given log message describing the changes.

Same here, and now we can conclude that the “index” tracks changes that have been “staged”.

git push --help

Updates remote refs using local refs, while sending objects necessary to complete the given refs.

We don’t know what a ref is but “sending objects” fits our model where we bring our documents to the “origin” table and merge our changes.

git pull --help

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for Git fetch followed by Git merge FETCH_HEAD.

This does not fit our mental model. So far, we said that when we are ready with our work, we bring our changes to the “origin” table. But in reality, we “pull” changes down to us. We found a gap in our model. Coming back to Pro git - What is git? we can now understand what is meant by Nearly Every Operation Is Local. If Git was new to you and you followed along with the steps of this article, I bet you have now a stronger understanding of what “everything is local” means compared to when you first time read about it.

“Real-life” testing

The ultimate test occurs when we apply our knowledge to real-life situations. Whenever Git does not behave as expected, we find out where we need to improve the model.

Polish & refine

As mentioned in the introduction post, building mental models is a four-step process:

1. Define your model. We all use some kind of model, whether we are aware of it or not.

2. Test your model. Either by researching or in real-life situations.

3. Improve your model. Take what you have learned in 2) and improve it. Then test again.

4. Simplify or go deeper. There will come a moment when steps 2) and 3) won’t bring any further improvements or when the model does not go deep enough because you have advanced in your understanding and tackling bigger challenges. You may be at a point where you can significantly simplify the model or build a new one.

We have not yet exhausted steps 2) and 3), but we can still simplify our model. The table metaphor has gaps and is not that useful (but it helped to develop the model of snapshots).

Instead, the model of snapshots and the three file states together seem to be a good first mental model of Git.

The final Git mental model

Log of hashes & three states

• Every committed change in Git is stored as a snapshot and referenced by a unique hash. A log of changes is represented by a log of hashes. To compare two branches, all we need to do is compare the hashes to know if they are the same or not.

• All files go through three possible states.

Summary

While developing an understanding of how Git works, we have gone through the process of constructing mental models. The key takeaways are the following:

Always build your mental model first. Before you start reading a book or tutorial, sit down and visualise how you believe that the thing you are interested in works. That will make your subsequent research a lot more efficient, as you have a base that guides your reading and a place where you can place new information and relate it to existing knowledge. Remember the last time you read a book without any preparation. You may have highlighted sentences and written some notes in the margins - but how much of that information could you actually remember?

Test and refine your model. That step is easy to forget, especially when it comes to improving your mental model. When you hit a plateau in your learning effort, that is the moment where you need to go back to your model and work out where the gaps are.

Just enough information. Good mental models are simple, some even elegant, and they convey just enough information to be useful.

The goal is not 100% correctness. A model is always an approximation and depends on your context and level of understanding. Don’t try to cram everything in it. Instead, figure out what are the most important facts of something. That exercise itself is very valuable to master a skill.

Next

With the model at hand, we can now go and apply it to our daily work.

A good idea might be to look at your .git folder and try to figure out what is going on there. That will give you a deeper understanding of the internals (the relevant chapter in Pro Git is Git Internals Plumbing and Porcelain).

Or even better, don’t do anything and just use Git and wait until you hit a bump. That is the beauty of learning with mental models. There is no fixed path that you have to follow - real-life situations will show you where you need to improve.

I will come back to Git in a follow-up post and apply the model to more advanced situations, showcasing examples of where our model is sufficient and where it is not.

Software engineering is a rapidly evolving industry, putting developers in a perpetual state of having to learn new things while doing their actual job. This is a daunting task, not only because a full-time job leaves little room for training and catching up on the latest changes in tech, but also for the reason that it is becoming increasingly more difficult to decide what and how to learn.

For example, when faced with an engineering problem, the following questions may pop up in a developer's mind:

• Should I search the internet for a quick answer, hoping to find a copy-and-pasteable solution to my problem? This may or may not work. Often it leads to fruitless attempts and wasted hours.

• Or should I better take out that textbook and try to understand the fundamental ideas? But books are long - where do I start? Maybe a shorter video is a better use of my time?

• Or is it time to get more practical experience instead of indulging in theory and picking up a tutorial or working on a proof-of-concept?

• Why do I seem to have hit a plateau in my understanding and what is required for me to move ahead?

• Why do others appear to grasp things faster while I struggle to get my head around this problem?

As we can all testify, the issue is not that there isn't enough information to solve a problem. It is the opposite: how can I make sure I invest time in the right activity to learn as efficiently as possible?

I believe there is an answer to all those questions and that it is possible to be confident about what and how to learn. The answer can be found by paying close attention to how we learn.

What does it mean to understand something? Understanding is related to knowledge. The deeper my understanding goes, the more "complete" my knowledge. Gaps in knowledge, on the other hand, are causing a lack of understanding. So when is my understanding "complete"?

I offer the following definition:

My understanding is complete if my knowledge about something is sufficient enough so that I can reliably predict future behaviour

The ability to reliably predict the behavior of the thing or process I'm interested in determines my level of understanding. The fewer surprises I encounter, the more I can explain behavior and the deeper my understanding.

However, all this depends on the purpose of what I'm doing and how deep I need to look into something.

For example, I don't need to understand how bits are moved on a chip to program a website that runs on a standard server. Knowing about hardware would not increase my ability to predict the behavior of my code. However, move away from a traditional operating system to specialized hardware, and the situation changes. Now my knowledge is not sufficient anymore to reliably predict the result of my work.

If our goal is to continuously widen our understanding over time the accuracy of our prediction would look similar to the following graph:

Prediction accuracy over time. Our understanding grows until we hit a plateau. To overcome it, we need to switch the context and go deeper into the subject. This might require extending our mental model or creating a new one, which will, in the beginning, cause the accuracy of our predictions to decrease, but once the improved model gets more accurate, our overall understanding becomes wider.

To avoid any gaps, why don't we learn everything there is about computers? Because we can't. Grey matter memory is limited. We would never get past all there is to know about hardware before we could even start figuring out how to program something.

That is true for almost everything else. Reality is by far too complex for the human brain to absorb completely. Instead, the brain creates a simplified inner model of the outer world that we use to reason about reality. Models help us to reduce complexity so we can spend our "brain power" on other things. The more accurate our models are, the fewer unexpected events we encounter in our daily life.

Mental models can go far and explain complex processes. Take, for example, the model of "supply and demand" 1, which in simple terms, describes how the cost of goods changes over time. More demand with the same supply will increase the price; more supply with less or the same demand decreases the price. This mental model has become so natural to us that talking about it seems trivial, but if I wanted to describe the economics of, let's say, hardware chips going from research to production to sales, I would need to dive into far more complex processes than mere supply and demand - yet the model is good enough to predict many use cases.

The first takeaway is that we use mental models for all of our thinking.

Unfortunately, models can be inaccurate or wrong. If we learn something new, our model is likely to be incorrect. That is fine as long as we continuously improve the model. The problem is that often we are not aware that we are using a model, even less so a wrong one. Having an inner image is so intrinsic that we don't realize that this image exists and that it might be wrong.

The second takeaway is that often, we are not aware that we use models at all, and worse, that we use wrong models.

Mental models are a "power" tool for efficient learning

A mental model is a tool that enhances our ability to think. As a physical tool enhances the human body's abilities (e.g. a bicycle amplifies the ability of my legs), mental tools extend brainpower.

What makes a good mental model? It is concise and ideally elegant so that it significantly simplifies the outer world without losing accuracy. The simpler the model, the easier it is for us to absorb it and make it our own.

The model enables us to make predictions. If I can simplify a model while the accuracy of my predictions stays the same, the simpler model is better.

But finding a good model is only the first step. When moving through the stages from beginner to expert, the changing purpose and context will make the best model inaccurate ("All models are wrong, but some are useful" 2). What matters more than the model itself is the ability to improve any model.

Taking an existing good mental model alone won't be sufficient. We can't just "copy-and-paste" the image into our brain and hope to gain understanding immediately. We still have to find meaning and have to "make it our own" (what I mean by that exactly is subject to another post). I believe improving the model requires deliberate practice and that having an accurate model can make learning vastly more efficient.

What would such a "practice" look like? The steps are something like the following:

1. Define. Be aware that you are using a model and make it visible. That can happen through writing, drawing diagrams, or teaching others. You have to express the model so you can actively measure and alter it.

2. Test. Find out where your model is wrong or not detailed enough. Do you encounter behavior that you can't explain? Has something unexpected happened? Those are the places that need work.

3. Improve. Increase the accuracy of the model. You have multiple options for doing that, depending on experience (are you a beginner or expert?), availability of resources, and how good the model is - more about this below.

4. Simplify or go deeper. Now that your model is primarily accurate, try simplifying it as much as possible. You can significantly increase leverage and deepen your understanding. Can you find a more elegant explanation? What parts of your model are essential, and which are superfluous? If you have reached a point where you can't make more gains, it is time to widen or go deeper. Switch the context.

How to learn efficiently and with confidence

With this in mind, we can answer the questions from above and solve the dilemma of how to best make use of the little we have available for learning.

If your model is mostly off, copy-and-paste answers from the internet will do little to improve understanding and likely cause more problems along the way. Instead, it is time to sit down and do step 2) from above: express your model and make it visible. Then learn the fundamentals (grab a book, watch a video, do an online course) and improve your model until you get to a stage where you can broadly explain behavior and make accurate predictions.

If you have done the above but still have not advanced much in your understanding, the next step is to get practical experience. Most likely, you need both: theory and practice. During your phase of gathering theoretical knowledge, you build your model. During practice, you test it with real-life situations.

If your model seems about right but has minor gaps, then look for quick answers. You will have a map where you can place the answer and are able to tweak your model.

If you feel you have hit a plateau and don't advance in your understanding while others seem to have a deeper grasp of things, you need to change the context of your challenge and go deeper. You likely need to create a new, more sophisticated model or come up with several related ones. Think like a scientist. Observe reality, make assumptions (which means formulate a model), and then run experiments to prove or disprove your model. Rinse and repeat.

If your model seems accurate but feels that you are generally slow and need to look up things often, then, and only then, is it time to memorize knowledge. This is the right time to, for example, learn the details of your Git CLI. Those commands that you keep forgetting. This requires practice. You may even use techniques like spaced repetition with flashcards (which can be helpful in any stage to deepen your internal models).

Mental models are overlooked in software engineering.

In software engineering, we lack good mental models. I see the reason for that in the fact that programming is an inherently practical exercise. Feedback loops are usually short - this is what makes programming such a satisfying experience. However, it can lead to a "just try things out until it works"-mentality without having gained a deeper understanding of how things work under the hood.

Also, as mentioned before, there is so much to learn that we simply don't have the time to look deeper. So we skip understanding the fundamentals. But this behavior is short-sighted because, in the long term, we become much faster and more productive once we have built a solid foundation of our knowledge.

The final takeaway is I'm convinced that having crisp mental models is by far the most significant leverage for becoming an efficient learner (and knowledge worker/software engineer). It lets you know where the gaps in your understanding are and what you need to do next. You can see what is essential and what is not. You can look beyond details and see the big picture, relieving you from the need to "cram" knowledge and rely on short-term memory.

For this reason, I created this site with the following two goals:

• describe mental models about selected subjects in software engineering (and related areas)

• and, more importantly, explore and investigate how to develop and improve mental models in general

I consider the second goal more valuable than the first (because knowing the model alone won't get you far, but if you can develop and improve your own models, you don't necessarily need an external model - though a good starting point can undoubtedly accelerate learning). Because of that, even though I mostly talk about mental models that occur in software engineering (because that is my day job), I do hope that anyone will benefit from this series.

Please subscribe if you want to keep up-to-date - or reach out if you'd like to share your thoughts.

Subscribe now

(*) Photo by Daniel McCullough