How Far One Frontend Class Took Me

Hi, there!

This is the first post on my blog.

I spent a while figuring out where to start, and in the end I decided to begin with the most honest place: how I actually got here. Not a polished résumé version, but a real look back — the nights stuck on a bug, the first thing I built that people actually used, and the quiet moment when I realized that what I wanted wasn't just to write code. If you're somewhere on a similar path, I hope some of this feels familiar.

It All Started with One Class in My First Year

My relationship with web development began in a frontend class during my freshman year.

It was the first time I understood that a few lines of code could turn into something on a screen that moved, responded, and could actually be used by real people. That feeling — "the thing I made just came to life" — hooked me. So I started teaching myself outside of class.

Looking back, this was the era before LLMs. There was no AI to ask whenever I got stuck. When I didn't understand something, the only option was to grind it out — digging through videos, books, and docs, wandering through a pile of resources with no clear direction, trying to piece together a learning rhythm of my own. It was slow, but every step felt solid.

From Learner to the Person Others Came To

Somewhere along the way, I started helping classmates read their code and debug. Eventually I became a TA for the frontend course, teaching the students a year or two behind me.

That was when it hit me: teaching someone a concept and knowing it yourself are two completely different things. To explain something clearly, I first had to truly understand it. Those days forced my fundamentals to settle into place, and they gave me a habit I still keep today — learning by putting things back out into the world.

My First Internship: Building a yoxi I Still Use Today

Then I landed my first internship.

I used everything I'd learned to help build yoxi (a taxi-hailing service) — an app that the people around me, and honestly I myself, still open and use to this day. Watching features I'd written get used by real people every day is a kind of satisfaction that's hard to put into words.

But this period gave me far more than technical skills. It was the first time I really understood what "the real world" of engineering looks like: code is only one piece of it. Just as much of the job is managing timelines, collaborating with people in very different roles, and shipping something within real constraints.

Agency Life: Learning Flexibility Under Tight Deadlines

I knew I still had a lot of gaps to fill. Before my next internship, I taught myself Vue, and then joined an agency.

The biggest thing that job gave me was walking the full path — from discussing a design mockup all the way to making it real. Because it was client work, I built more types of websites than I can count: campaign pages, brand sites, e-commerce, and more. Delivering reliably within such short cycles forced me to think hard about two things: how to build genuine rapport with the designers and product folks, and how to write components flexible and reusable enough that I wasn't reinventing the wheel with every new project.

Over the two-ish years there, I also started helping with backend API and feature development — my first real step into full-stack territory, pushing the edge of what I could do a little further out.

And it was during this stage that something slowly came into focus: more than client sites that come and go, what I really wanted to know was how to maintain and refine a product over the long term — one that was truly my own.

From "Executor" to "Architect": Joining tripool

Carrying that thought, I joined tripool — a long-distance intercity transfer platform in Taiwan — and became the only frontend engineer on the team.

That shift in role went deeper than I expected. My head was no longer in "receive a task, then execute it" mode. I had to become an architect, a planner. Beyond shipping new features and fixing bugs, the question I found myself sitting with most often was: how can this product feel better for the people using it — and how can the experience of building it feel better too?

That mindset is where the results came from, one layer at a time: an order flow supporting 15 languages and 9 currencies; a performance overhaul that lifted Lighthouse from 80 to 96 and cut the initial JS payload by roughly 44%. Behind each of those was the same underlying question — as the person responsible, what do I want this product to become?

In the Age of AI, I'm Learning All Over Again

The pace of AI over the past few years has been staggering, and I chose not to just watch from the sidelines.

I started learning the new concepts, building Agents hands-on, and continuously refining my own workflow — making AI a partner that lifts my overall efficiency, not just a buzzword. For me, this isn't all that different from the feeling of teaching myself at the computer back in freshman year: faced with something brand new, stay curious, then go and try it.

A Few Words to Close

From a single frontend class to owning the entire frontend of a product, this path has taken several years.

Looking back, what carried me here was never some impressive piece of technology. It was that pull — wanting to make things better, and wanting to make them better with more people. This blog is probably just an extension of that same pull. From here on, I want to slowly write it all down: what I've learned, what I've stumbled over, and what I'm still figuring out.

Thanks for reading this far. See you in the next one.

chinghuihui ☀️