From Mainframe to Cloud — My Journey Through 6 Industries

Why Industry Diversity Matters

When I am asked about my career path in job interviews, I sometimes see a furrowed brow. Banking, logistics, events, transport, cloud, AI — six different industries in twenty years. Some read that as instability. I see it as my greatest advantage.

Every industry taught me something that I could never have learned from any book or online course. And every industry gave me tools — both mental and technical — that I needed in the chapters of my career that followed.

This is the story of that journey.

Chapter 1: Banking — Where It All Began

My first professional job was at an Austrian bank. I was fresh out of school, full of enthusiasm, and had no idea about the real world of software development. What awaited me: PL/I on IBM mainframes, JCL batch jobs, green terminals, and deployment cycles that took weeks.

It was not glamorous. It was not exciting. But it was educational.

What I learned in banking is something many developers never truly understand: reliability. In a bank, software must not work “most of the time.” It must work all the time. Every transaction must be booked correctly, every cent must be accurate, every audit trail must be complete.

This mentality of absolute reliability shaped me. I learned to program defensively, to think through failure scenarios, and to regard transactional integrity as non-negotiable. I learned that “it works on my machine” is not an acceptable statement.

But I also learned what goes wrong in traditional organizations: too much bureaucracy, cycles that are too long, too little courage to experiment. After three years, I knew: I needed something faster.

Chapter 2: Logistics — The Real World

My next stop was the logistics industry. Here it was not about abstract financial transactions but about physical things that needed to be moved from point A to point B. Trucks, warehouses, barcode scanners, real-time tracking.

The biggest culture shock: in logistics, real-time systems are mission-critical. When the tracking system goes down, trucks end up in the wrong place, warehouses overflow or run empty, customers do not receive their deliveries. There is no “scheduled maintenance on the weekend” — the system runs around the clock, seven days a week.

What I learned here: building systems for the real world is fundamentally different from developing software in a vacuum. Hardware can fail, networks can be unstable, users can do things you would never have imagined in your wildest dreams. A warehouse worker using a barcode scanner as a doorstop is not an exception — it is Tuesday.

On the technical side, I learned a great deal about integration. Different systems need to work together, often through outdated protocols and interfaces. I learned to work with EDI, SOAP, and various proprietary formats. I learned that interoperability matters more than elegance.

Chapter 3: Events — Creative Freedom

The events industry was the opposite of banking. There was no planning over months; there was improvisation. A festival in six weeks? No problem. The system needs to handle access control, cashless payment, and artist management? Let us do it.

What fascinated me about the events industry was the combination of hardware and software. I did not just write code; I also configured barcode scanners, integrated RFID readers, and set up networks on festival grounds. In a tent, in the rain, with an unreliable power supply.

The lesson: delivering under pressure. When the festival starts tomorrow and the system is not running, there is no option to “postpone.” You solve the problem, no matter what. This mentality taught me to set priorities, to separate the essential from the inessential, and to find solutions instead of discussing problems.

On the technical side, I learned to build resilient systems. Systems that still work when half the infrastructure fails. Offline capability, local caches, conflict resolution — all concepts that became relevant again in the cloud era.

Chapter 4: Transport — Complex Domains

In the transport industry, I experienced for the first time just how complex business logic can be. Fare calculation, route planning, regulatory requirements, multimodal transport chains — the domain is a labyrinth of rules, exceptions, and exceptions to exceptions.

This is where I truly understood Domain-Driven Design — not as an academic concept, but as a survival necessity. Without clear domain models, bounded contexts, and a shared language with the domain experts, every project would have failed.

The most important lesson: listening. Before I write a single line of code, I need to understand what the domain experts are telling me. And “understand” does not mean “I have read the requirements” — it means “I know the domain well enough to ask questions the experts themselves have not thought of.”

Chapter 5: Cloud and DevOps — Automation as a Superpower

The move into the cloud and DevOps world was the biggest technical leap of my career. Suddenly, it was no longer about building individual applications but about automating entire infrastructures.

Terraform, Docker, Kubernetes, CI/CD pipelines, Infrastructure as Code — an entirely new world. And one that united everything I had learned so far. The reliability mentality from banking. The real-time requirements from logistics. The resilience from events. The domain understanding from transport.

What impressed me most about cloud and DevOps: the leverage effect. A single developer managing infrastructure as code can operate systems that previously required an entire operations team. Automation is a superpower, and in the cloud, you can use it to its fullest.

I also learned here what “scaling” really means. Not as a theoretical concept, but as a practical challenge. When a system suddenly receives ten thousand requests per second instead of one hundred, the weaknesses reveal themselves mercilessly.

Chapter 6: AI — The Current Chapter

And here I am now. I build tools for AI-powered software development. Atoo Studio, SiteHorse, and whatever comes next.

What distinguishes this chapter from all the previous ones is the speed of change. In the banking world, technology changed over years. In the AI world, it changes in weeks. Models that were state of the art six months ago are outdated today. Frameworks that did not exist yesterday are tomorrow’s standard.

This requires a new way of thinking. I can no longer build on a stable platform and use it for years. I have to design my architecture so that I can swap out the AI components without rebuilding everything. Abstraction and loose coupling are not optional best practices — they are a matter of survival.

The Common Thread

When I look back at all six chapters, I see a common thread: solving problems with technology. That was the case in banking, in logistics, at events, in transport, in the cloud, and in AI. The technology changed, the problems changed, but the fundamental attitude has remained the same.

And that is precisely why I believe that industry diversity is not a disadvantage. Every industry gives you a new set of mental models, new ways of thinking, new perspectives. And in a world that is changing ever faster, the ability to adapt and think from multiple perspectives is more valuable than deep specialized knowledge in a single domain.

What I Recommend to Everyone

If you have the opportunity to switch industries — do it. Not every year, but every few years. Leave your comfort zone. Get to know new domains. Work with different technologies, different teams, different cultures.

You will find that the things that truly matter — clear thinking, good communication, the ability to break complex problems into simple parts — apply everywhere. And every new industry will make you a better developer.