DEV Community: Javi Palacios

Using AI to learn programming concepts

Javi Palacios — Mon, 14 Sep 2026 16:54:03 +0000

You're reading about recursion. The explanation starts fine: “a function that calls itself.” Fair enough. You keep going. There's a factorial example. Still sort of fine. Then suddenly there's a call stack, a base case, return values unwinding in reverse order, and your brain returns HTTP 500.

So you do the reasonable thing: you ask AI.

Explain recursion to me.

And the AI gives you a correct definition, a correct example, and a correct analogy. Everything is correct. You still don't get it. Fantastic. We have produced documentation with a positive attitude and actionable insights.

The problem isn't that AI can't teach. It can. Very well, actually. The problem is that many people use it like a searchable encyclopedia with a chat box, when for learning programming it works much better as a technical tutor: patient, adaptable, and available at 2 AM, which is when questions actually decide to show up. During the day they hide. Like bugs.

In the previous lesson we looked at advanced context, role, task, and format. Now we'll apply the same idea to something more delicate: learning concepts without settling for an explanation that sounds good but collapses the moment you try to write code.

AI as a tutor, not an oracle

AI should not be the divine voice descending from the cloud to hand you truth in Markdown. If you use it that way, you train yourself to accept answers that sound convincing. And as we saw earlier in the course, a convincing answer is not always a correct one.

For learning, the useful mental model is this: AI is a tutor you can direct.

That changes the conversation. You don't just ask “explain closures” and passively receive. You tell it what you know, what you don't know, what confuses you, and how you want to test your understanding.

Look at the difference:

❌ Explain closures in Python.

That can work, yes. It can also give you a generic explanation that starts well, becomes abstract, and ends with the same outer() and inner() example you've seen in twenty blog posts.

Now try this:

Role: act as a Python mentor for someone learning programming.

Context:
I understand variables, functions, and local scope, but I struggle to understand
why an inner function can remember values from an outer function after the outer
function has finished running.

Task:
Explain closures by connecting them to what I already know. Don't use decorators yet.

Format:
1. Short explanation
2. Realistic analogy
3. Minimal Python example
4. Common mistake
5. One question to check whether I understood it

The second version doesn't ask for “content.” It asks for a learning experience. It's like going to the doctor: “it hurts” doesn't help much; “it hurts here, since yesterday, when I do this” gives someone something to work with.

And yes, you can ask questions that feel too basic. You should, actually.

“Stupid” questions that are not stupid

One of the best things about using AI to learn is that you can ask without the social pressure of looking lost. No teammate looking over your shoulder. No rushed teacher. No senior sighing because you mixed up map() and a for loop. Just you, the question, and a text box.

Use that.

I know this is basic, but: why does Python use indentation instead of braces?

I don't understand what it means for a variable to be "mutable".
Explain it assuming I know what a list is, but not what happens underneath.

I've read the docs about `return`, but I still confuse returning a value
with printing it to the screen. Can you compare them with small examples?

These questions are gold. Not because they're sophisticated, but because they hit the exact place where your brain is stuck. General documentation can't guess that place.

If you're following the Python course from scratch, this approach fits concepts like variables and data types, functions, or lists. Don't just ask “what is a list?” Ask about the specific confusion: “why does append() modify the list but string.upper() doesn't modify the original string?” That's where real learning starts.

A good learning question usually looks like this:

I'm learning [concept].
I already understand [what you know].
I'm confused by [specific blocker].
Explain it using [kind of example that helps you].
Then ask me a question to check whether I understood it.

No ceremony required. You're not submitting a petition to the International Prompt Committee. You're just making it clear where you are and where you fell over.

The Feynman technique with AI

The Feynman technique is brutally simple: if you want to check whether you understand something, try explaining it in your own words. If you can't, you don't understand it yet. If your explanation is hand-wavy, you don't understand it either. And if you explain it using words you couldn't define, your brain has just outsourced the problem.

With AI, this process has one more participant: someone who doesn't get tired of listening to you explain things badly, doesn't sigh when you take your time, and has exercises ready for when you finish.

Recommended flow:

Step 1:
Explain Python generators with a minimal example.

Step 2:
I'll explain it back in my own words. Correct me if there are errors or vague parts:
[your explanation]

Step 3:
Ask me 3 questions to check whether I understood it.
One should be conceptual, one should be code reading, and one should require writing code.

Step 4:
Here are my answers:
[your answers]

Tell me what I understood, what I got wrong, and what I should review.

Notice the important detail: you're not asking for yet another explanation. You're forcing yourself to produce one. That shift costs something. The kind of cost you feel when you've been reading someone else's code for a while and suddenly have to write your own. But that's exactly where learning starts.

Example explanation you might send:

I think a generator is a function that doesn't return all values at once.
It uses yield to pause execution and continue later from the same point.
That helps avoid loading a whole list into memory.

I'm not sure whether the generator remembers local variables between calls or
recalculates them each time.

That last sentence is the gem: “I'm not sure...” Don't hide it. Explicit doubts are anchors. If you leave them out because you're embarrassed, the AI can't help where it actually matters.

The dangerous part comes next: AI can correct you incorrectly. Yes, shocking, a probabilistic tool can make things up. We're not looking for faith here; we're looking for initial feedback. If the explanation matters, verify it against official docs, tests, or real code.

The “but why?” chain

Some concepts stay blurry because you memorize them too high up. You can repeat the sentence, but you don't know what holds it up.

“We use functions to avoid repeating code.” Fine. But why is repeating code bad?

“Because it makes maintenance harder.” Fine. But why?

“Because if a rule changes, you have to change it in several places.” Fine. And what happens if you forget one?

Now we're getting somewhere.

You can use AI to walk down that staircase:

I want to truly understand why code duplication is a problem.
Run a "but why" chain with me.
Don't give me a long explanation at the start: ask me, wait for my answer,
and then go deeper based on what I say.

Or, if you want a single response:

Explain why we reduce duplicated code in programming using a 5-level chain:
1. Simple answer
2. Why that answer matters
3. What problem appears in a real project
4. What bug it could cause
5. What design principle sits underneath

A useful answer might look like this:

1. We avoid duplication so we don't write the same thing several times.
2. It matters because each copy can become outdated.
3. In a real project, a duplicated discount rule might be changed in one endpoint
   but not another.
4. That can make two users receive different prices for the same purchase.
5. The principle underneath is DRY: one rule should have one source of truth.

This turns a textbook phrase into a causal chain. And a causal chain is easier to remember because it has weight. It isn't “DRY because reasons.” It's “DRY because if you duplicate business rules, production eventually sends you a bill with interest.”

AI is especially useful here because it doesn't get tired of your “but why?” A person, by the fourth one, starts looking at the door. AI doesn't. Unfair advantage; use it.

The connection game

Learning programming is not collecting loose definitions. It's connecting ideas.

A Python list is similar to an array in other languages, but not exactly the same. A dict is like an address book where you look things up by name, but it also has internal rules. A pure function is like an honest vending machine: same input, same output. If only all functions were like that. If only vending machines were too.

AI can help you create those connections if you ask explicitly.

I'm learning Python lists.
I already understand variables and `for` loops.

Explain lists by connecting them to:
1. An everyday analogy
2. How they work with a `for` loop
3. How they differ from a string
4. A common beginner mistake

You can also ask for comparisons between technologies:

How is Django's ORM similar to writing SQL directly?
How is it different?
Explain it for someone who knows basic SELECT, INSERT, and WHERE.

Or connections between patterns:

Is Python's `@timer` decorator related to the design pattern called Decorator?
Tell me what they share, where they differ, and where people usually get confused.

These questions work because they don't let the concept float in the air. They tie it to something you already know. Learning this way is like building a bridge: if there is no starting bank, it doesn't matter how pretty the bridge is; it ends in the middle of the river. Very poetic for a programming tutorial.

If you're learning several things at once — say Python, Git, and a bit of Docker — ask for connections between them. AI can help you see that a development environment is not a pile of unrelated tools, but a system where each piece has a job. And if you overdo it until everything seems connected to everything else, don't worry: that's also a phase. It passes. Mostly.

Verify that you understand, not that you nodded

The danger of learning with AI is that explanations often sound very good. Too good. Clean paragraphs, neat structure, confident tone. Your brain reads that and says: “yes, yes, got it.” Sure it did. Your brain also says “I'll just check one quick thing on YouTube,” and we know how that ends.

To know whether you understand, you need to produce something.

Ask for exercises:

Give me 5 progressive exercises about functions in Python.
Don't give me the solutions yet.
Each exercise should check a different concept.

Ask for code reading:

Show me a small code snippet with lists and loops.
Ask me 4 questions about what it prints and why.
Don't reveal the answer until I respond.

Ask it to find errors in your reasoning:

This is my explanation of the difference between `print()` and `return`:
[your explanation]

Point out errors, incomplete parts, and sentences that sound good but are imprecise.

And above all, ask for variations:

Give me a similar exercise, but with a different trap.

That sentence is more powerful than it looks. If you only solve an exercise identical to the example, you may have memorized the visual pattern. A variation checks whether you understood the idea.

Example:

Concept: `return` ends function execution.

Give me 3 code snippets:
1. One where `return` appears inside an `if`
2. One where there is code after `return`
3. One where a function calls another function that returns a value

Ask me what each one prints and why.

This is less comfortable than reading another explanation. But learning programming was never just reading. Reading is looking at the map. Solving exercises is walking. And yes, sometimes you step in mud. That's called software development.

Be careful: AI can help you learn wrong faster

AI accelerates learning. That sounds good, but there's a flip side: it can also accelerate misunderstandings.

If it explains a concept incorrectly and you don't verify it, you can internalize a wrong idea with a lot of confidence. Worse: because the explanation was clear, you'll be less likely to suspect it. It's the educational equivalent of a bug with good naming: it looks respectable until it breaks something important.

Practical rules:

If the concept is basic and general, use AI to understand and practice.
If the concept affects security, concurrency, money, or real data, verify with official documentation.
If there is code, run it.
If you can't run the code, at least ask AI to trace execution step by step, then compare it yourself.
If two answers contradict each other, don't choose the one that sounds more elegant. Investigate.

Useful verification prompt:

I want to check this explanation before trusting it.
Look for possible inaccuracies, dangerous simplifications, or cases where it doesn't hold:

[paste explanation]

Format:
1. What is correct
2. What is imprecise
3. Example where the explanation fails or needs nuance
4. Corrected version in 5 lines

You can also ask it to cite documentation, but remember: a made-up citation still looks like a citation. If it matters, open the real docs. Yes, in a browser. I know, very medieval.

Template for learning any concept

Save this template and use it when a concept refuses to land:

Role: act as a patient and precise technical mentor.

Context:
I'm learning [concept].
I already understand [previous knowledge].
I'm confused by [specific blocker].
I'm using [language/tool] and want examples in that context.

Task:
Help me understand the concept progressively.
Do not assume I understood it until I can explain it and solve an exercise.

Format:
1. Explanation in 5-7 lines
2. Realistic analogy
3. Minimal example
4. Counterexample or common mistake
5. Comprehension question
6. Small exercise without solution

And after answering the exercise:

This is my solution:
[your solution]

Evaluate it using this format:
1. What is correct
2. What is wrong or incomplete
3. What concept my answer proves I understood
4. What concept I should review
5. A similar exercise with one variation

The key is closing the loop: explanation, production, feedback, variation. Without that last part, it's easy to confuse familiarity with understanding. Familiarity is “this rings a bell.” Understanding is “I can use it when the example changes.” Not the same thing, even if your brain tries to sell you the bundle.

Key concepts from this lesson

Use AI as a directed tutor, not an oracle
Basic questions are valuable when they name the exact confusion
The Feynman technique works best when you explain and ask for correction
The “but why?” chain turns memorized phrases into causal understanding
The connection game ties new concepts to previous knowledge
To verify understanding, produce something: explain, read code, write code, or solve exercises
Clear explanations can still be wrong; verify important claims
A good learning session ends with feedback and a variation of the exercise

💡 Challenge: Pick a concept that still feels uncomfortable — recursion, closures, mutability, return, anything — and use the final template. Don't move to the next topic until you've explained the concept in your own words and solved a variation of the exercise.

Learning with AI is not about receiving faster answers; it's about building a smarter practice system. In the next lesson we'll get into prompts for code generation, and the bar goes up: understanding an explanation won't be enough anymore. You'll need to ask for verifiable code without letting AI turn a small function into a cathedral of boilerplate.

Never stop coding!

Context, role, task, and format: advanced application

Javi Palacios — Thu, 10 Sep 2026 14:37:12 +0000

Here's how it goes: you discover RCTF, try it out, and something clicks. The AI stops handing you vague garbage. You're sold on it. Then the next day you ask it something real — a weird bug, a half-built feature, a module that needs structure — and it falls flat. Same framework, same four letters, completely hollow answer.

Was RCTF a lie? Do you need more acronyms? Are we three lessons away from a full methodology with a keynote, a certification program, and a branded water bottle?

No. The framework is fine. The problem is that last lesson we used it like a form to fill out. This lesson is about using it the way you'd actually use it at work: with real context, iteration, and formats that give you something you can act on — not just a well-formatted nothing.

If the framework isn't fresh in your head, go back to the prompt core principles lesson. This lesson assumes you already know what role, context, task, and format mean.

The mistake: treating RCTF like a form

A prompt can include RCTF and still be bad. That's important.

Look at this:

Role: act as a senior backend developer.
Context: I have an API.
Task: help me improve it.
Format: give me a list.

It has all four letters. It also has the precision of a weather report written by someone glancing out the window: “there appears to be sky.”

The role is too generic. The context doesn't say stack, problem, constraints, or goal. The task has no useful verb. The format asks for a list, but defines no criteria. It's RCTF in name only.

Now compare it with this:

Role: act as a backend engineer specialized in REST APIs with Node.js.

Context: I'm maintaining an Express API that manages orders.
Stack: Node.js 22, Express, PostgreSQL, zod for validation, and Vitest.
Problem: the POST /orders endpoint has too much logic in the controller:
it validates input, calculates discounts, writes to the database, and emits events.
I want to refactor without changing behavior because this is already in production.

Task: propose a refactor plan in small steps. Do not write code yet.

Format:
1. Diagnosis of mixed responsibilities
2. Safe 4-6 step plan
3. Risks for each step
4. Tests I should add before touching code

Same structure. Completely different result.

It's not about length. Each part removes an assumption. And every assumption the AI doesn't have to make is one fewer ticket in the nonsense lottery. Context is almost always where most of them pile up.

Rich context doesn't mean your life story

Context is the most important part of RCTF, and also the easiest one to ruin. People often jump from “I give no context” to “here's half the company in Markdown.” Neither extreme helps.

Rich context isn't long context. It's relevant context.

A good context block answers these questions:

What are you building?
What stack or tools are you using?
What exact area are you touching?
What constraints must the solution respect?
What have you already tried?
What does “good” mean in this case?

Project example:

Project context:
I'm working on an e-commerce backend with Django 5 and Django REST Framework.
The database is PostgreSQL 15. We use Redis for cache and Celery for async jobs.
The code has type hints, tests with pytest, and the goal is to avoid breaking
compatibility with the public API.

Relevant domain:
- orders/: Order, OrderItem, Coupon
- products/: Product, Category, Inventory
- users/: CustomUser, Address

Important constraint:
I cannot change the endpoint contract because published mobile apps consume it.

This isn't a documentation dump. It's the minimum map the AI needs so it doesn't propose something that breaks production in sentence two.

Don't overthink it. Keep a base context block for the project and adapt it per task. Think of it like an .env.example file: not the actual secrets, just enough structure that you're not starting from scratch every time.

Project context gets you in the building. Code context puts you in the right room.

Code context: the bug doesn't live alone

When you ask about a bug, project context helps, but code context does the heavy lifting.

A decent debugging prompt should include four pieces:

When asking for bug help, include:
1. The relevant code
2. The failing test or reproduction steps
3. The full error message
4. What you expected vs what actually happened

The fourth point sounds obvious until you forget it. The AI can read the error, but it can't infer your intent. “This fails” isn't a diagnosis; it's a scream. Understandable, yes. Useful, less so.

Weak example:

This function breaks for users without email. Fix it.

Useful example:

Role: act as a senior Python developer.

Context:
This function normalizes user data imported from CSV. Some users don't have an
email because they come from old records. In that case I want to return None,
not raise an exception.

Code:
````python
def normalize_email(user):
    return user["email"].strip().lower()
````

Error:
KeyError: 'email'

Expected behavior:

- If user["email"] exists and contains text, return it normalized
- If it doesn't exist or is empty, return None
- Keep the function small and easy to test

Task:
Propose the implementation and 3 pytest tests.

Format:

1. Final code
2. Tests
3. Brief explanation of the covered cases

The AI doesn't get better because it has become “smarter.” It gets better because it no longer has to guess the function contract. You gave it the walls of the room before asking it to arrange the furniture.

Iterate: a conversation, not a vending machine

Here's the mental model most people skip: the AI is not a vending machine. You don't drop in a prompt, wait for the answer to fall out, and walk away with your solution. That's how you get responses that technically address the question and solve nothing.

The next mental shift is this: don't try to solve everything in one giant prompt.

AI works better when the conversation moves in rounds. The same way you'd work with a person: first define direction, then get into details, then review, correct, and test. You don't tell a teammate: “design, implement, test, document, optimize, and deploy this system; I'll be back in ten minutes.” Well, maybe at some companies. And then things happen.

An iterative flow could look like this:

Round 1:
Propose a structure for implementing user registration in Flask.
Architecture and files only, no code.

Round 2:
Now implement the User model and validation layer.
Keep the code simple and testable.

Round 3:
Write tests for the happy path and these error cases:
- invalid email
- duplicate email
- password too short

Round 4:
The duplicate email test fails with this error: [paste error]
Diagnose the cause before proposing changes.

Round 5:
Refactor the validation to reduce duplication without changing behavior.

This avoids two classic problems: huge responses that mix incompatible decisions, and changes you can't evaluate because everything happened at once.

Practical rule: each round should change one main thing. Architecture. Implementation. Tests. Debugging. Refactor. If you mix everything, you won't know which part worked and which part just smuggled a gremlin into your repository.

Format: ask for a response you can actually use

Format isn't decoration. It's the interface between the AI's response and your workflow.

If you ask “explain this,” you get an explanation. If you ask “give me a plan with risks and tests,” you get something you can execute. Sounds small, but it's the difference between reading content and moving work forward.

Useful formats for development:

For code generation

Format:
1. Implementation code
2. Example usage
3. Minimal tests
4. Technical decisions and trade-offs

For debugging

Format:
1. Likely root cause
2. Why it happens
3. How to confirm it
4. Minimal fix
5. How to prevent it in the future

For learning a concept

Format:
1. One-sentence definition
2. Realistic analogy
3. Minimal code example
4. Common mistake to avoid

For comparing options

Format:
Table with columns:
- Option
- When to use it
- Advantages
- Risks
- Recommendation for my case

The trick is asking for the format that matches your next action. If you're deciding, ask for a comparison. If you're implementing, ask for steps and tests. If you're learning, ask for an explanation, analogy, and gotcha. The AI doesn't know your next move unless you tell it.

Templates you can reuse

Here are three practical templates. Not to copy like scripture, but to adapt.

Reviewing code

Role: act as a senior developer specialized in [language/framework].

Context:
[What the code does]
[Relevant stack]
[Constraints: don't change public API, keep compatibility, etc.]

Code:
[paste code]

Task:
Review the code for readability issues, potential bugs, and edge cases.
Do not refactor yet.

Format:
1. 3-line summary
2. Issues ordered by impact
3. For each issue: why it matters and how you would confirm it
4. Questions that must be answered before touching code

Designing an implementation

Role: act as a pragmatic software engineer.

Context:
[Feature you want to build]
[Stack]
[Constraints]
[What already exists]

Task:
Propose a simple implementation design. Prioritize small, verifiable changes.
Do not write code yet.

Format:
1. Assumptions
2. Proposed design
3. Files you would touch
4. Step-by-step plan
5. Tests needed
6. Risks and alternatives

Asking for a technical explanation

Role: act as a technical mentor.

Context:
I'm learning [concept]. I already understand [previous knowledge], but I'm stuck on [specific blocker].

Task:
Explain [concept] by connecting it to what I already know.

Format:
1. Short explanation
2. Analogy
3. Minimal example
4. Counterexample
5. Question to check whether I understood it

A good template doesn't replace thinking. It removes mental boilerplate so you can focus on the actual problem. Like editor snippets: helpful when you know what you're inserting, dangerous when you fire them blindly.

What not to put in context

Less fun, but necessary: not all context should be shared.

Don't paste:

API keys
tokens
passwords
real personal data
company secrets
full database dumps
proprietary code if your tool or policy doesn't allow it

Yes, the AI “needs context.” No, it doesn't need your production token. That sentence belongs on a mug, right next to “don't run commands you don't understand.”

If you need to show data, anonymize it:

{
  "user_id": "user_123",
  "email": "user@example.com",
  "plan": "pro"
}

And if the problem depends on a sensitive value, describe it:

The token exists and has a valid JWT format, but the backend returns 401.
I can't share the real token; I can share the anonymized header and claims.

Context quality isn't measured by how many secrets you expose. It's measured by how many assumptions you remove without creating a new problem.

Key concepts from this lesson

RCTF doesn't help if each block is generic; each part must reduce assumptions
Rich context means relevant context, not long context
For bugs, include code, reproduction, error, and expected behavior
AI conversations work better in small rounds than in one giant prompt
Each round should change one main thing
Format should connect the response to your next action
Templates help, but they don't replace thinking
Never share secrets, tokens, or real personal data as “context”

💡 Challenge: Take a real prompt you've used for code help and turn it into a three-round conversation: (1) context and diagnosis, (2) solution proposal, (3) tests or verification. In each round, specify a different format based on what you need to do next.

RCTF is no longer just a checklist: it's a way to direct a technical conversation. In the next lesson we'll look at how to use AI to learn programming concepts without getting stuck with explanations that sound good but collapse under pressure — because real understanding isn't nodding at a convincing answer, it's being able to spot when someone is selling smoke with nice syntax.

Never stop coding!

Search in Vim: find text without losing your flow

Javi Palacios — Wed, 09 Sep 2026 11:33:00 +0000

You're inside a 400-line file. You need to find where userId is used, but your fingers start the classic ritual: j, j, j, j, look around, j, j, k because you overshot, sigh, repeat. Where was that variable? Why are there three similar blocks? Who wrote this endless function? Ah. You did. Always more fun when the culprit is you.

Vim doesn't want you wandering through files like you're searching for your keys in the dark — room by room, hand on the wall. It wants you to jump straight to the place. Search isn't a secondary tool: it's a way to move.

Two kinds of search

In Vim there are two search families worth separating early:

Search inside the current line: f, F, t, T
Search across the file: /, ?, n, N, *, #

The first helps you move quickly inside one specific line. The second lets you jump between matches across the whole file.

If you're coming from Visual mode, this fits nicely with what you already know: search can become part of a selection. Press v, search with /, and Vim extends the selection up to the match. Not magic; just Vim's grammar doing overtime.

Searching for characters inside a line

Start with a line like this:

const totalPrice = calculatePrice(quantity, unitPrice);

Place the cursor at the beginning of the line, on the c in const.

f{character} finds the next character on the same line and places the cursor on top of it:

fp

That command jumps to the p in totalPrice.

f stands for find. Easy enough. For once, Vim didn't call it zq or something that looks like a router spell.

The backward version is F{character}:

F=

It searches for = to the left from wherever you are.

The important difference comes with t and T.

t{character} searches forward, but stops right before the found character:

t(

In the line above, that leaves you right before the ( in calculatePrice(...).

T{character} does the same thing backward: it searches to the left and stops just after the found character.

The mental table looks like this:

Command	Direction	Where the cursor lands
`f{c}`	Forward	On the character
`F{c}`	Backward	On the character
`t{c}`	Forward	Before the character
`T{c}`	Backward	After the character

Why does t exist if we already have f? Because sometimes you don't want to land on the character; you want to stop right before it so you can operate precisely.

For example, to delete up to but not including the opening parenthesis:

dt(

From const totalPrice = calculatePrice..., that deletes from the cursor up to just before (. If you used df(, it would also delete the parenthesis. Sometimes you want the door; sometimes you want the doormat.

Repeating character search with ; and ,

After using f, F, t, or T, repeat the same search with ;:

f,
;
;

Imagine this line:

createUser(name, email, role, isActive);

f, jumps to the first comma. Each ; jumps to the next comma. Tiny command, constant real-world use.

To repeat in the opposite direction, use ,:

Yes, ; goes forward and , goes backward. Is it intuitive? Sort of. Will you end up using it without thinking? Also yes. Vim has many things that feel like private jokes at first and later become muscle memory.

Searching across the file with /

To search forward across the file, use /:

/userId

Press Enter and Vim jumps to the next occurrence of userId.

This changes how you move. Instead of counting lines or hammering j, you type what you're looking for. If the file is a city, / is taking the subway. You're not walking door to door checking nameplates.

To search for the next occurrence, press n:

To go back to the previous occurrence, press N:

Important detail: n repeats the search in the same direction you originally used. If you searched with /, n goes forward. If you searched with ?, n goes backward.

Searching backward with ?

? is like /, but it searches backward:

?userId

After that:

n keeps searching backward
N reverses direction and searches forward

This sounds like a tongue twister until you've used it twice. Short rule: n repeats, N reverses.

If you ever press n and the cursor goes the “wrong” way, Vim isn't being dramatic. The last search probably started with ?. It happens. Breathe, press N, move on.

Searching the word under the cursor with `*` and `#`

This is one of those commands you should pick up early because it removes a lot of noise.

Place the cursor on a word and press *:

Vim searches forward for the next occurrence of that whole word.

Press # and it does the same thing backward:

Typical case: you're on userId, press *, then walk through its uses with n. No typing the word, no opening a side panel, no reaching for the mouse like you're asking the editor for permission.

There are also g* and g#, which search partial matches. The difference:

Command	What it searches for
`*`	Whole word forward
`#`	Whole word backward
`g*`	Partial match forward
`g#`	Partial match backward

If you're on user, * searches for user as a whole word. g* may also find userId, currentUser, or users, depending on the text. Useful, but be careful: searching too broadly is like asking for “some food” and getting the supermarket inventory.

Search highlighting: hlsearch, incsearch, and noh

When you search, Vim can highlight all matches. That's controlled by hlsearch:

:set hlsearch

From then on, each search leaves matches highlighted.

You can also enable incsearch:

:set incsearch

With incsearch, Vim shows matches while you type the pattern. Type /use, and before pressing Enter you already see where you'll land. Very useful for avoiding blind searches.

Now comes the classic Vim moment: you enable hlsearch, search for something, finish the job, and the file stays highlighted like someone attacked your screen with a marker and too much coffee.

To clear the current highlight without disabling the option, use:

:nohlsearch

Or the short version:

:noh

This doesn't turn hlsearch off forever. It only clears the current search; the next search will highlight again. That's what you want most of the time.

Case sensitivity and precise searches

You can force a case-insensitive search with \c:

/userid\c

That finds userid, userId, USERID, and so on.

You can force a case-sensitive search with \C:

/userId\C

That searches exactly for userId, respecting uppercase and lowercase letters.

There are global options like ignorecase and smartcase, but you don't need to go there yet. For now, \c and \C give you local control when you need it. Not everything needs to become permanent configuration. Yes, even in Vim.

Search and replace: first contact

Full substitution deserves its own lesson later, but you need the basics here because substitution is tied closely to search.

To replace on the current line:

:s/var/let/g

That changes every var to let on the current line.

To replace across the whole file:

:%s/var/let/g

The % means “the whole file”. The final g means “all occurrences on each line”, not just the first one.

And here's the version you should use when you're not 100% sure:

:%s/var/let/gc

The c asks for confirmation at each change.

Global replacements without confirmation are fine when you know exactly what you're doing. When you don't, it's like using a chainsaw to open a cardboard box: technically it works, but you'll spend a while explaining the result.

Search as motion

The most powerful thing about search in Vim isn't finding text. Every editor can do that. The powerful part is that search is also a motion.

That means you can combine it with operators from Normal mode's grammar:

d/userId

That deletes from the cursor to the next occurrence of userId.

You can also use searches after entering Visual mode:

v/error

That selects from the cursor to the next occurrence of error.

This is where Vim stops feeling like a list of isolated commands and starts behaving like a small language: operator + motion + repetition. Search isn't “find text”; it's telling the cursor where the next destination is.

Key concepts from this lesson

f{c} and F{c} search for a character on the line and land on it
t{c} and T{c} search for a character but stop before or after it
; repeats the last character search; , repeats it in the opposite direction
/pattern searches forward; ?pattern searches backward
n repeats the search; N reverses direction
* and # search for the word under the cursor forward or backward
:noh clears the current highlight without disabling hlsearch
:%s/old/new/gc replaces across the file with confirmation
Search also works as a motion inside Vim's grammar

💡 Challenge: Open a real code file and practice without using arrows or j/k for long movements. Search for a variable with *, walk through its uses with n and N, jump between commas with f, and ;, and try a safe replacement with :%s/old/new/gc using names you can undo without drama.

You now know how to move through a file without walking line by line. In the next lesson we'll cover marks and jumps: how to leave “bookmarks” inside code and return to previous positions without depending on your memory, which is already busy remembering passwords, commands, and why you opened that browser tab.

Never stop coding!

Releasing new versions of our projects using Git tags

Javi Palacios — Tue, 08 Sep 2026 08:29:47 +0000

We're learning a lot of new things to master Git, but until now we haven't said anything about the versions of our projects. We know that you are very advanced in your project and thanks to Git you are working in a more efficient way. You are about to publish the version 0.1 of your project, so people can try it and leave their opinions, but… How the heck we create a new version of our software in Git? Let's go to it!

In Git there is a function to add tags to our commits, which are only a few pointers (like HEAD or each of the branches, as we saw before), this allows us to reference a commit that we want to be able to locate and access it easily. We can actually create tags for any commit we want to locate quickly once time has passed, but it's true that this function is generally used to launch versions of our applications.

FYI: There are two types of tags, annotated and lightweight tags.

Lightweight tags

First we will focus on the lightweight tags, which are the easiest to learn. This type of tags is usually used to locate a specially relevant commit but not a release of a new version. Why? Because you can only add a label with a name and this doesn't seem very useful, isn't it? It's a kind of reminder, usually a temporary one.

If you want to add the tag to the most recent commit just run the git tag v0.1 command, and if we use the git log --oneline --decorate command we'll see that now our HEAD also has the tag: v0.1 pointer; if we want to add a tag to a previous commit you can also do it, either through the hash of the commit (the code that references the commit located first in the log command) or, as we've learned to do, referencing it in a relative way from the most recent commit (HEAD), like: git tag v0.1 HEAD~2.

Annotated tags

In simple words, an annotated tag is something like a commit as it's treated as an object by Git; in this type of tags we can add a message that explain the reason for having added that tag, in addition, the date it was added and who added it will be saved; that's why it's great for our code versioning, since more information is stored and in the message we can write what are the changes that this new version adds.

The command is very similar to the one we have already learned, but adding some parameters. If we want to write a short message, we can do it as in commits: git tag -a v0.1 -m "Testing Git tags" but if you want to write a longer message, which is recommended, just write git tag -a v0.1 so that Git opens us the text editor that we've configured previously to write everything we want. Logically we can also add annotated tags for previous commits: git tag -a v0.1 -m "Testing Git tags" HEAD~2 easy peasy, right?

Listing tags

We can also get a list of all added tags, and the easiest way is through the git tag command. So easy for you guys, huh? Well, what if you already have a mature development and you have many added versions? Holy shit! That list would be very long! But fortunately there's a way to filter the results. If we want to filter the added tags of the 0.* versions we could execute the git tag -l "v0.*" command.

Getting more information about a tag

If we've added an annotated tag, with the git show v0.1 command we can see all the information related to the tag but also with the commit to which it refers; if we've added a lightweight tag, then we'll only get information about the commit to which it refers because from the tag there would be no information to obtain.

Removing tags

At any time we can delete a tag, whether it's an annotated tag or not, with the same command: git tag -d v0.1. This command doesn't need more explanation, isn't it?

Sending a tag to a remote node

If you want to send a certain tag to a remote node (if you do not know what a remote is, take a look at Creating our first repository on GitHub) you can do it in the same way as we'd send a new branch: git push origin v0.1 and if you want to send more than one tag you can execute the command git push origin --tags to send them all with a single command.

Working with tags on remote nodes

When sending tags to remote nodes like GitHub or GitLab we offer users who visit our projects the information that a new version was released but also that they can download it easily, and for convenience it's created automatically. In GitHub, for example, when a new tag is sent, it obviously appears in the section of tags, but also in the releases one, therefore create a new version of our application so that users can download it is a quick and easy task.

Now you can no longer say that you've not shared with the world a version of your application (I hope an open source application) because you didn't know how to do it.

Never stop programming!

Defining functions in Python: def, parameters, and return

Javi Palacios — Fri, 04 Sep 2026 10:56:54 +0000

You copy three lines of code. Then three more. Then the same three again, but with a different number. At first it feels productive. Ten minutes later your file looks like a haunted photocopier: lots of repetition, very little intention, and every tiny change has to be made in four different places because apparently we enjoy suffering.

That's where functions come in. Not as some academic ritual with fancy terminology, but as a way to tell Python: "this operation has a name; run it whenever I ask."

What is a function?

A function is a reusable block of code. You give it a name, put instructions inside it, and later you execute that block by calling the function.

Think of a coffee machine. You don't want to manually repeat every step each morning: grind beans, heat water, press button, stare into the void while life compiles. You want to press make_coffee() and let the process happen. A function is that: a name attached to a sequence of steps.

In the previous lesson you worked with lists and methods like append() and remove(). If you think about it, you've already been using functions constantly: print(), len(), range(). The difference now is that you're going to create your own.

Your first function with def

In Python, you define a function with the def keyword:

def greet():
    print("Hello, Python")

This defines the function, but it doesn't run it yet. It's like putting a recipe in a drawer: it exists, but nobody is cooking.

To execute it, call the function by name with parentheses:

def greet():
    print("Hello, Python")

greet()

Hello, Python

The basic structure looks like this:

def function_name():
    # Function body
    statement_1
    statement_2

Two details matter:

The def line ends with :
The function body is indented

If you forget the indentation, Python complains. And this time Python is right. Indentation tells Python which code belongs inside the function and which code is outside. It's not decoration; it's syntax.

Why functions matter

Look at this code:

price = 25
tax = price * 0.21
total = price + tax
print(total)

price = 40
tax = price * 0.21
total = price + tax
print(total)

price = 99
tax = price * 0.21
total = price + tax
print(total)

It works. Duct tape on a leaking pipe also works for a while. That doesn't make it architecture.

The issue isn't that the code is long; the issue is that the same idea is repeated. If the tax rate changes tomorrow, you have to update it everywhere. Miss one place and congratulations: you've created an accounting bug, which sounds boring until it bites.

With a function:

def calculate_total(price):
    tax = price * 0.21
    total = price + tax
    print(total)

calculate_total(25)
calculate_total(40)
calculate_total(99)

30.25
48.4
119.79

Now the logic lives in one place. That's the DRY principle: Don't Repeat Yourself. Not because repetition is morally wrong, but because repetition multiplies the number of places where bugs can hide.

Parameters and arguments

In this function:

def calculate_total(price):
    tax = price * 0.21
    total = price + tax
    print(total)

price is a parameter. It's the variable the function expects to receive.

When you call the function:

calculate_total(25)

25 is an argument. It's the actual value passed into that parameter.

The distinction sounds like quiz material until you need to explain code precisely:

Parameter: the name in the function definition
Argument: the value sent when calling the function

Like a reserved seat versus the person sitting in it. The seat is the parameter; the person is the argument. If you're like me when I started, you'll call everything a parameter for a while. You'll survive. Python won't confiscate your keyboard.

You can define multiple parameters:

def show_user(name, age):
    print(f"{name} is {age} years old")

show_user("Ana", 34)
show_user("Luis", 28)

Ana is 34 years old
Luis is 28 years old

Order matters: Python assigns the first argument to the first parameter, the second argument to the second parameter, and so on. In the next lesson we'll look at more flexible ways to call functions, but for now keep the simple rule: order wins.

return: giving a value back

So far our functions print things. That's fine for seeing output, but useful functions usually return a value so the rest of your program can keep working with it.

That's what return is for:

def add(a, b):
    return a + b

result = add(5, 3)
print(result)

The difference between print() and return is massive:

print() displays something on the screen
return gives a value back to the code that called the function

This matters. print() is like saying something out loud. return is like handing someone the tool they need to continue the job. One creates output; the other lets your program move forward.

Look at this example:

def create_message(name):
    return f"Hello, {name}"

message = create_message("Marta")
print(message.upper())

HELLO, MARTA

Because the function returns a string, you can store it, transform it, put it in a list, compare it, whatever you need. If it only printed the string, the value would disappear into the terminal like tears in production logs.

return exits the function

When Python reaches a return, it leaves the function immediately:

def classify_age(age):
    if age < 18:
        return "minor"

    return "adult"

print(classify_age(15))
print(classify_age(30))

minor
adult

If age is less than 18, Python returns "minor" and doesn't continue running the rest of the function. This lets you write clearer functions, especially when you want to handle simple cases early and leave the general case at the end.

Don't stress about patterns yet. For now, understand this: return doesn't just send a value back; it also marks the exit.

Functions that return None

In Python, every function returns something. If you don't write a return, the function returns None automatically.

def greet(name):
    print(f"Hello, {name}")

result = greet("Nora")
print(result)

Hello, Nora
None

Feeling like "wait, I didn't ask for that None"? Fair. Python does it anyway.

None means "no value here". It's not 0, not "", not False. It's its own thing: a special value that represents the absence of a useful result.

This usually appears when a function performs an effect — like printing to the screen — but doesn't return data for the rest of the program to use. Later, when you start writing larger programs, the difference between "doing something" and "returning something" becomes extremely important.

Function names

Function names follow the same convention as variables: snake_case.

def calculate_discount(price, percentage):
    return price - (price * percentage / 100)

The name should explain what the function does. Don't be mysterious with your future self. Your future self is not an archaeologist looking for a side quest.

def c(p, x):
    return p - (p * x / 100)  # ❌ Too cryptic


def calculate_discount(price, percentage):
    return price - (price * percentage / 100)  # ✅ Clear intent

A good rule: if you have to read the function body to understand why the function exists, the name probably needs work.

A practical case: simple calculator

Let's build a tiny calculator using functions. No interface, no strange menus, no eval() — let's not summon demons for sport.

def add(a, b):
    return a + b


def subtract(a, b):
    return a - b


def multiply(a, b):
    return a * b


def divide(a, b):
    if b == 0:
        return "Cannot divide by zero"

    return a / b

print(add(10, 5))
print(subtract(10, 5))
print(multiply(10, 5))
print(divide(10, 5))
print(divide(10, 0))

15
5
50
2.0
Cannot divide by zero

Each function has a clear responsibility. add() adds. subtract() subtracts. divide() divides and protects the problematic case. The code is simple, but it already has structure.

Could you write all operations one after another instead? Of course. You could also store all your socks in the oven. The question isn't whether it can be done; the question is how much you'll suffer when the program grows.

Key concepts from this lesson

A function is a reusable block of code with a name
def defines a function; calling the function executes its body
Parameters live in the definition; arguments are the values sent when calling
return gives a value back and exits the function
If a function has no return, it returns None
print() displays information; return lets you keep using the value
Function names should use snake_case and describe intention
Functions reduce duplication and make code easier to change

💡 Challenge: Create four functions: add(a, b), subtract(a, b), multiply(a, b), and divide(a, b). Then create a fifth function, show_result(operation, result), that prints a message like "Addition: 15". Test every operation with several numbers, including division by zero.

Functions are the first serious step toward modular code. You're no longer writing an endless sequence of instructions; you're naming ideas, separating responsibilities, and building pieces you can reuse. In the next lesson we'll go deeper into default parameters, keyword arguments, *args, and **kwargs — the part where functions stop being a door and become a Swiss Army knife.

Never stop coding!

Advanced Dockerfile instructions: ARG, ENV, ENTRYPOINT and more

Javi Palacios — Wed, 02 Sep 2026 08:49:57 +0000

Most Dockerfiles have a few lines that everyone copies from an example that worked once and never questions again. ENTRYPOINT and CMD near the bottom. ARG and ENV somewhere near the top. The container starts, the app runs, and nobody asks too many questions.

Until it breaks. Or until someone on the team notices the API key getting passed through ARG — which shows up in the image history for anyone to read — or asks why the container ignores the command you pass to docker run. That conversation should have happened earlier. This lesson is it.

ARG vs ENV

ARG or ENV? Which one persists into the container? Which one disappears after the build? Can you combine them? Does the order in the Dockerfile matter? They look similar — both define variables, both accept a name and an optional default value — but they exist at completely different moments in the Docker lifecycle.

ARG defines a variable that only exists during the build process. Once the image is built, it's gone. The container that runs from that image never sees it. Use ARG for things that affect how the image is built: the Node version, the app version string, a compile-time flag.

ENV defines an environment variable that persists into the running container. Use ENV for anything your application needs at runtime.

ARG NODE_VERSION=20
FROM node:${NODE_VERSION}-alpine

ARG APP_VERSION=1.0.0
ENV APP_VERSION=${APP_VERSION}

WORKDIR /app
COPY . .
RUN npm ci
CMD ["node", "index.js"]

NODE_VERSION only exists long enough to pick the base image. After that, it's gone. APP_VERSION is explicitly bridged from ARG to ENV — that's how a build-time value makes it into the running container.

You can override ARG at build time, and ENV at runtime:

# Override ARG during build
docker build --build-arg NODE_VERSION=22 -t my-app .

# Override ENV when running
docker run -e APP_VERSION=2.0.0 my-app

The security gotcha you need to know about

ARG is not a safe place for secrets. Values passed through ARG end up in the image history:

docker history my-app

IMAGE         CREATED       CREATED BY
abc123def456  2 hours ago   CMD ["node", "index.js"]
...           ...           ARG API_KEY=s3cr3t          ← right there

If you've passed an API key, token, or any credential through ARG, it's recoverable from the image by anyone who can pull it. This is covered in detail in Dockerfile security best practices — if you skipped that one, it's worth going back.

The rule: build-time secrets to BuildKit build secrets (next lesson). Runtime secrets to environment variables injected by your secrets management system, never hardcoded in the Dockerfile.

ENTRYPOINT vs CMD

If you're like most people when they first encounter this, you've copied those lines from Stack Overflow, seen that sometimes both appear and sometimes only one, and assumed Docker has its quirks. It doesn't. It has concrete rules, and once you understand them everything clicks.

CMD defines the default command a container runs. It's fully replaceable — pass a different command to docker run and CMD is ignored entirely.

ENTRYPOINT defines the executable that always runs when the container starts. You can't override it with a regular argument — you need --entrypoint explicitly.

When you use both, CMD provides the default arguments to ENTRYPOINT.

# CMD only — fully replaceable command
FROM ubuntu:22.04
CMD ["echo", "hello world"]

docker run my-image               # → "hello world"
docker run my-image echo "bye"   # → "bye"  (CMD replaced)

# ENTRYPOINT only — fixed executable
FROM ubuntu:22.04
ENTRYPOINT ["echo"]

docker run my-image               # → ""  (nothing, no args)
docker run my-image "hello"      # → "hello"

# ENTRYPOINT + CMD — the most useful pattern
FROM ubuntu:22.04
ENTRYPOINT ["echo"]
CMD ["hello world"]

docker run my-image               # → "hello world"  (default)
docker run my-image "other text" # → "other text"  (CMD replaced)

The ENTRYPOINT + CMD combination is what you want for CLI tools packaged as containers: the tool is fixed, the arguments are defaults you can override without knowing anything about the image internals.

If you're following along but it's not fully clicking yet, that's fine — this is the combination that gets googled most often by people who've been using Docker for months. The 90% case is exec form in ENTRYPOINT with CMD as default arguments. The rest comes with practice.

Shell form vs exec form

Both instructions come in two flavors:

# Shell form — runs via /bin/sh -c
CMD echo "hello"
ENTRYPOINT echo "hello"

# Exec form — executes directly, no shell involved
CMD ["echo", "hello"]
ENTRYPOINT ["echo", "hello"]

Use exec form for ENTRYPOINT. Shell form runs your process as a child of /bin/sh, which has two annoying consequences: OS signals like SIGTERM (sent when stopping a container) don't reach your process because the shell intercepts them, and on minimal images without a shell the container simply won't start. With exec form, your process is PID 1 and receives signals directly.

HEALTHCHECK

This is the instruction no one adds until a container fails silently in production and it takes longer than it should to notice. After that, they add it to everything.

HEALTHCHECK tells Docker how to verify a container is functioning correctly. Docker runs the specified command on a schedule and updates the container's status: starting, healthy, or unhealthy.

FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

CMD ["node", "index.js"]

The parameters:

--interval: how often the check runs (default: 30s)
--timeout: if the command takes longer than this, it's a failure (default: 30s)
--start-period: grace period at startup before failures start counting (default: 0s)
--retries: how many consecutive failures before marking as unhealthy (default: 3)

The check command should return 0 for healthy and 1 for unhealthy. The || exit 1 ensures that if curl fails — because the server isn't responding or returns an HTTP error — the check reports failure too.

docker ps

CONTAINER ID   IMAGE     STATUS
a1b2c3d4e5f6   my-app    Up 2 minutes (healthy)

That (healthy) in docker ps means the HEALTHCHECK is running and passing. Docker Compose and orchestrators use this status to know whether a container is ready to accept traffic, whether it needs to be restarted, and whether to consider a deploy successful.

If your image doesn't have curl — Alpine or distroless images — use wget or a small script in your app's runtime:

# With wget (Alpine)
HEALTHCHECK --interval=30s --timeout=5s \
  CMD wget -q --spider http://localhost:3000/health || exit 1

# With Node.js runtime
HEALTHCHECK --interval=30s --timeout=5s \
  CMD node -e "require('http').get('http://localhost:3000/health', r => process.exit(r.statusCode === 200 ? 0 : 1))"

VOLUME and EXPOSE

Here's the part nobody documents well because it's genuinely a bit odd: EXPOSE doesn't expose anything and VOLUME doesn't mount anything. They're very formal comments that Docker decided to turn into instructions. The naming is optimistic.

EXPOSE

EXPOSE declares which port the container listens on. It does not open that port on the host. It does not make the container accessible from outside. It does nothing at runtime. It's executable documentation — it tells anyone reading the Dockerfile what port to publish, and tools like Docker Compose can discover it automatically.

EXPOSE 3000

To actually publish the port to the host, you need -p when running:

docker run -p 8080:3000 my-app
# Host port 8080 → container port 3000

EXPOSE without -p or ports: in Compose is invisible from the outside. Add it anyway — it's good documentation practice and some orchestrators use it for service discovery.

VOLUME

VOLUME declares a mount point inside the container. Docker will automatically create an anonymous volume for that path when the container starts, ensuring data persists even if the container is removed.

VOLUME ["/app/data", "/app/logs"]

What it doesn't do: it doesn't define where on the host the data lives (that's -v in docker run or volumes: in Compose), and it doesn't save you from having to specify the volume if you want control over it.

# Without specifying — Docker creates an anonymous volume
docker run my-app

# Named volume — recommended
docker run -v my-data:/app/data my-app

# Bind mount — host directory
docker run -v $(pwd)/data:/app/data my-app

The primary use of VOLUME in a Dockerfile is to document which paths contain data that shouldn't be lost. It also has a practical side effect: any content copied into that path before the VOLUME instruction is included in the initial volume state. Any COPY or RUN that writes to that path after VOLUME won't behave as expected.

⚠️ For this reason, put VOLUME near the end of the Dockerfile, after copying everything that needs to be there.

With ARG, ENV, ENTRYPOINT, CMD, HEALTHCHECK, VOLUME, and EXPOSE in your vocabulary, you have all the tools to write Dockerfiles that aren't just functional — they're configurable, predictable, and observable.

Next up is BuildKit: how to enable it, what real advantages it brings over the classic builder, and how to use it to handle build secrets and package caches without compromising security.

Never stop coding!

💡 Challenge: Open a Dockerfile from any project you have or from any open source repo. Check whether it uses shell form or exec form for ENTRYPOINT and CMD, whether it has a HEALTHCHECK, and whether environment variables are in ARG or ENV. Is there anything you'd change now?

Pull Requests and code review: how to make your code easy to review

Javi Palacios — Tue, 01 Sep 2026 11:05:18 +0000

I once approved a PR without reading it. Not because I was lazy — because the description was blank, the title was "fix", and the diff had six hundred lines across eleven files with no explanation of what any of it did. I ran out of patience somewhere around file four and clicked Approve. Three days later, it took down the checkout flow in production.

That PR had a reviewer. It had an approval. It had zero useful review.

The Pull Request as a concept is sound: before code reaches main, another human looks at it. The breakdown happens when the PR is written as if review is a bureaucratic gate to get past, instead of a conversation worth having. Getting that distinction right changes everything — how fast your PRs get reviewed, how much friction the process creates, and whether code review makes your team better or just slower.

What a Pull Request is

A Pull Request (PR) — or Merge Request if you're on GitLab — is a formal request to integrate the changes from one branch into another. That's the technical side. The human side is where a team looks at code together before it goes anywhere near production.

The difference from a local git merge is the social layer: a review process, a comment thread, a record of decisions. Not just what changed, but why, who questioned it, what alternatives were considered. That context has a value that's invisible until six months later, when you're in git blame staring at a line you don't understand and there's a PR two clicks away with the entire discussion that led to it.

GitHub, GitLab, Bitbucket, Azure DevOps — different implementations, same concept. I'll use GitHub terminology throughout since it's the most common, but everything translates.

Anatomy of a PR people want to review

The difference between a PR that gets reviewed the same day and one that sits open for three weeks is usually in how it's written, not what it changes.

The title

The title is the first thing a reviewer sees. If it says fix or stuff or update things, you've already made their job harder — they don't know if this is five minutes or two hours, and when they have four PRs queued up, they'll default to the one that gives them the least resistance.

A good title says what the PR does, in the imperative:

✅ feat(auth): add JWT token refresh mechanism
✅ fix(cart): prevent duplicate items when clicking fast
✅ refactor: extract payment service from checkout controller

❌ fix
❌ stuff
❌ changes
❌ WIP do not merge  ← these always get merged

If you've been following commit best practices throughout this course, your PR title can be the main commit message, or a summary that covers all the commits in the branch.

The description

This is where you win or lose the reviewer. A good description answers three questions:

Why? — Context. What problem does this solve or what feature does it add? A link to the ticket or issue if there is one.
What? — Summary of the main changes. You don't need to detail every line — that's what the diff is for — but flag the parts that deserve special attention.
How to test? — Steps to verify it works. Especially important if the reviewer needs to run something locally.

A simple template that holds up:

## What does this PR do?

Adds JWT token refresh to prevent users from being logged out every hour.

## How to test

1. Log in with any test account
2. Wait 15 minutes (or set JWT_EXPIRY=1m in .env.test)
3. Verify the session is still active and the token has been renewed

## Notes

- Extracted refresh logic into AuthService to make it testable
- /auth/refresh endpoint is now idempotent

Closes #342

If the change is visual, add screenshots. A screenshot beats two paragraphs describing what the new button looks like.

Size

The size of a PR has a direct impact on the quality of review it gets — not as a moral judgment, but as a cognitive one.

A reviewer can carefully read a 200-line diff. At 800 lines, they start looking for the Approve button to get out alive. At 2000 lines, "LGTM" arrives in four minutes and nothing real has been reviewed.

The working rule: one PR, one thing. If you're adding a feature and fixing three unrelated bugs on the side, create three PRs. They're easier to review, easier to revert if something breaks, and easier to understand in the history six months from now.

Large feature? Break it down. Component first, business logic next, integration last. Or by layer: data model first, then services, then UI. Each PR should be reviewable in a sitting.

Creating a PR from the terminal

Opening the web interface to create a PR works, but if your workflow is already in the terminal, switching to a browser breaks the flow. GitHub's official CLI — gh — handles this without ceremony:

# macOS and Linux (Homebrew)
brew install gh

# Ubuntu / Debian
apt install gh

# Arch Linux (AUR)
pacman -S github-cli

Authenticate once:

gh auth login

From there, creating a PR is one line:

gh pr create --title "feat(auth): add JWT token refresh" \
             --body "Resolves #342. Adds automatic token refresh." \
             --reviewer teammate1,teammate2

Or interactive mode, which walks you through title, description, and reviewers:

gh pr create

Check your PR status without leaving the terminal:

gh pr list      # All open PRs in the repo
gh pr status    # Only the ones involving you

The web interface makes sense for PRs heavy on screenshots or when your team has a description template configured in GitHub. The flow is the same either way: push the branch, go to GitHub, click "Compare & pull request."

Requesting review

PR is open. Now what? Do you tell someone? Wait for it to show up in their list? Send a Slack message?

Answer: assign reviewers explicitly. In GitHub's sidebar, or with gh pr edit --add-reviewer. If your team has conventions about who reviews what, follow them. If you don't have those conventions, that's a conversation worth having.

One detail that changes a lot: draft PRs. If you have something half-done but want early feedback — on the direction, on whether the approach makes sense before you develop it fully — open it as a draft:

gh pr create --draft

A draft PR is an invitation to a conversation, not a request for approval. The advantage of opening it early is avoiding the opposite problem: two weeks working in the wrong direction, discovering it when the PR already has 800 lines and half of it needs to be thrown out.

When it's ready for real review:

gh pr ready

How to review a PR (when you're the reviewer)

Code review is a skill. Reading the code is the easy part — knowing what to look for and how to communicate it is what takes practice.

What to look for

Not just whether the code works. Also:

Is it correct? — Does it do what the title says? Are there edge cases not covered?
Is it readable? — Will someone understand this six months from now without having to ask?
Is it consistent with the rest of the codebase? — Does it follow established patterns, or introduce a new way of doing things without prior agreement?
Are the tests sufficient? — Not "are there tests?" but "do they cover the cases that matter?"

How to say it

This is where many code reviews go wrong — and where the difference between a review that builds trust and one that damages it lives.

The gap is whether the comment sounds like an attack on the code (and by extension, the person who wrote it) or a conversation about the problem:

❌ "This is wrong"
❌ "Why would you do it this way?"
❌ "Never do this"

✅ "This could cause a race condition if two requests arrive simultaneously.
   What do you think about using a mutex here?"
✅ "Pattern X tends to be more readable for this case. Not blocking,
   just a suggestion — have you considered it?"
✅ "I don't follow why this is done this way. Is there context I'm missing?"

Classify your comments by severity. GitHub doesn't do this natively, but a widely used convention is prefixes:

[blocking] — Must be fixed before merging
[nit] — Minor improvement, not blocking
[question] — Genuinely asking, no judgment attached
[suggestion] — Alternative worth considering

If the comments come out a bit blunt at first, don't stress — it's a learned skill. The intent carries: if you're trying to improve the code rather than demonstrate superiority, the tone usually follows.

The four-second LGTM problem

"LGTM" — Looks Good To Me — is the most common approval in code review. Also the most meaningless when it shows up thirty seconds after a PR with nine hundred lines of diff.

A four-second review doesn't protect main. It doesn't catch the subtle bug in the edge case. It doesn't flag the pattern that will cause problems in two months. All it does is give the author the false impression that someone actually reviewed the code, and the reviewer the false impression that they've done their job.

If you don't have time to review a PR properly, say so. It's more honest and more useful than a courtesy LGTM.

Responding to feedback

You receive comments on your PR. Eighteen of them. This is not a sign that you did something wrong. It's code review working exactly as it should.

First: read all the comments before responding or making changes. Several might be related, and the fix for one resolves others.

Then there are two kinds:

The ones that are right. Fix it, add the commit, mark the conversation as resolved:

git add src/auth/token-service.ts
git commit -m "fix(auth): handle concurrent token refresh requests"
git push origin feature/jwt-refresh

The new commit appears in the PR automatically. The reviewer sees it, verifies the issue is resolved, marks the conversation done.

The ones you disagree with. Explain why — not as a defense of your ego, but as a technical conversation:

"I understand the performance concern, but in our case the JWT payload
is always small (<1KB) and the overhead is negligible.
What if we add a comment explaining this decision?"

If a blocking comment isn't resolving itself in writing, move it to a five-minute call. Text threads in code review are the worst place to resolve technical disagreements — written tone strips nuance and what is a normal difference of opinion starts reading like a conflict.

And if the reviewer was right and you weren't — which happens, no drama — just fix it. Code review isn't a test of how much you know. It's a process where the whole team pushes the code upward.

The Pull Request is where individual work becomes team work. A good PR doesn't just facilitate review — it documents the decision, creates context for the future, and keeps main in the state it needs to be in.

This wraps up the Workflows and Best Practices module. The next module covers advanced Git features — we start with tags, which are how Git marks specific points in history to signal releases and versions.

Never stop coding!

GitHub Flow: the workflow for teams that ship continuously

Javi Palacios — Mon, 31 Aug 2026 13:25:33 +0000

Last year I watched a team spend forty minutes in a retro debating whether to adopt Git Flow. Their product: a SaaS web app. Team size: four developers. Release strategy: merge to main, pipeline deploys in ten minutes, repeat several times a day. The correct answer was no — and it took forty minutes to get there because Git Flow sounds serious and professional, and GitHub Flow sounds like the simplified version for people who haven't figured it out yet.

It isn't. They're different answers to different questions.

Git Flow asks: "how do I manage multiple versions of my software in production simultaneously?" GitHub Flow asks: "how do I get code to production as fast as possible without breaking things?" If your project lives in the second world, Git Flow is process you don't need.

What GitHub Flow is

GitHub Flow was designed by GitHub for teams that practice continuous deployment: code that goes through review, lands on main, and ships to production without waiting for a release window.

The entire model fits in two types of branches:

main — always stable, always deployable. Every commit on main could go to production right now.
Feature branches — short-lived, focused, named after the work they do. Days, not weeks.

No develop. No release/. No hotfix/. Not an oversight — a deliberate design choice. Every layer removed is a layer of coordination the team doesn't have to maintain.

The six steps

Every change in GitHub Flow follows the same cycle. No exceptions, no shortcuts.

1. Branch off main

Before touching anything, create a branch. Name it after the work — not the person doing it, not the date. If you need a refresher on branch naming conventions, the previous tutorial covers exactly that.

git switch main
git pull origin main          # Always start from the latest main
git switch -c feature/123-dark-mode

One rule that sounds obvious and gets skipped more than it should: always start from an updated main. Starting from a stale main creates merge debt before you've written a line.

2. Commit often

Work freely on the feature branch. Small, frequent commits — commit best practices apply here especially, because those commits are what reviewers will read in the PR.

git add src/components/ThemeToggle.tsx
git commit -m "feat(ui): add ThemeToggle component"

git add src/hooks/useTheme.ts
git commit -m "feat(hooks): add useTheme hook with localStorage persistence"

git add src/styles/dark.css
git commit -m "style: add dark mode CSS variables"

The test isn't "is the feature done?" — it's "is this commit coherent on its own?"

3. Open the Pull Request

This is where GitHub Flow diverges from just "using branches." The Pull Request is not only the mechanism to merge — it's the conversation about the code.

Open it as soon as you have something to show. A draft PR is an invitation for early feedback, not a declaration that the work is ready.

git push origin feature/123-dark-mode
# Then open the PR on GitHub, GitLab, or wherever your remote lives

A good PR has a title that says what it does (imperative: Add dark mode support), a description that explains why and how to test it, and screenshots if the change is visual.

If you're like me when I started, the first time someone comments on your PR it feels like an attack on your code. It isn't. It's your team thinking out loud about how the change fits the system. That friction is the process working, not failing.

4. Review and iterate

While the PR is open, teammates review, comment, suggest. You respond: with more commits, with discussion, with explanations. No need to close and reopen — new commits appear in the PR automatically.

# Addressing review feedback
git add src/hooks/useTheme.ts
git commit -m "fix(hooks): persist theme preference across page reloads"
git push origin feature/123-dark-mode

How many approvals before merging is a team decision. What matters is that someone with context looked at the code before it hit main.

5. Deploy from the branch (optional, recommended)

Before merging, some teams deploy the feature branch to a staging environment. If something breaks, the branch can be fixed without touching main.

Platforms like Vercel, Netlify, and Railway generate a preview deployment automatically for every PR. If your infrastructure supports it, this is free validation.

6. Merge to main and deploy

PR approved. Merge to main. In GitHub Flow, this triggers the deploy — either automatically through CI/CD or manually, depending on the team's setup.

# On the platform: click "Merge pull request"
# Or via CLI:
git switch main
git merge --no-ff feature/123-dark-mode
git push origin main
git branch -d feature/123-dark-mode

The branch is gone. The cycle closes. What was a three-day feature branch is now in production.

The main contract

The most important rule in GitHub Flow is also the hardest to hold: main must always be deployable.

Not "usually." Not "except when something's half-done." Always.

This means nothing goes into main without going through a PR. Not "tiny typo fixes." Not "quick config changes." Not "it's urgent, I'll push directly." That bypass is exactly what makes main a branch your team can't trust.

Urgent? Create the branch, open the PR, someone reviews it in ten minutes, merge. Same process. A critical bug in GitHub Flow doesn't have a special track — it's a feature branch born in urgency and merged fast.

GitHub Flow vs Git Flow

	Git Flow	GitHub Flow
Long-lived branches	`main` + `develop`	`main` only
Versioned releases	✅	❌
Continuous deployment	Awkward	Natural
Multiple versions in production	✅	❌
Hotfix handling	Dedicated branch type	Regular feature branch
Web apps / SaaS	Overkill	Ideal
Libraries / SDKs	Fits well	Insufficient

The common mistake is assuming Git Flow is "the serious one" and GitHub Flow is for teams that haven't matured yet. It doesn't work that way. GitHub Flow is the right choice for continuous deployment projects regardless of team size. Git Flow is the right choice for versioned releases and multiple active versions in production.

Most web apps don't have "version 2.1 in production while we develop 3.0." They have main, which is what's in prod. For those projects, Git Flow adds process layers the team will pay for in friction for years.

Tools

lazygit from the terminal gives you a visual overview of branches and stashes without leaving the keyboard:

# macOS and Linux (Homebrew)
brew install lazygit

# Ubuntu / Debian
apt install lazygit

# Arch Linux (AUR)
pacman -S lazygit

Arch users already know the drill. For those who prefer a mouse — GitHub Desktop, GitKraken, and SourceTree all visualize branch flow clearly enough. No Electron in the first one, full Electron experience in the other two.

GitHub Flow won't fix your merge conflicts, won't make feature branches shorter if the team doesn't stay disciplined, and won't substitute for a real code review culture. What it does is remove process layers that, for most web projects, never should have been there.

The next tutorial goes deep on Pull Requests: how to write one people actually want to review, how to give feedback that doesn't read as a personal attack, and what makes a PR easy to merge.

Never stop coding!

The art of the prompt: core principles

Javi Palacios — Fri, 28 Aug 2026 07:49:18 +0000

There's a moment almost everyone hits in their first week using AI for code. You type something like "help me with this error," the AI gives you a generic answer that applies to roughly everything except your actual problem, and you close the tab convinced this whole AI thing is overhyped.

Here's what no one tells you in that moment: the AI didn't fail. The prompt did.

That same model, thirty seconds later, with a structured question, would have given you exactly what you needed. The difference between those two questions isn't advanced technical knowledge — it's structure. And structure can be learned.

Why the same model gives such different answers

A quick callback to Module 1: the AI doesn't "think" in the human sense. It predicts tokens. That means if you give it little context, it fills the gaps with the most probable continuation — and for a vague question, the most probable answer is a vague one. If you want to dig into the mechanics behind that, the hallucinations tutorial covers exactly how this plays out.

To make this concrete, same model, same day, two separate sessions.

Prompt A:

How do I handle errors in Python?

Typical response: a clear explanation of try/except with a ZeroDivisionError example. Correct. Complete. Perfect for a CS101 assignment. Not remotely useful for whatever you're actually building.

Prompt B:

Act as a senior Python developer.

Context: I'm building a CLI tool that makes HTTP requests to an external API.
I need errors to be informative for the end user (no traceback) but I also
need the full traceback logged to a file.

Task: explain how I should structure the error handling for this case.

Format: concise answer, one working code example, and the trade-offs between
the two or three main approaches.

Typical response: a well-designed AppError class, two handling patterns with their pros and cons, a complete example you can adapt directly. What you actually needed.

Same model. Thirty seconds apart. All because of structure.

The RCTF framework

If you're anything like I was when I started, you probably assumed that "asking good questions" was one of those fuzzy skills you pick up with experience — no rules, just intuition. And experience does help. But there's also a concrete framework that works from day one.

It's called RCTF: Role, Context, Task, Format.

It's not magic — it's a mental checklist that guarantees you're giving the AI enough to produce a useful answer. Let's go through each part.

R — Role

You tell the AI what perspective it should respond from. This isn't just cosmetic: it changes how it weighs and prioritizes everything it knows.

# Without a role — generic answer
What's the best folder structure for a Node.js project?

# With a role — calibrated answer
Act as a backend engineer with experience on team-scale Node.js projects.
What's the best folder structure for a Node.js project?

Without a role, the AI assumes a neutral viewpoint — which in practice means "generic beginner." Not because it's trying to be unhelpful, but because when no instruction is given, it defaults to the lowest common denominator. With a concrete role, the level of the response shifts.

The temptation is to write something elaborate: "you are a legendary engineer with thirty years of experience and three published papers on distributed systems..." Don't bother. "Act as a senior [language/technology] developer" covers 90% of cases. The important thing is that it's there.

C — Context

This is where the quality of the response is won or lost. Context is everything the AI can't know on its own: what stack you're using, what constraints you're working under, what the real problem is, what you've already tried.

# Without context
I have a bug in my authentication code

# With context
I have a bug in my authentication code. Stack: Express + JWT + bcrypt.
The issue: when a token expires, the middleware returns 500 instead of 401.
I've already checked the validation middleware and the try/catch looks correct.

The more context you provide, the less the AI fills in with assumptions. A dead giveaway that your context was too thin: when the response starts with "To help you better, I'd need to know..." — that's the AI politely telling you it's working with nothing.

A useful mental model: think about what you'd tell a colleague who knows nothing about your project but is an expert in the technology. Skip the onboarding deck, skip the backstory — just the minimum they need to understand your problem right now. That's context.

T — Task

The specific action you want performed. Not "help me with this" — the exact verb: review, refactor, explain, generate, compare, identify.

# Ambiguous task
Help me with this function

# Concrete task
Review this function and identify potential memory leaks. Don't refactor it
yet — just list the issues with an explanation of why each one is a problem.

The difference between "help me" and "review and identify" is the difference between a response that does everything (poorly) and one that does exactly what you asked.

Negative constraints work too. The AI has a natural tendency toward over-engineering — leave it unchecked and your three-line function comes back as a module with its own logging system and two interfaces. "Don't refactor it yet" stops that from happening.

F — Format

How you want the response structured. Without a format, the AI guesses — and sometimes it guesses right, but often you get three paragraphs when you needed code, or code without comments when you needed an explanation.

# Without format — free-form response
Explain how the Node.js event loop works

# With format — exactly what you can use:
Explain how the Node.js event loop works.
Format: three paragraphs max, an ASCII diagram if it helps visualize the flow,
and a code example showing the difference between synchronous and async execution.

The most useful formats for development work:

Code with comments: for implementations
Numbered list: for steps, procedures, priorities
Comparison table: for choosing between options
Before / after: for refactors
Code only, no preamble: when you understand the pattern and just need the output

The F is what most people skip because it feels optional. Skip it and the AI picks whatever format it feels like. Spoiler: it rarely matches what you needed. It's not optional when you have to actually use the response for something.

Prompt B, revisited

With the framework in mind, Prompt B from earlier doesn't look long or complicated anymore — it's just the four parts in order:

[R] Act as a senior Python developer.

[C] I'm building a CLI tool that makes HTTP requests to an external API.
    I need errors to be informative for the end user (no traceback) but I also
    need the full traceback logged to a file.

[T] Explain how I should structure the error handling for this case.

[F] Concise answer, one working code example, and the trade-offs between
    the two or three main approaches.

Don't worry if your prompts feel long at first. Length isn't the problem — lack of structure is. Over time, writing in RCTF becomes automatic. You stop thinking of it as a framework and it's just how you write.

Common anti-patterns

Three prompt failure modes show up over and over. Worth naming them directly.

Too vague

"Help me with my authentication function"
"This isn't working"
"How do I improve this code?"

Which function? What exactly isn't working? Improve it in what direction — performance, readability, security, test coverage? The AI will try to answer, but it'll be guessing. The practical rule: if your prompt doesn't have at least one concrete verb and one specific piece of context, it's too vague.

No constraints

# ❌ No constraints
"Write a function to manage users"

What language? What operations does it need? Is there a database? What fields does a user have? Is this a full CRUD or just the authentication piece?

Without constraints, the AI generates something plausible that probably isn't what you need. Constraints don't limit the response — they focus it.

# ✅ With constraints
"Write a Python function that takes a user_id, queries PostgreSQL, and returns
the user or None if not found. Use psycopg2. No ORM."

No format specification

# ❌ No format → wall of text
"Explain the differences between SQL and NoSQL"

# ✅ Format specified → something you can actually use
"Explain the differences between SQL and NoSQL.
Format: a comparison table with the most relevant selection criteria for a
backend developer, followed by three concrete use cases."

The no-format version gives you a correct answer. The with-format version gives you a correct answer you can process and use in the next two minutes.

RCTF is, at its core, a four-item checklist. Not glamorous. But the difference in response quality when all four are present is significant enough that it's worth making it a habit before this module is done. Most bad prompts don't fail on all four at once — they fail on one, and one is enough to make the answer useless.

In the next tutorial, we go deep on the C in RCTF: what rich context actually looks like, how iterative prompting works, and how to specify complex formats so the response connects directly to your workflow.

💡 Challenge: Take three questions you've asked an AI recently (or invent them if you haven't) and rewrite each one using RCTF. For each rewrite, identify which of the four parts changes the result the most. The answer tends to be surprising.

Never stop coding!

List methods in Python: append, remove, and list comprehensions

Javi Palacios — Thu, 27 Aug 2026 09:52:43 +0000

You have the list. The one from the previous tutorial — shopping cart items, player names, search results. You created it, iterated over it with for, checked membership with in. All good. Then the user adds a product, removes another, and you want to know how many times "t-shirt" appears in their order history. And that's when you realize: knowing how to create a list isn't the same as knowing how to work with one.

Methods are where lists stop being a static container and become actually useful.

Adding elements

The most common operation by far is append() — it adds one element to the end:

cart = ["t-shirt", "jeans"]

cart.append("sneakers")
print(cart)   # ["t-shirt", "jeans", "sneakers"]

If you need to insert at a specific position, insert(index, value):

cart.insert(1, "socks")   # Insert at index 1
print(cart)   # ["t-shirt", "socks", "jeans", "sneakers"]

Here's the trap that catches everyone exactly once: append() vs extend().

extend() adds every element of another iterable, one by one. append() adds the object as a single element — if you pass it a list, it inserts that entire list as one nested element:

cart = ["t-shirt", "jeans"]

cart.extend(["sneakers", "cap"])
print(cart)   # ["t-shirt", "jeans", "sneakers", "cap"] ✅

cart2 = ["t-shirt", "jeans"]
cart2.append(["sneakers", "cap"])
print(cart2)  # ["t-shirt", "jeans", ["sneakers", "cap"]] ❌ — nested list

Simple rule: adding one item? append(). Merging two lists? extend().

Removing elements

Python gives you four ways to remove elements, and each one covers a slightly different case. It's not that the language is broken — the use cases are genuinely different.

remove(value) deletes the first occurrence of a specific value:

fruits = ["apple", "pear", "grape", "pear"]

fruits.remove("pear")
print(fruits)   # ["apple", "grape", "pear"] — only the first one removed

⚠️ If the value doesn't exist, remove() raises a ValueError. Guard with in if you're not sure:

if "kiwi" in fruits:
    fruits.remove("kiwi")

pop(index) removes by position and returns the removed element. Without an index, it removes the last one:

fruits = ["apple", "pear", "grape"]

last = fruits.pop()      # Removes "grape" and returns it
print(last)    # "grape"
print(fruits)  # ["apple", "pear"]

first = fruits.pop(0)    # Removes "apple"
print(first)   # "apple"

The key difference from remove(): pop() works with indexes and gives back what it removed. Useful when you need the element before discarding it — process and delete in one step.

del is a language statement (not a method). It removes by index or slice, returning nothing:

fruits = ["apple", "pear", "grape", "kiwi", "orange"]

del fruits[1]       # Removes "pear"
del fruits[1:3]     # Removes a slice — "grape" and "kiwi" after the previous del
print(fruits)       # ["apple", "orange"]

And when you need to empty a list entirely while keeping the same reference, clear():

cart = ["t-shirt", "jeans", "sneakers"]
cart.clear()
print(cart)   # []

This isn't the same as cart = []. With cart = [] you create a brand-new list and orphan the old one — anything else pointing to the original won't see the change. With clear() you empty the one you already have, in place.

Modifying elements directly

Access an index and assign a new value:

fruits = ["apple", "pear", "grape"]

fruits[0] = "peach"
print(fruits)   # ["peach", "pear", "grape"]

It also works with slices — replace an entire range at once:

fruits[1:3] = ["mango", "papaya"]
print(fruits)   # ["peach", "mango", "papaya"]

Searching inside a list

index(value) returns the position of the first occurrence:

fruits = ["apple", "pear", "grape", "pear"]

print(fruits.index("pear"))   # 1 — first occurrence

⚠️ Like remove(), it raises ValueError if the element doesn't exist. Protect yourself with in before calling it.

count(value) counts how many times an element appears:

votes = ["yes", "no", "yes", "yes", "no", "yes"]

print(votes.count("yes"))   # 4
print(votes.count("no"))    # 2

List comprehensions: the first time Python surprises you

This is the part where Python does something that, the first time you see it, looks too clean to be real — but it works, and after five minutes you'll wonder why every language doesn't do this.

Say you have a list of numbers and you want a new list with all of them squared. The long way:

numbers = [1, 2, 3, 4, 5]

squares = []
for n in numbers:
    squares.append(n ** 2)

print(squares)   # [1, 4, 9, 16, 25]

That works. Four lines. Now the same operation with a list comprehension:

squares = [n ** 2 for n in numbers]

print(squares)   # [1, 4, 9, 16, 25]

One line. Same result. Read it left to right: "give me n ** 2 for every n in numbers." If that reads almost like plain English, it's because Python designed it exactly that way.

The syntax is [expression for variable in iterable]. Add a condition to filter:

evens = [n for n in numbers if n % 2 == 0]

print(evens)   # [2, 4]

[expression for variable in iterable if condition]. Only elements that satisfy the condition make it into the result.

Feeling like this shouldn't be this comfortable? Fair. Developers coming from Java or C++ stare at this with a mix of confusion and mild jealousy. JavaScript folks have map() and filter() that do the same thing, just with more ceremony. Don't stress if it feels like magic at first — write it slowly, read it aloud, and in a week you'll wonder how you lived without it.

For now, stick to the simple cases: transforming elements and filtering lists. Comprehensions can get more complex, but the pattern is always the same.

Key concepts from this lesson

append(value) adds one element to the end; extend(iterable) merges element by element
remove(value) deletes by value (first occurrence); raises ValueError if not found
pop(index) removes by position and returns the element; without index, removes the last
del list[index] removes by position without returning anything; also accepts slices
clear() empties the list keeping the same reference; different from list = []
index(value) returns the position of the first occurrence
count(value) counts how many times an element appears
List comprehension: [expression for variable in iterable if condition]

That wraps up the Control Flow module. You've gone from conditionals to loops, from basic lists to full method coverage and list comprehensions — you have the tools to handle real collections of data. Next up: functions. You'll learn to define reusable blocks of logic with def, pass parameters, return values, and write code that doesn't need to be read from top to bottom every time something breaks.

Never stop coding!

💡 Challenge: Start with this task list: ["email", "call", "email", "meeting", "email"]. Work through it step by step: (1) add "report" to the end with append(); (2) remove the first task using pop(0) and store it in a variable; (3) remove all occurrences of "email" using a while loop and remove(); (4) create a new list containing only tasks with more than 4 letters, using a list comprehension. Print the result after each step.

Multi-stage builds in Docker: smaller, cleaner images

Javi Palacios — Wed, 26 Aug 2026 08:53:52 +0000

There's a particular kind of waste that happens in Docker images and that everyone accepts as normal until someone points it out: shipping the compiler to production.

You need the Go toolchain to build your binary. You don't need it to run it. You need TypeScript, all your dev dependencies, and a working tsc setup to compile your app. You don't need any of that once the JavaScript exists. And yet, in a single-stage Dockerfile, all of it ends up in the image that gets pushed, pulled, and deployed.

Multi-stage builds are Docker's answer to this: use as many environments as you need to build your application, then carry only what's needed to run it.

The single-stage problem

The most natural Dockerfile for a Go application looks like this:

# ❌ Single-stage — drags the entire toolchain to production
FROM golang:1.22
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o server .
CMD ["./server"]

docker build -t my-app .
docker images my-app

REPOSITORY   TAG       IMAGE ID       SIZE
my-app       latest    a1b2c3d4e5f6   823MB

823 MB. Your application binary is 12 MB. The other 811 MB is the Go compiler, the complete toolchain, Debian system libraries, and everything the build process touched — none of which runs a single instruction in production.

The same pattern plays out with TypeScript. You need typescript, ts-node, type definitions, and dev tooling to compile. Once you have the output JavaScript, none of that is needed. But without multi-stage builds, all of it rides along.

How multi-stage builds work

The mechanism is simple: use multiple FROM instructions in a single Dockerfile. Each FROM starts a new stage with its own isolated filesystem. The COPY --from=<stage> instruction lets you pull specific files from a previous stage into the current one.

The last FROM in the file defines the final image.

# Stage 1: build
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o server .

# Stage 2: run
FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

docker build -t my-app .
docker images my-app

REPOSITORY   TAG       IMAGE ID       SIZE
my-app       latest    f7e8d9c0b1a2   11.2MB

823 MB to 11 MB. The builder stage uses the full Go toolchain to compile. The final image starts from scratch — literally an empty filesystem — and contains only the compiled binary.

A few things worth noting about the build command:

CGO_ENABLED=0: disables CGo and produces a fully statically linked binary. It doesn't depend on any system libraries, which is what makes it work from scratch.
-ldflags="-w -s": strips the symbol table and debug information. Not needed in production, reduces binary size noticeably.
AS builder: names the stage so you can reference it in COPY --from=builder. Name it whatever makes sense.

FROM scratch and its implications

FROM scratch is the smallest possible base: an empty filesystem. Ideal for self-contained Go binaries, but with one consequence — there's nothing else there. No shell, no SSL certificates, no system utilities.

If your application makes HTTPS requests, you need root certificates. Copy them from the build stage:

FROM scratch
# Copy SSL certificates for outbound HTTPS
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

If you need more than a bare binary but less than a full OS, distroless images from Google are the middle ground: no shell, no package manager, but with the essential runtime libraries, timezone data, and certificates already in place. They're also a meaningful security improvement — less surface area, fewer things to patch.

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

Real example: Node.js with TypeScript

The same pattern delivers similar results for JavaScript projects. The gains come from two directions: keeping dev dependencies out of the final image, and not shipping TypeScript source when only the compiled output is needed.

# Stage 1: compile TypeScript
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json tsconfig.json ./
RUN npm ci
COPY src/ ./src/
RUN npm run build

# Stage 2: production
FROM node:20-alpine AS production
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist

RUN addgroup --system appgroup && \
    useradd --system --no-create-home --ingroup appgroup appuser && \
    chown -R appuser:appgroup /app
USER appuser

EXPOSE 3000
CMD ["node", "dist/index.js"]

REPOSITORY   TAG          SIZE
my-app-ts    single       687MB   (typescript, dev deps, source files — all of it)
my-app-ts    multi-stage  198MB   (node, prod deps, compiled dist only)

The builder stage installs everything — TypeScript, type definitions, linters, whatever the build needs — compiles, and its job is done. The production stage starts fresh, installs only runtime dependencies, and copies just the compiled JavaScript from dist. The TypeScript source never makes it into the final image.

Notice the non-root user setup from the previous lesson is in the production stage. Security practices apply to the final image regardless of how many stages preceded it.

Multiple targets in one Dockerfile

This is where multi-stage builds get genuinely powerful: instead of maintaining separate Dockerfiles for development, testing, and production, you can have them all in one file and build whichever target you need with --target.

# Shared base
FROM node:20-alpine AS base
WORKDIR /app
COPY package*.json ./

# Target: development (with hot reload)
FROM base AS development
RUN npm ci
COPY . .
CMD ["npm", "run", "dev"]

# Target: test
FROM base AS test
RUN npm ci
COPY . .
CMD ["npm", "test"]

# Target: builder (intermediate, not a final target)
FROM base AS builder
RUN npm ci
COPY . .
RUN npm run build

# Target: production
FROM base AS production
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

Building each environment:

# Development server with hot reload
docker build --target development -t my-app:dev .
docker run -v $(pwd)/src:/app/src my-app:dev

# Run the test suite
docker build --target test -t my-app:test .
docker run --rm my-app:test

# Production image
docker build --target production -t my-app:prod .

When you don't specify --target, Docker builds the last stage in the file — in this case production. That means docker build . in CI produces the right image without extra flags, and the other targets are available whenever you need them.

The base stage is a shared starting point. Change the Node version or add a global package once, and all four targets inherit it.

Multi-stage builds are one of those features that, once you understand them, make you wonder how you were shipping images before. One Dockerfile, multiple environments, only what's needed at runtime.

Next up is Docker Compose: how to orchestrate multiple containers that need to work together — database, backend, frontend — with a single configuration file and one command.

Never stop coding!

💡 Challenge: Take any Go or Node.js/TypeScript project you have. Write a single-stage Dockerfile and measure the image size. Then convert it to multi-stage and compare. If you don't have a project handy, the minimal HTTP server from the Go example works perfectly.

Dockerfile Best Practices: Security

Javi Palacios — Tue, 25 Aug 2026 10:35:55 +0000

Run this against your current containers:

docker inspect $(docker ps -q) --format '{{ .Name }}: {{ .Config.User }}'

Most of them will return a blank after the colon. Blank means root. You're running production workloads as the most privileged user on the system, and nobody sent you a warning email about it.

Security in Dockerfiles isn't glamorous. It doesn't make it into conference talks the way Kubernetes migrations do. But these four practices are the difference between an image you can deploy to production with confidence and one that's a liability waiting to be discovered. The last lesson covered efficiency — fast builds, lean images. This one covers what keeps you employed.

Don't run as root

Every Docker container runs as root by default. Not a sandboxed root, not an elevated user — actual UID 0, the same root that owns your filesystem. The container is isolated, yes, but isolation has failure modes.

If your application has a vulnerability (and every application does), an attacker who compromises the process gets root-level access to everything in the container. If there's a container escape bug — rare, but they exist and get discovered — that root inside becomes root outside. The principle of least privilege isn't a DevSecOps buzzword; it's the reason you create separate database users instead of using postgres for everything.

# ❌ Default — process runs as root
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

# ✅ Non-root user
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

# Create non-root user and group
RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser

# Transfer ownership, then switch
RUN chown -R appuser:appgroup /app
USER appuser

CMD ["python", "app.py"]

The order matters. WORKDIR creates the directory as root before your user exists. Create the user, transfer ownership, then switch — everything after USER appuser runs as that user, including the final CMD.

You can compress the setup into one layer:

RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser && \
    chown -R appuser:appgroup /app
USER appuser

Official Node.js images include a node user out of the box, which saves a step:

FROM node:20-slim
WORKDIR /app
COPY package*.json .
RUN npm ci --only=production
COPY . .

# node user is already there in official Node.js images
RUN chown -R node:node /app
USER node

CMD ["node", "server.js"]

Scan for vulnerabilities

Your image inherits every vulnerability in its base image and installed packages. A fresh python:3.12-slim can carry dozens of CVEs that have nothing to do with your code. Most developers have no idea what's in their images because they've never looked.

Trivy is the de facto standard for image scanning — open source, fast, zero configuration to get started:

# macOS and Linux (Homebrew)
brew install trivy

# Ubuntu / Debian
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | \
  gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] \
  https://aquasecurity.github.io/trivy-repo/deb generic main" | \
  sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# Arch Linux (AUR)
paru -S trivy

Scan any image with one command:

trivy image python:3.12-slim

python:3.12-slim (debian 12.10)
===============================
Total: 47 (UNKNOWN: 0, LOW: 28, MEDIUM: 14, HIGH: 4, CRITICAL: 1)

That's not a contrived example — base images carry OS-level CVEs from Debian, OpenSSL, and system libraries. Most are LOW or MEDIUM: background noise you live with. HIGH and CRITICAL are what you act on. Filter to see only those:

trivy image --severity HIGH,CRITICAL my-app:latest

You can scan your own built images too, not just bases:

trivy image my-app:latest

If you're on Docker Desktop or Docker >= 24, Docker Scout is already installed and covers similar ground:

docker scout cves my-app:latest

Trivy tends to be more thorough and is what you'll see in most CI/CD pipelines. Scout is convenient if you prefer the Docker Desktop dashboard and don't want another CLI tool — for those who like their metrics with a GUI and don't mind clicking around (no judgment, it works).

Fixing vulnerabilities by rebuilding

Scanning tells you what's there. The fix is often simpler than expected: rebuild against an updated base image.

docker pull python:3.12-slim      # Pull the latest base
docker build --no-cache .         # Rebuild without cache to pick up updates
trivy image --severity HIGH,CRITICAL my-app:latest   # Check again

A surprising number of CVEs in "old" images disappear just from rebuilding. The maintainers of official images patch continuously. If you never rebuild, you never get those patches.

Pin versions correctly

The last lesson covered pinning your base image tag — python:3.12.10-slim instead of python:3.12-slim — for reproducibility. But tags have a security problem: tags are mutable.

Anyone with push access to a registry can overwrite a tag with different content. For official Docker Hub images this essentially never happens, but in CI/CD pipelines pulling from private registries or third-party sources, it's a real supply chain attack vector.

The immutable alternative is the SHA256 digest:

# Get the digest of an image
docker inspect python:3.12-slim --format='{{index .RepoDigests 0}}'

python@sha256:f4f0ef4e6a9a7bbd4954d6e5f4cd89b21f483d39beee63c3a17c840c10f5dd96

# ❌ Floating tag — can change without warning
FROM python:3.12-slim

# ✅ Pinned tag — better, but still mutable
FROM python:3.12.10-slim-bookworm

# ✅✅ SHA256 digest — immutable by definition
FROM python:3.12-slim@sha256:f4f0ef4e6a9a7bbd4954d6e5f4cd89b21f483d39beee63c3a17c840c10f5dd96

A digest is the hash of the image content. That image is exactly that image, forever, on any machine. If someone replaces the tag, the digest still points to the original content.

The same logic applies to system packages. Unpinned installs grab whatever's available today:

# ❌ Unpinned — installs whatever version is current
RUN apt-get update && apt-get install -y curl

# ✅ Pinned version — reproducible
RUN apt-get update && apt-get install -y curl=8.5.0-2ubuntu1

To see what versions are available:

apt-cache madison curl

Do you need digest pinning for every project? Probably not for a personal side project. Yes for production images handling sensitive data or sitting in regulated environments.

Secrets: what must never be in your image

This is where most people trip up. And it makes sense: you need credentials during development. The obvious solution is ENV or ARG in the Dockerfile. It's convenient, it works, and it's a ticking clock.

The obvious problem is "it ends up in git." The less obvious problem is worse: even if it never touches git, every Docker layer is permanently recorded in the image. Delete an ENV in a later layer and the value is still there, visible in the build history:

# ❌ The "cleanup" layer changes nothing
FROM python:3.12-slim
ENV API_KEY=super-secret-key-12345
RUN make some-api-call-using-the-key
RUN unset API_KEY   # Completely useless — still in the previous layer

docker history my-image --no-trunc
# IMAGE          CREATED BY
# ...            ENV API_KEY=super-secret-key-12345  ← visible forever

ARG has the same problem, despite what the docs imply. It doesn't persist as an environment variable in the final image — but it does persist in the layer of the RUN that used it:

ARG API_KEY
# ❌ The value is baked into this layer's metadata
RUN curl -H "Authorization: Bearer ${API_KEY}" https://api.example.com/setup

The right solution for build-time secrets is BuildKit's --mount=type=secret:

# syntax=docker/dockerfile:1
FROM python:3.12-slim
WORKDIR /app
COPY . .

# The secret is available only during this RUN — never stored in any layer
RUN --mount=type=secret,id=api_key \
    API_KEY=$(cat /run/secrets/api_key) && \
    curl -H "Authorization: Bearer ${API_KEY}" https://api.example.com/setup

Pass the secret at build time:

docker build --secret id=api_key,src=./secrets/api_key.txt .

The secret is mounted in a tmpfs during that specific RUN and never written to any layer. The # syntax=docker/dockerfile:1 line at the top enables BuildKit's extended syntax — without it, Docker won't recognize the --mount option.

For runtime secrets — database passwords, API tokens your application needs while running — the answer is straightforward: don't put them in the image. Runtime secrets are injected from outside, at deploy time:

# ✅ The image contains no credentials
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser && \
    chown -R appuser:appgroup /app
USER appuser
CMD ["python", "app.py"]
# The app reads DATABASE_URL from the environment at runtime — never from the image

# In development
docker run -e DATABASE_URL=postgres://... my-app

# In production with Docker Compose
services:
  app:
    image: my-app:latest
    environment:
      DATABASE_URL: ${DATABASE_URL}  # From the host environment, never in the Dockerfile

For more rigorous setups: Docker Secrets in Swarm, Kubernetes Secrets with proper RBAC, or a dedicated secrets manager like HashiCorp Vault. But even the basic pattern of injecting at runtime is infinitely better than credentials baked into a layer that follows the image everywhere it goes.

Non-root user, vulnerability scanning with Trivy, immutable digests instead of mutable tags, secrets out of the image. Four practices that aren't complicated — they just require actually doing them.

Next up is one of the most powerful Docker features for production images: multi-stage builds. You'll learn how to separate the build environment from the runtime environment, with real examples in Go and Node.js that shrink final image sizes from hundreds of megabytes down to a fraction.

Never stop coding!

💡 Challenge: Take your image from the previous lesson's challenge. Add a non-root user and scan it with trivy image --severity HIGH,CRITICAL. Then compare against python:3.12-alpine — there's a surprise waiting for you there.

DEV Community: Javi Palacios

Using AI to learn programming concepts

AI as a tutor, not an oracle

“Stupid” questions that are not stupid

The Feynman technique with AI

The “but why?” chain

The connection game

Verify that you understand, not that you nodded

Be careful: AI can help you learn wrong faster

Template for learning any concept

Key concepts from this lesson

Context, role, task, and format: advanced application

The mistake: treating RCTF like a form

Rich context doesn't mean your life story

Code context: the bug doesn't live alone

Iterate: a conversation, not a vending machine

Format: ask for a response you can actually use

For code generation

For debugging

For learning a concept

For comparing options

Templates you can reuse

Reviewing code

Designing an implementation

Asking for a technical explanation

What not to put in context

Key concepts from this lesson

Search in Vim: find text without losing your flow

Two kinds of search

Searching for characters inside a line

Repeating character search with ; and ,

Searching across the file with /

Searching backward with ?

Searching the word under the cursor with * and #

Search highlighting: hlsearch, incsearch, and noh

Case sensitivity and precise searches

Search and replace: first contact

Search as motion

Key concepts from this lesson

Releasing new versions of our projects using Git tags

Lightweight tags

Annotated tags

Listing tags

Getting more information about a tag

Removing tags

Sending a tag to a remote node

Working with tags on remote nodes

Defining functions in Python: def, parameters, and return

What is a function?

Your first function with def

Why functions matter

Parameters and arguments

return: giving a value back

return exits the function

Functions that return None

Function names

A practical case: simple calculator

Key concepts from this lesson

Advanced Dockerfile instructions: ARG, ENV, ENTRYPOINT and more

ARG vs ENV

The security gotcha you need to know about

ENTRYPOINT vs CMD

Shell form vs exec form

HEALTHCHECK

VOLUME and EXPOSE

EXPOSE

VOLUME

Pull Requests and code review: how to make your code easy to review

What a Pull Request is

Anatomy of a PR people want to review

The title

The description

Size

Creating a PR from the terminal

Requesting review

How to review a PR (when you're the reviewer)

What to look for

How to say it

The four-second LGTM problem

Responding to feedback

Searching the word under the cursor with `*` and `#`