Why I chose this path, and where I want to go next

Just once, I wanted to write something that wasn't your typical self-introduction.
Something that honestly explores why I chose this path, and where I hope it’ll take me.

As I’ve mentioned before, this blog isn’t just a portfolio or a devlog.
It’s more like a sketchbook—a space where I plan to come back and check in with myself even after I enter the industry.
This post isn’t meant to impress anyone. It’s for future-me, a few years from now, to look back and ask:

"What was I thinking back then?"
"How have I changed?"
"Did I keep my promises to myself?"

Why I chose backend

There was a time when people were called “webmasters” or “web programmers,”
and there wasn’t even a clear line between frontend and backend.
Being full-stack was just the default.

But as AJAX and jQuery came along, roles started to separate.
Frontend emerged as its own discipline, and we now have completely different development ecosystems.

When I started learning development, I had to choose between the two worlds.
And even now, one belief has never changed:

"The backend is the gum. The frontend is the teeth."

You can chew with just gums if you have to.
But teeth without gums? They can’t stand on their own.

That’s not to say I don’t value frontend.
I’m actually into fashion and design, and I love painting as a hobby—
so I deeply respect visual aesthetics and creativity.

But when I ask myself "what needs to exist first?",
my answer has always been: the backend.

And if the goal is to eventually become full-stack,
I believe it's more natural to move from backend to frontend, not the other way around.

Why Python?

If I had to sum it up:

I chose what felt right for me, not just what everyone else was doing.

In Korea, they often call it “The Republic of Java.”
Most IT structures are still centered around government or enterprise-led SI projects,
and in that world, stability is king—and so is Java (Spring).

As a result, nearly all bootcamps push Java as the default.
Python was basically the only mainstream alternative that didn’t feel like walking a paved road someone else already laid down.

I didn’t want to follow a pre-made path.
I wanted to build something of my own.
To choose tech that fit my mindset and my way of thinking—not just what the industry expects.

Of course, Python is still a minority in Japan.
The perception that “Python = AI” is deeply rooted,
and many job posts treat it like a machine learning language, not a backend one.

But after nine months of building real projects with Python, I’ve grown attached to it.
I’m not switching languages just because it might help me get hired faster.
I want to go deeper first.

Why FastAPI, not Django

This wasn’t a “hipster pick.” Not on purpose, anyway.

My bootcamp curriculum went: Flask → Django → FastAPI.
Most of the focus was on Django.

One of the first assignments in the Flask module was to build a simple personality quiz using a given template.
Tweak it a little, submit the output, and you’re done.

But honestly? That didn’t sit well with me.

I hated the idea of just analyzing someone else’s code.
If I was going to make something, I wanted to build it from scratch.
So I rewound the lecture, started from zero, and made the whole thing myself.

It was rough, sure—but the final result got positive feedback from my mentor,
and I even heard it was shared with later students as a reference project.
That process helped me bond with Flask,
and eventually… I skipped Django entirely.

Later, when my team project collapsed and I had to continue solo,
I was free to choose whatever framework I wanted.
I hadn't studied Django or FastAPI deeply yet,
but since I was already comfortable with Flask, FastAPI felt like the logical, more modern step forward.

And it turned out to be a perfect fit—for both my personality and coding style.

How I got hooked on DevOps

The project I’ve been talking about?
It’s this blog you’re reading right now—cliche.life.

After the team split, I had one week left.
No time for perfect planning. Just build, ship, survive.

But I didn’t want something that just barely runs.
I wanted an MVP that actually worked—and could be shown with pride.

While other teams were git pull-ing their code onto servers last minute,
mine was already auto-deploying via GitHub Actions.

And at that moment, my mentor’s words clicked:

"Docker is God."

From then on, I started introducing tools and systems like CI/CD, ELK stack, and automated logging—
not because they looked cool, but because I needed them.

What I want now

My current goal is clear:
Gain real experience in backend, then gradually expand into DevOps.

I know DevOps isn’t exactly a beginner-friendly field.
So I’ll start by working with real systems, learning how production works,
and growing into an engineer who can handle both development and operations.

In the end

I want a lot of things.
Backend, DevOps, sometimes even security or design.
But what I really want is to understand the whole system.

I don’t just want to write clean code.
I want to understand the flow, the architecture, the context—and make decisions that matter.

That’s the kind of developer I want to become.
Not just a coder, but a system thinker and builder.

Whatever choices I make from here on out,
I want them to be mine.
My decisions. My responsibility.

This blog is my record of that process—of all the wrong turns, late nights, little wins and course corrections.

And if it ever helps someone else feel a little less lost,
I’ll consider that a success, too.