The Dream Job

Well done. You’ve landed the dream job.

You made it through:

  • A recruiter call.

  • An intro meeting.

  • A 30-question multiple choice quiz.

  • A 6-hour unpaid take-home tech test.

  • A technical interview and live code review.

  • A culture fit call where someone asked, “If you lost your toe, how would that make you feel?”

  • A personality test that made you question if you’re too emotional, in general.

  • A final interview with the CEO (“errr… what’s your name again?”).

You even accepted a slightly lower salary because “they’re going to help you grow.”

Throughout you’ve been grilled about TDD, solid principles, DRY, N+1 problems, clean code, best practices, leet code, random cool new technologies, the global economic impact of saying ‘thank you’ to ChatGPT etc etc.

You’re the best. Fact.

Your first day arrives…

Day One

You boot up your shiny laptop.

Nobody meets you, they’re all in meetings that could’ve been Slack messages.

You finally track someone down.

“Oh right! You’re starting today! Yeah uh… hang on I’ll find someone who knows the setup.”

Six hours, and five cups of regret later, you finally spin up your local dev environment.

You open the codebase.

It’s PHP 5.5.9.

No tests.
One file has 5,000 lines and looks like it’s been wrote by someone under the heavy influence of a psychedelic drug.

Comments like “don’t delete this it breaks stuff” and “not sure why this works but don’t touch it.”

You're assigned a task to refactor a method for improved readability — an intro meant to ease you into the codebase.

The Horror: Deeply Nested If Statements

You resist the urge to walk into the sea and crack on.

Here’s a real monstrosity. It works, but it’s painful to read:

function processOrder(User $user, Cart $cart): Checkout {
    if ($user) {
        if ($user->isActive()) {
            if ($cart) {
                if (!$cart->isEmpty()) {
                    if ($user->hasPermission('checkout')) {
                        // Do the thing
                        return $this->checkout($user, $cart);
                    } else {
                        throw new Exception('No permission.');
                    }
                } else {
                    throw new Exception('Cart is empty.');
                }
            } else {
                throw new Exception('No cart.');
            }
        } else {
            throw new Exception('Inactive user.');
        }
    } else {
        throw new Exception('No user.');
    }
}

Your first thought?
What the actual flip, who would write something like this?

And then it hits you:
It was probably written by someone deep in survival mode, trying to make sense of a broken codebase. The Broken Window Theory in full effect: once the first cracks appear, people stop caring. The mess multiplies.

But here’s the thing: you don’t have to fix everything all at once. You just have to resist the temptation to make it worse. Every time you touch a file, aim to leave it 1% better than you found it.

Clean up a nested if. Rename that awful variable. Flatten some logic. It might not feel like much, but over time, those little changes stack up — and slowly, the mess becomes manageable. Maybe even beautiful (like me).

So how would we improve this code?

Return Early & Promote Logic

Returning early lets us bail out when we hit a problem, no need to keep venturing down the rabbit hole, we can get out early.

Let’s clean that mess up:

function processOrder($user, $cart) {
    if (!$user) {
        throw new Exception('No user.');
    }

    if (!$user->isActive()) {
        throw new Exception('Inactive user.');
    }

    if (!$cart) {
        throw new Exception('No cart.');
    }

    if ($cart->isEmpty()) {
        throw new Exception('Cart is empty.');
    }

    if (!$user->hasPermission('checkout')) {
        throw new Exception('No permission.');
    }

    return $this->checkout($user, $cart);
}

Simple, right?

Now the logic reads top-to-bottom like a clear checklist. Each check guards the next, and the cognitive load is way lower.

No mental gymnastics needed.

Name Your Intent

Want to take it even further? Extract chunks of logic into well-named private methods. Code isn’t just for machines, it's also for humans.

function processOrder($user, $cart) {
    $this->ensureUserExists($user);
    $this->ensureUserIsActive($user);
    $this->ensureCartExists($cart);
    $this->ensureCartIsNotEmpty($cart);
    $this->ensureUserCanCheckout($user);

    return $this->checkout($user, $cart);
}

private function ensureUserExists($user) {
    if (!$user) {
        throw new Exception('No user.');
    }
}

private function ensureUserIsActive($user) {
    if (!$user->isActive()) {
        throw new Exception('Inactive user.');
    }
}

private function ensureCartExists($cart) {
    if (!$cart) {
        throw new Exception('No cart.');
    }
}

private function ensureCartIsNotEmpty($cart) {
    if ($cart->isEmpty()) {
        throw new Exception('Cart is empty.');
    }
}

private function ensureUserCanCheckout($user) {
    if (!$user->hasPermission('checkout')) {
        throw new Exception('No permission.');
    }
}

Each guard clause acts like a blocker, if you don’t meet the requirement, you’re not getting any further.

Why Return Early?

  • Readability: Top-to-bottom logic is easier to scan.

  • Maintainability: Smaller blocks of code are easier to update and test.

  • Avoids mental gymnastics: No need to track nested scopes in your head.

  • Scalability: Easier to refactor or extract functionality later.

Stu’s Final Thoughts

Write code your future self will thank you for.

Keep it clear. Returning early is a great tool, it can help protect the happy path, keep your functions focused and flatten logic.

Be rootin’
Be tootin’
And by god be shootin’
And most of all be kind…

…to the next dev.

Especially if that dev is you, six months from now, running on caffeine, 2 hours of sleep, and dealing with a crappy HR department (which is actually just one person, and that person is the CEO’s wife).

Want a code example? Check out my repo.