When I start a new endeavor, it usually feels like a New Year’s resolution: bold promises, clean slates, a grand vision of how everything’s going to change.

I plan like I own the world—when the truth is, I barely own my calendar.

Take fitness. Let’s say I need to lose weight (who doesn’t, right?). So I build a plan: I’ll train every day, ninety-minute sessions, eat clean, stretch, sleep early, journal… the whole works.

But here’s the thing. I’m the father of a 3-year-old. I live in a city where my wife and I don't have any relatives around. Work? Always on fire.

In this context, my ambitious plan isn’t a blueprint for success; it’s a recipe for failure.

It reminds me of a time I worked with probably the worst codebase I've ever seen. It was a Fintech platform built with Python and AWS Lambdas. Don’t get me wrong, that stack can be rock-solid—but given our particular domain and the skill set of the original developers, the application was a complete mess. Lambdas calling Lambdas, infinite triggers, debugging nightmares—the kind of scenario that could bring a tear to even the toughest developer’s eye.

One day, I was chatting with a junior engineer on the team. He’d been reading classics like Clean Code, Refactoring, The Pragmatic Programmer, and other gems. We were excited, bouncing ideas back and forth about how things should be. Then he paused, looked at me, and asked:

“Why aren’t we doing all these things in our code?”

I had to stop and think for a moment. I remembered a recent conversation with our team architect. He had been enthusiastically describing all the cool things we were planning to build someday. But then he paused and said:

"Before we build the cool stuff, we have to make the features we already have work. The code we have today is terrible but it works most of the time, and it will be replaced soon. In the meantime, we need to endure.”

The architect is a pragmatic no-fluff kind of guy, I knew he wasn't saying we should give up on best practices. He was saying that sometimes we need to keep things working while a better solution is cooking. The code we need to hold doesn't have to be the greatest ever; it needs to be shipped fast and just good enough to endure the next season.

I told that story to the junior engineer and reflected for a moment. You know, all those design patterns are nice things to know, identify, and talk about, but you need to keep in mind that those are ideas, not requirements. You don't have to replicate all of them at once. You have to recognize that if objects are alike, a base class and simple inheritance will do the trick. Same with composition. Almost all your problems can be solved with one or the other. What really matters is being able to think critically about the business domain, the company's current moment, and the general context. That skill is actually more valuable than trying to force the code to fit a design pattern.

Are you able to recognize when good enough is enough?