The Enemy of Comfort: What UFC Fighter Ian Garry Taught Me About Technical Debt

# webdev# ai# programming# productivity
The Enemy of Comfort: What UFC Fighter Ian Garry Taught Me About Technical DebtDavi Jonck

I’ve been following the UFC closely, and Ian Garry’s trajectory always strikes a specific chord with...

I’ve been following the UFC closely, and Ian Garry’s trajectory always strikes a specific chord with me. He calls himself "The Future," but what truly defines him isn’t the trash talk—it’s his absolute allergy to comfort.

He changes gyms, travels the world to train where he is the "white belt" in the room, and purposefully exposes himself to chaos. For him, comfort is a prerequisite for defeat.

In software development, I see the exact opposite pattern repeating constantly.

Many teams avoid refactoring or modernizing their stack under the excuse of "not breaking what works." They call it "stability." But let’s be honest: the technical term for this is stagnation.

We often kick the can down the road on refactoring because it’s uncomfortable. But staying in that comfort zone is expensive. The data is brutal:

  1. The Cost of "Bad Code" (Stripe Data) Stripe conducted a massive global study (The Developer Coefficient) and found that developers spend, on average, 42% of their work week dealing with "Bad Code" and technical debt.

Think about that. Almost half of a team's week—and the company's budget—is burned just keeping the lights on, fixing the past instead of building the future.

  1. Discomfort Pays Off (McKinsey Data) If anyone thinks "innovation is too much work," McKinsey has a financial counter-argument.

In their Developer Velocity report, they analyzed 440 companies and found that those with the courage to adopt modern tools and step out of the traditional comfort zone grow revenue 4x to 5x faster than their conservative competitors.

The Binary Choice
Ian Garry understands that if he doesn't evolve his grappling or wrestling, he will get run over. In our field, if a company doesn't pay down technical debt and fears touching the legacy code, it becomes the dinosaur in the room.

The choice is binary:

Embrace the discomfort of learning and refactoring now.

Accept that 42% of your future will be spent fixing today's bugs.

I prefer the discomfort. What about you?