When a Professor Named What I Was

I was in Valencia, Spain, in a master's class, when a professor said something that stuck with me.

She said the perfect team to solve a complex problem was the triad: an industrial engineer, a mathematician, and a programmer.

The industrial engineer to understand the business from the inside — not from a manual, but from the people who do the work every day. The mathematician to convert that problem into logic, into formulas, into something that can be optimized. And the programmer to build what the industrial engineer and mathematician have already figured out.

What I didn't tell my professor that day is that I had already seen that before. I just had never called it that.

# Venezuela: The Physical Process

In Venezuela, before emigrating, I worked as an industrial contractor. One of the things I did most was walk into a plant, look at how it was organized, and ask myself why things were where they were. Sometimes the answer was that no one had ever questioned it.

There was a machine whose position had made sense in the past — when raw material was brought directly from outside the company. But the company grew, closed the warehouse entirely, and suddenly that direct feed was no longer possible. The machine was still in the same place. The process had changed, but no one had moved anything. They kept working that way because they always had — until I pushed to change it.

That's what an industrial engineer does: sees the company as a process. And a process always has the same basic structure, regardless of industry. There's always raw material, a transformation, and a finished product. Everything else is detail. Important, but detail.

# Chile and the Data Pivot

When I arrived in Chile during the pandemic and started a company to import laser machines from China, I knew nothing about those machines. I did know how to sell, negotiate, and understand what a client needed. The first thing I did was learn how they worked — not to be technical, but to translate the client's problem into a concrete solution.

When I decided to pursue the logistics master's in Valencia, it wasn't to accumulate a degree. It was because I wanted to give a formal name and structure to something I was already doing intuitively. And when I later completed the Big Data master's, it was because I understood that data is the raw material of the 21st century — and an industrial engineer without data works blind.

# The 3PL System: Building from the Inside

The first system I built was for the 3PL company where I work. A real operation, with cargo moving between Ireland, the United States, and Latin America, managed with Excel, WhatsApp, and emails that got lost. There was an ERP called Magaya — good, powerful, complete. And no one used it. Not because the team was incapable, but because it was oversized for what we needed.

So I decided to build something custom. And that's where the real learning began.

Every module I finished left me with the same doubt: is it right? How do I know it's right? How do I catch the silent errors?

Those questions led me to understand testing, validation, database triggers that guarantee consistency without depending on someone remembering to do something manually. I learned AI-assisted development — not as a shortcut, but as a conversation: you frame the problem, the system proposes, you question.

# The Academy: The Real Problem

One day, in a conversation with a friend, he asked me what I did. I accepted the challenge of building a system for his academy. But before opening the editor, I asked him what worried him.

He said he wasn't tracking attendance well. I asked why that worried him. He said that when he went to pay teachers, he didn't know if he was paying right or wrong.

That was the real problem. It wasn't attendance — it was that without reliable attendance, there was no way to calculate what each teacher was owed.

I worked backwards: if payment depends on attendance, I need to control who enters each class. If I need to control entries, I need it to be fast so it's not a task no one wants to do. And since the owner wanted ID cards — done: QR, USB reader, entry in two seconds.

I understood the complete flow before writing a single line of code. In two weeks, the system was in production with over 240 active students.

A conventional development team would have needed weeks of meetings to understand what I understood in a half-hour conversation. Not because they're worse — but because they would first need to study how an academy works. I already had that information. Not in a requirements document — in the conversation.

# The Three Languages

There's something that happens to me when something doesn't add up: I can't let it go. It's not anxiety — it's curiosity with teeth. I stay until I find the why. I search, document, investigate the best way, propose the solution. And when I find it, I don't just implement it — I understand it.

That constant question — why does it hurt?, why is it done this way?, why isn't the flow reliable? — is what connects the industrial engineer with the developer in me. They're not two different modes. They're the same mode applied to different materials: before it was physical processes and machines, now it's tables, triggers, and data flows.

My professor's triad doesn't need to be three people. Sometimes it can be one, if that person learned to move between the three worlds — and if they learned that the most powerful question isn't 'how is it done?' but 'why does it hurt?'

I know I don't do things perfectly. And as they say all roads lead to Rome, in development it's the same — I always reach the result. My effort is in making it as efficient as possible. And when it works, I audit it to improve it.