It had been blissfully peaceful since Professor Quacks left.

No loud quacking echoing through the office. No unwanted advice about legacy code. Not a single feather in sight. Even the air smelled fresher.

I was starting to believe he was gone for good. Maybe he finally took up that job at GitLab support. Maybe he flew south for the sprint.

But then, without warning, it began.

A faint slapping echoed down the hallway. Soft at first, growing louder and more frantic. It sounded like someone was sprinting through a tiled bathroom in flip-flops.

slap. Slap. SLAP.

And then... BANG.

Professor Quacks comes careening around the corner at full speed, sacred scrolls tucked under one wing, his tiny spectacles hanging on for dear life. His little duck legs are moving so fast that they've completely lost sync with the rest of his body. He's leaning dangerously forward, webbed feet flapping like broken paddles, completely out of control.

CRASH. SLAM.

He skids sideways into my desk, feathers flying.

“Hope you’re ready for round two”. He says, casually adjusting his ruffled feathers like he didn’t just recreate the opening scene of an action movie. "We've still got five more principles to cover".

I blink once, slowly. My coffee mug is still trembling from the impact. A lone feather drifts past my face like it’s seen some serious shit.

I glance at my screen, then at Professor Quacks. I consider faking a medical emergency, or maybe just sliding under my desk and pretending to be dead.

But it's too late. He's already shuffling his scrolls with the determination of someone who has zero intention of being ignored.

And just like that, we're back in it. Five more principles, no time to breathe and one very determined little rubber duck.

🛠️ We Build Tools That Don’t Suck

We’ve all written that quick fix function. The ole patch job duct-taped together with array_map(). It works but every time you look at it, a part of you dies inside.

Good engineers don’t just make stuff work. They make stuff that helps other people work.

That means building actual tools. Tools don’t have to be fancy. Sometimes the best tool is just a small, simple function that does one thing really well and then gets combined with other small functions to create something beautiful and reusable.

One trick that really helps is the Tell, Don’t Ask principle.

Instead of poking at an object and asking "hey, what's your story?" and then figuring out what to do about it, just tell it what you want to happen and let it worry about the how.

// Don't ask:
if ($duck->isAnnoyed()) {
		$duck->quackBackAtYouLoudly();
}

// Do tell:
$duck->expressOutrage();

Ultimately, when we build tools, we build with others in mind. Maybe that’s you in six months after you’ve forgotten everything about the code. Maybe it’s your colleague who’s trying to understand what you were thinking.

We extend on what already exists instead of starting from scratch. If there’s a function that does 80% of what you need, make it do 100% rather than writing your own version. If there’s a library or a package that handles the boring stuff, then use it. Build on what’s already there, instead of reinventing the wheel.

We write small, simple functions that can be composed into something greater than the sum of their parts. We leave behind thoughtful, reusable code so that the next developer can pick it up without wanting to rewrite everything.

We’re not just solving today’s problem. We're building the foundation for tomorrow’s solution.

🦆 Professor Quacks says: “Throwaway code is like a one-night stand. Seems like a great idea in the moment. It gets awkward when you try to explain it, and you’ll definitely have regrets later.”

🏃‍♀️We Work with Urgency (But NOT in a panic)

There’s a world of difference between moving fast and running around like a headless chicken.

Urgency isn’t about pulling all-nighters or frying your brain. It’s about keeping things moving without losing your mind or producing crappy code.

That mindset starts with figuring out what actually matters. Instead of diving head-first into code we talk to the people who actually care about it. We ask the uncomfortable questions upfront. We try to establish what ‘done’ actually looks like.

Once we know what we're building and why, the real trick is staying focused on the results instead of getting lost in the forest. You know how it goes… you start investigating why a variable is undefined and then suddenly you’re two hours deep in a Reddit thread about Javascript’s relationship with the concept of nothingness.

That’s where setting timers becomes your best friend. Give yourself thirty minutes to solve the mystery and then either ask for help or try a different approach. I know this can make you feel defeated but it’s not about giving up, sometimes you just need to tell yourself that the most urgent thing you can do is stop digging and look for a helping hand out of that hole.

This same principle applies everywhere. We’re not trying to obsess over perfecting things. We’re not letting technical debt pile up just because having that awkward conversation feels uncomfortable. We also don’t panic-rewrite half the codebase when the real issue was probably something embarrassingly simple.

Most importantly, we pick our battles. Yep, some requests are confusing as hell. Some are downright terrifying. But we take a deep breath, slowly chip away at the hard stuff or at least break it down into manageable pieces and keep moving forward with purpose.

Because that’s what healthy urgency looks like.

🦆 Professor Quacks says: “Running fast in the wrong direction still gets you lost”.

🧰 We Plan

We’ve all been there. You open your editor with the enthusiasm of a caffeinated squirrel, smash out half a feature and then you realise you forgot one tiny, insignificant detail. A plan.

Now you’re screwed! Three layers deep in code spaghetti hell, your branch name is a complete lie, and the thing you’re building has quietly mutated into something else entirely.

That’s where a little planning comes in.

And no, were not talking 40 page PDFs or Gantt charts that look like they were designed by Tolkien. Just take a moment to pause, reflect and think it through. Maybe even sketch out a rough shape of what you’re building and gut-check the approach with a colleague before getting into the implementation.

Because this is what we have learnt the hard way: it’s way faster to iterate on an idea than to backtrack through code that’s already half-alive (or half-dead, depending on your perspective). A written plan is something you can actually share and discuss, especially when you’re trying to get feedback and someone’s already busy with another task.

Plus, planning helps people understand why things got built the way they did. It forces us to catch those delightful edge cases early.

In practice, planning might be as simple as drawing boxes on a Miro board, or creating a flow diagram with a colleague. Sometimes it’s just writing three sentences about what you’re trying to accomplish.

The key is to keep it light and flexible. We’re not trying to predict the future or create a sacred document that can never be changed (I’m sure Professor Quacks would love that). Plans are meant to be living things that adapt as you learn more about the problem. Oh, and one word of advice: if you find yourself spending more time perfecting the plan than putting it into action, then you’ve probably crossed the line into overthinking territory.

🦆 Professor Quacks says: "The best code you'll ever write is the code you planned not to write.”

🫶 We Work Well with Others

I know you might be thinking, “Didn’t we already cover this in ‘We Work as a Team’?”

Fair point. They’re definitely in the same neighbourhood, they probably share a side alley and the odd random WiFi signal. But while working as a team is about how we collaborate, working well with others is more about the mindset we bring into those collaborations.

Because here’s the thing: you can absolutely “work as a team” and still be a pain to work with. But if you work well with others, chances are your team actually wants you around.

Working well with others isn’t just about smiling in meetings and giving the occasional thumbs up on a PR. It’s about having patience, humility and a genuine desire to not be responsible for someone going home stressed.

It starts with the basics. When someone asks a question, explain it like you’re helping a friend figure something out, instead of reciting a manual to them out loud. Remember, you didn’t always know this stuff either, so it doesn’t make sense to make someone else feel stupid because they’re asking about something that feels obvious to you now.

Sometimes that means taking a step back and wondering if maybe you're the one missing something. It’s okay to be wrong, even when you’re really, really sure you were right. That also means listening to other people’s ideas before preparing your counterargument and waiting for your turn to explain why they’re mistaken. And it means laughing at yourself when you mess up instead of getting defensive.

On top of that, we admit our mistakes freely and quickly because honestly we’ve all deployed something questionable at least once, or twice. Or that one time we accidentally took down the entire staging environment on a Monday morning and had to do that awkward Slack message of shame.

Most importantly, we should never forget that the person we’re helping, reviewing or disagreeing with is just trying to do a good job, same as us. They're not trying to make your day harder. They're not the enemy. They're just someone else navigating this beautiful chaos that is building software.

When we work well with others we're building relationships. We're creating environments where people feel safe to ask questions, admit mistakes and try new things. We're building teams that people actually want to be a part of.

🦆 Professor Quacks says: "A team that quacks together, stacks together”

👩‍🏫 We are Role Models

One of the biggest surprises I didn't expect when starting this job is that you don't need a fancy title or ten years of experience to change how things work. Sometimes someone who's been here for six months is the one who points out that our deployment process is a complete disaster.

Being a role model isn't about being perfect or having all the answers. It's about representing in a way that doesn't make everyone else's day worse. Which honestly, is a pretty low bar that somehow a lot of us still manage to trip over.

I've started asking myself this question: "If everyone did what I'm doing right now, would I actually want to work here?" Not just "will this code work?" but like, genuinely would I want to be on a team where everyone handles problems the way I'm handling this one right now?

If anything, its made me realise how much of the annoying stuff exists because someone, somewhere, decided it was waaaay easier to just work around the broken thing than fix it. And then everyone else learned to work around it too. And now we're all just... working around broken stuff all day.

I've definitely gotten better at being honest when I don't know something. It used to feel like admitting ignorance was announcing to the world that I was a fraud. But as it turns out, saying "I have no idea how this works" is way more useful than spending three hours pretending I do.

Same goes for mistakes. Now I'm much more likely to tell people about that time I spent an entire afternoon debugging something only to realise I was looking at the wrong environment. Because hey, maybe that'll save someone else from their own crisis and also… it’s kinda funny.

When someone does something well, I try to actually say so instead of just thinking it. When someone gives me feedback that makes me a little defensive, I try to listen anyway. Both of those things are way harder than they sound.

The thing is, we're all kind of setting the tone whether we mean to or not. The way we talk about a legacy codebase everyone hates, the shortcuts we take when we think nobody's looking, whether we bother writing tests or not, it all becomes part of how things work around here.

If I'm constantly complaining about technical debt but never actually addressing any of it, people will pick up on that. If I skip writing tests for whatever reason then that becomes the norm. If I ignore that voice saying "this doesn’t feel right" because having a lengthy conversation seems worse than shipping dodgy code, well... that becomes the standard.

But the flip side is pretty cool: if I'm genuinely curious about problems instead of just frustrated by them, that seems to rub off on people too. If I'm kind to someone when they're struggling with something I find easy, they tend to pay that forward. If I'm a little obsessed with making code readable and variable names make sense, sometimes other people start caring about that stuff too.

Turns out we're not just building software. We're accidentally building the culture of this place, one interaction at a time.

🦆 Professor Quacks says: "You can't control how your code will be used, but you can definitely control how your attitude spreads."

Professor Quacks gives the scroll one final dramatic roll, tucks it under his wing and adjusts his spectacles like he’s just handed down the Ten Commandments of Engineering.

He looks at me. I look at him.

We both know I’m not gonna follow all of these perfectly.

He gives me a solemn nod and heads towards the exit. His footsteps fade down the hallway until there's nothing left but the faint smell of pond water and broken promises.

He's gone.

I sit there for a moment.

Then look at my screen where a comment reads: // TODO: fix this later

I delete the comment. And actually fix it.

It's a start.

The end.