DEV Community: Javi Palacios

while loops in Python: repetition with a condition

Javi Palacios — Wed, 15 Jul 2026 08:05:48 +0000

Picture this: you ask the user to type a number between 1 and 10. You write the input, check with an if whether it's in range, and if it isn't... what do you do? Copy and paste the input five times and hope they get it right by the third try? No. What you need is a loop.

Loops are the solution when you need to repeat something without knowing exactly how many times. They're not the last tool you'll learn, but they're one of the most important. And in Python, the most fundamental one is while.

What is a while loop?

A while loop executes a block of code as long as a condition is true. When the condition becomes false, the loop stops. If the condition was already false from the start, the block never runs at all.

The structure is intentionally similar to if:

while condition:
    # This code repeats as long as the condition is True
    do_something()

Same colon. Same mandatory indentation. The difference is that instead of running once, the block keeps cycling until the condition is no longer met.

A concrete example: counting from 1 to 5.

counter = 1

while counter <= 5:
    print(counter)   # Print current count
    counter += 1     # Increment — or we'll be here forever

Every time Python reaches the end of the block, it goes back to the while header and re-evaluates the condition. When counter hits 6, 6 <= 5 is False and the loop ends.

There are three components that almost always appear together in a while:

Initialization — counter = 1 (before the loop)
Condition — counter <= 5 (in the header)
Update — counter += 1 (inside the loop)

Forget the third one and you have a problem. A pretty famous one.

The infinite loop: it's not a myth

If your while condition never becomes False, the loop doesn't stop. Ever. Your program stays stuck running that block forever — or until you kill it with Ctrl+C.

# ⚠️ Infinite loop — don't run this unless you enjoy Ctrl+C
x = 1
while x > 0:
    print(x)
    x += 1   # x keeps growing, condition never becomes False

Feeling a slight sense of dread? Good. That means you already understand why updating the control variable matters.

Infinite loops aren't always accidental. Sometimes you use them on purpose — more on that in a moment. But when it's not intentional, they usually come from one of these:

You forgot to update the control variable
You're updating it in the wrong direction
The exit condition is impossible to reach with your logic

The quickest way out in the terminal is Ctrl+C. And whenever your program seems frozen... there's probably a while True hiding somewhere.

break: exit on your terms

Sometimes you need to leave the loop before the condition goes false. That's what break is for: it stops the while immediately and jumps to whatever code comes after the loop.

number = 1

while number <= 10:
    if number == 6:
        break   # Exit loop immediately when we hit 6
    print(number)
    number += 1

print("Loop ended")

1
2
3
4
5
Loop ended

break really shines in the while True pattern, where the loop is designed to run indefinitely and the exit condition lives inside the block:

while True:
    answer = input("Do you want to continue? (y/n) ")
    if answer == "n":
        break   # The only way out
    print("Continuing...")

print("Program ended")

This pattern — while True with an inner break — is completely legitimate and very common for menus, games, or anything that keeps going until the user decides to stop.

continue: skip one iteration

continue is break's smaller sibling. Instead of exiting the loop, it jumps back to the start of the next iteration — re-evaluates the condition and picks up from there if it's still true.

number = 0

while number < 10:
    number += 1
    if number % 2 == 0:
        continue   # Skip even numbers
    print(number)

When number is even, continue sends Python straight back to the while header without executing print. Only the odd numbers make it through.

A warning about continue: make sure the variable update happens before the continue. Look at what happens when it doesn't:

# ⚠️ Infinite loop — number never increments when it's even
number = 0
while number < 10:
    if number % 2 == 0:
        continue   # Jumps back before number += 1... forever
    number += 1
    print(number)

When number is 0 (even), continue fires before number += 1 has a chance to run. Next iteration, number is still 0. And the next. And the next. Instant infinite loop, even though it doesn't look like one at first glance.

Real-world use cases

while shines in situations where you don't know in advance how many repetitions you'll need. A few common patterns:

Validating user input

while True:
    age = input("Enter your age: ")
    if age.isdigit() and int(age) >= 0:
        age = int(age)
        break   # Valid input, exit loop
    print("Please enter a valid number.")

print(f"Your age is {age}.")

The loop keeps asking until the user gives something valid. Doesn't matter how many attempts it takes.

Counter with a business condition

attempts = 0
max_attempts = 3
correct_password = "python123"

while attempts < max_attempts:
    password = input("Enter your password: ")
    if password == correct_password:
        print("Access granted.")
        break
    attempts += 1
    remaining = max_attempts - attempts
    if remaining > 0:
        print(f"Wrong password. You have {remaining} attempts left.")

if attempts == max_attempts:
    print("Too many failed attempts. Account locked.")

This is the kind of logic behind any login form. The while controls the attempts; the break exits on success; the final if handles total failure.

Guessing game

import random

secret_number = random.randint(1, 100)  # Random number between 1 and 100
attempts = 0

print("Guess the number between 1 and 100.")

while True:
    try:
        guess = int(input("Your guess: "))
    except ValueError:
        print("That's not a number.")
        continue

    attempts += 1

    if guess < secret_number:
        print("Too low.")
    elif guess > secret_number:
        print("Too high.")
    else:
        print(f"Correct! You got it in {attempts} attempts.")
        break

Here the while True has no explicit exit condition in the header — the only way out is the break inside the else. Until the user guesses the number, the game keeps going.

while vs for: when to use each

If you've used other languages, you're probably already wondering when to pick while and when to pick for. Spoiler: you'll learn for loops in the next tutorial, and they're the preferred choice whenever you know how many iterations you want.

The rule is straightforward:

while: when the stopping condition depends on something that can change unpredictably (user input, network data, game state...)
for: when you're iterating over a sequence of known length (a list, a range of numbers, a file...)

If you can phrase it as "repeat this N times" or "go through this list", use for. If you're thinking "keep doing this until something happens", use while.

You now know how to make Python both make decisions and repeat code in a controlled way. The natural next step is the for loop — more predictable, more expressive for most everyday iteration, and the one you'll reach for most often in real Python code. You'll also meet range(), which turns numbers into iterable sequences without having to manage counters by hand.

Never stop coding!

💡 Challenge: Write a guessing game where the user has exactly 5 attempts to guess a number between 1 and 20. After each failed attempt, tell them whether their guess is too high or too low. When the 5 attempts are up without success, reveal the secret number. Bonus: track how many attempts they used when they win, and congratulate them with a different message depending on whether they got it in 1, 2–3, or 4–5 attempts.

Interactive containers and exec: get inside, run commands, get out

Javi Palacios — Tue, 14 Jul 2026 12:02:36 +0000

Up until now, you've been treating containers like vending machines: put in a coin, take the snack, walk away. That's fine for learning the basics, but the moment something breaks in a real environment — and it will — you're going to need to open the machine and look inside.

That's what docker exec and interactive mode are for. And once you're comfortable with them, you'll realize they're probably the commands you'll reach for most.

Interactive mode: what `-it` actually means

When you see docker run -it, those two letters aren't a typo or a habit. They're two separate flags:

-i (interactive): keeps stdin open, even if you're not attached to it
-t (tty): allocates a pseudo-terminal so the session behaves like a real shell

On their own, neither does much. Together, they give you something that looks, feels, and behaves like a proper terminal session inside the container. Without them, the process either starts and immediately exits, or sits waiting for input you can't give it.

# With -it: you get an interactive shell
docker run -it ubuntu bash

root@7a2f1d3c9e4b:/#

You're in. That thing before /# is the container ID. Now you can run anything:

root@7a2f1d3c9e4b:/# ls /etc
root@7a2f1d3c9e4b:/# cat /etc/os-release
root@7a2f1d3c9e4b:/# apt-get update
root@7a2f1d3c9e4b:/# exit

When you type exit, the main process of the container — bash, in this case — terminates. The container stops. It doesn't disappear, but it's no longer running.

This is the key mental model: the container's lifecycle is tied to its main process. When bash exits, the container stops. This feels obvious in retrospect, but it trips people up the first few times.

Detached mode: the `-d` you already know

The opposite of interactive mode is detached mode (-d). The container starts in the background and you get the control back immediately. Perfect for services that are supposed to run indefinitely: web servers, databases, message queues.

# Without -d: process stays in the foreground, locks your terminal
docker run nginx

# With -d: starts in the background, returns control
docker run -d --name my-nginx nginx

3f4e5d6c7b8a9e1f2d3c4b5a6e7f8d9c

That hash is the full container ID. Your terminal is free. The container is running, serving HTTP on its internal port 80 — though nobody outside Docker can reach it yet. That's what port mapping is for, and we'll get there next lesson.

To verify it's running:

docker ps

CONTAINER ID   IMAGE   COMMAND                  CREATED         STATUS        PORTS   NAMES
3f4e5d6c7b8a   nginx   "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds   80/tcp  my-nginx

`docker exec`: get inside a running container

Here's the one you'll use most. docker exec runs an additional command inside an already-running container, without stopping or restarting it.

# Open a bash shell in the already-running my-nginx container
docker exec -it my-nginx bash

root@3f4e5d6c7b8a:/#

The difference from docker run -it is worth making explicit:

docker run -it creates a new container and drops you inside it
docker exec -it enters an existing container that's already running

When you exit from a docker exec session, the container keeps running. The main process — Nginx, in this case — hasn't been touched. You just closed the extra shell you'd opened on the side.

Common exec patterns

# Inspect Nginx's config file
docker exec -it my-nginx cat /etc/nginx/nginx.conf

# Open a bash shell to poke around
docker exec -it my-nginx bash

# Some containers don't have bash — sh is always there
docker exec -it my-alpine sh

# Check the environment variables of the running process
docker exec my-nginx env

# See what processes are running inside
docker exec my-nginx ps aux

# Install something for a one-off debugging session
docker exec -it my-nginx bash -c "apt-get update && apt-get install -y curl"

⚠️ Anything you install inside a running container with exec disappears when the container is removed. If you need something to be there permanently, it goes in the Dockerfile. exec is for inspection and debugging only.

`exec` without `-it`

You don't always need the interactive flags. If you just want to run a command and see the output, skip them:

# Run a command and see the output directly
docker exec my-nginx nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Without -it, the command runs, prints its output, and exits. No interactive shell, no pseudo-terminal. This is the form you'd use in scripts or CI pipelines.

The Alpine trap: bash vs sh

This one will catch you off guard eventually. Not all images have bash. Alpine-based images — which are wildly popular because of their tiny size — ship with sh only:

# ❌ This fails on an Alpine image
docker exec -it my-alpine-container bash

OCI runtime exec failed: exec: "bash": executable file not found in the PATH

# ✅ Use sh instead
docker exec -it my-alpine-container sh

If you genuinely need bash in Alpine for something:

docker exec -it my-alpine-container sh -c "apk add bash && bash"

Honestly though, sh covers 99% of what you'll need during an inspection session.

Copying files with `docker cp`

Sometimes you don't need to enter the container — you just need to get a file out (or put one in). docker cp copies files between the host filesystem and a container's filesystem.

From container to host

# Copy Nginx's config file out of the container to your local machine
docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf

Useful for: grabbing a config you want to inspect and edit locally, pulling out logs generated inside the container, extracting build artifacts.

From host to container

# Copy a local file into the running container
docker cp ./my-config.conf my-nginx:/etc/nginx/conf.d/custom.conf

And then reload without restarting the container:

docker exec my-nginx nginx -s reload

`docker cp` vs volumes

docker cp is a one-off tool — great for debugging, for pulling a file out of a live container, for quick one-time injections. For ongoing file sync between host and container (like your application source code during development), you want volumes. Volumes are the right mechanism for that, and we'll cover them later in the course.

Think of docker cp as the Swiss Army knife. Volumes are the power tools.

Seeing what's happening: logs and inspect

Two more commands that pair naturally with exec:

`docker logs`

# See all logs from the container
docker logs my-nginx

# Follow logs in real time (like tail -f)
docker logs -f my-nginx

# Show only the last 50 lines
docker logs --tail 50 my-nginx

# Add timestamps
docker logs --timestamps my-nginx

`docker inspect`

While logs tells you what's coming out, inspect tells you everything about how the container is configured: environment variables, port mappings, mounted volumes, the network it's connected to, the image it came from:

docker inspect my-nginx

It returns a large JSON blob. Use jq to extract what you need:

# Check environment variables
docker inspect my-nginx | jq '.[0].Config.Env'

# Check the image ID
docker inspect my-nginx | jq '.[0].Image'

# Check the container's current state
docker inspect my-nginx | jq '.[0].State'

A typical debugging workflow

Here's what all of this looks like in practice when something's broken:

# 1. Container is running but something's wrong
docker ps
docker logs --tail 100 -f my-app

# 2. Logs aren't enough — enter the container to inspect
docker exec -it my-app bash

# 3. Inside the container, investigate
root@abc123:/# ls /var/log/
root@abc123:/# cat /var/log/app.log
root@abc123:/# env | grep DATABASE

# 4. Found a config file worth looking at — exit and pull it out
root@abc123:/# exit
docker cp my-app:/app/config.json ./config.json

# 5. Edit it locally, push it back in
docker cp ./config.json my-app:/app/config.json

# 6. Reload the process without restarting the container (if the app supports it)
docker exec my-app kill -HUP 1

This is what makes Docker genuinely useful for debugging: you can get in, look around, modify, and reload without taking the service down.

With docker exec, -it, and docker cp in your toolkit, you can actually interact with your containers rather than just launching them and hoping for the best. The ability to step inside a running container and see exactly what's happening is what separates someone who "uses Docker" from someone who understands it.

Next up: port mapping — how to make a service running inside a container accessible from your browser or from other processes outside Docker. This is where containers start feeling truly useful for building real applications.

Never stop coding!

💡 Challenge: Start an Nginx container in detached mode. Use docker exec to open a bash shell inside it. Copy /etc/nginx/nginx.conf to your machine with docker cp. Change worker_processes auto; to worker_processes 2;, push the file back into the container, and reload with docker exec my-nginx nginx -s reload. Verify the configuration is valid using docker exec my-nginx nginx -t.

Cherry-picking commits in Git

Javi Palacios — Mon, 13 Jul 2026 11:34:46 +0000

Production is down. There's a null pointer exception in the payment service and your on-call rotation landed on a Tuesday. You know exactly where the fix is: that commit from three days ago on feature/payments, the one called "Fix null pointer in payment service." The problem? That branch is a warzone — an unfinished refactor, a half-baked API that breaks half the existing code, and at least two commits named "wip" (there are always at least two commits named "wip"). Merging that branch into main would be like performing surgery by dropping a bowling ball on the patient.

You don't need the whole branch. You need that one commit.

That's exactly what git cherry-pick is for.

What is cherry-pick?

Think of your Git history as a playlist. Branches are playlists, commits are individual tracks. A merge is like saying "add this entire album to my playlist." A rebase is like moving your songs so they come after a different album. git cherry-pick is you pulling a single track from someone else's playlist and adding it to yours — without subscribing to their whole discography.

The mechanics: Git takes the diff introduced by that specific commit (what changed between it and its parent), and replays that diff on top of your current branch as a brand-new commit. Same content, different hash. The original commit stays exactly where it was. You just get a copy of the change.

That's worth repeating: the new commit gets a new hash. We'll come back to why that matters.

Basic usage

First, find the hash of the commit you need. Run git log on the source branch:

git log feature/payments --oneline

a3f9c12 Fix null pointer in payment service
b7e4d89 WIP: new payment gateway integration
c2a8f01 Refactor billing module (incomplete)
d6c3b47 Add payment model

There it is — a3f9c12. Switch to your target branch and apply it:

git switch main
git cherry-pick a3f9c12

[main 9b1d4e3] Fix null pointer in payment service
 Date: Mon Apr 14 18:32:01 2026 +0200
 1 file changed, 3 insertions(+), 1 deletion(-)

That's it. The fix is in main. The other fourteen commits are still sitting on feature/payments, waiting to be ready. Production breathes again.

Cherry-picking multiple commits

Sometimes one commit isn't enough. You have two options.

Individual commits

Pass multiple hashes in the order you want them applied:

git cherry-pick a3f9c12 d6c3b47 e1f2a03

Git applies them one by one, in that order. If any of them causes a conflict, it stops and waits for you to sort it out before continuing.

A range of commits

If the commits you need are consecutive, use range syntax:

git cherry-pick a3f9c12..e1f2a03

⚠️ Watch out: this syntax is exclusive on the left. a3f9c12..e1f2a03 applies every commit after a3f9c12 up to and including e1f2a03. If you also want a3f9c12 itself, use the ^ suffix:

git cherry-pick a3f9c12^..e1f2a03

This catches everyone exactly once. File it under "Git syntax that looks like line noise but actually makes sense once you've been burned by it."

Useful flags

`-n` / `--no-commit`: stage without committing

git cherry-pick -n a3f9c12

Git applies the changes to the staging area but doesn't create a commit. Useful when you want to combine changes from multiple commits into a single one, or when you want to inspect what's about to happen before pulling the trigger:

git cherry-pick -n a3f9c12 d6c3b47
git status              # review staged changes
git commit -m "Apply payment fixes from feature branch"

`-e` / `--edit`: edit the message before committing

git cherry-pick -e a3f9c12

Opens your editor with the original commit message so you can modify it. Handy when the original said "fix" and you want something that actually describes what was fixed.

`-x`: record where the commit came from

git cherry-pick -x a3f9c12

Appends a line to the commit message pointing back to the original:

Fix null pointer in payment service

(cherry picked from commit a3f9c12b3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8)

Free traceability. Six months from now, when someone's auditing release/1.x and wondering why a commit clearly born on a feature branch is sitting there, the message explains itself. In projects with multiple maintainers or multiple active release branches, -x is effectively mandatory. Use it.

Handling conflicts

Cherry-pick isn't always painless. If the changes you're bringing in touch the same lines that have changed in the target branch since the original commit was made, you'll get a conflict. Here's where things get fun (and by "fun" I mean mildly annoying, but entirely manageable).

When Git hits a conflict mid-cherry-pick, it stops and tells you:

error: could not apply a3f9c12... Fix null pointer in payment service
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

The resolution flow is the same as merge or rebase conflicts:

# 1. Open the conflicting files, resolve manually
# (look for <<<<<<< / ======= / >>>>>>> markers and choose what stays)

# 2. Mark the conflict as resolved
git add src/services/payment.ts

# 3. Continue
git cherry-pick --continue

If the commit you're trying to apply already exists in the target branch (maybe it was merged in earlier), Git might try to apply an empty diff. In that case:

git cherry-pick --skip   # skip this commit and continue with the rest

And if you want to back out entirely and pretend this never happened:

git cherry-pick --abort  # back to square one, no harm done

Don't stress about conflicts — they're unavoidable when you're moving code between branches with diverged histories. Resolve them carefully, verify the result compiles and passes tests, then carry on.

Real-world scenarios

Backporting a hotfix to release branches

You maintain v1.x and v2.x in production. A security vulnerability surfaces and you fix it on main. Both versions need the patch, but you absolutely don't want to push all of main into either release branch:

# Fix is on main as commit f4e3d2c
git switch release/1.x
git cherry-pick -x f4e3d2c

git switch release/2.x
git cherry-pick -x f4e3d2c

The -x flag leaves a paper trail in both branches. This is backporting — carrying fixes backward in time without merging entire version lines. Cherry-pick is the standard tool for it, and it handles this use case extremely well.

Rescuing commits from a dead branch

You've been on a refactoring branch for weeks. The scope ballooned, priorities shifted, and the branch isn't going anywhere. But it has two commits — utility functions, an HTTP client abstraction — that you genuinely want to keep. Those commits deserve better than dying with the branch.

git log feature/big-refactor --oneline | head -20

7a9b1c2 Add generic retry helper
8b0c2d3 Extract HTTP client abstraction
c1d3e4f Refactor entire codebase (never mind)
...

git switch main
git cherry-pick 7a9b1c2 8b0c2d3

The branch closes. The useful work survives. Everything else disappears without drama. If you're like me when I started, you probably assumed losing a branch meant losing everything in it — cherry-pick makes it easy to be selective about what's worth saving.

When NOT to use cherry-pick

Cherry-pick is sharp, precise, and genuinely useful — which makes it tempting to reach for it in situations where it's the wrong tool. Using it wrong leaves you with a duplicate-commit-infested history, perpetual conflicts, and teammates giving you looks in standup.

Don't use cherry-pick when you need a full merge or rebase.

If a feature branch is done and ready to integrate, use git merge or git rebase. Cherry-picking commit by commit is slow, error-prone, and destroys the natural traceability of your history:

# ❌ Pulling in an entire feature one commit at a time
git cherry-pick a1b2c3d e2f3a4b f3a4b5c g4b5c6d h5c6d7e

# ✅ Integrating the feature properly
git merge feature/my-feature
# or
git rebase feature/my-feature

Don't use cherry-pick as a branch synchronization strategy. If you find yourself cherry-picking the same commits across three different branches on a regular basis, you don't have a Git problem — you have a branching strategy problem. That's a different conversation.

The duplicate hash problem. When you cherry-pick a commit, Git creates a new commit with the same content but a different hash. If you later merge the original branch, Git sees those changes as new and tries to apply them again — leading to conflicts or outright duplicates. The longer those branches coexist, the worse this gets. The rule is simple: use cherry-pick for specific, one-off situations (hotfixes, rescues, backports). Don't make it your routine synchronization mechanism.

Cherry-pick is the scalpel of Git: precise, effective, and the wrong choice when what you actually need is a shovel. For hotfixes, backports, and rescuing useful work from abandoned branches, nothing beats it. For integrating complete features, merge and rebase do the job with far less collateral damage.

In the next tutorial we'll look at git reflog — Git's internal diary that records every movement of every reference, including ones you've deleted. If you've ever reset --hard to the wrong commit, deleted a branch by accident, or stared at an empty working tree wondering what you just did, reflog is your safety net. We'll cover how to read it, how to navigate it, and how to recover work that feels permanently gone.

Never stop coding!

Interactive Rebase in Git: Edit Your History Like a Pro

Javi Palacios — Sat, 11 Jul 2026 22:15:23 +0000

You've been working on a feature for two days. Twelve commits. One says "fix", another "more fixes", one says "ok now it works", and three in a row say "wip". When you open the pull request, your history looks like a novelist's rough draft, not the work of a professional.

You can clean that up before anyone sees it.

git rebase -i — interactive rebase — gives you full control over your commits: you can reorder them, combine them, rename them, split them, or delete them entirely. All before they land in the shared history. It's like having editorial rights before publishing.

What is interactive rebase?

Interactive rebase is git rebase with the -i flag (for interactive). Instead of replaying commits automatically, Git opens an editor with a list of your commits and lets you decide what to do with each one.

The most common invocation:

git rebase -i HEAD~n

Where n is how many commits back you want to review. To edit the last five:

git rebase -i HEAD~5

Git will open your configured editor (vim, nano, VS Code, whatever you have) with something like this:

pick a1b2c3d Add login form
pick b2c3d4e Add password validation
pick c3d4e5f fix
pick d4e5f6a wip
pick e5f6a7b ok now it works
pick f6a7b8c Add remember me option
pick g7b8c9d fix typo
pick h8c9d0e tests
pick i9d0e1f more fixes
pick j0e1f2a final wip
pick k1f2a3b Add logout button

# Rebase 9f8e7d6..k1f2a3b onto 9f8e7d6 (11 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, and meld into previous commit
# f, fixup <commit> = like "squash" but keep only the previous commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# ...

The list shows commits oldest to newest — the opposite of git log. This trips everyone up the first few times. Yes, it's counterintuitive. No, there's nothing you can do about it.

The main operations

Each line starts with an action (defaulting to pick) followed by the hash and commit message. You change the action in the editor, save, close, and Git does the work.

pick: keep as-is

pick a1b2c3d Add login form

Leave it alone. The commit stays exactly as it is. The default action.

reword: change only the message

reword c3d4e5f fix

Git applies the commit but pauses to let you edit the message. The content doesn't change, only the text. Perfect for those "fix" or "wip" messages that scream "I had no idea what I was doing" in production history.

squash: combine with the previous commit

pick a1b2c3d Add login form
squash b2c3d4e Add password validation

Git combines b2c3d4e into a1b2c3d and opens an editor for you to write the final commit message. You can keep both messages, discard one, or write a new one from scratch.

fixup: combine and discard the message

pick a1b2c3d Add login form
fixup c3d4e5f fix
fixup d4e5f6a wip

Like squash, but automatically discards the absorbed commit's message. It disappears without a trace, no editor, no questions asked. It's the mode for: "I want this change to exist, but I don't want anyone to know it took me three attempts."

drop: delete the commit

drop d4e5f6a wip

The commit and all its changes vanish. Use with care — the code it contains is gone. If in doubt, use squash or fixup instead.

edit: stop to amend

edit b2c3d4e Add password validation

Git applies the commit and pauses so you can modify it: add forgotten files, change code, or even split it into multiple commits. When you're done:

git rebase --continue

A complete example

Start with this disaster:

pick a1b2c3d Add login form
pick b2c3d4e fix
pick c3d4e5f wip
pick d4e5f6a Add password validation
pick e5f6a7b fix typo
pick f6a7b8c Add remember me option

What we want:

Combine b2c3d4e (fix) into a1b2c3d (login form)
Combine c3d4e5f (wip) into the login form as well
Give e5f6a7b (fix typo) a proper message
Leave the rest alone

Edit the file:

pick a1b2c3d Add login form
fixup b2c3d4e fix
fixup c3d4e5f wip
pick d4e5f6a Add password validation
reword e5f6a7b fix typo
pick f6a7b8c Add remember me option

Save and close. Git:

Applies a1b2c3d
Silently absorbs b2c3d4e and c3d4e5f
Applies d4e5f6a
Applies e5f6a7b and opens the editor — you write "Fix email validation regex"
Applies f6a7b8c

Result:

* f6a7b8c Add remember me option
* e5f6a7b Fix email validation regex
* d4e5f6a Add password validation
* a1b2c3d Add login form

Four clean commits where there were six. The history now tells what you did, not how many tries it took.

Reordering commits

Interactive rebase also lets you change the order. Just move the lines in the editor:

# Original
pick a1b2c3d Add login form
pick d4e5f6a Add password validation
pick f6a7b8c Add remember me option

# Reordered: password validation before the form
pick d4e5f6a Add password validation
pick a1b2c3d Add login form
pick f6a7b8c Add remember me option

Keep in mind that if commits depend on each other (the second one modifies a file the first one creates), reordering them can cause conflicts. Git will let you know if that happens.

Splitting a commit into multiple

Sometimes the opposite problem: a monolithic commit that mixes too many things. The edit mode lets you break it apart:

git rebase -i HEAD~3
# Mark the commit you want to split as: edit

When Git stops at that commit:

# Undo the commit but keep the changes in the working directory
git reset HEAD^

# Now commit in logical chunks
git add src/auth/login.ts
git commit -m "Add login form component"

git add src/auth/validation.ts
git commit -m "Add email and password validation"

# Continue the rebase
git rebase --continue

Where there was one "Add auth stuff" commit, there are now two specific, focused commits.

Autosquash: automating the cleanup

If you already know a commit is going to be a fix for a previous one, you can create it with a special format from the start:

# Create a commit that will be auto-squashed onto abc123
git commit --fixup abc123

# Or onto the last commit
git commit --fixup HEAD

This creates a commit with the message fixup! Add login form. When you later run interactive rebase with --autosquash:

git rebase -i --autosquash HEAD~5

Git automatically moves the fixup! commits next to their target and assigns them the fixup action. You just confirm the order and close the editor.

It's the most efficient workflow if you have the discipline to use it from the start.

When to use interactive rebase

Interactive rebase is your pre-PR tool. The question to ask yourself: does this history help anyone who comes after me?

Do you have "wip", "fix", "temp", "asdf" commits? → fixup or squash
Are your commit messages vague or misleading? → reword
Does one commit mix unrelated things? → edit + reset + re-commit in pieces
Are commits in the wrong logical order? → reorder the lines

What you don't want to do is use interactive rebase on commits you've already pushed to a shared branch. The golden rule of rebase applies here the same as anywhere: branches that are only yours, yes; branches others have cloned, never.

Interactive rebase is one of those tools that feels intimidating at first — you open the editor, see a list of cryptic commands, and think "I'm going to break something here." But with a bit of practice it becomes a habit. A clean history isn't vanity: it's documentation. It's the context someone is going to need six months from now to understand why the code is the way it is.

In the next lesson we'll look at cherry-pick: how to take a specific commit from any branch and apply it to another without merging everything. It's the perfect tool for when you have a critical fix buried in a feature branch and need to get it to production now.

Never stop coding!

AI for Programming: The Paradigm Shift

Javi Palacios — Sat, 11 Jul 2026 12:47:02 +0000

Picture this: it's 2019. You're a mid-level developer. You spend your mornings writing boilerplate, your afternoons debugging stack traces, and your evenings on Stack Overflow trying to remember the exact syntax for a thing you've done a dozen times before. That was the job. Nobody thought it was weird — it was just how programming worked.

Now it's 2026. The boilerplate is gone in thirty seconds. Stack traces get explained in plain English. That CRUD endpoint you used to spend a morning on? Twenty minutes with good context and a decent prompt. The job hasn't disappeared — it's been compressed. And that compression creates a gap between people who adapted and people who are still typing like it's 2019.

This tutorial is about that gap. Not the tools — we'll get to those. The mental model. Because without the right mental model, even the best tools become a crutch instead of a multiplier.

The old way vs the new way

Let's be concrete about what changed, because "AI changes everything" is meaningless without examples.

The 2019 workflow, if you were building a REST endpoint:

1. Recall the framework syntax (or search for it)
2. Type the boilerplate — route definition, middleware, validation
3. Write the business logic
4. Write the error handling
5. Write the tests (if you wrote tests)
6. Document it (if you documented)
7. Realize you missed an edge case, loop back to 3

The 2026 workflow:

1. Describe the intent clearly to the AI
2. Review what it generates — actually understand it
3. Test it against your real requirements
4. Adjust and verify

The bottleneck shifted. Before, it was typing and recall. Now it's clarity of specification. If you can't explain what you want precisely enough for another intelligent entity to implement it, the AI won't save you — it'll generate something plausible-looking that solves the wrong problem.

That's not a limitation of the AI. That's the job now.

You're becoming an engineering director

Here's the analogy that makes this click for most people.

Imagine you've just been promoted. You used to write code all day. Now you have a team of developers — smart, fast, eager to help — and your job is to direct them effectively. You still need to understand the code deeply: you review it, you spot problems, you make architectural decisions. But you're not the one typing every line.

Working with AI is exactly that dynamic. The AI is the developer. You're the director.

Engineering director without AI:
→ "Why is the auth failing?" → looks through logs → reads code → finds the bug → fixes it

Engineering director with AI:
→ "Why is the auth failing?" → shows logs + relevant code to AI → AI explains root cause → director evaluates → directs the fix

What doesn't change: you still need to understand what the bug is. You still need to evaluate whether the fix makes sense. You still own the decision. The AI accelerates the mechanical parts — reading through 300 lines to find the one that matters, generating the corrected version, suggesting where to add a test.

What changes: the ratio of time spent thinking versus time spent typing shifts dramatically in favor of thinking. And thinking clearly about problems turns out to be the part nobody automated.

The new bottleneck: specification

There's a concept in software engineering called Garbage In, Garbage Out. It was coined for databases, but it describes AI interaction perfectly.

An AI is not a mind reader. It doesn't know your codebase, your team's conventions, your performance requirements, or that you have a legacy service that uses a slightly non-standard error format. It only knows what you put in the context window.

The quality of the output is bounded by the quality of the input. Always.

Watch how different these prompts are:

❌ Weak specification:
"Write a function to validate email addresses."

✅ Strong specification:
"Write a TypeScript function that validates email addresses. It should:
- Return a boolean
- Follow RFC 5322 (standard format, no exotic edge cases)
- Reject addresses over 254 characters (per spec)
- Reject addresses with consecutive dots in the local part
- NOT use external libraries — just regex and length check

We're on Node.js 22, TypeScript 5.4 strict mode.
The function will be called thousands of times per second in a hot path,
so avoid any allocations we don't need."

The first prompt gets you a function. The second gets you the function you actually need. The difference isn't the AI's capability — it's your ability to say what you want.

This is the skill that compounds. The developer who can write the second prompt consistently will extract ten times more value from AI than someone who writes the first one, regardless of which model they use.

Delegation without abdication

Here's where a lot of developers stumble: they treat AI as either a magic oracle they trust blindly, or a toy they use for trivial things and never for anything real. Both are wrong.

The right mental model is delegation with ownership.

When you delegate to a colleague, you don't stop being responsible for the outcome. You describe what you need, you check the work, you integrate it, you own it. Delegating doesn't mean disappearing from the loop.

Same with AI. The rule that matters:

Never merge AI code you don't understand.

Not "review it quickly." Not "it looks right." Understand it. If you can't explain in plain English what a piece of code does and why it's correct, you haven't reviewed it — you've rubber-stamped it. And when it breaks in production at 3 AM, "the AI wrote it" is not a defense.

This is especially important for developers early in their career. The paradox is brutal: AI helps the most with the mechanical parts of coding, which is exactly the part that builds foundational understanding when you're learning. If you skip the understanding because "the AI already did it," you build speed without foundations. That works until it doesn't, and when it stops working, it stops working hard.

What's worth delegating (and what isn't)

Not all tasks are equal. Here's the practical breakdown after two years of industry data:

High-value delegation

Boilerplate and scaffolding: This is the clearest win. Setting up a new service, creating data transfer objects, writing CRUD endpoints, configuring test infrastructure — tasks that are repetitive and well-defined. AI does these well because there's a massive amount of training data showing exactly how they should look.

Explaining unfamiliar code: You join a new project. There's a 200-line function with no comments, written two years ago, by someone who left the company. Give it to the AI: "explain what this function does, what it assumes about its inputs, and what could go wrong." You'll understand it in two minutes instead of twenty.

Writing tests: Counterintuitive for many people, but AI is genuinely good at this. Give it a function, ask for edge cases, ask for tests that cover those cases. The output quality is high because tests have structure — arrange, act, assert — and that structure is exactly the kind of pattern AI learns well. You still verify that the tests make sense, but the mechanical part of writing them is delegated.

Documentation: Explaining what code does in prose is exactly what a next-word prediction machine optimized on human writing should be good at. It is.

Debugging stack traces: "Here's the error, here's the relevant code, here's the context." This is the exact kind of "given all this information, predict what's wrong" task where large context windows shine.

Low-value or risky delegation

Security-critical code: Authentication logic, authorization checks, cryptographic operations, input sanitization against injection attacks. The AI knows the patterns, but the stakes of getting them wrong are severe enough that you need deep personal understanding of every line. Use AI as a starting point or reviewer, never as the sole author.

Complex algorithms: Sorting, graph traversal, optimization problems — AI can produce code that looks correct and has subtle off-by-one errors. Correctness here requires proof, not confidence. Always verify independently.

Domain-specific business logic: AI doesn't know that in your company, "active" users are those who logged in within 90 days, or that your pricing model has seven edge cases inherited from a 2017 migration. It will make assumptions. Some will be right. You need to catch the ones that aren't.

Novel architecture decisions: Should this be synchronous or async? One service or two? Event-driven or request-response? These decisions require understanding your specific system's constraints — load, latency requirements, team size, operational complexity. AI gives you options and trade-offs, which is valuable input. But it can't make the decision for you, because it doesn't know what you're optimizing for.

The verification mindset

Let's talk about the daily habit that separates effective AI users from dangerous ones.

Every piece of AI-generated code goes through the same checklist before it enters your codebase:

1. Run it — does it actually execute without errors?
2. Test it — does it handle the edge cases you care about?
3. Read it — do you understand every line? Could you rewrite it from scratch?
4. Question it — are there assumptions that might not hold?
5. Own it — can you defend this code in a code review?

Step 3 is where most people skip. "It works" and "I understand why it works" are different statements. Both matter. The first gets it past testing. The second gets it past production incidents.

The habit sounds slow. In practice, it takes maybe two minutes for a typical function. And it saves you the debugging session that takes three hours, the production fix that wakes you up at 2 AM, and the six-month accumulation of code you're afraid to touch because nobody knows how it works.

A note on junior developers

I want to be direct about something the hype glosses over.

If you're early in your career, AI is both your biggest advantage and your biggest risk. The advantage: you can produce at a level above your experience, which opens doors that used to take years to open. The risk: you can ship code you don't understand, build a track record on borrowed foundations, and hit a wall when you need to debug something deep.

The differentiator is the understanding habit. Use AI to go faster — absolutely. But make sure "faster" means "less time on the mechanical parts" and not "less time understanding." Your 10-years-from-now self will have the foundations or won't. The choice happens now, in how you use the tool.

You now have the mental model. You know why specification matters, what's worth delegating, and how verification fits into the workflow. In the next tutorial, we get concrete about a specific failure mode: AI hallucinations — how to detect them, when to trust AI, and the practical toolkit for not getting burned. Because knowing the theory of verification is one thing. Knowing what hallucinations look like in the wild is another.

Never stop coding!

How LLMs Work (Without the Math)

Javi Palacios — Fri, 10 Jul 2026 12:13:08 +0000

In the previous tutorial, we said LLMs "predict text." And you probably thought: "okay, but that doesn't actually tell me anything useful." Fair. We need to go one level deeper — not down to the math level, but to the level of what's actually happening, because that directly explains why AI sometimes invents functions that don't exist, why the same prompt can give different answers, and why giving it more context makes a massive difference.

This tutorial is arguably the most important one in this module. Not because of what you'll learn to do, but because of the mental model you'll build. And that mental model, I promise, will save you hours of frustration.

The next-word prediction machine

Here's the uncomfortable truth: an LLM doesn't "understand" anything. It has no opinions of its own, no lived experience, no intuition. What it has is something stranger and, in a way, more impressive: it's read absurd quantities of text and learned, statistically, what words tend to follow other words.

The task during training was brutal in its simplicity:

Training text:  "The cat sat on the..."
Objective:       Predict "roof"

Multiply that by trillions of examples, over weeks, across thousands of GPUs. The result is a model that, given any fragment of text, can predict with surprising accuracy what comes next.

And here's the magic nobody expected: predicting the next word well requires understanding an enormous amount about the world. To predict that after "The president signed the..." comes something related to legislation or agreements, the model has to have learned what a president is, what they do, in what contexts they act. Not as an abstract concept — as a statistical pattern extracted from millions of texts.

Is that "understanding"? Philosophers have been arguing about it for years. For us as developers, the practical answer is: it doesn't matter. What matters is that the emergent behavior is useful, and knowing its origin makes us use it better.

The intern who has read all of Stack Overflow

The most useful analogy I know for an LLM is this:

Imagine an extraordinarily well-read intern. They've read the complete documentation for Python, Node.js, Rust, and 50 other languages. They've processed millions of Stack Overflow posts. They've seen tens of thousands of GitHub repositories. They've read technical articles, blog posts, programming books. All of that is in there, compressed somehow.

But there are things that intern simply cannot do:

What they can do:
✅ Synthesize information from multiple sources quickly
✅ Write coherent, structured code
✅ Explain concepts at different levels of detail
✅ Generate tests, docs, and boilerplate at high speed
✅ Recognize patterns and suggest improvements

What they can't do:
❌ Look up new information (unless given tools to do so)
❌ Remember what you talked about yesterday
❌ Know with certainty whether what they're saying is correct
❌ Access your codebase (unless you show it to them)
❌ Know anything that happened after their training cutoff

That last point — the training cutoff — matters. The model doesn't know what happened after they closed the data tap. If a library's API changed six months ago, the LLM might give you the old syntax with total confidence. It's not lying: it genuinely doesn't know.

Why AI says nonsense with absolute confidence

This is what's called hallucination, and understanding why it happens is fundamental to not falling into the trap.

The model generates text by predicting the next word. At no point does it have access to a mechanism that says "wait, is this actually true?" There's no query to a facts database. No verification module. There's statistical prediction, and that's it.

So when you ask about a Python function that doesn't exist:

# Prompt: "How do I use python.utils.magic_sort()?"
# AI response:
import python.utils

result = python.utils.magic_sort(my_list, reverse=True, stable=True)
# The stable parameter ensures equal elements maintain their relative order

The AI didn't look up magic_sort anywhere. It generated text that sounds like the correct answer to that question, based on how answers about Python functions tend to look. The name, the parameters, the explanation — all of it has the right shape. It just doesn't exist.

This isn't a bug they're going to fix. It's a direct consequence of how these models work. That's why verification isn't optional — it's part of the workflow.

Warning signs you should learn to recognize

Over time, you develop a nose for this. In the meantime, here are the most common signals:

Overly confident response about a very specific or poorly-documented topic
Function names that "sound right" but that you don't recognize
Specific library versions or release dates with no source
Code that has the right shape but throws AttributeError or ModuleNotFoundError when you run it
Explanations that shift when you repeat the question with slight variations

The golden rule: treat AI output like code from a colleague who's very smart but works in a rush. Review before you trust, always.

Context is your superpower

Here's the variable you control the most and that makes the biggest difference: the context you give the model.

The LLM has no memory between sessions (unless you explicitly provide it). Every conversation starts from zero. The only thing it knows about you, your project, and your problem is what's inside the current context window.

The context window is the amount of text the model can "see" at once. Claude Sonnet, for example, has a 200,000-token window — enough for a medium-sized complete codebase. This is enormous and relatively recent: two years ago, windows were 8,000 tokens and you had to manually manage what to include.

What does this mean for you in practice?

❌ Weak prompt:
"My code doesn't work, help me"

✅ Context-rich prompt:
"I have this Python function that should parse dates in ISO 8601 format,
but it fails when the string includes a timezone offset (e.g., 2026-03-07T10:30:00+01:00).
Here's the code: [code]
And here's the error: [error]
I'm using Python 3.12 with dateutil 2.9.0"

The difference in response quality is enormous. Not because the model got smarter — but because it has the information it needs to predict relevant answers.

Temperature: why the same question gives different answers

If you've ever asked the same thing twice and gotten different answers, that's not a bug. It's by design.

When the model predicts the next word, it doesn't always pick the most probable one. There's a parameter called temperature that controls how much randomness gets injected into that choice. With high temperature (more creative), it might pick less probable words. With low temperature (more deterministic), it almost always picks the most probable one.

Temperature 0.0  → very deterministic, consistent responses
Temperature 0.5  → balance between creativity and consistency
Temperature 1.0  → more variation, more creative, more erratic

For code, you generally want low temperature: you want the model to give you the most probable solution, not to experiment. For brainstorming or idea generation, a bit more temperature helps break out of familiar patterns.

opencode manages this automatically based on task type, but it's good to know the concept exists — especially when you notice the AI being "more conservative" or "more creative" depending on context.

Newer doesn't always mean better (for you)

One last expectation-breaker: just because a new model came out doesn't mean you should immediately switch to it for everything.

Models are optimized for different objectives. A very new model might be better at mathematical reasoning but worse at following complex instructions. Or it might have a smaller context window. Or it might be significantly slower or more expensive.

Model choice should be pragmatic:

Task	Priority
Full codebase analysis	Large context window
Repetitive code generation	Speed and cost
Architecture design	Reasoning capability
Quick, simple answers	Any lightweight model

opencode lets you specify the model per session. In practice, Claude Sonnet is an excellent starting point for most development tasks — a good balance of quality, speed, and cost. We'll go deeper on this when we look at the model landscape in tutorial 5.

With this mental model in place, you can start working with AI more intelligently: you know why verification matters, you know why context is everything, and you know that hallucinations aren't dark magic — they're statistical prediction applied confidently. In the next tutorial, we go to the next level: the paradigm shift of going from writing code to directing an AI — and why the ability to specify clearly becomes the most valuable skill you can develop.

Never stop coding!

Normal Mode: The Power of Vim

Javi Palacios — Thu, 09 Jul 2026 10:45:57 +0000

Every new Vim user makes the same mistake: they treat Normal mode as an inconvenience — that awkward state you have to pass through to get to Insert mode, where the "real work" happens. They tap i, type a word, tap Esc, tap i again, type another word. Normal mode is just the lobby.

Here's the thing: Normal mode is not the lobby. It's the whole building.

In VS Code or Sublime, you spend 80% of your time navigating: moving the cursor, selecting text, deleting words, jumping between lines. The keyboard handles maybe 20% of that; the mouse handles the rest. Vim flips this completely. Normal mode gives you a vocabulary of precise, composable movements and operations — and once you're fluent, you'll navigate and edit without ever lifting your hands from the keyboard.

This tutorial is where Vim starts to click.

Moving faster than one character at a time

hjkl got you into the game. Now it's time to actually play.

Word movements

Instead of pressing l seventeen times to get to the word you want, Vim lets you jump by word:

w — jump to the start of the next word
b — jump back to the start of the previous word
e — jump to the end of the current (or next) word

These three form a triangle. w and b are opposites; e gets you to the last character of a word. In practice you'll use w and b constantly, and e when you need to land precisely on the final character.

The quick brown fox jumps over the lazy dog
^   ^     ^     ^   ^     ^    ^   ^    ^
                              w movements (one per press)

There's also the uppercase variants: W, B, E. These do the same thing, but they define "word" differently — they skip over punctuation and treat user_name, foo.bar, and http://example.com as single words. The lowercase w would stop at every underscore and dot.

" Cursor on 'u' in user_name
w    " → stops at '_' (between user and name)
W    " → skips to next whitespace-separated chunk

Rule of thumb: use lowercase when you care about punctuation boundaries, uppercase when you want to jump over the whole "thing."

Line movements

Getting around within a line:

0 — go to the absolute start of the line (column 1)
^ — go to the first non-blank character (ignores indentation)
$ — go to the end of the line
g_ — go to the last non-blank character (ignores trailing spaces)

You'll use ^ and $ far more than 0 and g_. Code has indentation; ^ puts you at the actual first character of the code, not at column 1.

File movements

gg — jump to the first line of the file
G — jump to the last line of the file
5G or :5 — jump to line 5 (replace 5 with any number)
Ctrl+d — scroll half a page down (d for down)
Ctrl+u — scroll half a page up (u for up)
Ctrl+f — full page forward
Ctrl+b — full page back

The Ctrl+d / Ctrl+u pair deserves a special mention. Once these are in your muscle memory, you'll browse through files at a completely different speed. Down, down, down, up — no more dragging a scrollbar with the mouse.

The Vim grammar: operator + motion

This is the part where it all clicks. Stay with me.

Every command in Vim follows a simple grammar:

[count] operator motion

count (optional): how many times to apply
operator: what to do (d for delete, c for change, y for yank/copy)
motion: where to do it (w for word, $ for end of line, j for down)

You already know several motions: w, b, e, $, 0, G. The moment you learn even one operator, you can combine it with every motion you know.

The operators

Operator	What it does
`d`	Delete (and put in clipboard — it's actually "cut")
`c`	Change (delete and immediately enter Insert mode)
`y`	Yank (copy to clipboard without deleting)
`p`	Put (paste — after cursor by default)
`P`	Put before the cursor

Combining them

dw    " delete from cursor to start of next word
db    " delete from cursor back to start of current word
d$    " delete from cursor to end of line
d0    " delete from cursor to start of line
dG    " delete from cursor to end of file
d5j   " delete current line + 5 lines below (6 total)

cw    " change word (delete word, enter Insert mode)
c$    " change to end of line
c^    " change from start of code to cursor

yw    " yank (copy) one word
y$    " yank to end of line
yy    " yank entire line (special case — doubled operator = full line)

That last one is worth dwelling on: doubling an operator applies it to the whole line. dd deletes the current line. yy yanks it. cc changes it. You'll use dd and yy constantly.

A concrete example

Say you're editing this Python function and want to rename calculate_total:

def calculate_total(items):
    return sum(item.price for item in items)

Position your cursor on the c of calculate_total. Now:

cw    " deletes 'calculate_total' and drops you into Insert mode

Type compute_sum, press Esc. Done. Two keystrokes to delete the word, type the replacement, exit Insert mode.

Without Vim: click at the start of the word, click-drag to the end, type the replacement. Five gestures, two of which require the mouse.

The dot command: the most powerful key in Vim

Once you've made a change, you can repeat it instantly: press . (dot).

The . command replays the last change you made — whatever it was. Added async before a function? Press . to add it to the next one. Deleted a line with dd? Press . to delete the next line. Changed a word with cw? Press . to change the next word the same way.

cw    " change current word, type 'newName', press Esc
w     " move to next occurrence
.     " repeat: change that word to 'newName' too
w
.     " and again

This is how Vim users do what looks like multiple-cursor editing without actually using multiple cursors. Find the pattern, make the change once, then . your way through the file.

Don't underestimate .. Experienced Vim users think about their edits in terms of "how do I make this change once, repeatably?"

Counts: do it N times

Any command can be prefixed with a number to repeat it:

3w      " move forward 3 words
5j      " move down 5 lines
3dd     " delete 3 lines
2p      " paste twice
10G     " go to line 10

Counts plus operators plus motions give you a genuinely expressive system. d3w means "delete 3 words." y5j means "yank current line plus 5 below." You're not memorizing a list of commands; you're speaking a language.

A few essential shortcuts

Some combinations appear so often they've earned their own single keys:

Shortcut	Equivalent	What it does
`D`	`d$`	Delete to end of line
`C`	`c$`	Change to end of line
`Y`	`yy`	Yank entire line
`x`	`dl`	Delete character under cursor
`s`	`cl`	Substitute character (delete + Insert mode)
`S`	`cc`	Substitute entire line

These aren't exceptions to the grammar — they're just common abbreviations. Learn them as shortcuts, not as separate rules.

Practical exercise

Open any code file you've been working on and spend five minutes on this:

Navigate to a function or method name using w and b only — no arrow keys
Use cw to rename it, type the new name, press Esc
Press gg to go to the top of the file
Press G to go to the bottom
Use 10G (or whatever line number makes sense) to jump somewhere in the middle
Delete three lines with 3dd
Paste them back with p
Find another word you want to delete and use dw
Press u to undo
Press . — notice what happens

If you feel slightly overwhelmed at this point, that's completely normal. For now, don't stress about memorizing every combination — focus on the grammar: operator + motion. Once that's in your head, the rest follows naturally.

Key concepts from this lesson

Word movements: w / b / e jump by word; W / B / E jump by WORD (ignoring punctuation)
Line movements: ^ → first non-blank, $ → end of line
File movements: gg → top, G → bottom, Ctrl+d / Ctrl+u → scroll
The grammar: [count] operator motion — d3w, c$, y5j
Operators: d (delete/cut), c (change), y (yank/copy), p (put/paste)
Doubled operators = whole line: dd, yy, cc
. repeats the last change — use it constantly
Counts multiply any command: 3dd, 5j, 2p

You now understand what makes Vim fundamentally different from every editor you've used before. It's not the number of shortcuts — it's the grammar. Operators combine with motions, counts scale them, and . repeats them. You're not memorizing; you're composing.

The next step is understanding the other side of the grammar: Insert mode in depth. There's more there than just "press i and type" — Vim has a set of powerful ways to enter and exit Insert mode that will make your edits more precise and your . repetitions more effective.

Never stop coding!

Conditional statements in Python: if, elif, and else

Javi Palacios — Wed, 08 Jul 2026 10:30:06 +0000

Every program you've written so far works exactly the same every time you run it. It doesn't matter what data you enter, doesn't matter what happens: the code always follows the same path, top to bottom, no detours.

That's fine for a calculator script. But real programs need to react. An online store that shows the same price to everyone regardless of whether they have a discount isn't very useful. A fitness app that tells you to exercise even when you've already done it isn't either.

The ability to make decisions is what separates a rigid program from one that does something interesting. And in Python, that ability is called control flow.

What is a conditional statement?

Think about how you make decisions in real life. "If it's raining, grab an umbrella. If it's not, go out normally." That's exactly what an if does in Python: it runs a block of code only when a condition is met.

The basic structure looks like this:

if condition:
    # This code runs only if the condition is True
    print("The condition is met")

Two important things before we continue:

The colon (:): it's mandatory at the end of the if line. Forget it and Python will throw a SyntaxError without mercy.

Indentation: the block of code inside the if must be indented — typically 4 spaces. In Python, indentation isn't optional or decorative. It's part of the syntax. Without it, the code doesn't belong to the if.

age = 20

if age >= 18:
    print("You are an adult")    # Inside the if — runs if True
    print("You can vote")        # Also inside — same indentation

print("This always shows up")    # Outside the if — always runs

If age is 20, you'll see all three messages. If age were 15, you'd only see the last one.

The else: plan B

What if you want to do something different when the condition isn't met? That's what else is for. It works like the "otherwise" in everyday speech:

temperature = 35

if temperature > 30:
    print("It's hot, stay inside")
else:
    print("Pleasant temperature, go for a walk")

else carries no condition — it simply catches all the cases the if didn't cover. If the if condition is True, the if block runs and else is ignored. If it's False, the opposite happens.

One important thing: else always pairs with an if. You can't have a standalone else. Python would complain, and rightly so.

The elif: when there are more than two options

Life is rarely binary. Sometimes you need to evaluate multiple conditions in order, until you find one that's true. That's where elif comes in — short for "else if":

grade = 72

if grade >= 90:
    print("A — Excellent")
elif grade >= 80:
    print("B — Good")
elif grade >= 70:
    print("C — Average")
elif grade >= 60:
    print("D — Passing")
else:
    print("F — Fail")

C — Average

The evaluation order is top to bottom. Python checks the first condition; if it's False, it moves to the next elif; if that's also False, to the next one... until one is True or it reaches the else. As soon as it finds a true condition, it runs that block and exits. It doesn't keep checking the rest.

This means order matters. A lot. Look at what happens if we mix up the conditions:

grade = 95

# ⚠️ Wrong order — will never reach the higher grades
if grade >= 60:
    print("D — Passing")    # This runs for 95... not what we wanted
elif grade >= 70:
    print("C — Average")
elif grade >= 80:
    print("B — Good")
elif grade >= 90:
    print("A — Excellent")

D — Passing

A grade of 95 classified as passing. The problem: 95 >= 60 is True, so Python runs that block and never reaches the 90 condition. The general rule: most restrictive first, most permissive last.

Truth and falsiness in Python

Python has a pretty flexible view of what it considers true and what it considers false. Any value can be used as a condition, not just True and False:

# These are "falsy" — Python treats them as False in a condition
if 0:
    print("This never shows")

if "":
    print("Neither does this")

if []:
    print("An empty list either")

if None:
    print("None either")

# These are "truthy" — any non-empty, non-zero value
if 42:
    print("A non-zero number: truthy")

if "hello":
    print("A non-empty string: truthy")

if [1, 2, 3]:
    print("A list with elements: truthy")

This comes in handy. Instead of writing if len(my_list) > 0, you can just write if my_list. Python knows an empty list is "false" and one with elements is "true".

name = input("What's your name? ")

if name:
    print(f"Hello, {name}!")
else:
    print("You didn't enter your name")

Clean, direct, readable.

Compound conditions

You already know how to use and, or, and not from the previous lesson. Now it all makes sense inside an if:

age = 25
has_license = True

if age >= 18 and has_license:
    print("You can rent a car")
else:
    print("You don't meet the requirements")

day = "Saturday"

if day == "Saturday" or day == "Sunday":
    print("It's the weekend, time to rest")
else:
    print("Back to work")

is_premium = False

if not is_premium:
    print("Go premium to access this content")

A condition with and is only true if all sub-conditions are true. With or, it's enough for one to be true. With not, you invert the result.

Nested conditionals: with care

It's perfectly valid to put an if inside another if. These are called nested conditionals:

age = 20
has_ticket = True

if age >= 18:
    if has_ticket:
        print("You can enter the concert")
    else:
        print("You're old enough but you need a ticket")
else:
    print("You can't enter, you're underage")

It works, but use them sparingly. Every nesting level adds complexity and makes the code harder to read. If you find yourself three if levels deep, you can probably simplify with and:

# ✅ Cleaner with and
if age >= 18 and has_ticket:
    print("You can enter the concert")
elif age >= 18:
    print("You're old enough but you need a ticket")
else:
    print("You can't enter, you're underage")

The unwritten rule: if you can avoid nesting, avoid it.

A program that makes real decisions

Let's put everything together in a concrete example. A library access system that checks multiple conditions:

age = int(input("How old are you? "))
has_card = input("Do you have a library card? (y/n) ") == "y"
books_on_loan = int(input("How many books do you currently have on loan? "))

print()  # Empty line for readability

if age < 6:
    print("Sorry, you need to be at least 6 years old to use the library.")
elif not has_card:
    print("You need a library card. You can get one at the reception desk.")
elif books_on_loan >= 5:
    print("You've reached the loan limit. Return a book before borrowing more.")
else:
    print("Welcome! You can borrow books.")
    if books_on_loan >= 3:
        print("Remember, you only have", 5 - books_on_loan, "loans remaining.")

Notice the structure: we check the cases that block access first, and leave the successful case for the else. This is a common pattern called early exit — filtering out the negative cases upfront so the main flow stays clean at the end.

Summary

if condition: runs a block only if the condition is true
elif chains alternative conditions; Python evaluates top to bottom and stops at the first true one
else catches all cases that didn't match any previous condition
Indentation (4 spaces) isn't decorative — it defines which code belongs to which block
Python has truthiness: values like 0, "", [], and None evaluate as False
Nested conditionals work, but and / or are usually cleaner

With conditional statements, your programs can finally make decisions. But decisions alone aren't enough — often you need to repeat an action a certain number of times, or as long as a condition holds. In the next tutorial you'll learn while loops: how to make Python repeat code automatically, and why you need to watch out for infinite loops.

Never stop coding!

💡 Challenge: Write a program that asks the user for a numeric grade from 0 to 10 and displays the letter grade (A, B, C, D, F). Add validation: if the user enters a number outside the 0–10 range, show an error message instead of trying to classify it. Bonus: what happens if they enter a negative number? What if they enter text instead of a number?

Docker images and containers: understanding the relationship

Javi Palacios — Tue, 07 Jul 2026 06:39:39 +0000

You pulled ubuntu, you pulled nginx, you've been running containers and destroying them. But here's the thing — do you actually know what an image is? Not the one-liner ("a template"), but what's actually happening on your disk? Why does pulling node:22 take a while the first time and almost nothing the second? Why can you run ten containers from the same image and none of them affect each other?

If you got through lesson 2 with a vague intuition of how this works, this lesson is about turning that intuition into a mental model you can rely on. Because everything in Docker — Dockerfiles, image caching, volumes, multi-stage builds — makes a lot more sense once you understand what's happening underneath.

What is a Docker image, really?

Let's start with what an image is not. It's not a file. It's not a zip archive. It's not a snapshot of a running system.

A Docker image is a stack of layers. Each layer is a set of filesystem changes — files added, files modified, files deleted. When you stack them all together, you get a complete filesystem that a container can run. Think of it like a Git commit history: each commit (layer) describes what changed, and the full history gives you the current state of the project.

This is called a union filesystem (OverlayFS is the most common implementation on Linux). Docker merges these read-only layers into a single coherent view, and that's what the container sees as its filesystem.

Let's make it concrete. Imagine an image built like this:

Layer 1 (Base): Ubuntu 22.04 — adds ~80MB of OS files
Layer 2: apt-get install python3 — adds Python interpreter
Layer 3: pip install flask — adds Flask and its dependencies
Layer 4: COPY app.py /app/ — adds your application code

Each layer only stores the diff from the previous one. And here's where it gets efficient: if you have ten different images that all start from ubuntu:22.04, they all share that first layer on disk. Docker doesn't download or store it ten times — it references the same layer. Pull a new image that shares base layers with something you already have, and Docker will say "already exists" for those layers.

docker pull python:3.12

3.12: Pulling from library/python
fa9b7e77b6bf: Already exists       ← base layers shared with other images
48be9699aae1: Already exists
...
b0c4ce42c5d0: Pull complete        ← new layers specific to python:3.12
Digest: sha256:...
Status: Downloaded newer image for python:3.12

That's the layer cache doing its job.

Exploring layers

You can inspect exactly what layers an image contains:

docker image inspect nginx

This dumps a large JSON object. The relevant section is RootFS.Layers, which lists the SHA256 hashes of each layer. You can also see a higher-level view with:

docker image history nginx

IMAGE          CREATED        CREATED BY                                      SIZE
a7be6198544f   2 weeks ago    CMD ["nginx" "-g" "daemon off;"]               0B
<missing>      2 weeks ago    STOPSIGNAL SIGQUIT                             0B
<missing>      2 weeks ago    EXPOSE 80                                      0B
<missing>      2 weeks ago    COPY /etc/nginx /etc/nginx /                   4.61kB
<missing>      2 weeks ago    RUN /bin/sh -c apt-get update && apt-get ...   91.4MB
<missing>      2 weeks ago    ENV NGINX_VERSION=1.27.4                       0B
<missing>      2 weeks ago    FROM debian:bookworm-slim                      0B

Read it bottom to top: start with the base debian:bookworm-slim, install packages, copy Nginx config, set the startup command. Each line is a layer (or a metadata instruction that adds 0 bytes).

Image tags: this is not optional knowledge

When you run docker pull nginx, you're actually running docker pull nginx:latest. The :latest is a tag, and latest is the default. Tags are mutable pointers — today's nginx:latest is not the same image as nginx:latest from six months ago. It just points to the newest stable build.

In production, you never use latest. You pin to a specific version:

docker pull nginx:1.27.4         # Specific patch version — deterministic
docker pull nginx:1.27           # Minor version — gets patches
docker pull nginx:1              # Major version — gets minor updates too
docker pull nginx:latest         # ❌ Fine for local experiments, not for prod

Why? Because latest means your deployment changes every time you pull. Upgrading Nginx should be a deliberate decision, not a side effect of running docker pull.

There's also a pattern you'll see often: variant tags. The same version with different base images:

nginx:1.27.4-alpine    # Alpine Linux base (~5MB), minimal, fast to pull
nginx:1.27.4           # Debian base (~180MB), more compatible
nginx:1.27.4-slim      # Reduced Debian, middle ground

Alpine is popular for production because of its tiny size. The tradeoff: it uses musl libc instead of glibc, which can cause subtle compatibility issues with some software. For most things it's fine; for others it's a frustrating debugging session (because C library mismatches).

The container lifecycle

An image is static. A container is alive — and it has a lifecycle.

When you run docker run, the container doesn't just appear in a running state. It goes through a series of states:

Created → Running → (Paused) → Stopped → Removed

Created: the container exists but hasn't started yet. You can do this explicitly with docker create, or it's an implicit step inside docker run.

Running: the main process is executing. The container consumes CPU, RAM, and filesystem resources.

Paused: the process is suspended (SIGSTOP). The container still exists in memory but isn't doing anything. docker pause and docker unpause. Rarely used, but useful for debugging — freeze a container in place and inspect its state.

Stopped: the main process has exited. The container still exists as a stopped entity — its filesystem is preserved, its logs are still accessible. You can restart it with docker start.

Removed: the container is gone. Filesystem, logs, everything. You can't bring it back.

# Walk through the lifecycle manually
docker create --name demo nginx          # Created
docker start demo                        # Running
docker pause demo                        # Paused
docker unpause demo                      # Running again
docker stop demo                         # Stopped (SIGTERM → SIGKILL after 10s)
docker rm demo                           # Removed

Or skip the ceremony and do everything at once:

docker run --rm nginx    # Creates, starts, and removes when done

The writable layer: why containers don't modify images

Here's a key detail that confuses people. If images are read-only, how can a container write files?

When Docker creates a container from an image, it adds a thin writable layer on top of all the read-only image layers. This is where everything the container writes goes — log files, temporary data, any apt-get install you do inside the container. The image layers beneath are never touched.

┌─────────────────────────────┐
│   Container writable layer  │  ← changes here only
├─────────────────────────────┤
│   Image layer 4 (app.py)    │  read-only
├─────────────────────────────┤
│   Image layer 3 (Flask)     │  read-only
├─────────────────────────────┤
│   Image layer 2 (Python)    │  read-only
├─────────────────────────────┤
│   Image layer 1 (Ubuntu)    │  read-only
└─────────────────────────────┘

When the container is removed, the writable layer disappears with it. The image is exactly as it was. Start another container from the same image and you get a fresh writable layer — a clean slate.

This is what makes containers ephemeral by design. They're not meant to be permanent homes for data. Anything you want to persist beyond a container's lifetime goes in a volume — but that's a topic for later in the course.

Ten containers, one image

Let's make this tangible. You can have ten containers running from a single image simultaneously:

# Start ten nginx containers, each on a different port
for i in $(seq 1 10); do
  docker run -d -p "808${i}:80" --name "nginx-${i}" nginx
done

docker ps

CONTAINER ID   IMAGE   COMMAND                  PORTS                  NAMES
a1b2c3d4e5f6   nginx   "/docker-entrypoint.…"   0.0.0.0:8081->80/tcp   nginx-1
b2c3d4e5f6a7   nginx   "/docker-entrypoint.…"   0.0.0.0:8082->80/tcp   nginx-2
...

Each one is completely isolated. Writing to the filesystem of nginx-1 doesn't affect nginx-2. They all share the read-only Nginx image layers. On disk, the overhead of ten containers is ten tiny writable layers — not ten full copies of Nginx.

Clean up when done:

for i in $(seq 1 10); do
  docker stop "nginx-${i}" && docker rm "nginx-${i}"
done

Or more directly:

docker rm -f $(docker ps -aq --filter name=nginx-)

Pulling, listing, and removing images

A few commands you'll use constantly:

# Download an image without running it
docker pull node:22-alpine

# List all locally available images
docker images

REPOSITORY   TAG          IMAGE ID       CREATED        SIZE
nginx        latest       a7be6198544f   2 weeks ago    192MB
node         22-alpine    f7d2a4e85d2c   3 weeks ago    141MB
ubuntu       22.04        3db8720ecbf5   4 weeks ago    77.9MB
python       3.12         b3a18c9e2f1d   3 weeks ago    1.02GB

# Remove an image (only works if no containers — running or stopped — reference it)
docker rmi nginx

# Force remove (also removes derived containers)
docker rmi -f nginx

# Remove all unused images
docker image prune
docker image prune -a    # Also removes images with no running containers (more aggressive)

⚠️ You can't remove an image while a container (even a stopped one) references it. Remove the container first, then the image.

Naming containers: don't skip this

If you don't name your containers, Docker assigns random adjective-noun combinations (ecstatic_hopper, confident_kepler). Endearing, but useless for anything beyond a quick experiment.

# Always name your containers
docker run -d --name web-server nginx
docker run -d --name api-backend node:22-alpine node app.js
docker run -d --name db-primary postgres:16

Named containers are easier to reference in every subsequent command:

docker logs web-server
docker exec -it web-server bash
docker stop web-server

And when you use Docker Compose (coming later), naming becomes even more important because services discover each other by name over Docker's internal network.

The image-container relationship is the foundation of everything Docker does. Layers explain the cache behavior, the efficiency of pulling images, and why modifying a container doesn't affect others sharing the same image. The lifecycle explains why containers are designed to be disposable — and why data persistence requires a different mechanism.

In the next lesson we'll go hands-on with interactive containers and exec: running shells inside containers, copying files in and out, and understanding when to use -it vs -d and why the difference matters.

Never stop coding!

💡 Challenge: Pull three different images (nginx, node:22-alpine, python:3.12-slim). Create two containers from nginx, stop one, remove the other. View the logs of the remaining container. Check what layers nginx and python:3.12-slim have in common using docker image inspect. Clean everything up with docker system prune.

Installing Docker and running your first container

Javi Palacios — Mon, 06 Jul 2026 11:32:44 +0000

Every tool has its initiation ritual. With Git it's git init. With Node it's npm install and watching node_modules devour half your disk. With Docker, it's a command that's been the opening line of every tutorial for years:

docker run hello-world

It looks trivially simple. But what it does under the hood is anything but: Docker downloads an image from the internet, creates a container, runs it, prints a message, and destroys it — all in seconds. No Dockerfile. No configuration. And yet you've just completed the full container lifecycle.

Before you get there, though, you need to install the thing.

Docker Desktop vs Docker Engine: which one?

The first fork in the road, and worth understanding upfront.

Docker Engine is the raw engine: the daemon that manages containers, no GUI, built for Linux servers and people who live in the terminal. This is what you'll run in production.

Docker Desktop is a desktop application that bundles Docker Engine, a graphical interface, and a compatibility layer that makes Docker work on macOS and Windows (which don't have a native Linux kernel). It also includes Docker Compose and a few extra tools.

The practical rule:

Linux: install Docker Engine directly. Docker Desktop exists for Linux but adds an unnecessary virtualization layer.
macOS: Docker Desktop is the standard choice and the simplest path.
Windows: Docker Desktop with WSL2. Without WSL, the pain is real (because Windows).

Installation on Linux

Linux is Docker's native environment, so installation is the most straightforward here. Arch users already know the drill — pacman -S docker and done. For everyone else, the most reliable method that works across Ubuntu, Debian, Fedora, and most derivatives is the official script:

# Download and run the official install script
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

The script detects your distribution and configures the right repositories automatically. Once installed, there's one step most people miss, and it causes the classic "why am I getting permission denied?" moment:

# Add your user to the docker group
sudo usermod -aG docker $USER

# Apply the group change immediately (or log out and back in)
newgrp docker

Without this, you'll need sudo for every Docker command. Technically it works, but it's annoying and goes against how the workflow is meant to feel.

Verify everything is working:

docker --version

Docker version 27.4.1, build f31f73a

docker info

docker info shows you the daemon's state: how many containers are running, how many images you have locally, the kernel version, the storage driver. If you see all that without errors, the engine is running.

Installation on macOS

Two options. The most comfortable for most people is Docker Desktop:

# Via Homebrew (recommended)
brew install --cask docker

Or download directly from docker.com. Once installed, open Docker Desktop from Applications. You'll see the whale icon in the menu bar — when it stops animating, the engine is ready.

The minimalist alternative, if you'd rather skip the GUI, is OrbStack: lighter, faster to start, and fully compatible with all standard Docker commands. More and more people on macOS are using it instead of Docker Desktop.

Installation on Windows (WSL2)

Windows needs WSL2 (Windows Subsystem for Linux) as its foundation. If you don't have it yet:

# Run in PowerShell as Administrator
wsl --install

Restart, then install Docker Desktop from docker.com. During installation, make sure "Use WSL 2 based engine" is checked.

⚠️ Important: if you have WSL1 installed from before, upgrade to WSL2 first. Docker works with WSL1, but the performance is noticeably worse and you'll hit weird edge cases.

Docker's architecture (what actually happens when you type a command)

Before running that first container, it's worth understanding what's happening behind the scenes. When you type docker run nginx, you're not just launching a process. There are three pieces talking to each other:

Docker Client (the CLI): the tool you use in the terminal. It converts your commands into REST API calls to the daemon. It's just a client — it doesn't do the heavy lifting.

Docker Daemon (dockerd): the process that actually manages containers, images, networks, and volumes. It runs in the background. When you run docker run, the client tells the daemon "start this container", and the daemon does it.

Docker Registry: the image repository. Docker Hub is the default public registry. When you request an image you don't have locally, the daemon downloads it from there.

[docker CLI] → REST API → [dockerd] → pulls from [Docker Hub]
                                     → creates the container
                                     → manages its lifecycle

This client-server model has a practical implication: you can point your local Docker client at a daemon running on a remote server. Useful for managing production from your terminal.

Images vs containers: the mold and the pieces

This distinction is fundamental. Get it wrong and Docker will feel confusing forever. Get it right and everything clicks.

An image is a read-only template. It defines which base OS to use, what software to install, what files to copy in, what command to run at startup. It's immutable — it doesn't change. Think of it like a class in object-oriented programming, or a cookie cutter.

A container is a running instance of an image. It's what actually executes, what consumes CPU and RAM, what has its own isolated filesystem and its own network. You can create ten containers from the same image — ten cookies from the same cutter, each independent of the others.

When a container stops, it's gone (unless you explicitly told it to persist data). The image stays, ready to create more containers.

Your first container

With Docker installed, the moment of truth:

docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

The message walks you through exactly what just happened. The first time it takes a moment because it's downloading the image. The second time it's instant — the image is cached locally.

Now something a bit more interesting: an interactive container.

docker run -it ubuntu bash

root@a3f8c2b1d9e7:/#

Feeling disoriented? That's expected. You just opened a shell inside a completely isolated Ubuntu container. You can install things, delete files, break whatever you want — when you exit, the container disappears and your machine is untouched.

# Inside the container
cat /etc/os-release
ls /
whoami  # root (containers run as root by default — we'll address this later)
exit

And the classic web server:

# Run Nginx in the background, mapping port 8080 on your machine to port 80 in the container
docker run -d -p 8080:80 --name my-nginx nginx

Open your browser at http://localhost:8080. You have an Nginx server running in a container, without having installed anything on your system. When you're done:

docker stop my-nginx
docker rm my-nginx

The essential commands

You don't need to memorize all of this now — it'll sink in through use. But having it as a reference helps:

docker pull <image>        # Download image from registry
docker images              # List locally available images
docker run <image>         # Create and start a container
docker ps                  # List running containers
docker ps -a               # List all containers (including stopped)
docker stop <container>    # Stop a container (SIGTERM)
docker start <container>   # Start a stopped container
docker rm <container>      # Remove a stopped container
docker rmi <image>         # Remove an image
docker logs <container>    # View container output
docker exec -it <container> bash  # Open shell in running container

One handy trick: docker run --rm removes the container automatically when it stops. Perfect for quick experiments where you don't care about persistence.

# Container disappears automatically when you exit
docker run --rm -it ubuntu bash

Cleaning up

After experimenting, you'll have accumulated images and stopped containers. To clean house:

# Remove all stopped containers
docker container prune

# Remove unused images
docker image prune

# Remove everything unused (containers, images, networks, build cache)
docker system prune

⚠️ docker system prune is aggressive — it will ask for confirmation, but it removes everything not actively in use. Use it deliberately.

Docker is installed, and you've run your first containers. In the next lesson, we'll go deeper into the image-container relationship: what image layers are, how the full container lifecycle works, and how to inspect and manage everything you have running.

Never stop coding!

Common beginner mistakes in Python (and how to fix them)

Javi Palacios — Sat, 04 Jul 2026 10:13:39 +0000

Your code doesn't work. Python shows you some red text, and you stare at the screen wondering what just happened. Sound familiar?

If you're like me when I started, your first instinct is to close the terminal and pretend it never happened. Your second instinct is to paste the error into Google and hope someone on Stack Overflow had the exact same problem in 2014.

There's a better way.

Python errors are not your enemy

Here's the thing most beginners don't realize: Python's error messages are the most helpful feedback you'll get. They tell you exactly what went wrong, where it went wrong, and often how to fix it. The problem isn't that the messages are unhelpful — it's that we don't know how to read them yet.

Let's fix that.

Anatomy of a traceback

When Python encounters an error, it shows you a traceback — a trail of breadcrumbs leading to the problem. Here's a typical one:

Traceback (most recent call last):
  File "hello.py", line 5, in <module>
    result = add(10, "five")
  File "hello.py", line 2, in add
    return a + b
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Read it from bottom to top. That's the key insight. The last line is the actual error. Everything above it is the path Python took to get there.

Breaking it down:

TypeError — the category of the error
unsupported operand type(s) for +: 'int' and 'str' — what happened in plain English
File "hello.py", line 2, in add — where it happened
return a + b — the exact line of code

With this information alone, you can fix most errors without searching the internet. You know what went wrong, where it went wrong, and what the code looked like when it did.

The most common Python errors

SyntaxError — Python can't understand you

print("Hello World"   # ❌ Missing closing parenthesis

  File "hello.py", line 1
    print("Hello World"
                       ^
SyntaxError: '(' was never closed

Python found a problem so fundamental it couldn't even run your code. Common causes:

# ❌ Missing colon after if/for/while/def
if x > 5
    print(x)

# ✅ Correct
if x > 5:
    print(x)

# ❌ Mismatched quotes
message = "Hello, World!'

# ✅ Correct
message = "Hello, World!"

The ^ character in the error points to where Python got confused. It's not always exactly where you made the mistake — Python sometimes notices a problem later than where it occurred — but it's a good starting point.

IndentationError — Python takes whitespace seriously

This one catches everyone. Python uses indentation to define code blocks, not curly braces like many other languages. Four spaces (or one tab, consistently) per level:

# ❌ Missing indentation inside if
if age >= 18:
print("You can vote")   # IndentationError: expected an indented block

# ✅ Correct
if age >= 18:
    print("You can vote")

# ❌ Inconsistent indentation (mixing spaces and tabs)
def greet(name):
    print("Hello")   # 4 spaces
    print(name)      # 1 tab — TabError!

# ✅ Consistent: always 4 spaces
def greet(name):
    print("Hello")
    print(name)

⚠️ Configure your editor to always use spaces (4 of them), never tabs. This avoids the mixing problem entirely. VS Code does this by default for Python files.

NameError — using something that doesn't exist

print(message)   # ❌ NameError: name 'message' is not defined
message = "Hello"

Python executes code top to bottom. If you try to use a variable before defining it, Python has no idea what you're talking about. The fix: define before use.

Another common variant:

user_name = "Alice"
print(username)   # ❌ NameError: name 'username' is not defined

Spot the difference? user_name vs username. Python is case-sensitive and typo-sensitive. name, Name, and NAME are three completely different variables.

TypeError — mixing incompatible types

age = input("Your age: ")   # input() always returns a string
next_year = age + 1          # ❌ TypeError: can only concatenate str (not "int") to str

TypeError: can only concatenate str (not "int") to str

The fix: convert the type explicitly.

age = int(input("Your age: "))   # ✅ Convert to int immediately
next_year = age + 1
print(f"Next year you'll be {next_year}")

Or the other direction — trying to print a number directly in a concatenation:

score = 42
print("Your score: " + score)      # ❌ TypeError
print("Your score: " + str(score)) # ✅ Convert int to str
print(f"Your score: {score}")      # ✅ Better: just use an f-string

ValueError — right type, wrong value

number = int("hello")   # ❌ ValueError: invalid literal for int() with base 10: 'hello'

The type is correct (int() expects a string to convert), but the content isn't — "hello" can't be converted to an integer.

Common scenario: reading user input and assuming it's a number.

user_input = input("Enter a number: ")  # User types "abc"
result = int(user_input)                 # ❌ ValueError

We'll handle this properly when we cover error handling later in the course. For now, just understand what the error means.

IndexError — going out of bounds

numbers = [10, 20, 30]
print(numbers[5])   # ❌ IndexError: list index out of range

The list has 3 elements (indices 0, 1, 2). Index 5 doesn't exist. Python tells you: you went off the edge.

# ✅ Access within bounds
print(numbers[0])   # 10
print(numbers[-1])  # 30 — last element, always safe

AttributeError — method doesn't exist on that type

number = 42
print(number.upper())   # ❌ AttributeError: 'int' object has no attribute 'upper'

.upper() is a string method. Integers don't have it. You're calling something that doesn't exist on that type of object.

Usually this means either you have the wrong type, or you made a typo in the method name:

text = "hello"
print(text.uper())    # ❌ AttributeError: 'str' object has no attribute 'uper'
print(text.upper())   # ✅

Debugging strategies for beginners

Knowing the errors is half the battle. The other half is systematically finding them. Here's the approach that works:

1. Read the error message completely

Don't glance at the red text and panic. Read it. What type of error? What line? What was the code doing? The answer is almost always in the traceback.

2. Add `print()` to inspect your variables

The simplest debugging tool in existence:

def calculate_total(price: float, quantity: int) -> float:
    print(f"DEBUG: price={price}, quantity={quantity}")  # Add this temporarily
    total = price * quantity
    print(f"DEBUG: total={total}")                        # And this
    return total

Print the values right before the line that crashes. Nine times out of ten, you'll immediately see the problem: the variable has the wrong value, the wrong type, or is None when you expected something else.

3. Isolate the problem

If you have 50 lines of code and something's broken, you don't need to fix all 50 lines. Find the minimum code that reproduces the error:

# Instead of debugging your entire program, test the specific operation:
user_input = "abc"
result = int(user_input)   # Isolate this — does it fail here?

4. Check your assumptions

Most bugs come from an assumption that turns out to be wrong. "I assumed this would be a number." "I assumed the list had at least one element." "I assumed Python counts from 1."

When your code doesn't behave as expected, ask: what am I assuming here that might not be true?

Case sensitivity is not optional

Name = "Alice"
print(name)   # ❌ NameError: name 'name' is not defined

Python sees Name and name as completely different things. This is by design and non-negotiable. Pick a convention (snake_case as per PEP 8) and stick to it.

Same goes for built-in functions:

print(True)    # ✅
print(true)    # ❌ NameError — Python booleans are True/False, capital T/F
print(none)    # ❌ NameError — it's None, not none

The `print()` debugging workflow

Before diving into proper debuggers, get comfortable with this pattern — it works, it's fast, and every professional uses it at some point:

# Original code that's misbehaving
result = process_data(user_input)

# Add print statements to understand the flow
print(f"user_input = {user_input!r}")   # The !r shows the repr — useful for strings
result = process_data(user_input)
print(f"result = {result!r}")

The !r format specifier shows the repr() of the value, which includes quotes around strings. This makes it easy to spot trailing spaces, newlines (\n), or other invisible characters that are often the culprit.

Errors aren't failures — they're Python talking to you. The faster you get comfortable reading tracebacks, the faster you'll write working code. Every error message is a clue, and now you know how to read them.

In the next tutorial we move into control flow: if, else, and elif. For the first time, your programs will be able to make decisions based on what the user does or what the data looks like.

Never stop coding!

💡 Challenge: Intentionally write code with 5 different types of errors from this tutorial (SyntaxError, IndentationError, NameError, TypeError, ValueError). Run each one, read the traceback carefully, and fix it. You'll remember them much better than any list of rules.

Rewriting History with git rebase

Javi Palacios — Fri, 03 Jul 2026 12:04:43 +0000

Imagine you've spent three days working on a new feature in your feature/login branch. Meanwhile, someone has pushed four commits to master that touch parts of the code you're working with. When the time comes to integrate your work, the history is going to look like a plate of spaghetti that nobody wants to untangle.

There's a cleaner alternative: git rebase. A tool that rewrites history so everything appears to have happened in a straight line, without the knots that merge leaves behind. But with great power comes responsibility, and there's one rule that, if broken, will make your teammates' lives miserable.

What is rebase?

To understand rebase, you first need to be clear on what merge does. When you run git merge master from your feature branch, Git creates a new merge commit that joins the two histories. The result works, but the history is branched — two lines converging at a point.

Rebase does something different. It literally replays your commits on top of the target branch. It's as if you started your work today, after all the latest changes to master, even though you actually started three days ago.

An analogy: imagine you're writing a report while your manager keeps updating the base draft. With merge, your version and your manager's version are combined into a final document with merge markers. With rebase, it's as if you had read your manager's updated draft before you started writing your section. The result is cleaner, the authorship clearer.

How git rebase works

Here's the mechanics. You have this situation:

      A---B---C  feature
     /
D---E---F---G    master

Commits A, B, and C are yours on feature. Commits F and G arrived on master while you were working.

When you run:

git switch feature
git rebase master

Git does three things in order:

Finds the common ancestor between feature and master (commit E)
Temporarily saves your commits (A, B, C) as patches
Replays them one by one on top of G, the latest commit on master

The result:

              A'--B'--C'  feature
             /
D---E---F---G             master

Commits A', B', and C' are new commits (with new hashes) that contain the same changes as A, B, and C, but applied on top of G. The history is linear.

The golden rule of rebase

⚠️ Never rebase commits that have already been pushed to a public branch.

This is the most important rule and the one most people break when they're learning. The reason is technical, but the consequence is very concrete.

Rebase creates new commits. Even though the content is the same, the hashes change. If other people have cloned those commits and you rewrite them with rebase, when they try to pull they'll find an incompatible history. You'll create a mess of duplicate commits and conflicts that are very hard to undo.

The practical rule is simple: only rebase branches that are exclusively yours. Your local feature branch that nobody else has touched: yes. master, develop, or any branch your teammates have cloned: never.

Basic rebase: updating your branch with master's changes

The most common case is wanting to bring your branch up to date with the latest changes from master before opening a pull request. The workflow:

# First, make sure master is up to date
git switch master
git pull

# Then rebase your feature branch on top of master
git switch feature/login
git rebase master

If there are no conflicts, Git replays your commits automatically and you're done:

Successfully rebased and updated refs/heads/feature/login.

Your feature/login branch now starts from the latest commit on master. When you merge or open a pull request, it will be a clean fast-forward with no merge commit.

Resolving conflicts during rebase

Sometimes Git can't replay a commit automatically because there are conflicts. In that case it stops and tells you:

Auto-merging src/auth/login.ts
CONFLICT (content): Merge conflict in src/auth/login.ts
error: could not apply a1b2c3d... Add login validation
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the original state, run "git rebase --abort".

The process to resolve:

Edit the file with the conflict and choose which code to keep
Mark the conflict as resolved:

git add src/auth/login.ts

Continue the rebase:

git rebase --continue

Git will apply the next commit and so on until it's done. If you get lost at any point or decide it's not worth continuing, you have an escape hatch:

git rebase --abort

This returns your branch exactly to the state it was in before you started the rebase. As if nothing happened.

Rebase vs merge: when to use each

There's no absolute answer. It depends on context and your team's conventions. But there's a useful heuristic:

Situation	Recommendation
Updating your local branch with `master`	Rebase — cleaner history
Integrating a finished feature into `main`	Merge — preserves the context of the work
Shared branches with the team	Merge — never rebase
Preparing commits for a clean PR	Rebase — ideal
Branch with many small "WIP" commits	Interactive rebase (next lesson)

The philosophy behind rebase is: history should tell the story of the project, not the story of how you developed it. Some teams prefer to see exactly how the work evolved, and for them merge is more honest. Others prefer a linear, clean history that's easy to read. Neither stance is wrong.

Checking the result

After a successful rebase, you can verify that your history is linear with:

git log --oneline --graph

Something like:

* c3d4e5f (HEAD -> feature/login) Add remember me option
* b2c3d4e Add password validation
* a1b2c3d Add login form
* 9f8e7d6 (master) Fix user session timeout
* 8e7d6c5 Add user profile page
* 7d6c5b4 Initial commit

Linear, clean, easy to read. Each of your feature commits applied on top of the latest state of master.

Rebase is one of those tools that feels a little dizzying at first because it "rewrites history," but once you master it and use it in the right context, it becomes a natural part of your workflow. The key is to internalize the golden rule: your own local branches, yes; public and shared branches, never.

In the next lesson we'll look at interactive rebase (git rebase -i), a variant that lets you reorganize, combine, and edit individual commits in your branch before integrating them. It's the perfect tool for cleaning up those "fix typo" and "wip wip" commits before they end up in the history forever.

Never stop coding!

DEV Community: Javi Palacios

while loops in Python: repetition with a condition

What is a while loop?

The infinite loop: it's not a myth

break: exit on your terms

continue: skip one iteration

Real-world use cases

Validating user input

Counter with a business condition

Guessing game

while vs for: when to use each

Interactive containers and exec: get inside, run commands, get out

Interactive mode: what -it actually means

Detached mode: the -d you already know

docker exec: get inside a running container

Common exec patterns

exec without -it

The Alpine trap: bash vs sh

Copying files with docker cp

From container to host

From host to container

docker cp vs volumes

Seeing what's happening: logs and inspect

docker logs

docker inspect

A typical debugging workflow

Cherry-picking commits in Git

What is cherry-pick?

Basic usage

Cherry-picking multiple commits

Individual commits

A range of commits

Useful flags

-n / --no-commit: stage without committing

-e / --edit: edit the message before committing

-x: record where the commit came from

Handling conflicts

Real-world scenarios

Backporting a hotfix to release branches

Rescuing commits from a dead branch

When NOT to use cherry-pick

Interactive Rebase in Git: Edit Your History Like a Pro

What is interactive rebase?

The main operations

pick: keep as-is

reword: change only the message

squash: combine with the previous commit

fixup: combine and discard the message

drop: delete the commit

edit: stop to amend

A complete example

Reordering commits

Splitting a commit into multiple

Autosquash: automating the cleanup

When to use interactive rebase

AI for Programming: The Paradigm Shift

The old way vs the new way

You're becoming an engineering director

The new bottleneck: specification

Delegation without abdication

What's worth delegating (and what isn't)

High-value delegation

Low-value or risky delegation

The verification mindset

A note on junior developers

How LLMs Work (Without the Math)

The next-word prediction machine

The intern who has read all of Stack Overflow

Why AI says nonsense with absolute confidence

Warning signs you should learn to recognize

Context is your superpower

Temperature: why the same question gives different answers

Newer doesn't always mean better (for you)

Normal Mode: The Power of Vim

Moving faster than one character at a time

Word movements

Line movements

File movements

The Vim grammar: operator + motion

The operators

Interactive mode: what `-it` actually means

Detached mode: the `-d` you already know

`docker exec`: get inside a running container

`exec` without `-it`

Copying files with `docker cp`

`docker cp` vs volumes

`docker logs`

`docker inspect`

`-n` / `--no-commit`: stage without committing

`-e` / `--edit`: edit the message before committing

`-x`: record where the commit came from

2. Add `print()` to inspect your variables

The `print()` debugging workflow