DEV Community: Amish Singh

The Docker Layer Duplication Penalty: Why Modifying Files in Old Layers Costs You Twice

Amish Singh — Sat, 22 Aug 2026 16:14:02 +0000

As modern backend developers, we all know the drill: Never run your containers as root. It's a massive security hazard.

To fix this, the intuitive workflow most of us learn is straightforward:

Copy your application code and virtual environments into the container as root.
Create a restricted, non-root system user profile.
Run a swift RUN chown -R appuser:appuser /app right at the bottom to hand over permissions.

It builds successfully. The app runs. You push it to production. Job well done, right?

Wrong. You just triggered a silent architectural tax known as the Layer Duplication Penalty.

Let's look at a live terminal discovery that catches Docker's layering engine red-handed, and see how trying to fix user permissions can either double your image size or silently brick your application.

The Accidental Discovery

While debugging a Python 3.13 production multi-stage build, I decided to pull back the sheets on the container layers using docker history. I built two different variations of the image: n-py (the standard layered approach) and m-py (a selective path "optimization" attempt).

Take a close look at the layer footprint from docker history n-py:latest:

IMAGE          CREATED         CREATED BY                                      SIZE
<missing>      3 minutes ago   COPY --chown=appuser:appuser . .                28.7kB
<missing>      3 minutes ago   COPY --chown=appuser:appuser /opt/venv /opt/…   91.7MB
<missing>      3 minutes ago   RUN /bin/sh -c chown -R appuser:appuser /opt…   91.7MB

Look at that double-take payload!

COPY /opt/venv enters the ring at 91.7MB (originally owned by root).
RUN chown -R appuser:appuser /opt/venv registers another 91.7MB right above it.

Because we ran a separate RUN chown command on a directory that was already frozen in a previous layer, Docker duplicated all 91.7MB of dependencies a second time just to alter the user metadata.

The Hazard "Optimization" Trap

Seeing this bloat, your immediate engineering instinct might be: "Fine, I'll just narrow the chown to my local app directory in the home folder, and leave the virtual environment alone — it's a system path anyway." It's a reasonable guess. It's also wrong, and it's worth walking through exactly why, because the failure mode it produces is worse than the bloat you started with.

That instinct creates image m-py:

IMAGE          CREATED         CREATED BY                                      SIZE
<missing>      4 minutes ago   COPY . .                                        28.7kB
<missing>      4 minutes ago   COPY /opt/venv /opt/venv                        91.7MB
<missing>      4 minutes ago   RUN /bin/sh -c chown -R appuser:appuser /hom…   28.7kB

The manual chown layer dropped from 91.7MB down to a microscopic 28.7kB. We bypassed the duplication penalty.

But there's a catch: because /opt/venv sits at the system root level (/opt/), the narrowed chown path never touches it. The 91.7MB virtual environment is still 100% owned by root. The moment the container switches to USER appuser and boots up, Python drops dead with a fatal PermissionError: [Errno 13] Permission denied, because a low-privilege user is trying to execute locked-down dependencies.

You're stuck with a brutal choice: double your image footprint, or silently brick your runtime.

Deep Dive: Why Modifications Pay a 100% Tax

To understand why Docker behaves this way, look at the Union File System (UnionFS). Docker images are stacked like immutable sheets of glass. Once a layer is built and sealed, it is permanent and read-only.

In Linux, file permissions and ownership (UID/GID) aren't separate config floating around — they're metadata baked directly into the filesystem blocks of the files themselves.

When you execute a RUN chown in a subsequent layer, Docker can't travel back in time to edit Layer 1. Instead, it triggers a Copy-on-Write (CoW) event:

Docker copies the files up from the frozen layer into the active layer.
It rewrites the filesystem metadata tags to match your new non-root user.
It uses a virtual filesystem overlay to hide the original root files underneath.

To your terminal, it looks like a clean modification. To your deployment bandwidth and disk space, the data now exists twice.

This is the same reason multi-stage builds help elsewhere but don't save you here on their own: a multi-stage build lets you drop an entire build stage's layers from the final image, but it doesn't make a layer's own contents editable once sealed. If you COPY as root in your final stage and chown afterward in that same stage, you pay the tax regardless of how clean your earlier stages are.

A quick note on why this doesn't apply to folders the same way it applies to files: in most Linux filesystems, a directory isn't a physical container of data — it's closer to a small index of names and pointers to where the actual data blocks live.

Adding a new file to an existing folder only requires a tiny record in the new layer.
Modifying an existing file's metadata — including ownership — costs 100% of that file's size, because the file's data blocks get copied up whole.

The Clean Solution: Inline Interception

You don't need to choose between bloat and instability. Intercept the permissions at the exact moment the data enters the container layer — BuildKit's inline --chown flag on COPY stamps files with the right ownership as they're written, so there's no separate modification layer to pay for.

A Fuller Before-and-After

The toy example above proves the mechanism, but real Dockerfiles have more going on — pinned base images, pip flags, hash-randomization settings. Here's the antipattern at full scale, the way it actually shows up in a production build:

# ❌ BEFORE — pays the duplication tax twice
FROM python:3.13-slim@sha256:ffb752e139c0a19692a43af8d8523b274222dd68eebad5d583b45c2201c6e30a AS builder
WORKDIR /build

ENV PIP_NO_CACHE_DIR=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1

RUN python3 -m venv /opt/venv
COPY requirements.txt .
RUN /opt/venv/bin/pip install -r requirements.txt


FROM python:3.13-slim@sha256:ffb752e139c0a19692a43af8d8523b274222dd68eebad5d583b45c2201c6e30a
WORKDIR /home/appuser/app

ENV PYTHONUNBUFFERED=1 \
    PYTHONFAULTHANDLER=1 \
    PYTHONHASHSEED=random \
    PATH="/opt/venv/bin:$PATH"

RUN useradd -U -m -s /bin/bash appuser

# Copied as root, with no ownership stamp — the tax gets paid later
COPY --from=builder /opt/venv /opt/venv
COPY . .

# Two RUN chown calls, each rewriting a frozen layer's files:
RUN chown -R appuser:appuser /home/appuser/app
RUN chown -R appuser:appuser /opt/venv

USER appuser
CMD ["python3", "main.py"]

That second pattern is worth calling out on its own: two separate RUN chown instructions, each one walking back over data that a previous COPY already froze into a layer. Every path you list there — the app directory and the venv — pays the full CoW tax independently. It's the same mistake as the single-chown case earlier, just spread across two commands instead of one, which makes it easy to miss in a longer Dockerfile. (Worth noting too: a bare RUN chown -R appuser:appuser with no target path isn't just wasteful, it's an invalid command — chown needs an operand to act on, and Docker will fail the build outright rather than silently doing nothing.)

Here's the same build with the tax removed:

# ✅ AFTER — ownership is stamped inline, nothing gets rewritten
FROM python:3.13-slim@sha256:ffb752e139c0a19692a43af8d8523b274222dd68eebad5d583b45c2201c6e30a AS builder
WORKDIR /build

ENV PIP_NO_CACHE_DIR=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1

RUN python3 -m venv /opt/venv
COPY requirements.txt .
RUN /opt/venv/bin/pip install -r requirements.txt


FROM python:3.13-slim@sha256:ffb752e139c0a19692a43af8d8523b274222dd68eebad5d583b45c2201c6e30a
WORKDIR /home/appuser/app

ENV PYTHONUNBUFFERED=1 \
    PYTHONFAULTHANDLER=1 \
    PYTHONHASHSEED=random \
    PATH="/opt/venv/bin:$PATH"

RUN useradd -U -m -s /bin/bash appuser

# Ownership is set as the bytes land — no separate RUN, no CoW event
COPY --from=builder --chown=appuser:appuser /opt/venv /opt/venv
COPY --chown=appuser:appuser . .

USER appuser
CMD ["python3", "main.py"]

Same base image, same pinned digest, same env vars — the only difference is where the ownership gets assigned. docker history on the "after" build shows no RUN chown line at all, because there's nothing left for it to do.

The Production Payoff

Check the history of the inline layout and the duplicate layer vanishes entirely. The virtual environment lands exactly once, already owned by appuser.

Because your non-root worker has native ownership over its /home workspace, Python can generate performance-boosting .pyc caches at runtime without hitting a permissions wall.

The Golden Rule of Layers

Docker layers are strictly cumulative, never subtractive or editable.

Additions are close to free.
Modifications — including ownership changes — pay a tax proportional to what they touch.

Run docker history <image_name> on your own images tonight. If you see redundant size payloads mirroring your COPY steps, swap them out for inline --chown flags. Your deployment pipeline, cloud bill, and cold-start times will thank you.

My Docker Build Was Slow Before It Even Started, Here's Why

Amish Singh — Thu, 20 Aug 2026 17:37:11 +0000

We build several independently deployed Python API services out of one monorepo — an image-processing service, a document service, a similarity service, and a handful of others. They all share a common/ package with GCP storage helpers, parallel download utilities, and other plumbing nobody wants to duplicate three times.

One afternoon I ran a build for image-service and watched this happen:

[internal] load build context
=> transferring context: 1.48GB

Ten seconds. Before a single line of the Dockerfile had executed. Ten seconds just to hand files to the builder.

That line is what sent me down the rabbit hole this post is about.

The Setup

Here's roughly what the repo looks like:

repository/
├── common/
│   ├── gcp/
│   │   ├── download.py
│   │   ├── upload.py
│   │   └── storage.py
│   └── utils/
│
├── services/
│   ├── image-service/
│   │   ├── Dockerfile
│   │   ├── src/
│   │   └── models/
│   │       └── model.bin        # ~1.5GB
│   │
│   ├── document-service/
│   │   ├── Dockerfile
│   │   └── src/
│   │
│   └── similarity-service/
│       ├── Dockerfile
│       └── src/
└── ...

image-service ships with a local ML model file baked into the repo (don't ask — legacy reasons). It needs two things to build: its own source, and common/. Simple enough, except those two requirements pull in opposite directions on how you'd normally structure a build.

Attempt 1: Repo Root as Context

The obvious move, since common/ lives at the top level, is to build from the repo root:

docker build -f services/image-service/Dockerfile .

This works. The Dockerfile can do COPY common/ /app/common because everything under the repo root — including common/, every other service, every model file, every .git object — is now part of the build context: the set of files the Docker client tars up and streams to the builder before a single instruction runs.

That's the part that tripped me up initially. I assumed context size and image size were basically the same problem. They aren't.

Build context is what gets sent to the daemon/builder as raw input. Image size is what actually ends up in the layers of the final image, after your Dockerfile's COPY/ADD/RUN instructions decide what to keep. You can have a 1.5GB context and a 200MB image, because the model file for document-service never gets copied into image-service's image at all — it's just sitting there, transferred over the wire, unpacked, and then ignored.

That transfer isn't free. Every docker build from repo root re-sends the entire context — including every other service's model files, .git history, virtualenvs, whatever — even though image-service only needs a fraction of it. That's where the 10-second, 1.48GB "transferring context" step came from. Not a slow build. A build that hadn't even started yet.

Attempt 2: Shrink the Context

So the next instinct: build from inside the service directory instead.

cd services/image-service
docker build .

Now the context is just image-service/ — no other services, no unrelated model files, no repo-wide .git. Fast, small, focused.

Except now common/ is gone. It's outside the build context entirely, and the Dockerfile has no way to reach it:

COPY ../../common /app/common

This fails, and it's worth understanding why rather than just memorizing "don't do that." A build context isn't just "the current directory" in some loose sense — it's a boundary. The Docker client only ever tars up and sends what's inside the context you pointed it at. Instructions inside the Dockerfile can't reach outside that boundary using ../ or any other path trick, because as far as the builder is concerned, nothing outside the context exists. It was never transferred. There's nothing to COPY from.

So we're stuck between two bad options:

Repo root as context → everything's reachable, but the context is huge and mostly irrelevant to any single build.
Service directory as context → fast and focused, but common/ is unreachable.

Attempt 3: The Temporary Directory Hack

The first real fix I reached for was filesystem manipulation. Stage a temporary directory that contains exactly what the build needs, and build from there:

/tmp/image-service-build/
├── Dockerfile
├── src/
├── models/
└── common/

A small shell script does the assembly:

#!/usr/bin/env bash
set -euo pipefail

BUILD_DIR=$(mktemp -d)

cp -r services/image-service/* "$BUILD_DIR/"
cp -r common "$BUILD_DIR/common"

docker build -t image-service -f "$BUILD_DIR/Dockerfile" "$BUILD_DIR"

rm -rf "$BUILD_DIR"

This works, and for a while it was our actual solution. But it bothered me. We were solving a build-input problem — "this build legitimately needs files from two different locations" — by physically rearranging the filesystem to fake a single location. It's copy-paste as architecture. Every service needs its own version of this script, and any deviation between the service's actual layout and what the script assembles becomes a silent, easy-to-miss bug.

There had to be a way to tell Docker directly: "the build needs inputs from two places," without lying to it about where those places are.

Attempt 4: Named Build Contexts

This is what BuildKit's named build contexts are for. Instead of forcing everything into one directory, you give the builder multiple, independently named sources for a single build:

docker build \
  --build-context common=./common \
  -f services/image-service/Dockerfile \
  services/image-service

Breaking this down:

services/image-service (the final positional argument) is the default build context — this is what unqualified COPY instructions read from.
--build-context common=./common registers an additional, named context called common, pointing at the common/ directory.
Nothing gets merged or copied on disk. Both contexts stay exactly where they are; the builder just knows about both of them now.

The Dockerfile then references each context explicitly:

FROM python:3.12-slim

WORKDIR /app

# reads from the default context: services/image-service/
COPY . /app

# reads from the named context: "common"
COPY --from=common . /app/common

RUN pip install --no-cache-dir -r requirements.txt

CMD ["python", "src/main.py"]

The key line is COPY --from=common . /app/common. Normally --from in a COPY refers to a previous build stage in a multi-stage build. With named build contexts, --from can also refer to a named context registered via --build-context. So this instruction means: "copy everything from the common context (i.e. ./common on disk) into /app/common in the image" — completely independent of whatever the default context is doing.

Conceptually, the build now looks like this:

Docker Build
├── default context
│   └── services/image-service/
│       ├── Dockerfile
│       ├── src/
│       └── models/
│
└── named context: common
    └── common/
        ├── gcp/
        └── utils/

Two separate, explicit inputs. No repo-root scan. No temp directory. No ../../ path traversal that the builder would reject anyway.

This is strictly better than the repo-root approach because the build now only ever sees what it actually asked for. document-service's model file, similarity-service's source, the .git directory — none of it is transferred, none of it is even considered, because it was never part of either context.

.dockerignore: Also About Context, Not Just Image Size

It's easy to think of .dockerignore as "the file that keeps junk out of my image." That's a side effect, not the main point. .dockerignore controls what enters the build context in the first place — before the Dockerfile ever runs, before any COPY decides what to keep.

A typical one for a service like this:

.git
__pycache__
.venv
*.log
tests/

The flow looks like:

Repository
    ↓
.dockerignore   (filters what gets read into the context)
    ↓
Build context   (what's actually sent to the builder)
    ↓
Dockerfile      (decides what from the context becomes image layers)
    ↓
Image

One thing worth being precise about: .dockerignore applies to the context it lives next to — it doesn't automatically reach across and filter every named context you register separately. If you have a .dockerignore in services/image-service/, it governs the default context (services/image-service/). It has no bearing on what gets sent from the common named context unless common/ has its own .dockerignore. Named contexts and .dockerignore solve two different questions:

.dockerignore answers: what files should be excluded from this context?
Named build contexts answer: what additional, explicitly named sources should this build consume at all?

One trims an input you already have. The other declares an input you didn't have before. They're complementary, not substitutes for each other.

The Insight That Actually Mattered

The deeper realization here wasn't really about Docker flags. It was this:

The repository structure and the build structure don't have to be identical.

The monorepo is organized the way developers want to navigate it:

repository/
├── common/
├── service-a/
├── service-b/
└── service-c/

But a given Docker build shouldn't default to "the repository" just because the Dockerfile happens to live somewhere inside it. A build should be scoped to its actual inputs:

image-service/
    +
common/

not

entire repository

This matters more as a monorepo accumulates the things monorepos tend to accumulate: multiple independently deployable services, shared libraries, ML models, generated files, frontend and backend projects living side by side, node_modules, datasets, test artifacts, documentation. None of that is relevant to any single service's build, and none of it should be treated as if it were just because it's reachable from the repo root.

What I Got Wrong Initially

A few assumptions I had to unlearn:

I thought the Dockerfile's location determined the build context. It doesn't — the context is whatever path (or paths) you point docker build at; the Dockerfile can live anywhere and be referenced with -f.
I treated "the repository" as the natural, default build context for anything inside a monorepo, mostly out of convenience.
I assumed a large context mainly mattered because it would produce a larger final image. It doesn't directly — context size and image size are separate concerns, linked only by what your COPY instructions choose to keep.
I saw the temp-directory copy trick as the only real workaround for cross-directory dependencies, because I didn't yet know named build contexts existed as a first-class BuildKit feature.

The Mental Model I Use Now

Before writing or changing a Dockerfile in this repo, I ask three questions:

What is my build context? Where am I telling docker build to look, and what does that actually include?
What are the actual inputs required by this build? Not "what's nearby," but what does this specific service genuinely need to compile and run?
Which files are unnecessary and should be excluded? Anything not required is a candidate for .dockerignore or for simply not being in the context in the first place.

In practice that translates to:

Default to a focused, service-scoped build context — not the repo root.
Use .dockerignore to keep incidental junk (caches, logs, test artifacts, VCS metadata) out of whatever context you do use.
Reach for named build contexts when a build legitimately needs files that live outside its natural directory — shared libraries, generated schemas, whatever.
Don't reach for repo-root-as-context just because it's the path of least resistance in a monorepo.

Final Picture

MONOREPO
│
├── common/
│
├── services/
│   ├── image-service/
│   ├── document-service/
│   └── similarity-service/
│
└── ...

For image-service specifically, the build only ever sees:

Docker Build
├── default context
│   └── image-service/
│
└── named context: common
    └── common/

Nothing else in the monorepo is transferred, scanned, or even visible to this build.

Key Takeaways

Build context size and final image size are different things — a huge context doesn't necessarily mean a huge image, but it does mean slower, wasteful transfers.
A Dockerfile can't reach outside its build context with ../ — the context is a hard boundary, not just "the current directory."
Named build contexts (--build-context name=path + COPY --from=name) let a single build pull from multiple, explicitly declared locations without merging anything on disk.
Temporary-directory staging scripts work, but they're a filesystem workaround for what's really a build-configuration problem.
.dockerignore filters its own context — it doesn't automatically apply to separately named contexts.
In a monorepo, the build context should represent the service's actual inputs, not the repository's overall layout.
Don't make your repository the build context by default. Make the build context represent the actual inputs required by the build.

The Recursive Mindset: Unlocking the Code You Already Know

Amish Singh — Thu, 21 May 2026 17:09:38 +0000

The Philosophy: Why This Article Exists

You might have opened a computer science textbook or scrolled through tutorials and hit a wall.

There are two traps that people fall into:

The Overly Academic Trap: Some platforms make concepts sound scary with formulas and jargon that leaves your questions unanswered.
The Hyper-Focused Scope Trap: Some tutorials teach you how to copy-paste code. Don't teach you how to think like a problem solver.

I wanted to change that. I think to master an algorithm you need to see how it relates to real life.

I am not going to oversimplify things.

My goal is to balance accuracy with engaging storytelling. I want anyone to be able to read this enjoy it and understand how things work.

When I tackle concepts I turn them into stories. Like a conversation between a Guide and a Learner in a coffee shop figuring things out from scratch. Code is details; the intuition is where the magic happens.

Welcome to a way of learning. Lets learn how to chew.

This series is my solution. Every time I tackle a technical concept I strip away the academic pretension and transform it into a story—a conversation between a Guide and a Learner sitting in a coffee shop figuring things out from scratch. Because code is the paperwork; the intuition is where the magic happens.

Welcome to a way of learning. Lets learn how to chew.

The Setup

The coffee shop is buzzing with the hum of espresso machines and light chatter. At a corner table sunlight streams across two filled notebooks, a couple of coffees and a single laptop open to a blank text editor.

There is no panic the quiet casual energy of two people hanging out ready to build something cool from scratch. The Guide takes a sip of their drink looks at the screen and smiles at the Learner.

Guide: You know there is something satisfying about a blank file. It is like a notebook. No bugs no logic. Just pure potential. How are you feeling about diving into the project today?

Learner: Honestly? I am excited. Of amused. I was looking at the syllabus for what we need to implement. The first topic is titled "The Divide and Conquer Paradigm." It sounds like programming and more like an emperor trying to take over Europe. I am just wondering why computer science loves making simple things sound so intensely academic.

Guide: The Guide laughs. You are not wrong. Academic textbooks have a talent for making intuitive ideas look like terrifying ancient runes.. What if I told you that you have been using the Divide and Conquer paradigm since you were a kid? You are actually already a master at the Divide and Conquer paradigm.

Learner: That is a claim. I am pretty sure I have not conquered any empires recently.

Guide: Maybe not empires,. Let us talk about street food. Imagine you and your sister walk up to your Pani Puri stall. You look at the bhaiya. Say, "Bhaiya, plate challenge. Give us 60 golgappas now."

Learner: The Learner laughs. Okay first of all if I try to shove 60 golgappas into my mouth at the time I will literally choke and explode.

Guide: Exactly. You physically cannot solve the "60 Golgappas" problem at once. The human brain.. Stomach. Short-circuits at that scale. So what actually happens? How do you and your sister eat the Divide and Conquer paradigm golgappas?

Learner: Well obviously we split the problem in at the start. I tell the bhaiya "Put 30 on her plate and 30 on my plate."

Guide: Boom. Step one done. You took a 60-unit problem. Split it into two identical 30-unit problems.. Wait can you eat 30 golgappas in one gulp?

Learner: No. I am a human, not a hole. Even the 30 on my plate is too big to handle in one go. So I ignore my sisters plate look at my 30 and the bhaiya starts serving them to me one by one. I take one golgappa crunch it swallow it and repeat.

Guide: Pause. Look at the magic of what happened.

You had a problem: Eat 60 Golgappas.

You split it into two problems: Eat 30 Golgappas.

How do you solve the 30? By breaking it down until you are dealing with the smallest most trivial version of the problem: Eat 1 Golgappa.

Can you eat 1 golgappa?

Learner: Easily. It is a bite.

Guide: Exactly. That single bite is what we call the Base Case in computer science. It is a problem you do not need to break it down anymore; you just solve it instantly.

Now what happens when you finish eating your 30 golgappas and your sister finishes eating her 30 golgappas?

Learner: The bhaiya wipes the counter counts the small bowls adds our two plates together and says, "Sahab, 60 ho gaye." The giant 60-golgappa problem is completely solved.

Guide: Look at what you did. You did not need a professor to teach you the Divide and Conquer paradigm. Your hunger naturally figured out the algorithm template in history. You followed a three-step ritual:

Divide: You took a problem. The Divide and Conquer paradigm.. Split it into two identical smaller versions of the same problem.
Conquer: You solved the problems by breaking them down all the way to the possible unit, which you can solve effortlessly.
Combine: You let the results of those bites gather up until the entire original mountain of food was gone.

In Computer Science we just call this the Divide and Conquer paradigm.

Learner: Wait. Seriously? So the Divide and Conquer paradigm is not a formula? It is literally just... Breaking a problem down into versions of itself until it is small enough to handle in one bite?

Guide: That is the rule. The sub-problems must be mirrors of the problem. Eating a golgappa is a version of eating a plate of golgappas.

When we write code like Merge Sort to sort a million numbers the computer does not try to sort all million at once. It panics, just like you did at the number 60. So it splits the million numbers in half. Then it splits those halves in half. It keeps splitting until it is looking at one number.. Sorting a number is as easy as eating a single golgappa. It is already done. Then it just merges them up.

Learner: Wow. Okay seeing it like that actually takes all the anxiety away. I have been executing algorithms every time I eat on the street. So of staring at a file wondering how to write a massive complex system I just need to ask myself: "What is the single-bite version of this problem?"

Guide: Precisely. You already have the intuition; we just need to teach your keyboard how to chew.

The Wrap-Up

Learner: Wait, no way. Look outside the sun is already setting. How did we spend three hours talking about pani puri?

Guide: Time flies when you are realizing you are smarter than the textbooks give you credit for.

Learner: Honestly I am glad we did not touch the keyboard yet. My brain feels full. In a way. For once I am actually looking forward to opening this file tomorrow.

Guide: You know there is a reason I wanted to start with this today. It is not, about passing your exams or writing efficient code.

Learner: What do you mean?

Guide: Think about it. When you looked at the syllabus earlier you felt that sudden weight of anxiety right? The "60 golgappas" of a curriculum. Life does that to us all the time. It throws a chaotic problem at your feet. A huge project, a relationship choice or a massive career decision.. Your brain panics. It freezes because it tries to swallow the 60-unit problem at once.

Learner: Yeah... That is what burnout feels like. Just staring at a mountain. Feeling paralyzed.

Guide: You know computer science isn't that complicated. It's actually pretty simple. Algorithms are a way to live your life. When things get really crazy you don't have to try to fix everything at. Just look at the mess find a way to make it smaller and ask yourself "What's one thing I can do now to make it better?"

The Living Algorithm

You don't fix your life at once. You start with one thing. You clear off one desk. You send one email. You take one breath. You deal with one thing in front of you trust that it will all work out and let the small wins add up over time. Don't be scared of a problem. If a computer can take a billion pieces of information and make sense of them you can take any problem. Break it down into one small step.

Learner: I never thought about it that way. I mean I've always thought of computer science as code but it actually makes sense for life too. What's the one thing I can do now to make this problem better?... Yeah I really needed to hear that.

Guide: . Grabs his backpack. I love it when people get it. When you look at things differently everything seems easier. Lets go the cafe is closing. I have my phone with me lets find a spot and play that game we've been putting off.

To be continued....