Stop Trying to ‘Learn’ OOP. Just Build Something.

I had to pull a junior dev aside last week. Good kid, sharp. But he was spinning his wheels on a new feature for a client’s membership site. For two weeks, he’d barely written a line of code. When I checked in, he said, “I’m just trying to get a handle on the right design patterns. I want to make sure I really learn object-oriented programming before I start building the classes.”

And that was it. The classic trap. He wasn’t building software; he was chasing a ghost. He was trying to “learn” a topic that has no finish line.

You Can’t ‘Finish’ Learning OOP

Here’s the thing they don’t tell you in the tutorials: you never actually finish learning this stuff. I’ve been doing this for 14+ years, and I’m still picking up new things about object-oriented programming. The landscape is always shifting—new PHP versions, new WordPress APIs, new contexts. It’s a continuous process, not a checkbox you can tick.

I told him about my first big project. I spent a solid month trying to read and understand the Gang of Four design patterns book. I was convinced I needed to know all of it—factories, singletons, observers—before I could write “good” code. Total nightmare. I learned more in the first hour of actually building a crappy, messy, but *functional* widget class than I did in that entire month of theoretical reading. My first attempt was wrong, but it worked. And then I could make it better.

This whole idea of learning as a separate, initial step is a flawed concept, an idea that Carl Alexander also touched on in a post a while back. You’re treating it like an enemy to be studied from afar before the battle. The battle is the classroom. You learn by writing code that solves a problem.

A Practical, Concrete Example

Instead of reading another article, I had him build the smallest possible thing. A single class to handle a simple shortcode. That’s it. A concrete, measurable goal. Not “learn OOP,” but “create a shortcode that displays the user’s first name.”

<?php

class Simple_User_Shortcode {

    public function __construct() {
        // This hook registers the shortcode when the class is created.
        add_action( 'init', array( $this, 'register_shortcode' ) );
    }

    public function register_shortcode() {
        add_shortcode( 'user_firstname', array( $this, 'render_shortcode' ) );
    }

    public function render_shortcode( $atts ) {
        // Don't do anything if the user isn't logged in.
        if ( ! is_user_logged_in() ) {
            return '';
        }

        $user = wp_get_current_user();
        
        // Return the user's first name. Simple.
        return esc_html( $user->first_name );
    }
}

// And to kick it all off:
new Simple_User_Shortcode();

Is this the pinnacle of object-oriented design? Nope. But it’s practical. It works. It isolates a piece of functionality inside a class, it uses a constructor, and it hooks into WordPress. It’s a real-world starting point. We got more done in an afternoon than he had in the previous two weeks. Because he had a tangible goal.

So, What’s the Real Takeaway?

Stop trying to learn and start trying to *build*. The learning is a byproduct. It happens when you’re stuck, when you have to debug something, when you look at your own code a week later and realize there’s a better way to do it. Your text editor is your real classroom.

• Pick a small, real problem. Don’t build a “car” class. Build a plugin that adds a custom field to the user profile page.
• Write the code. Don’t worry if it’s “right.” Just make it work.
• Refactor it later. Once it works, you can improve it. This is where the deep learning happens.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

The beast isn’t OOP itself. It’s the illusion that you can conquer it with theory alone. You can’t. You slay it one line of functional code at a time.