perri.to: A mashup of things (by Horacio Duran)

Professionally, if I had to summarize it in one sentence, I’d say this:

I’ve always chosen tools that someone was willing to pay me the most to use.

It all started with Visual Basic 6.

At the time, at least in my country, it was the dominant language for business applications. Accounting firms, mid-sized companies, internal management systems - everything ran on VB6. I became highly efficient with it. Not just productive - I learned how it worked underneath, its limits, its quirks.

Eventually, people started calling me to optimize programs that had grown beyond what a straightforward “business logic developer” could handle.

What did that mean?

Applications would start small, grow alongside the business, and eventually hit a performance wall. Visual Basic 6 wasn’t exactly designed for heavy processing, but back then “large workloads” weren’t as large as today. Hardware had very real constraints, and knowing how to squeeze performance out of it made a difference.

I’ve always been curious about how tools work at a lower level. That curiosity allowed me to optimize code that had been written with business rules in mind, but not necessarily with memory models, execution costs, or internal behavior in focus.

Sure, there were alternatives like Java used by larger companies and more formal teams. But I focused on the niche that made the most sense for me professionally. And that niche was simple: wherever many developers worked, performance bottlenecks eventually appeared. That’s where I stepped in.

The Move to the Web

Around 2003 or 2004, I noticed a shift. Developers who once built desktop applications in VB6 were moving to PHP.

Until then, the web was mostly a medium for publishing information. But after the dot-com bubble, something started to change: applications began moving from the desktop to the browser. They were primitive - but clearly, something was happening.

So I learned PHP.

And once again, I did what I knew how to do: optimize, find bottlenecks, understand the limits of the runtime. Early PHP versions were prone to memory issues, partly because they were designed for short-lived execution cycles - render a page and exit - not for long-running processes or heavy workloads.

That opened a niche for me similar to the one I had before, but in a completely different domain.

PHP exploded in popularity. Ironically, that’s what made me start thinking: the more mainstream it became, the less room there would be for deep specialization. Saturated markets compress margins.

So I started looking ahead again.

Python and Understanding the Language Deeply

Through my local Linux user group, I discovered Python - I think it was version 2.1 at the time.

I was fascinated.

It had interesting quirks, and I spent a long time refining my understanding of it. Somewhere in those years, a friend of mine, Diego Sarmentero, started an editor called Ninja IDE. I helped him with it, and that project forced me to truly understand many lower-level aspects of Python.

Python always struck me as interesting in one particular way: the most academically “correct” code wasn’t always the most efficient. Instantiating many objects strictly following object-oriented paradigms might be elegant - but under high contention scenarios (like heavily used REST endpoints), memory pressure can become significant.

There was plenty of room to grow with Python. The language was evolving rapidly and looked promising.

But then another opportunity came up.

Canonical, Juju, and Discovering Go

I joined Canonical to work on Juju, a cloud orchestration system that eventually lost the race to Kubernetes (some would argue they were not in the same race at all).

Regardless of that outcome, that period introduced me to Go.

I immediately sensed that Go had something special in the cloud space. I specialized as much as I could and spent many years working with it. Even today, when I start a new personal project, Go is often my default choice - unless another technology is clearly a better fit.

Luck or Pattern?

Professionally, you could say I’m like a cat - I tend to land on my feet.

Maybe (and likely) it’s more luck than talent, but I’ve consistently moved toward tools that later became commercially viable. Although, thinking about it more carefully, maybe I’m not choosing programming languages.

Maybe I’m choosing the next tool that enables building products someone is willing to buy.

And Now?

Today, I don’t think the next step is a language - or even a framework.

It’s an LLM. Or a combination of AI-assisted tools.

The question is no longer “Which language should I use?” but rather:

What combination of tools allows me to build viable, maintainable, commercially relevant services?

The language becomes merely a compilation target for ideas.

This time, my niche may lie in architectural experience. In knowing what to ask these tools to generate. In guiding them toward something that not only works today but remains maintainable tomorrow.

Maybe this is the time I’m wrong.

But there’s only one way to find out.