It’s been quite a while since I last wrote here. Life has a funny way of reshuffling priorities when you least expect it. For those wondering where I’ve been hiding, the answer can be summed up in two words: life happened.

The biggest and most wonderful change? My little coding apprentice (also known as my son) is now almost one year old (11 months tomorrow when I’m writing, exactly…)! He’s recently started daycare and is growing rapidly, making even the fastest software updates look sluggish. Watching him discover the world has been nothing short of magical – and yes, exhausting, too. There hasn’t been much time for personal coding adventures between diaper changes, first-word attempts, and that contagious giggle that could melt even the sternest code compiler.

Speaking of coding, my last update chronicled my ambitious dive into Swift and SQL. Well, friends, I’ve got a confession: I fell into what developers affectionately call “tutorial hell.” You know the drill – jumping from DataCamp to Codecademy, starting courses without finishing them, accumulating half-baked knowledge but never building anything substantial.

So what’s different now? I’ve taken a step back to rethink my approach. Rather than chasing the shiny new programming language or platform, I’ve realized something we often tell our students but forget to apply ourselves: it’s not about the tools. It’s about the thinking.

I’m not making grand promises this time. No declarations about becoming a Swift expert by summer or building the next revolutionary education app. Instead, I’m simply sharing a modest restart to my journey – beginning with the fundamentals of computational thinking and problem-solving through Harvard’s CS50x course. And yes, I’m starting with Scratch – the same visual programming language our elementary students use.

The Tutorial Hell Experience: When Learning Becomes a Maze

If you’ve been following my coding journey, you might remember my enthusiasm for diving into Swift and SQL simultaneously. Picture this: a school principal with stars in his eyes, convinced he could master iOS development while also becoming a database wizard – all while running schools and preparing for fatherhood. Ambition is admirable, right? Sometimes it’s just a fancy word for “setting yourself up for frustration.”

My approach was like trying to learn tennis and golf simultaneously – both involve hitting balls with sticks, so how different could they be? (Spoiler alert: very different). I’d spend a week deep in Swift tutorials, fascinated by building simple iOS interfaces, then suddenly pivot again to SQL because, “Databases are important too!” This context-switching was as effective as teaching algebra one day and poetry the next, expecting mastery.

Then came the platform-hopping. DataCamp’s structured SQL courses seemed perfect until I discovered Codecademy’s interactive Swift lessons. “This is even better!” I’d think I’m abandoning my half-finished DataCamp progress. I’d find another promising platform with “more comprehensive” content a few weeks later. Each transition meant starting fresh, relearning basics with slightly different terminology, and never reaching the advanced content that might actually help me build something meaningful.

Why did this approach fail? For the same reason we tell students not to study for exams by randomly flipping through textbook chapters, I collected puzzle pieces from different boxes without a coherent learning path, never completing a single picture. I was learning syntax without context and commands without purpose, accumulating what seemed like knowledge but was actually just familiarity.

By September, the enthusiasm had waned. Each coding session felt like reopening a book I’d started months ago, struggling to remember where I’d left off. Between school responsibilities and preparing the nursery for our incoming little one, coding became another obligation rather than the creative outlet I’d hoped for. The final straw came after spending an entire Saturday hopping between three different tutorials, ending the day feeling like I’d accomplished nothing.

So, I closed the laptop. Decided that maybe programming wasn’t for me after all.

Looking back, I realize I wasn’t failing at coding—I was failing at learning how to code. There’s a crucial difference that I should have recognized sooner as an educator. Sometimes, knowing when to step back, regroup, and find a better path forward is the wisest decision.

The irony isn’t lost on me that I advocate for structured, sequential learning with clear objectives in my professional life – exactly what was missing from my own coding journey. Sometimes, we need to become students again to remember what effective learning truly requires.

The Parenting Perspective Shift: Learning Lessons From My Tiny Teacher

They say children are our greatest teachers, and whoever “they” are, they’re absolutely right. Becoming a father hasn’t just changed my daily routine – it’s revolutionized my entire approach to learning.

When my son arrived in May 2024, my coding ambitions were temporarily replaced by more pressing skills: mastering the art of one-handed diaper changes, deciphering different cries, and functioning on fragments of sleep. But as the initial fog of new parenthood lifted, I observed something remarkable – a master learner at work.

My little boy doesn’t approach learning with grand plans or ambitious timelines. He doesn’t declare, “By next Tuesday, I shall perfect the art of standing!” Instead, he tries, fails, adjusts, and tries again – day after day, with a persistence that would shame most adults. When he first attempted to roll over, he didn’t give up after three failed attempts and declared rolling “not his thing.” He kept at it, making microscopic improvements until one day – success!

Watching him learn to grab objects was a masterclass in iterative development. First came the wild, uncoordinated swings. Then slightly more controlled movements. Then, the pincer grip began developing. There were no skipping steps, no rushing ahead to more “exciting” milestones.

The parallel to my scattered coding journey couldn’t be more clear. While I had been jumping between advanced Swift concepts and SQL queries without mastering fundamentals, my son was demonstrating the only learning path that actually works: consistent, incremental progress.

Perhaps most humbling was realizing the value of patience. As parents, we never expect a baby to walk before crawling or speak in sentences before babbling. We celebrate each tiny advancement, understanding it’s part of a natural progression. Yet with ourselves, we often expect to leap from novice to expert, growing frustrated when mastery doesn’t come quickly.

Then there’s the matter of time management. Pre-parenthood, I might have dedicated entire weekends to coding, convincing myself that “immersion” was the only way to learn. Now, with a curious crawler demanding attention, I’ve learned that consistent 20-minute focused sessions accomplish more than sporadic marathon efforts. My son doesn’t learn to stand by practicing for 8 hours on Saturday – he practices for brief periods daily.

Problem-Solving First, Language Second

Everyone knows that programming isn’t primarily about memorizing syntax or learning languages but solving problems.

In my previous attempts at learning to code, I’d been obsessing over the “how” before properly understanding the “what.” I was trying to master Swift’s optional binding mechanics and SQL’s join statements without first clarifying what problems I was actually trying to solve.

The true nature of programming isn’t about writing code; it’s about computational thinking—breaking down complex problems into manageable parts, recognizing patterns, creating algorithms, and designing solutions. The programming language is the tool that expresses this thinking, not the thinking itself.

In our schools, we’ve actually been teaching this approach all along. When our elementary students use Scratch to create simple games, they’re not primarily learning about loops and conditionals—they’re learning to decompose problems, think algorithmically, and design systematic solutions. The coding syntax is just the medium for expressing these mental models.

Similarly, when our middle schoolers tackle design challenges, we don’t start by teaching them CAD software commands—we begin with identifying problems worth solving, empathizing with users, and brainstorming possible approaches. The technical skills come later, serving the larger purpose.

The irony is that in my role as principal, I’ve championed this exact approach. I’ve celebrated teachers who focus on critical thinking over memorization, who teach concepts before procedures, who create purpose-driven learning experiences. Yet somehow, in my own learning journey, I’d forgotten these principles.

Back to Basics: The CS50x Journey

With countless online coding resources, choosing the right starting point felt overwhelming. Should I focus on web development? Mobile apps? Data analysis? Each option led down a different rabbit hole of specialized tutorials.

Then I remembered a course that kept appearing in conversations with tech-savvy educators and in “best of” lists across the internet: Harvard’s CS50 Introduction to Computer Science. What caught my attention wasn’t just the prestigious Harvard name (though I won’t lie, that didn’t hurt), but the course’s philosophy. CS50x doesn’t begin by teaching a specific programming language—it starts by teaching you how to think.

The decision to enroll was cemented when I learned CS50x was completely free, self-paced, and designed with beginners in mind. It’s perfect for a busy principal or new dad who might need to pause lessons when a tiny human decides sleep is optional.

My first impression after watching Professor David Malan’s opening lecture? “This is what engaging teaching looks like.” The man dropped from the ceiling to introduce binary numbers, for goodness sake!

Then came the first assignment: create a project in Scratch. Yes, Scratch—the block-based programming environment we use with our third graders. I’ll admit it: my ego took a hit. After all, I had previously been learning “real” programming languages. Returning to Scratch felt like a professional chef being asked to make a peanut butter sandwich.

However, humility is the prerequisite for genuine learning. As I began arranging colorful blocks to create a simple animation, I realized something profound: I was actually thinking more clearly about programming concepts than I ever had while copying and pasting Swift code. Without syntax errors to distract me, I could focus purely on the logic—the sequences, conditions, and loops that form the backbone of computational thinking. As I submit my Scratch project alongside thousands of other CS50x students around the world, I feel a renewed appreciation for the beauty of foundational learning. Starting with basics isn’t a step backward—it’s ensuring the path forward is built on solid ground.

So here I am, a school principal with graying hair, creating animated sprites alongside children a fraction of my age, and feeling not diminished but enlightened by the experience.

The Scratch Project: Musical Memory Game

The project is a musical memory game that combines educational elements with entertainment—a reflection of my dual interests as both an educator and a parent (and ex music teacher of course).

The assignment required using at least two sprites (neither of which could be the default Scratch cat), incorporating at least three scripts, using conditionals, loops, and variables, and creating at least one custom block with inputs.

My solution is a musical memory game featuring five musical note sprites (C, D, E, F, and G) that tests the player’s ability to remember and repeat sequences. Here’s how it works:

1. When the green flag is clicked, the game initializes with a title screen.
2. Pressing the space bar starts the game, switching to the main gameplay backdrop.
3. The game uses a custom block I created called “set random number” which generates a random number between 0 and 4, corresponding to one of the musical notes.
4. When a player clicks on a note, it plays the corresponding piano sound. If the player clicks the correct note (matching the random number), the backdrop changes to indicate success. If not, a different backdrop appears showing the player made a mistake.
5. The game includes an interactive loop that continues until the player decides to end it, with a yes/no prompt asking if they want to continue playing.

What I particularly enjoyed about this project was how it forced me to think about program flow and user interaction. Creating a custom block helped me understand the concept of abstraction—taking a repeated set of commands and packaging them into a reusable component. The conditional statements (if-else blocks) were essential for implementing the game logic, determining whether the player selected the correct note.

Working with variables to track the random number was also enlightening, as it demonstrated how programs maintain state and make decisions based on changing values. The loop structures ensure the game continues until specific conditions are met, showcasing how programs can create persistent experiences.

You can explore the complete project here:

Grade: 8/8. Yeah!

Conclusion: From Tutorial Hell to a Learning Journey

Moving forward, I’m committing to more regular updates (even if they will be less in number) on this blog. Not because I need external accountability (though that helps), but because documenting this journey has value both for me and potentially for others walking similar paths. I’ll share my progress through CS50x, highlighting both the technical concepts I’m learning and the broader insights they generate about learning itself.

These won’t be polished tutorials or expert analyses—there are plenty of those already. Instead, they’ll be honest reflections from a school principal and new dad who’s learning to code one 20-minute session at a time. I’ll share what works, what doesn’t, and all the messy learning in between.

See you in the next post—probably after bedtime, with a cup of tea in hand and CS50 problems waiting to be solved.