Claudio Lassala's Blog

In reflecting on past projects, I’ve noticed a recurring contrast in how developers respond when shown a functional application. Given just enough context to understand what it does, and then shown both the finished product and the code, you can quickly see where their attention goes first.

Some gravitate immediately toward the code — including formatting, naming conventions, performance details, and the underlying technology choices, such as programming languages, frameworks, and libraries. Others focus on the solution itself: Does this actually address the problem we set out to solve?

Lessons From Experience

I’ve seen this pattern across decades of technology shifts — FoxPro vs. Visual Basic, .NET vs. Ruby on Rails, the rise and fall of frontend frameworks, and now AI-assisted development. Some developers get caught up in whether the syntax aligns with their personal style or whether it utilizes the latest tools. Others start with a simpler, more fundamental question: does it actually help the people it’s meant to serve?

Often, the code-first group never asks the most important question: Does this move us closer to solving the problem? I’ve seen beautiful code that solved nothing, and quick, imperfect prototypes that delivered immense business value.

Why the Order Matters

Focusing on the solution first doesn’t mean ignoring code quality. It means sequencing your attention:

1. Validate the outcome. Does it solve the problem?
2. Refine the implementation. Once you know it’s worth building, then make the code great.

When developers skip step one, they risk perfecting something no one needs.

A Developer’s Reflection

It’s easy to take pride in syntax. It’s tangible, it’s ours, and it reflects our craft. But the craft exists to serve a purpose. Stakeholders don’t thank you for perfect indentation; they thank you for solving their problem.

The real skill is balancing both instincts — the love for elegant code and the discipline to ask what Seth Godin calls in This is Strategy:

“Better”, the heart of your strategy.
Better for who?
When we lack the empathy to imagine someone else’s “better”, we’re on the road to frustration.

If you can’t imagine someone else’s “better,” you might be chasing perfection that doesn’t matter.

The Takeaway

Both perspectives are valuable. But the order matters. Doing the right thing first, then doing it right, gives you the best chance of delivering something that lasts.

Next time you see a new solution, notice your instinct. Do you dive into the code, or do you try it to see if it solves the problem?

That moment reveals a lot — not just about the project, but about how you approach your craft as a developer.