It's another day in the wonderful world of software engineering and Professor Quacks, the world’s foremost authority on debugging (self-proclaimed, of course), is back. As I open my laptop, he jumps onto my desk, feathers slightly ruffled.

"We need to talk", he quacks, tapping an ominous-looking document with his tiny little wing.

I blink slowly, rubbing my eyes as if I might be imagining this surreal visit. “Can’t this wait until after I’ve scrolled Slack aimlessly for ten minutes?” I reply, trying to sound nonchalant.

He stares me down with his beady eyes, glasses perched precariously on the end of his beak like he’s actually some kind of professor.

“It’s time to revisit the principles! Remember?”

“Right”, I mutter halfheartedly. “The sacred texts, written in YAML and guarded by ducks“.

I take a deep breath, pushing my laptop aside to make space for Professor Quacks’ enthusiasm. With a sigh that could only come from someone who's seen too many production outages on a Monday morning, I settle in.

Professor Quacks adjusts his glasses, clears his throat (a surprisingly loud sound for a duck) and we begin our deep dive into the unwritten (and very much written) rules of engineering excellence.

We get curious

It starts with a bug. Don’t they all?A tiny glitch on the dashboard that shouldn’t be there. “We’ll fix it later,” someone says. But later never comes and now it’s your problem. Little do we know that tiny bug is just the tip of the iceberg.

Eventually, curiosity gets the better of us. Instead of patching symptoms, we ask:

Why is it broken?What else is affected?How did we get here in the first place?

If something doesn’t make sense, we keep digging until it does. When an error pops up that we don’t recognise, we don’t just Google the solution, we try to understand why it happened……and then we Google the solution.

When we inherit legacy code that looks like it was written by a sleep-deprived goblin, we don’t just blindly refactor. We ask, what was the original intent?

During planning meetings, we ask questions like: why are we doing this? What problem does this solve?

Good engineers don’t just accept things at face value; they get curious. They ask questions, repeatedly, until they truly understand the problem they are solving.

🦆
Professor Quacks says: “If you don’t understand the problem, how do you know your solution is correct? Always ask 'Why?' at least five times”.

We think for ourselves

You’re staring at the screen again, cursor blinking, Stack Overflow open in one tab, docs in another, with an uneasy feeling in your stomach. The accepted answer looks solid. It's got plenty of upvotes and yet a nagging doubt lingers. Something doesn’t feel right. It doesn’t quite fit your scenario.

Now what? Copy-pasting is easy, but genuinely understanding why the code works and whether it’s actually the right approach for you is where the real thinking happens.

Best practices are great guidelines, but just because everyone does it, doesn't mean it’s right - blind consensus is normally how bad patterns go viral.

That’s why we push back. We question defaults. We challenge assumptions. Not to be difficult, but to avoid building yet another feature we'll be rewriting or regretting in six months time.

Thinking for yourself means making peace with the messy middle. There’s rarely one ‘right’ solution, only trade-offs. Context is king. Constraints are real. And your job isn’t just to deliver, it’s to decide what’s worth building in the first place.

It also means talking things through. We value conversations that challenge our assumptions and sharpen our thinking. Explaining your approach out loud is often the fastest way to realise it doesn’t make sense.

We don’t just build for today. We design with the assumption that things will change, requirements will shift, and someone in the future will have to maintain this without crying.

🦆
Professor Quacks says: “If you can't tell whether the problem is with your code or your understanding of the code, the answer is yes.”

We hold ourselves to a higher standard

It’s a Friday afternoon. You've just pushed your final commit of the week. The feature looks slick. It passed the tests (at least, the ones you ran) and you couldn’t be more chuffed with yourself. You deploy and confidently call it a day.

But Monday arrives, bringing chaos in its wake. There’s mass hysteria in the workspace. Slack notifications are flowing in and production is on fire. You reluctantly open the dreaded git blame… and there it is. Your own name, staring back at you like a twist in a bad thriller.

Let's unpack this. And no, we’re not even going to mention that deploying on a Friday might’ve been your first mistake.

Did you test it thoroughly or just hit the happy path once, smile and call it a day?

Holding ourselves accountable means taking ownership from start to finish, not just throwing commits over the wall and hoping for the best. It means confirming that it works in staging, behaves in production and doesn’t inadvertently break three unrelated features in the process.

Ownership isn’t saying, “Okay, my part is done; someone else can follow up.” It’s owning the problem, not just the pull request.

It means writing code with empathy. For your teammates. For the person reviewing your pull request and for whoever has to maintain it later. Clean code is kind code. And letting someone poke holes in your work during review isn’t just responsible…it’s how we all grow.

We care about our work because it matters, not because someone's peering over our shoulder. After all, we’re usually the ones revisiting our own creations months down the line, head in hands after running git blame, only to realise… the call was coming from inside the house.

We’re the kind of people who spend two hours renaming a variable because its original name gives us secondhand embarrassment. Nobody should have to work with a $doStuff() or a $data2 or whatever questionable naming choice you thought made perfect sense at the time.

🦆
Professor Quacks says: “Deploying on a Friday? Bold move. I respect it. I don’t recommend it, but I respect it”

We work as a team

A wise duck once said, “If a bug is squashed in the forest but nobody sees it, did it really happen?”

Software engineering is rarely a solo sport. Great code comes from collaboration, communication and occasionally three people staring at the same blank spec until someone finally admits: “Wait…what are we building again?”

Working as a team isn't just about being nice. It’s about being effective. We move faster when we're on the same page. We make better decisions when we talk to each other and we build more resilient software when we share the context and not just the code.

We speak up early and often and if we miss the early part? We speak up anyway. Silence is never the better option. When we get stuck, we don’t wait until it’s an emergency, we ask for help. Even when it feels awkward. Especially when it feels awkward.

We follow through on commitments and when chaos hits, we don’t go quiet, we keep each other informed. 

We write things down, not because we’re obsessed with documentation, but because our brains have the memory retention of a goldfish. Wins, mistakes, weird edge cases, it all gets shared, because the next person shouldn’t have to rediscover it all from scratch.

If we figure something out, we share it. If we fall into a trap, we leave a warning sign, whether it’s in the code, in Slack or buried in a Notion doc with an unnecessarily long title. Breadcrumbs save lives.

We don’t hoard knowledge. We don’t gatekeep and we don’t confuse “being the only one who knows” with job security. 

Every shortcut we document. Every insight we offer. Every lesson we pass along. Knowledge shared lifts the whole team. Besides, who wants to be the only poor soul who knows the dark secrets of that one ancient cron job?

🦆
Professor Quacks' wisdom: "Teamwork makes the stream work!"

We test our code

Let’s be honest…no one wakes up excited to write tests. There’s no dopamine hit. No flashy UI. No standing ovation. Just you, a test runner and a vague feeling that you’ve probably missed something important. But we do it anyway, because we know the best bug reports always start with: “…but it worked on localhost”.

We don’t just test the happy path. We throw monkeys into the form fields, click buttons out of order, pretend to be hackers and try to break our own assumptions before production does it for us. We simulate nonsense inputs, disconnected APIs, expired tokens and scenarios we sincerely hope never happen, but probably will.

And newsflash: “testing in prod” isn’t a real strategy. Okay, granted, sometimes it’s your only option. But hoping nothing catches fire after a Friday deploy? That’s not a strategy. That’s a lifestyle choice.

We even test code we didn’t write, especially if we didn’t write it. Not because we’re paranoid (well, maybe a little), but because experience has taught us that bugs don’t care whose name is on the commit. Nothing says “bonding moment” quite like discovering a seven-year-old method that silently swallows exceptions, returns false on failure and logs absolutely nothing. You don’t fix that kind of code… you perform an exorcism.

Testing is how we show respect, for our colleagues, for our future selves and for everyone who has to touch this code after us. It’s not just about finding bugs, it’s about building trust in the system, confidence in the release and a vague sense that maybe, just maybe, things won’t blow up this time.

Tests don’t guarantee perfection. But they do give us a fighting chance. And when they fail, they fail loudly, unapologetically and ideally before a customer sees the error.

🦆
Professor Quacks says: “Tests are like clothes. If you don’t have any, things can get uncomfortable real quick.”

Halfway through the list, a creeping doubt began to settle in. Was this still about engineering?

Had I accidentally joined a cult led by a power-hungry duck with a mysterious vendetta and an overly detailed Google Doc? Or was Professor Quacks just dragging me through a redemption arc for all the sins I committed against past codebases?

“I need a break”, I whisper, unsure if it’s to Quacks or to myself.

“My coffee’s finished, my soul’s hanging by a thread and we’re still only on principle five?” I mutter, side-eyeing Quacks as he flaps to the next page with the enthusiasm of someone who clearly doesn’t know what it’s like to maintain a legacy Symfony codebase.

Quack's glances up at me, clearly disappointed, like a CI job that almost passed.

“Alright”, he says, closing the document with a dramatic flap of his wing. “We’ll cover the remaining five another time. The duck has spoken”.

And just like that, I got back to work, this time with some principles and a duck firmly by my side.