I Built Systems for Years—So Why Did I Understand Nothing?

The Reality Check I Faced in London as an Engineer

Wow! An engineer who crossed the ocean full of confidence found himself completely lost in front of a system.

It was my eighth year with the company.

I was traveling to London to attend training for a financial system that one of our customers had purchased.

The server engineer, network engineer, and operations engineer were all there as well.

And I was the only application engineer.

What I was responsible for was not just a business application.

It was the entire financial system.

A massive platform where countless functions worked together and multiple systems were connected in complex ways.

I was highly motivated.

I had built many systems before.

Java-based three-tier architectures.

Web applications.

Database design.

Interface design.

Customer-facing systems.

I was confident in my application development skills.

"My mission is to understand this entire system and eventually support its development and operations."

With that sense of purpose, I headed to London.

The First Sign Something Was Wrong

On the first day of training, the instructor began explaining the system.

But something felt off.

I couldn't absorb what he was saying.

The problem wasn't English.

In fact, he was using system terminology almost exclusively.

These were words I knew.

Yet somehow, the meaning wasn't connecting.

The server engineer understood.

The network engineer understood.

The operations engineer was actively asking questions.

And I was the only one being left behind.

Why?

I Thought I Understood Systems

It took me a long time to realize the answer.

For years, I had been focused on what was "inside the application."

There was a user interface.

Business logic.

A database.

The classic Java-based three-tier architecture.

But what was being explained in London was everything outside of that world.

How do systems connect to each other?

How does one system identify another?

How are communication paths designed?

When a failure occurs, where do you start troubleshooting?

How is authentication handled?

Where are endpoint configurations managed?

How does a load balancer work?

How do systems communicate across network boundaries?

I had experience designing data integrations between systems.

I had designed CSV integrations.

I had designed API integrations.

But looking back, I had always designed them assuming that the systems were already connected.

I had never seriously asked:

How are they connected in the first place?

Why do they connect successfully?

Which configurations make those connections possible?

My understanding of those foundations was shockingly weak.

The Frustrating Days in London

The training continued.

But my understanding did not.

Every morning, I left the hotel.

I attended training sessions.

I didn't understand.

Every evening, I returned to the hotel.

I studied the materials.

Still, I didn't understand.

Then another day would begin.

Before I knew it, not only the first half but almost the entire training program had passed, and I still couldn't grasp the full picture.

My anxiety grew day by day.

I was the only application engineer.

There was nobody else to rely on.

I was supposed to be the person who understood the system best.

But reality was the opposite.

Looking back, it was one of the biggest setbacks of my engineering career.

A Challenge to Japanese Engineering Education

I'd like to raise a somewhat controversial question.

In Japan, application development and infrastructure engineering are often treated as separate disciplines.

Specialization is important, of course.

But are we producing too many engineers who cannot see the system as a whole?

I certainly was one of them.

I could write code.

I could design systems.

I could review architecture and implementation.

But I couldn't explain how the entire system worked.

Can we truly call that a systems engineer?

Perhaps this is one reason why Cloud, DevOps, and SRE have gained so much attention in recent years.

Applications alone are not enough.

Infrastructure alone is not enough.

Operations alone are not enough.

Only when we understand the whole picture can we claim to truly understand a system.

What I Really Learned in London

The most important thing I learned in London wasn't the financial system.

It was my own limitation.

And it was the existence of a world I had never really seen.

The frustration I felt back then was painful.

But looking back now, without that experience, I might have remained an engineer who viewed systems only through the lens of application development.

There is a difference between having experience building systems and truly understanding systems.

The days I spent in London, confronted by that reality, remain one of the defining moments of my career.

I can do it! Take the first step tomorrow.