WHY I'M NOT THE FASTEST CODER (AND WHY THAT'S ACTUALLY MY STRENGTH)_
After 19 years in IT, I'll admit it: I'm not the fastest coder. I spend hours investigating things others would move past. But here's why that's made me more valuable, not less.
The Three Days Nobody Wanted to Hear About
A few years back, I spent three days on a bug that most engineers would have patched in an afternoon.
A service was intermittently dropping connections under load. The obvious fix was right there: increase the connection pool size, redeploy, move on. My colleague had it working in two hours. I kept digging.
What I found on day three: the connection pool wasn't the problem. The underlying TCP socket settings on the host were misconfigured — specifically, net.ipv4.tcp_fin_timeout was set to the kernel default, which meant sockets were lingering in TIME_WAIT far longer than they should. Under load, we were exhausting ephemeral ports. The pool increase just masked it. It would have come back, worse, at 3am on a Friday.
My colleague's fix would have held for maybe six weeks. Mine held for three years.
Nobody thanked me for those three days. The ticket got closed either way. But I knew what I'd actually fixed, and that mattered.
Why Knowing the Fundamentals Saves You Later
There's a version of engineering where you learn just enough to make the thing work. Stack Overflow, copy-paste, ship it. That works, until it doesn't.
The problem with skipping the fundamentals is that you don't know what you don't know. You can't reason about failure modes you've never understood. When something breaks at 2am, you're not debugging — you're guessing.
I've spent years learning things that felt academic at the time. How TCP actually works. How the Linux kernel handles memory. How distributed consensus algorithms fail. How DNS propagation behaves under load. None of it felt immediately useful. All of it has paid off.
Deep knowledge doesn't just help you fix things faster. It helps you design systems that don't break in the first place. It helps you look at an architecture diagram and say "that's going to cause a thundering herd problem" before anyone writes a line of code. That's not slow — that's cheap. Fixing a design flaw on a whiteboard costs nothing. Fixing it in production costs everything.
Infrastructure Is Not a Feature
"Move fast and break things" is a product philosophy. It has no business being an infrastructure philosophy.
When you break a feature, users get a bad experience. When you break infrastructure, users get nothing. There's a difference between a bug in your recommendation algorithm and a misconfigured security group that exposes your database to the internet. One is embarrassing. The other is a breach.
I've watched teams apply startup velocity to infrastructure work. It goes fine until it doesn't. Then it goes very badly, very fast. A misconfigured IAM policy. A missing backup verification. A firewall rule that was "temporary" and became permanent. These aren't edge cases — they're the predictable result of moving fast through systems that require precision.
Infrastructure work rewards the person who reads the documentation, not the person who skims it. It rewards the person who asks "what happens if this fails" before deploying, not after. Speed is a liability here, not an asset.
I'm not saying be slow for the sake of it. Match your pace to the risk profile of what you're touching. A blog post? Ship it. A VPC peering configuration? Read the docs twice.
The AI Speed Trap
Here's the thing about 2026: everyone is fast now.
AI coding assistants can generate a working implementation in seconds. Junior engineers ship features that would have taken a senior engineer a day. The floor for "functional code" has dropped dramatically. That's genuinely good. It's also created a new problem.
Speed is no longer a differentiator. Everyone has it. What's rare now is understanding.
When an AI generates a Terraform module, it generates something that looks correct. It often is correct, for the happy path. What it doesn't do is reason about your specific blast radius, your compliance requirements, your existing network topology, or the three legacy systems that will break if you change that subnet. That reasoning requires a human who understands the system deeply.
The engineers who will matter most in the next decade aren't the ones who can prompt an AI fastest. They're the ones who can look at AI-generated output and know whether it's actually right. That requires the kind of deep knowledge that only comes from spending time in the weeds — from being the person who spent three days on a bug instead of two hours.
Thoroughness is becoming a competitive advantage precisely because it's being optimized away everywhere else.
When Speed Matters and When It Doesn't
I want to be honest here: not everything deserves three days.
There's a version of "being thorough" that's actually just avoidance. Endless investigation as a way to not ship. Perfectionism dressed up as diligence. I've been guilty of it. It's not a virtue.
The question I've learned to ask is: what's the cost of being wrong?
If I'm wrong about the color of a button, the cost is low. Fix it in the next deploy. If I'm wrong about a database migration strategy, the cost is potentially catastrophic. Those two things deserve different amounts of my time.
I also ask: is this a reversible decision? Reversible decisions can be made quickly. You can always change them. Irreversible decisions — or decisions that are expensive to reverse — deserve more investigation.
For infrastructure specifically, I've developed a rough heuristic: anything that touches security, data, or network topology gets the slow treatment. Everything else gets the fast treatment. That's not a perfect rule, but it's kept me out of most of the bad situations I've seen others walk into.
How I Actually Decide When to Dig Deep
When I hit something I don't understand, I give myself a time budget.
For a low-stakes question, I'll spend 20 minutes. If I don't have an answer, I make a reasonable call and move on. I note what I didn't verify.
For a high-stakes question, I'll spend as long as it takes. And I'll document what I found, because the next person who hits this problem shouldn't have to spend three days on it too.
The documentation part matters. Thoroughness that lives only in your head doesn't scale. Write it down. Put it in the runbook, the PR description, the internal wiki. Make your deep knowledge transferable. That's how you turn a personal habit into a team asset.
And when I'm genuinely stuck — when I've spent the time and I still don't have a clear answer — I surface it. I say "I don't know, and here's why it matters that we find out." That's not weakness. That's the job.
The Permission You Didn't Know You Needed
Here's what I actually want to say to the engineers who feel slow:
You're probably not slow. You're probably thorough. Those are different things.
The hustle culture narrative says speed is the virtue. Ship fast, iterate, move. There's truth in that for certain kinds of work. But it's been applied so broadly that engineers who think carefully have started to feel like they're doing something wrong.
You're not.
The engineer who spends an extra hour understanding a system before changing it is not behind. They're ahead. They're the one who won't be paged at 3am. They're the one whose changes don't get rolled back. They're the one who, five years from now, will be the person others come to when something is genuinely broken and nobody knows why.
That's not a consolation prize. That's the job.
I've been in IT for 19 years. I've watched fast engineers burn bright and burn out. I've watched thorough engineers build things that lasted. The ones who are still doing interesting work, still trusted with the hard problems — they're not the fastest. They're the most reliable.
Speed gets you noticed. Reliability keeps you employed. Understanding keeps you valuable.
Joe Gajeckyj is a founder and infrastructure engineer with 19 years in IT, currently building AI-assisted development workflows at JRGWorkshop.