8 Lessons from 8 Years as a Frontend Engineer
I started writing frontend code in 2018. Since then I’ve shipped food delivery apps, ride-hailing platforms, and everything in between — from scrappy startup MVPs at Lozi to systems serving millions of daily users at Be Group. Some of those projects succeeded. Some burned. All of them taught me something.
Here are eight lessons — one for each year — that I keep coming back to.
1. The Best Code Is the Code You Don’t Ship
Early in my career at Lozi, I spent three weeks building a beautiful, reusable drag-and-drop component for reordering menu items. Custom animations, keyboard accessibility, the works. It was the best code I’d ever written.
Product killed the feature before it launched. The restaurant owners just wanted a simple number input to set display order.
That hurt, but it permanently rewired how I think. Now I ask “should we build this?” before “how should we build this?” The highest-leverage skill a senior engineer has isn’t writing code — it’s knowing when not to.
2. Performance Is a Feature, Not a Phase
At Be Group, we had a booking flow that worked perfectly in our Ho Chi Minh City office on fast Wi-Fi. Then we tested on a mid-range Android phone on 3G in a rural area. The app took 11 seconds to become interactive.
We treated performance as something we’d “optimize later.” Later never came gracefully — it came as an emergency when metrics showed we were losing riders in tier-2 cities.
I learned to set performance budgets on day one. Not aspirational ones — hard limits enforced in CI. A 200KB JavaScript bundle limit for critical paths. Lighthouse scores gating deployments. When performance is a gate, not a goal, you design differently from the start.
3. Your State Management Choice Matters Far Less Than You Think
I’ve used Redux, MobX, Zustand, Jotai, and plain React context across different projects. You know what killed us the most? Not the library — it was having no conventions around where state lives.
The real question isn’t “Redux vs. Zustand.” It’s: “Can a new engineer join this project and immediately know where to find and modify a piece of state?” If your team can answer that, you could use window.APP_STATE for all I care.
Stop debating libraries. Write a one-page state management guide for your project instead. I promise it will save more time than any migration ever will.
4. TypeScript Won’t Save You From Bad Abstractions
I was a TypeScript evangelist. I believed that if you typed everything strictly enough, the codebase would stay healthy. Then I worked on a project with 98% type coverage and the most convoluted component hierarchy I’ve ever seen.
Every component had 15+ props, half of them controlling conditional rendering logic. The types were immaculate — and completely useless, because the underlying design was a mess. We had perfect autocomplete for a component that no one could understand.
TypeScript catches typos and contract violations. It doesn’t catch “this component is doing seven things and should be five components.” That’s still on you.
5. Delete Your Clever Code
I once wrote a custom hook that dynamically composed API calls using higher-order functions, currying, and a proxy-based caching layer. It was about 80 lines. I was incredibly proud of it.
Six months later, a bug surfaced in production. I — the author — stared at my own code for 20 minutes trying to understand the execution flow. A junior engineer on the team had no chance.
I rewrote it as three straightforward functions with some duplication. The total line count went up. The bug was fixed in five minutes. And critically, anyone on the team could now maintain it.
Clever code is a debt you take out against your future team’s time. Boring code is a gift.
6. The Gap Between Senior and Staff Is Not Technical
For years I thought the path to staff engineer was “be really, really good at React.” So I went deep — custom renderers, fiber internals, build tooling. That knowledge was useful, but it’s not what changed my trajectory.
What actually mattered was learning to write a clear technical proposal that non-engineers could follow. Learning to run a meeting where a decision actually gets made. Learning to say “I think we should cut this scope” and having the data to back it up.
The jump from senior to staff is about expanding the blast radius of your impact beyond your own pull requests. If you’re heads-down coding 90% of the time at senior level, you’re optimizing the wrong metric.
7. Tests Are Documentation That Runs
I used to write tests because I was told to. The coverage number went up, the team felt good, nobody actually read the tests.
Then I joined a project mid-flight with zero documentation but excellent test coverage. The integration tests told me exactly what the app was supposed to do. “When a user submits an expired promo code, show an error and preserve the cart.” That single test taught me more than any Confluence page could.
Now I write tests as if the reader has never seen the codebase. Descriptive names. Arrange-act-assert with clear intent. If someone can read your test file and understand the feature, you’ve written a good test — regardless of what percentage the coverage report shows.
8. Your Career Is Longer Than Any Company
Lozi’s food delivery business shut down. Projects I poured my heart into at Be Group got deprioritized. Features I was proud of got rewritten by someone else six months later. This is normal.
The thing that compounds isn’t your code — it’s you. The debugging instincts, the product sense, the ability to mentor someone, the pattern recognition that tells you “we tried this in 2021 and it didn’t work because…” That stuff follows you everywhere.
Invest in things that survive a git rm -rf: your judgment, your communication skills, your network, your health. The codebase is temporary. You’re not.
That’s eight years distilled into maybe a ten-minute read. None of these lessons were things I could’ve learned from a tutorial. They all came from shipping the wrong thing, debugging at 2 AM, or watching a project I loved get killed.
If you’re early in your career, I hope some of these save you a scar or two. And if you’re further along — I’d love to hear what your list looks like. Reach out through my contact page or find me on X. I’m always up for comparing notes.