Chapter 26 Exercises: Learning to Code

These exercises are designed for active learners — whether you're new to programming or experienced in one language and moving into a new area.

Exercise 1: The Tutorial Escape Test (30–60 minutes)

This exercise tests the difference between tutorial comprehension and genuine programming ability.

Step 1: Find a tutorial, course section, or chapter you've completed recently. Something you "know."

Step 2: Close the tutorial completely.

Step 3: Open a blank code editor. Write a brief comment describing what you're going to implement: a similar problem to what the tutorial covered, but your own version. (Example: tutorial covered building a list with functions → your version builds a simple contact book. Tutorial covered linear regression → your version implements on a different dataset with an original feature.)

Step 4: Attempt to implement it from scratch. No tutorials, no examples, minimal lookup. Allow yourself to look up specific syntax or formula details (not solutions), but only after you've identified specifically what you don't know.

Step 5: After 20–30 minutes of genuine effort (regardless of whether it worked): - What did you implement successfully? - What did you discover you couldn't do without help? - What did you discover you'd thought you understood but didn't?

Step 6: Based on your findings, identify the specific gaps in your understanding. Write them down. These become the targets for your next study session.

Reflection: How close was your felt understanding (while following the tutorial) to your actual ability (when implementing independently)? If there was a large gap, you've experienced the tutorial comprehension illusion firsthand.

Exercise 2: The Rubber Duck Debugging Protocol (10–15 minutes per bug)

This exercise builds the expert debugging habit: understanding cause before attempting fix.

The next time you have a bug in your code, before touching anything:

Step 1: Read the error message carefully. Write down: - What error is being reported? (Exact error type and message) - On what line does the error occur?

Step 2: Form a hypothesis. On paper or in a comment block, write: - "Based on this error, I believe the problem is " - "I believe this is the cause because " - "If my hypothesis is correct, then [this specific test] should confirm it"

Step 3: Test your hypothesis. (Not: make a random change and see if the error goes away. Test: check the specific thing your hypothesis predicts.)

Step 4: If your hypothesis was wrong, update it: "I was wrong about X because Y. My new hypothesis is Z."

Do not make any code change until you have a hypothesis you're confident enough to test.

The goal: Every bug you fix should come with a one-sentence explanation of why it was broken. "It works now" is not a debugging outcome. "The function was receiving an integer where it expected a string because I hadn't converted the user input" is a debugging outcome.

Keep a brief debugging journal for two weeks. At the end, review it: What types of bugs do you make most frequently? What do they have in common?

Exercise 3: Code Reading Session (30–45 minutes)

This exercise develops the code-reading skill that distinguishes experienced developers from beginners.

Choose a piece of open-source code that uses a library or framework you've been working with. Good options: - A function from a library you use (find the source code on GitHub) - A small, well-regarded project on GitHub (filter by "good first issues" in languages you're learning — these tend to be well-organized and accessible) - One function or class from the standard library of your language

Your task: Understand every line.

For each function or logical unit you read: - What does this function do? (Write it in one sentence) - Why is it designed this way? What problem does this design solve? - What alternatives could have been used? Why were they rejected? - What surprised you? What did you not expect? - What idiom, pattern, or technique did you learn that you might apply elsewhere?

You will not understand everything on the first reading. That's fine. Note what you don't understand — then look it up. Return to the code after you've filled the gap.

Reflection after your reading session: - What's one specific pattern, idiom, or design decision you encountered that you'll try to use in your own code? - What did you discover about how experienced developers approach problems that you wouldn't have thought to do?

Exercise 4: Deliberate Practice on Code Katas (3 sessions × 30 minutes)

This exercise introduces structured deliberate practice via code katas.

Step 1: Sign up for Exercism.io (free) in your primary programming language.

Step 2: Choose your starting difficulty level honestly — not the hardest problems you can potentially solve with effort, but problems that will consistently challenge you at your current level.

Step 3: For each kata: - Attempt it without any outside help for the first 15 minutes - If stuck after 15 minutes, you may look up specific technical questions but NOT the solution to the problem itself - Submit your solution - Read 2–3 community solutions that are significantly different from yours - For each community solution: understand every line, understand why the person chose this approach, and write a brief note about what you learned

Step 4: After three sessions, write a brief assessment: - What patterns are you struggling with most? - What have you seen in community solutions that you want to add to your toolkit? - What's your next area to deliberately practice?

Exercise 5: The AI Protocol Challenge (one week)

For one week, follow this strict protocol whenever you use AI assistance for code:

The rule: For every coding task, you must attempt the problem independently for a minimum of 20 minutes before consulting any AI assistant.

During your independent attempt: - Write code, even if it's wrong - Write comments explaining your approach and where it breaks down - Identify specifically what you don't know

After your attempt, if you consult AI: - Ask for conceptual help, not code generation: "I'm trying to do X. I approached it by Y, and the problem I'm running into is Z. What am I missing conceptually?" - If the AI provides code, don't use it until you've read every line and can explain every decision - After the interaction, try to implement the solution yourself from your new understanding

Tracking: Keep a brief log for the week: - What you attempted independently - What you discovered you didn't know (before consulting AI) - What you learned from the AI interaction - What you implemented based on that learning

Reflection at the end of the week: Compare code you wrote after following this protocol to code you'd typically produce. Is it better understood? Did the additional struggle time produce better outcomes?

Reflection Questions

After completing at least two exercises:

1. What is the difference between reading comprehension of code and being able to write it? Where do you currently sit on this spectrum?

2. Have you experienced tutorial hell? What does it feel like from the inside? What is the specific moment when you realized the gap between "following along" and "actually knowing"?

3. What is the one type of deliberate practice (katas, code reading, original implementation, debugging practice) that feels most valuable for your current learning goals?

4. What is the most significant thing you've recently looked up that you discovered you thought you understood but didn't? What triggered the discovery?