Welcome aboard. If you’ve googled “Python tutorial” you’ve seen this garbage:
for foo in bar:
print(baz[foo])
That’s not teaching. That’s a curse from the 1970s.
Foo, bar, and baz aren’t variables: they’re diseased rats that infest new crew members bunks.
Why it’s poison
- Foo/bar/baz tell you nothing.
- You don’t know what the loop does.
- You don’t know what the data is.
- But hey, the tutorial writer saved three keystrokes.
Future You at 2 AM will see this and start googling “how much do goat herders make per year?”
How sane pirates write code
for poster in posters:
context.log.info(
"Poster processed",
extra={"name": poster["name"], "bounty": poster["bounty"]}
)
Now it reads like English: “For each poster in posters, print the name and bounty.”
Even Zoro can follow this without getting lost.
Pirate Rule #0: Don’t be generic
👉 Foo/bar/baz walk the plank.
👉 Single-letter variables are banned unless you’re literally looping the alphabet.
👉 Name your variables so even Roronoa Zoro can follow the map.
Exercise: Wanted!
Fix this crime:
for d in y:
for o in d["z"]:
print(o["g"])
Rewrite it with names that make sense. (Hint: posters → poster → items → menu_id
)
Welcome to Day 1. Many tutorials start with nonsense like:
for foo in bar:
print(baz[foo])
It runs. But it doesn’t teach.
Why it’s unhelpful
- Doesn’t describe the data.
- Doesn’t describe the operation.
- Creates technical debt before you’ve even learned the language.
How professionals write code
for poster in posters:
context.log.info(
"Poster processed",
extra={"name": poster["name"], "bounty": poster["bounty"]}
)
Readable, structured, and logs in a way Future You can actually filter.
Engineering Rule: Don’t be generic
👉 Ban foo/bar/baz.
👉 Don’t use single-letter variables (except trivial math).
👉 Variables should tell the story of the data they hold.
Exercise: Rewrite the Loop
Given:
for d in y:
for o in d["z"]:
print(o["g"])
Refactor it with:
posters → poster → items → menu_id
- Replace
print()
withcontext.log.info
and structuredextra
.