Why ‘Write More Code’ Is Terrible Advice for Developers

I got a call from a new client. Their WooCommerce checkout page was throwing a fatal error, but only sometimes. A real ghost in the machine. They’d paid another developer to add a custom fee based on the payment gateway, and it had worked for a week before things started falling apart. Total mess.

After about ten minutes of digging, I found the problem. A twenty-line function in functions.php, copied straight from some tutorial blog. The dev who put it there knew how to write code—or at least, how to copy and paste it. What he didn’t know was how to read code, and that was the entire problem.

The Stack Overflow Trap: You’re Just Gluing Parts Together

We’ve all been there. You hit a problem, you Google it, and you find a snippet that looks like it works. You paste it in, and the problem goes away. Ship it. The issue is, you’re just practicing your Google-fu. You’re not actually getting better at solving problems; you’re just getting better at finding parts built by other people.

My first thought with this client’s site was to just delete the function and write it properly myself. But I stopped. Instead of writing a single line, I spent the next 20 minutes just reading the WooCommerce core files related to the cart and checkout process. I wanted to see the architecture, the hooks, the filters. I wanted to understand the *context* of the problem. Trust me on this, it’s a critical step.

And here’s the kicker: The original function was 90% right. The logic was basically sound. But it was hooked into woocommerce_cart_calculate_fees, which was too early in the process and didn’t have access to all the session data it needed. The fix wasn’t a full rewrite. It was moving the logic to a later hook and adding one conditional check.

// The WRONG way - hooked in too early
add_action( 'woocommerce_cart_calculate_fees', 'legacy_custom_gateway_fee' );
function legacy_custom_gateway_fee( $cart ) {
    // This might fail because the chosen gateway isn't set yet
    $chosen_gateway = WC()->session->get( 'chosen_payment_method' );
    if ( $chosen_gateway == 'custom_gateway' ) {
        $cart->add_fee( 'Custom Fee', 15 );
    }
}

// The RIGHT way - found by reading core code
add_action( 'woocommerce_review_order_before_payment', 'correct_custom_gateway_fee' );
function correct_custom_gateway_fee() {
    // This hook runs later, ensuring session data is available
    $chosen_gateway = WC()->session->get( 'chosen_payment_method' );
    if ( $chosen_gateway == 'custom_gateway' ) {
        // Logic to add fee would be different here, maybe via JS or another hook
        // The point is: the CONTEXT is correct.
    }
}

So, What’s the Real Fix?

Stop focusing only on writing code. Start reading it. A lot of it. You’ll start to see patterns. You’ll build a mental map of how a complex system like WordPress or WooCommerce actually works. This whole idea builds on a concept I first read about on carlalexander.ca, and it’s one of the most important shifts a junior or mid-level developer can make.

• Next time you use WP_Query, don’t just use it. Find the class in the WordPress core files and read through the constructor. See how it builds the SQL.
• When a plugin breaks, don’t just deactivate it. Open the files and trace the function that’s throwing the error. Try to understand what it was trying to do.
• Look at how popular plugins like ACF or Gravity Forms structure their code. You’ll learn more from that than from ten blog tutorials.

Seniority isn’t about knowing every function. It’s about understanding the system well enough to know where to find the answer. And the answer is always in the code itself.

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.