Be Wrong and Proud

Chronicles of Python Series — Part 2

Has anyone else felt like they’re losing their mind learning to code, or is it just me?

In my last piece, I told you about falling down the Python rabbit hole on my Chromebook, building decentralized identity systems, wrestling with unsaved files, and celebrating every successful JWT signature. I showed you the victories. But today? Today we’re talking about the stumbles.

Here’s what I’ve discovered: the communities I’ve joined are filled with people who struggled with the same things I’m struggling with right now. There’s something deeply comforting in knowing that thousands of developers have stared at the same error messages, questioned the same concepts, and felt the same frustration when their code didn’t run because they forgot to save (again).

When you’re learning something new — whether it’s Python, blockchain, or anything else, it’s okay to do what works for you. Practice makes you better. Learn publicly if that’s your style. Sure, there will always be people asking, “Why are you sharing this?” But there’s also that crucial 1% cheering you on for doing something hard in public. Plus, it holds you accountable.

I’ve learned to be wrong and proud. When I started, I tortured myself reading stories of people who learned Python in three weeks or mastered blockchain in a month. But we’re all walking different paths at different paces, and that’s the truth worth remembering.

So let’s get back to basics. While I’m building DID systems and wrestling with cryptographic primitives, I want to share the foundational concepts I wish someone had explained to me when I started. Because even when you’re working on complex projects, you’re still using these fundamentals every single day.

So let’s talk about the fundamentals, but not the way you’ve seen them before, as I have added a little twist.

Variables: The Art of Naming Things You Don’t Understand Yet

Here’s what nobody tells you about variables when you’re starting: you’re going to name things badly, and that’s fine. You are kinda supposed to do that, that’s part of learning.

Python
x = "did:ethr:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb1"

Versus:

Python
issuer_decentralized_identifier = "did:ethr:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb1"

When I started, I obsessed over having the “perfect” variable name before I even understood what the variable would do. Here’s the secret: your variable names will evolve as you better understand your problem.

Start with x. Then rename it to user_did. Then, realize it's specifically an issuer's DID and rename it again. Each rename is proof that you're understanding the problem more deeply and finding solutions more quickly.

Variables aren’t just storage containers. They’re the words you use to think about your problem. And just like learning a new language, you’ll start with broken grammar before you get to poetry. Don’t quote me here.

The evolution is the point.

Data Types: Reality Has Structure (And So Does Your Code)

Python has data types. Strings, integers, lists, dictionaries, booleans. Don’t act brand new, you’ve seen the tutorials. But here’s what clicked for me:

Data types aren’t arbitrary categories — they’re different ways reality manifests in code.

A string is language. A number is a quantity. A boolean is true or false. A list is a sequence. A dictionary is a relationship.

I keep trying to store everything as strings because it feels “safe.” Then I realized: this isn’t how information actually exists. Information has structure.

A dictionary isn’t just a “data structure.” It’s the recognition that things have properties, and properties have names, and relationships matter.

Here’s where it gets interesting: choosing the wrong data type is often the first sign you don’t fully understand your problem yet.

I spent two days trying to manage multiple credentials as separate variables — credential_1, credential_2, credential_3. The frustration of managing credential_47 is what taught me I needed a list. The problem taught me the solution.

Every data type exists because someone had a problem that previous types couldn’t elegantly solve.

Tuples exist because sometimes order matters but change doesn’t. Sets exist because sometimes presence matters but duplicates don’t. Understanding why these types exist is more valuable than memorizing their syntax.

If Statements: The Art of Branching Reality

If statements are decision trees. But here’s what made them click for me:

Every if statement is you anticipating a future you can't predict.

When I verify a credential, I don’t know if it’s valid. So I write code now, in the present, for a situation that will happen later when I’m not here, and I don’t know which branch of reality will take.

That’s profound when you think about it.

Here’s where beginners and experienced developers diverge: beginners learn if/else syntax. Experienced developers learn what questions to ask.

The difference isn’t syntax. It’s paranoia. Don’t laugh, I am onto something. It’s the accumulated weight of every time your code broke because you assumed data would be clean, present, and correct.

If statements are where you encode your distrust of the future.

And the beautiful part? Each if statement you write is a tiny prediction. When your code runs and takes the else branch, you predicted that possibility. You were ready for it. That's not just programming; that's foresight.

Loops: Doing Boring Things So You Don’t Have To

Loops are repetition. Everyone knows this. But here’s the reframe:

When I needed to generate 100 test DIDs for my system, I could have written generate_did() a hundred times. Or I could write a loop and let the computer do it.

That for loop isn't just "efficient code." It's the recognition that your time is finite and valuable, and the computer's isn't.

But here’s where it gets deeper: loops taught me about scale.

Generating one DID? Easy. Generating 100? You need a loop. Generating a million? You need to think about memory. Generating a billion? You need to rethink your entire approach.

Loops are where you learn that scale changes everything.

The patterns that work at a small scale break at a large scale. And that’s not a bug in Python, that’s a fundamental truth about systems.

Functions: Creating Words That Didn’t Exist

Functions are “reusable code blocks.” That’s what every tutorial says. But that’s not what they are.

Functions are how you name your intentions.

When I write verify_credential_signature(credential, public_key), I'm creating a word that didn't exist before. Now, every time I want to verify a signature, I don't have to think about JWTs or ECDSA algorithms. I just think: "verify."

The mistake beginners make is thinking they need to understand the implementation before they can use the abstraction. You don’t. That’s why the function exists.

And here’s the meta-lesson: as you write more code, you’re not just building a program — you’re building a language. Your functions are the vocabulary. Your modules are the grammar.

Good code reads like a well-written essay.

Django: When Your Code Becomes A World

Everyone learns Django as a “web framework.” But here’s what Django actually is: an opinionated answer to the question “how should a web application be structured?”

Django doesn’t just give you tools. It gives you a worldview.

Django’s structure is the accumulated wisdom of thousands of developers who built web apps before me.

The separation of models, views, and templates isn’t about being “correct.” It’s about what happens six months later when you need to change your database schema without touching your URL routing. Or redesign your frontend without breaking your API.

The structure is for future-you.

Here’s the part that blew my mind: Django models are executable documentation. They simultaneously define your database schema, document your domain model, and provide an API for interacting with your data.

One class. Three functions. That’s elegant.

Django taught me that good architecture makes the implicit explicit.

The Meta-Lesson: Code Is Thinking Made Visible

Here’s what ties all of this together:

Variables force you to name things. Data types force you to understand structure. If statements force you to anticipate. Loops force you to recognize repetition. Functions force you to abstract. Django forces you to organize.

Every programming concept is a different lens for looking at problems. Remember this.

Learning to code isn’t about memorizing syntax. It’s about developing a taste for which abstraction fits which problem and then solving it.

And yes, you’ll choose wrong. A lot. I’ve written functions that should have been classes. Django projects that should have been Flask. Flask projects that should have been Django.

Being wrong is how you develop taste.

Be wrong. Be proud. Then be different next time. Be better

Where I Am Now

I still write variables namedx and y. I still overcomplicate solutions before finding the simple one. I still question whether I'm doing things "the right way."

But I also structure applications that separate concerns. I write code that future-me will understand.

The gap between “I don’t understand this” and “I built this” isn’t talent. It’s time plus reflection. It’s being willing to write bad code and then make it better.

It’s being wrong, out loud, until you’re less wrong.

The tutorials that show you perfect code are lying. Perfect code doesn’t exist on the first try, or the tenth. What exists is iteration, refinement, and the slow accumulation of understanding.

So write messy code. Use terrible variable names. Fight your framework. Then step back, reflect, and make it better.

The stumbles are the point. The confusion is the curriculum. The frustration is proof you’re pushing against the edge of your understanding.

Be wrong. Be proud. Be better tomorrow.

That’s the only path through the rabbit hole.

Be Wrong and Proud was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.