bongoDev

30-Day Path: Day 1
Level: Beginner
Suggested focused time: 28 minutes

Learning goal

Understand the month-long learning loop and create a repeatable daily study routine.

Why this matters

A self-guided learner needs more than syntax. For this lesson, the goal is to understand the mental model, run a small example, predict what it does, inspect the real output, then reuse the idea in an engineering-shaped problem.

The daily rule is:

Text

READ → PREDICT → RUN → EXPLAIN → BREAK → DEBUG → BUILD

Do not copy the code and immediately move on. Before execution, write down what you think the output will be. After execution, explain any difference.

Concepts to understand

run code every day
predict output before execution
break code intentionally
debug using evidence
save exercises in Git

First example — run this yourself

Python

message = "Python becomes easier when you practice daily."
print(message)

Expected outcome

Text

Python becomes easier when you practice daily.

If your output differs, first check the Python interpreter, file you executed, exact input values, indentation and spelling before changing the design.

How to read this code

Identify the inputs: literals, variables, function arguments, files or environment values.
Identify the transformation/control flow: calculation, branch, loop, function call or object behavior.
Identify the observable result: returned value, printed line, file change, exit status or raised exception.
Change exactly one input and predict the new result before rerunning.
Explain the example without using the words “it just works.”

Real-world engineering example

Python

days = 30
minutes_per_day = 75
total_hours = days * minutes_per_day / 60
print(f"Study plan: {total_hours:.1f} focused hours")

Expected outcome

Text

Study plan: 37.5 focused hours

Common mistakes to watch for

Editing several things at once after the first failure instead of reading the exact traceback/output.
Copying an example while using a different interpreter, working directory, input file or installed package set.
Ignoring Python's indentation and case sensitivity.
Treating external input—CLI, files, environment variables, network data—as already validated.
Writing a clever one-liner when a small named function would communicate intent better.

Debugging exercise — break it on purpose

Run or inspect this intentionally problematic example:

Python

print("I will learn by doing"

Your debugging goal: Find the syntax error before running the program, then fix it.

Use this workflow before searching for a replacement solution:

Text

1. REPRODUCE
2. READ THE LAST TRACEBACK FRAME / WRONG OUTPUT
3. NAME THE EXCEPTION OR FAILED EXPECTATION
4. INSPECT THE RELEVANT VALUE + TYPE
5. FORM ONE HYPOTHESIS
6. CHANGE ONE THING
7. RUN AGAIN
8. ADD A TEST WHEN POSSIBLE

Hands-on task

Stretch challenge

Take the hands-on solution and improve one of these dimensions: clearer names, a reusable function, explicit validation, better error message, logging, a unit test, or less duplicated code. Do not add complexity unless you can explain the benefit.

Self-check before moving on

You are ready for the next lesson when you can answer:

What problem does this feature solve?
What are the important inputs and output?
What is one common failure mode?
How would you prove your code works?
Where would you use this in a real script, service, automation or debugging task?

Key takeaway

Understand the month-long learning loop and create a repeatable daily study routine. Learn the concept by executing it, but keep it by explaining, breaking, debugging and applying it.