Category: Programming

  • Learning Python by Doing: A Hands-On Guide for Active Learners

    Learning Python by Doing: A Hands-On Guide for Active Learners

    Remember the last time you tried to learn something from a textbook, only to realize weeks later that you couldn’t actually do anything with that knowledge?

    Maybe you highlighted every other sentence, took good notes, and still drew a blank when it came time to apply what you’d learned.

    If you’re nodding along, you’re not alone and you’ve probably discovered something important about yourself: you’re a learn by doing person.

    The good news? Python is practically made for hands-on learners. Unlike subjects that require years of theory before practice, Python lets you write your first useful program on day one.

    But here’s the challenge: with thousands of tutorials, courses, and resources available, how do you find the ones that actually let you build instead of just watch?

    Let me show you exactly how to learn Python through action, experimentation, and real projects that matter.

    Why Learning by Doing Actually Works

    Before we dive into resources, let’s talk about why this approach is so effective. When you learn by doing, you’re engaging in what educators call “active learning.”

    Your brain doesn’t just passively absorb information. It creates neural pathways through problem-solving, debugging, and the satisfying moment when your code finally works.

    Think about it: would you rather spend three hours watching someone else cook, or one hour actually making a meal (even if you burn the garlic)?

    The second option teaches you more because you’re dealing with real problems: the pan’s too hot, you forgot to chop the onions first, the timing is trickier than it looked.

    Python is the same way. Every error message is a lesson, every bug you fix makes you stronger.

    Plus, when you build something actual, even something simple like a dice roller or a to-do list.

    You get instant proof of your progress. That motivation is gold when you’re learning something new.

    Two Paths for Hands-On Python Learning

    There are two main approaches to learning Python by doing, and both work brilliantly. The key is choosing the one that matches your personality.

    Path 1: Interactive Courses with Built-In Practice

    Some people thrive with a bit of structure. A roadmap that tells them what to learn next while still keeping their hands on the keyboard. Interactive coding platforms are perfect for this.

    Unlike traditional video courses where you watch passively, these platforms put you in the driver’s seat from minute one.

    Boot.dev takes you from complete beginner to building real backend systems through gamified lessons. You’re not just reading about functions; you’re writing them to solve actual challenges.

    Each module builds on the last, and you’re coding in every single lesson.

    The gamification aspect (earning XP, leveling up) might sound gimmicky, but it’s surprisingly effective at keeping you engaged during the inevitable frustration moments.

    Codecademy offers a more traditional course structure but with a critical difference: the entire experience happens in their browser-based code editor.

    When they teach you about lists, you immediately practice creating and manipulating them. When they introduce APIs, you make real API calls right there in the lesson.

    It’s like having training wheels that gradually come off as you progress.

    CodinGame takes a completely different approach it teaches you Python through games and puzzles. You might write code to control a robot through a maze or solve optimization challenges.

    It’s fantastic if you need that extra layer of fun to stay motivated, and it sneakily teaches you algorithmic thinking along the way.

    When to choose this path: If you like having clear milestones, appreciate some guidance on what to learn next, or tend to get overwhelmed by too many choices.

    Path 2: Project-Based Learning (Jump Into the Deep End)

    Now, if you’re the type who learns best by figuring things out as you go, who gets excited by a challenge and enjoys the detective work of finding solutions.

    Project-based learning might be your sweet spot.

    This approach flips traditional learning on its head. Instead of learning Python concepts and then building something, you decide what to build first and learn the concepts as you need them.

    Want to create a web scraper? You’ll learn about requests, HTML parsing, and file handling because your project demands it.

    Practical Tutorials Project-Based Learning is a treasure trove of tutorials where you build complete, functional projects.

    We’re talking about creating your own neural network from scratch, building a web crawler, making a command-line game, or crafting a personal finance tracker.

    Each tutorial walks you through building something real while explaining the Python concepts along the way.

    What makes this resource special is its diversity. You can choose projects that align with your interests.

    Love data? Build a data visualization dashboard.

    Into gaming? Create a text-based adventure or a simple 2D game.

    Want to automate your life? Build a web scraper or an automated email sender.

    Build Your Own X takes this even further with the philosophy that you only truly understand something once you’ve built it yourself.

    This collection guides you through recreating technologies you use every day: your own Git, your own Docker, your own BitTorrent client, your own text editor.

    These aren’t toy projects, they’re simplified versions of real systems.

    Building them gives you a profound understanding not just of Python, but of how software actually works under the hood.

    Yes, they’re challenging.

    Yes, you’ll get stuck. But that’s exactly where the learning happens.

    When to choose this path: If you’re self-motivated, don’t mind googling for answers, get energized by challenges, or already have a specific project idea in mind.

    The Bottom Line: Just Start Building

    The beauty of learning Python by doing is that there’s no single “right” path.

    There’s only the path that keeps you coding.

    Whether you thrive with the structured guidance of interactive platforms or prefer diving headfirst into building real projects, both approaches share one critical element: your hands stay on the keyboard.

    Choose the approach that excites you most.

    If you’re unsure, try one for a week and if you are not feeling it.

    Switch to the other. The worst thing you can do is spend weeks researching the “perfect” way to learn while never writing a single line of code.

    Your Next Steps Start Now

    Learning Python by doing isn’t just an effective strategy.

    It’s the most sustainable one.

    When you build things, you stay motivated because you can see your progress.

    When you solve real problems, the knowledge sticks because you earned it through struggle and triumph.

    So here’s my challenge to you: close this tab, pick one resource from this post (just one!), and write your first five lines of code today. Not tomorrow. Not when you have more time. Today.

    Because at the end of the day, the best way to learn Python isn’t through the perfect course or the perfect tutorial.

    It’s through that messy, frustrating, exhilarating process of building something that doesn’t work, then making it work, then making it better.

    Your first project is waiting. What are you going to build?

    Enjoyed this post?

    Here’s the thing: I discover stuff like this all the time. Type quirks. Debugging shortcuts. FastAPI gotchas. Lessons from the real world. And, I share them all in my newsletter.

    Want them delivered to your inbox?

  • Why I Choose Maintenance Work Over New Features (And You Might Too)

    Why I Choose Maintenance Work Over New Features (And You Might Too)

    Imagine this: Your team’s Slack channel lights up with an announcement. “We’re building a brand new feature!” Developers start claiming tickets, excitement buzzes through the air, and everyone wants a piece of the action. Meanwhile, I’m quietly raising my hand for something else entirely. That hideous bug that’s been lingering in the backlog, or the refactoring task everyone’s been avoiding.

    I know what you’re thinking. Who actually prefers maintenance work?

    Well, I do. And before you write me off as some kind of rockstar developer, hear me out.

    About 70% of the time, I actively choose maintenance work over new projects. Not because I lack ambition or creativity, but because I’ve discovered something most developers overlook:

    Maintenance work offers a kind of professional satisfaction that new features simply can’t match.

    The Unexpected Freedom of Low Expectations

    Let’s talk about the elephant in the room, PRESSURE.

    When stakeholders greenlight a new project or feature, they’re not just giving you creative freedom. They’re making an investment, and investments come with expectations. If the company pours $10,000, $50,000, or more into your new feature, you’d better believe there’s a return-on-investment conversation happening in every planning meeting.

    This creates what I call “creative anxiety.” You’re supposed to be innovative, but you’re also supposed to deliver measurable business value. You’re given freedom, but it’s freedom within very specific guardrails. Ship too slowly, and you’re blocking revenue. Ship something that doesn’t gain traction, and suddenly you’re in post-mortem meetings explaining what went wrong.

    Maintenance work flips this dynamic entirely.

    When you’re fixing bugs, refactoring legacy code, or optimizing existing features, expectations are refreshingly straightforward: make it work better. There’s no quarterly revenue target tied to your pull request. No one’s calculating the ROI of a bug fix the same way they scrutinize new feature development.

    This doesn’t mean maintenance work isn’t important. It absolutely is. But it operates under a different kind of pressure. Instead of “will this make us money?” the question becomes “does this make our product more reliable?” That subtle shift changes everything.

    The Freedom to Experiment

    Here’s what this looks like in practice: Imagine volunteering to refactor a complex form flow that’s accumulated years of technical debt. The code is brittle, test coverage is minimal, and every change takes three times longer than it should.

    Because this is “just maintenance,” you have freedom to experiment with patterns you’ve been wanting to try. You can introduce better state management, restructure components for clarity, add comprehensive documentation—things that might get pushback on a high-stakes feature launch.

    The beauty is that you can iterate and improve without someone constantly asking about the business impact. Your success metric is simple: does it work better than before? That simplicity is liberating.

    The Deep Dive: Where Real Expertise Lives

    There’s another reason I prefer maintenance work, and it’s arguably more important: depth of understanding.

    Working on new features often means staying at the surface level. You’re building something fresh, which means you’re focused on the immediate requirements and getting it shipped. You learn the new thing you’re building, but you don’t necessarily learn why the system works the way it does.

    Maintenance work forces you to go deep.

    Understanding the “Why” Behind the Code

    When you’re debugging a production issue or refactoring a legacy module, you don’t have the luxury of ignoring context. You need to understand:

    • Business Rules: Why does this validation exist? What edge case is it protecting against?
    • Historical Decisions: Why was this architecture chosen? What constraints existed at the time?
    • System dependencies: How does this component interact with everything else?

    This deep dive transforms you from someone who just writes code into someone who truly understands the product.

    For example, while fixing what seemed like a simple data inconsistency bug, you might discover an undocumented business rule that’s been embedded in conditional statements for years. Nobody wrote it down it just exists in the code.

    With that knowledge, you can:

    1. Document the business rule properly for the first time
    2. Suggest a simpler implementation that reduces complexity
    3. Identify other places where similar logic should be applied consistently
    4. Save the team weeks of confusion on future features

    You can’t gain this level of insight when you’re only building new things. New features are built on assumptions about how the system works. Maintenance work shows you the reality.

    The Unexpected Career Advantage

    Here’s something nobody tells junior developers: being the person who understands the existing system is incredibly valuable.

    Teams are full of people who want to build new features. They’re much rarer to find developers who can confidently say, “I know exactly why that error occurs, where it’s happening, and how to fix it without breaking three other things.”

    This expertise makes you:

    • The go-to person when things break in production.
    • A better architect because you’ve seen what works and what doesn’t.
    • A valuable code reviewer who catches subtle bugs others miss.
    • A strategic advisor who can estimate effort accurately and flag risks early.

    When New Features Do Call

    Don’t get me wrong I’m not anti-innovation. That remaining 30% of the time, I absolutely love diving into new features. But I approach them differently because of all the maintenance work I’ve done.

    When I do work on something new, I build it with maintenance in mind:

    • Clear documentation because I’ve struggled with undocumented legacy code
    • Comprehensive tests because I’ve debugged too many “it works on my machine” bugs
    • Thoughtful architecture because I’ve refactored too many “we’ll clean this up later” compromises that never got cleaned up

    My maintenance work makes me a better feature developer. And my feature development gives me more empathy for the maintenance work I’ll do later.

    The Question Back to You

    So here’s what I’m curious about: Where do you find your professional satisfaction?

    Are you energized by the blank canvas of a new project, or do you get a rush from finally solving that mysterious production bug? Do you prefer building new systems, or do you love the detective work of understanding existing ones?

    There’s no right answer here. Development teams need both types of people. The innovators who push forward and the maintainers who ensure everything keeps running smoothly.

    But if you’ve never given maintenance work a fair shot, I’d encourage you to volunteer for that next refactoring ticket or bug hunt. You might be surprised at how much you learn, how much creative freedom you actually have, and how satisfying it feels to make something better rather than just making something new.

    After all, in a world where everyone wants to build the next shiny feature, there’s something quietly powerful about being the person who makes sure everything we’ve already built actually works.

    What’s your take? Are you team new-features or team maintenance? Let me know!

    Enjoyed this post?

    Here’s the thing: I discover stuff like this all the time. Type quirks. Debugging shortcuts. FastAPI gotchas. Lessons from the real world. And, I share them all in my newsletter.

    Want them delivered to your inbox?