The Fast Engineer Trap

At one of my first jobs out of college, I worked at a tiny development agency - just me, one other iOS engineer, and the founder.

The founder was a retired iOS engineer who'd published a few programming books and built several successful apps - and, being fresh out of college, I wanted to impress him. He was one of my first real bosses, and I figured if anyone could determine whether or not I was cut out for this industry, it’d be someone like him.

Most of his day was spent on client calls, but whenever he wasn't on one, he’d stand behind us watching us code - literally. Occasionally, he’d chime in with some unsolicited live code review that derailed my train of thought entirely.

He’d pick one of us at random to start his surveillance shift, following along from wherever we happened to be in the task. Once we wrapped up whatever we were working on - quick fix or complex new feature - he’d drift over to the other guy. It didn’t matter how big or small the task was; the mission was clear: get his eyes off our back as fast as possible. The other engineer and I never talked about it, but we both instinctively started optimizing for one goal — to escape surveillance.

The experience wasn’t just unpleasant - it warped my sense of what the job, and even the industry, was like. It felt like being stuck in a never-ending coding interview - except instead of whiteboard questions, I was shipping production code with someone second-guessing every decision I made.

That kind of pressure shaped how I approached work. I stopped thinking of code as something to design thoughtfully and started seeing it as something to finish before his next client call ended.

And the incentives? Completely broken:

• If you moved quickly, you bought yourself a little bit of peace and silence - at least until the next ticket was assigned.
• The backlog was endless, and delivery velocity was the only thing being tracked.
• Output mattered. Outcome didn’t.
• You were constantly trying to distance yourself from being the “bottleneck” or, worse, “layoff material.”
• Working alongside others felt competitive - everyone chasing visibility, promotions, or just survival.
• Speed gave you cover; it made you look like someone who had it all under control.

So, you adapt. You start cutting corners without realizing it:

• You make PRs that are functional, but fragile.
• You avoid “scary” parts of the codebase because getting stuck feels riskier than delivering a subpar fix.
• You skip tests because “I’ll come back and add them later.”
• You default to the same solutions because learning new ones might slow you down.
• You skip documentation and deeper reads because those don’t “burn down” the board.
• You move from task to task with the goal of closing, not understanding.
• You get in the habit of copy-pasting from StackOverflow / ChatGPT without pausing to understand what the code is really doing.

And before long, you’re the “fast engineer.” Congrats. A rockstar developer. The one who always gets things done - even if it’s duct tape and dreams holding it together. That's how the bad habits form - not because you’re trying to be reckless, but because the environment makes slowness feel dangerous.

And look, speed can feel great. Early in your career, it gets you noticed and praised. You get labeled as a “10x engineer.” You become the person people turn to when something needs to get done quickly. But the label is a trap.

That mindset followed me to Porsche’s research and development wing - my dream job at the time. But, the focus there was specifically rapid prototyping - building fast was part of the mandate. And without proper checks, I leaned even harder into my speed-over-stability tendencies. One day, a friendly, sassy product manager I worked with started calling me “Bugs Bunny” - because what I built was fast, but often… buggy. Not entirely unfair. It was a joke, of course - we got along well - but it left an impression.

Now, I’m in a new job again. New team, new codebase, new first impressions to make. I’m working alongside some of the sharpest engineers I’ve ever met, and the temptation is real - to make every PR flawless, to move quickly, to prove I belong. But I’ve been reminding myself - sometimes daily - that it’s okay to take a beat.

You can write a great PR tomorrow after learning the system today. You can ask that “dumb” question instead of pretending you already know how it all works. You can flag uncertainty instead of quietly hoping it won’t blow up later. You can hold off on shipping until you’ve triple-checked the edge cases.

Because in the long run, no one’s going to remember whether you shipped that one PR in 20 minutes or two hours. Everyone’s juggling their own deadlines and anxieties. They’re not watching your GitHub Pulse as closely as you think.

This isn’t advice and it's not meant for anyone in particular. It's a note to myself to be a little more honest about the habits I’ve picked up, and the ones I want to leave behind. If it happens to mirror your experience, great - you're not alone.

Here’s what I wish I had internalized sooner:

• Being fast makes you feel valuable. Being thorough makes you trusted. Trust takes longer to build, but it lasts a hell of a lot longer than “Wow, that was quick!”
• You only get so many chances at learning something deeply. Don’t waste them rushing. Understanding the system once saves you from firefighting it ten times.
• The engineer who’s always “busy” is often just the one stuck cleaning up their own shortcuts. There's no badge for that kind of hustle.
• The “slow” path compounds. Reading documentation, writing tests, digging through related files - all of that adds up to better judgment, stronger instincts, and more meaningful contributions. That growth pays off in ways no burndown chart can ever measure.

So, yeah - read the docs. Understand the why. And maybe don’t rely on AI to solve everything for you.

More than anything, give yourself permission to slow down. Not forever. Not for everything - just for the stuff that matters.

Because if you don’t - if you chase speed at all costs - you pay for it eventually. In tech debt. In brittle codebases. In late-night outages. In burnout. In never actually getting better - just faster at doing the same shallow things. Take your time. Ask the "dumb" question. Write that extra test.

And don’t worry - Bugs Bunny already took the hits for you.