Origin

From a Reel-to-Reel tape machine to Linux Infrastructure: A journey of curiosity, learning, and sharing

My journey into technology started with a question.

Not a question about programming, networking, or computers. It started with an old reel-to-reel tape machine and a thought I could not ignore:

How does this actually work? I was fascinated by the idea that something could appear simple on the outside while hiding a complex world underneath. I wanted to understand what was happening inside, how the pieces connected, and why things worked the way they did.

Looking back, that curiosity became the foundation of everything that followed. Whether I was repairing computers, learning Linux, building infrastructure, or automating systems, the motivation was always the same: do not just use something, understand it.

The first computers and the foundations

My first computer arrived in the 1990s. It was a modest AMD Athlon system, but for me it was a gateway into an entirely new world.

I quickly moved from simply using computers to experimenting with them. I enrolled in a technical high school with a strong informatics program, where technology was not taught as a collection of tools but as a combination of principles. Mathematics, physics, computer architecture, and electronics were all part of the foundation.

Learning about the Von Neumann architecture, understanding how processors and memory interact, and studying the electrical side of hardware gave me a deeper appreciation for what was happening beneath the operating system.

Outside school, I spent years building, rebuilding, and troubleshooting Windows machines. Like many people from that generation, I learned a lot from forums, documentation, and trial and error. Breaking things was often the fastest way to understand them.

Starting over in another country

Moving to southern Spain changed everything.

I arrived without speaking the local language and with the assumption that English would be enough. It was not. On top of that, getting my previous education officially recognized became a long process.

Professionally, it felt like starting from zero.

I worked different jobs, many of them unrelated to technology. Each one taught me something valuable: how to adapt, communicate, solve problems with limited resources, and keep moving forward when the obvious path disappears.

When the economic crisis hit, freelance computer repair became my main source of income. What started as a practical way to earn money became a valuable learning experience. Every broken computer, every strange software problem, and every frustrated user was a new challenge to solve.

I started seeing problems differently. A problem was no longer just something broken. It was an opportunity to understand something new.

The mistake that introduced me to Linux

One mistake changed my relationship with technology.

I accidentally deleted a partition containing all my personal photos.

The recovery software I found online was expensive, and I could not afford it. While searching for alternatives, I ended up on a Linux forum.

At the time, Linux felt unfamiliar. The command line was intimidating, and the community was very different from the commercial software world I knew.

But something immediately stood out.

People were willing to help.

There was no sales pitch, no locked features, and no requirement to buy something first. People simply shared their knowledge. They explained how to boot from an Ubuntu Live CD, use recovery tools, and restore my data.

It worked.

I recovered my photos, but I gained something much more important: my first real connection with the Linux philosophy.

Technology could be shared. Knowledge could be freely exchanged. Communities could help people solve real problems.

That idea stayed with me.

Linux becomes more than a hobby

Linux slowly became a constant part of my learning journey.

Windows remained my main work environment for a long time, but Linux was always there in the background, powering experiments and personal projects.

Eventually, that interest became a career direction. I moved into professional computer repair, completed a degree in Network Systems Administration, and started building larger projects.

For my final project, I created a Raspberry Pi-based surveillance system running Debian. It included remote access and security filtering and received a 9/10 grade.

The grade was nice, but the more important lesson was realizing that Linux gave me the freedom to build solutions instead of simply consuming them.

That was when I decided I wanted to start contributing back.

From experiments to real-world solutions

As my Linux knowledge grew, my curiosity moved deeper into the hardware layer.

I started exploring microelectronics, breadboards, UART debugging, and homelabbing. I enjoyed creating small environments where I could test ideas, break things safely, and learn how everything connected.

One example came from a digital signage problem at work.

The existing solution depended on expensive licensing, and there was a need for something more flexible and affordable.

I designed a Raspberry Pi-based alternative using standardized hardware and a cost-effective software stack. After testing and refining the solution, it became the standard approach for the company.

It was a simple idea, but it represented something I enjoy most about technology: taking limitations and turning them into engineering challenges.

Learning infrastructure properly

Eventually, my experiments moved from individual machines to complete environments.

VirtualBox was no longer enough for what I wanted to test, so I moved to Proxmox. Having a real hypervisor changed the way I learned. I could simulate infrastructure, test different scenarios, and understand how systems behaved together.

When I later moved into a Linux administration role, I quickly discovered that knowing Linux was only the beginning.

Managing infrastructure at scale was a different challenge.

I inherited systems with limited visibility into their health. The first problem was not fixing failures. It was understanding what was happening.

I learned Zabbix from the ground up, evaluated the environment, implemented monitoring, and created custom monitoring items where the default templates were not enough.

The result was a shift from reacting to problems after they happened to having the information needed to prevent them.

That experience reinforced a pattern that has followed me throughout my career:

Understand first. Improve second. Automate whenever possible.

The automation journey

That mindset naturally led me toward automation and infrastructure as code.

I started with Ansible, and it immediately felt like the right way to manage systems. Instead of repeating manual tasks, infrastructure could become consistent, documented, and repeatable.

From there, I expanded into AWS, CloudFormation, and eventually Terraform, which has become my preferred infrastructure-as-code tool.

Along the way, tools like Git, Jenkins, Airflow, Prometheus, and Grafana became part of my daily toolkit, helping me build systems that are not only functional but observable and maintainable.

The same question remains

From that first reel-to-reel tape machine to modern cloud infrastructure, the technology has changed completely.

The question has not.

How does this actually work?

That curiosity continues to drive me. It pushes me to learn, experiment, build, and share knowledge with others.

Because the best part of technology is not only creating solutions. It is understanding them deeply enough that you can help someone else create theirs.