The Next Step in My Career — Quick and Dirty

I am approaching my first decade in frontend development.

Naturally, Computer Science students encounter web development courses in college. Back then, Angular had a bigger name than React; Vue had probably already been released, but I wasn’t aware of it yet.

Living through that “Warring States period” of frontend tooling was very helpful for understanding subsequent evolutions and gaining perspective. Looking back at community discussions now, many are debates we already had years ago, making me wonder—is this what growing older feels like?

Early in my career, I tried many things: writing articles, giving talks, building side projects. Yet my primary contributions were still largely confined to company products and services, which is something I somewhat regret.

Here, I’d like to share some thoughts on the future and career paths. Feedback and discussions are always welcome.

Thoughts on Frontend and the Future

Lately, it feels like the frontend engineer market has reached saturation; landing a job isn’t as easy as it used to be.

Even for engineers who don’t specialize in frontend—or anyone who is tech-savvy and comfortable writing code—piecing together a webpage is no longer a challenge: just skim the React or Vue docs, pick a convenient UI component library, and pair it with ChatGPT or a local LLM. Of course, beginners will inevitably spend time debugging, but the fact remains. Consequently, the value of a frontend engineer must be demonstrated elsewhere, which also means that junior frontend developers will find it harder to secure jobs.

Here’s another path worth discussing.

Most junior engineers pigeonhole themselves into a narrow domain: frontend is strictly frontend; they don’t touch anything outside the browser, focusing solely on fulfilling requirements and slicing UI. While demand for this still exists in the short term, as barriers to entry drop and UI libraries mature, these developers will inevitably hit a ceiling: if most requirements can be fulfilled by other developers, or if your only skill is translating business requirements into code, where does your value lie?

In the short-to-medium term, my answer is: be a software engineer.

Before being a frontend engineer, you should be a qualified software engineer who simply happens to have deeper domain knowledge in frontend.

This encompasses computer architecture, algorithms, data structures, security, and so on. Naturally, these are broad disciplines, but the more you understand, the broader your perspective will be when tackling a problem. For example, understanding computer architecture, tinkering with Arduino to grasp low-level protocols, or writing a simplified HTML parser out of curiosity about how Svelte works under the hood—none of these have an immediate, direct tie-in to everyday frontend work, but they give you far more mental flexibility and problem-solving breadth.

Many of the most technically adept software engineers I’ve met are like this. They may not have solved hundreds of LeetCode problems, but they possess a deep intuition for how things work under the hood. A former colleague once excitedly shared how he modified a humidifier with a relay so he could control its power via Arduino, enabling handy features like scheduled timers.

I also recommend developing domain knowledge. For instance, when working on securities-related services, I took the time to understand Japanese regulatory constraints, the NISA system, margin trading, quantitative trading, and integrations with external services (such as private mailboxes/PO boxes). While researching Japanese broadcasting systems, I wrote a simple subtitle parser. These domain-specific insights are key to standing out from other engineers.

Another path is joining and creating ecosystems.

The advent of React revolutionized how the industry builds UIs, abstracting UI into functions and state management, isolating side effects, and enabling UIs to be broken down into reusable components.

This is another path frontend engineers can pursue. However, unless your company is massive, it’s hard to find opportunities internally; you often have to enter through open-source communities, and not everyone has the capability to reshape an ecosystem. Still, there’s no reason to sell yourself short—Rich Harris, the creator of Svelte, was originally a journalist who ended up building Svelte while coding for visual reporting.

Yet another path is exploring the various sub-fields of frontend engineering. Usually, “frontend” refers to web development—more precisely, constructing UIs with HTML, CSS, and JavaScript. But browser capabilities are evolving rapidly, giving rise to many specialized branches, including but not limited to:

• Data visualization
• Animations (UI animations, transitions, micro-interactions, etc.)
• Accessibility (a11y)
• Web games
• WebGPU applications: Porting LLMs to the web, or leveraging WebGPU to bring previously local-only applications directly into the browser
• WebAssembly
• Visual effects and 3D: WebGL or Three.js
• Web-to-IoT integrations: WebSerial, Web Bluetooth, WebUSB, etc. While this market is niche and somewhat limited, I find its potential immense. For instance, VIA is virtually essential for custom mechanical keyboard enthusiasts; configuring keymaps directly in a browser is a prime example of leveraging WebUSB.
• Low-level protocols: WebRTC applications, the newer WebCodecs API, etc.
• Performance optimization

Naturally, the more specialized branches you master, the harder you are to replace.

Although the entry barrier to frontend has lowered (and was never particularly high to begin with), building a site that balances SEO, performance, and accessibility still demands real experience. LLMs can currently stitch together a functional site, but balancing all these nuances simultaneously is far from trivial.

Other Directions

From a software engineering standpoint, areas like CI/CD, automated deployment, version control, and testing are also viable avenues. However, I consider these things that any software engineer naturally picks up; unless the deployment architecture is unusually complex, writing configuration files gets you most of the way there.

Ideally, combine this with a specific industry—such as solar energy, food services, hospitality, and so on. Find unmet needs in an industry you care about, build an MVP to test and validate, and you’ll eventually realize that frontend is simply a means to an end.

Recently, I watched Pieter Levels on the Lex Fridman Podcast. PHP, jQuery, MySQL—he builds most of his projects solo, pulling in $300k a month.

All of it is built with old, seemingly outdated tech, yet it solves real problems. That, too, is a valid path: approaching development with a product- and service-first mindset, where the technology merely needs to be good enough.

This philosophy resonates with the exchange between Linus Torvalds and Junio Hamano during the early days of Git, as described in Git 的故事：這一次沒這麼好玩. (It’s a fantastic read, highly recommended!)

At the time, Linus wanted to write a merge algorithm but felt a scripting language was better suited for the job. He asked for help, and Junio Hamano stepped up, implementing a version in Perl—quick and dirty.

Linus replied:

…Quick and Dirty That’s exactly what I wanted. Q ‘n’ D is how the ball gets rolling.

That line struck a chord with me. I believe a great engineer should embody this trait: prioritize getting it “Quick and Dirty” first, and worry about the rest later.

Reflections on Career

I haven’t mentioned soft skills like communication, leadership, and management. Of course, they are crucial, but my recent view is that soft skills and technical skills reinforce one another. As you sharpen your technical expertise, your ability to communicate effectively develops alongside it.

Many people ask how to get promoted or which programming language offers the best job prospects. There is nothing wrong with these questions; I used to ponder them constantly myself: How do I move into management? How do I get a raise?

However, once you accumulate a certain amount of experience, pursuing a “better career” should no longer be the end goal—it should be a means to an end.

Unless your personal goal is crystal clear—say, building products and services you genuinely love within a company—from a capital-market perspective, we are merely trading our time for money. And if you are only trading time, the return is hardly worth it.

This is something I am actively navigating. If you work at a solid, reputable company, try to expand your network and leverage internal relationships and resources to learn what you want. Relationships and networks are assets you take with you even after leaving. Due to recent project shifts, I’m currently doing mostly backend development, which has given me perspectives I never paid much attention to before—a rewarding shift in itself.

A realization that has hit me hard recently: a steady monthly paycheck is both a reassuring anchor and a slow poison.

When stressed, you tell yourself to just push through a few more days until payday; once your assigned tasks are done, you can clock out early and head home. That stability has its merits, but for me right now, the downsides outweigh the benefits.

Of course, this also stems from my own shortcomings or personality misfits. Even when you have the technical chops to pull off great work, most of the time you are simply executing against specification sheets, with little room to drive a project from zero to one. Not to mention that in large corporations, spinning up a simple server requires wading through layers of security reviews and legal compliance checks.

Years ago, I too bought into this myth wholeheartedly.

In Designing Your Life, the authors reference James Carse’s concept of finite and infinite games:

如果是有限遊戲，我們會照規則走以求獲勝；但如果是無限遊戲，我們會享受一直玩下去的樂趣。 (In a finite game, we play by the rules to win; but in an infinite game, we play for the joy of keeping the game going.)

Putting aside the fact that everyone seeks a different life path, I feel that from childhood through exams, competitions, and job hunting, we are constantly indoctrinated with the idea that achieving a specific milestone will suddenly make life complete. In reality, it rarely works that way.

In short, I believe we should anchor our goals in things outside of our careers. What matters more is: what kind of life do you actually want to live? Does what you are doing right now align with that life?

Some physical constraints are admittedly harder to break through—factories, hardware manufacturing, semiconductor design, etc. You can’t just quit tomorrow and single-handedly design ICs or open a fab. But you can flip the question and ask whether your current career trajectory genuinely aligns with your personal goals.

Going forward, I want to ask myself every day: Did you go Quick and Dirty today?

Naturally, when it comes to career or life itself, I am still searching for answers too. If you have any thoughts, I’d love to hear them.