A Decade of Frontline Engineering: 3 Rules I Write Code By

It is hard to believe I have been crafting websites and backends for ten years. Over this decade, I have seen frameworks rise, flare up, and die. I have seen jQuery give way to Angular, which gave way to React, which gave way to SSR setups.

Through these shifts, I have built multiple production systems that still run cleanly today without needing a week of maintenance every time someone runs an install command. Here are the three non-negotiable rules I follow to write software that stands the test of time:

1. Build Around Semantics, Not Hype

A web engineer's greatest tool is still the simple, boring, semantic HTML block.

When you prioritize semantic markup, accessibility and SEO are handled naturally, browsers understand the document structure perfectly, and you spend infinitely less time writing container queries or patching rendering bugs. Style guides and frameworks can change, but the underlying browser API remains stable.

2. Guard the Bundle Performance Budget

If your portfolio of a few pages requires 3MB of client-side Javascript to render a greeting, you are not engineering; you are wrapping bloated frameworks in more bloated layers.

• Keep it tight: Aim for sub-150ms Interaction to Next Paint (INP).
• Defer non-essentials: Do not bundle massive external graph engines or animation libraries unless you are rendering active, interactive canvases.
• Lazy initialize: Only boot complex modules when the user actually accesses that screen or clicks that button.

3. Maintain Absolute Dependency Discipline

Every NPM package you add is a liability. It is a potential security vulnerability, a source of breaking changes, and a point of failure during builds. If a helper package only does 15 lines of string conversion, write those 15 lines yourself.

By keeping your codebase slim and owning your core algorithms, your projects will compile instantly, build reliably, and be comfortable to jump back into even multiple years down the road.