The way I work.
Four habits I keep coming back to in serious work. Each one is wired into the site you're reading — the column on the right is the receipt, pulled straight from the source. Crack open devtools any time you want to check my math.
I build in rings.
I split a system into rings — the most important things in the middle, the optional things on the outside. You should be able to peel off any feature without breaking the core. This site is wired exactly that way: a tiny kernel at the center, mode renderers in the middle, optional features at the edge.
Keeping the rings honest is forced clarity. The bus doesn't know about modes; modes don't know about features; features don't know about each other. Coupling is what makes systems brittle — the boundary is where I draw the line.
assets/ ├── kernel/ bus, router, mode, loader ├── modes/ terminal · swiss ├── features/ indicator · snippets │ banner · keys └── tokens/ palette + base
Every byte earns its place.
I treat dependencies and code lines like ingredients — every one has to earn its spot. This site has no third-party libraries, no build step, and a hard rule that no file is allowed to grow past 150 lines. (A small script checks all of that on save.)
Constraints aren't about being a purist; they're how I keep the codebase legible six months later. The first time I cut a feature because a file was creeping past the line limit, I realized I didn't need that feature anyway. Fast is a side-effect of small.
- deps
- 0
- files
- 17
- longest
- 149 lines
- average
- 66 lines
- fonts
- system
- build
- none
Source is the product.
Open devtools right now. The HTML, CSS, and JavaScript you'll see is the same code I edited — no compiler in between, no Shadow DOM hiding things. Every file opens with a short comment naming what it's for, what it depends on, and what it deliberately won't do.
The reader I'm writing for is a senior engineer poking around for ten minutes. Comments explain why something is the way it is — names handle the what.
/* * mode-manager.js — owns <html data-mode>. * Wraps swap in a View Transition with * reduced-motion fallback. Emits 'mode:change'. * Dependencies: ./event-bus.js * Invariants: data-mode set inline before paint. * Non-goals: no UI; no scheduling. */
Numbers over adjectives.
"Faster" is unfalsifiable. "P99 dropped from 412ms to 89ms after dropping the N+1 query" isn't. When I claim something about performance, I want a number behind it and a script that reproduces it. Otherwise the optimization didn't really happen.
This site has a budget too — the table on the right. They're not impressive numbers, just ones I picked on purpose and then held myself to.
| metric | target |
|---|---|
| first paint | < 100 ms |
| transfer | < 50 KB |
| CLS | 0 |
| INP | 1 frame |
| fonts | system |
Habits I keep coming back to.
-
Signal-style bus
Topics remember their last value. Late subscribers replay. Init order stops mattering.
→ kernel/event-bus.js -
View Transition + motion fallback
Feature-detect
→ kernel/mode-manager.jsstartViewTransitionand respectprefers-reduced-motionin four lines. -
Registry of renderers
One shell per element, mode-keyed renderer per shell. Add a mode without touching the shell.
→ modes/components.js -
Inline pre-paint script
Set the theme attribute on
→ <head> of every page<html>before any stylesheet loads. FOUC dies.
Where I've put this to work.
Past here the source goes private. The four above are the part I can prove on this page; the rest you take on the numbers — or on a call.
-
Sensor fleets at volume
Ingestion for 100,000+ sensors, each reporting every few minutes — tens of millions of data points a day, sustained, zero dropped readings, no backlog.
→ 100k+ devices · ~tens of M points/day -
LoRaWAN, end to end
Gateways, device provisioning, network-server integration — the full path from radio to database. The edges you only hit running a live fleet, not reading the spec.
→ field-deployed, full stack -
AWS in production
Compute, storage, queues, and the pipelines between them — production systems I own from the instance up, not just the code on it. The fleet above runs here.
→ years in production -
Data analysis on the stream
Sensor-signal analysis on the telemetry above; document and word-frequency analysis on text corpora; sentiment analysis on social-media streams. Reading the data with the same pipeline that moves it.
→ sensor · text · social sentiment -
Networking & bare metal
CCNA1-level networking fundamentals and end-to-end physical machine setup — rack, OS, network, runtime. "End to end" includes the box: the radio→DB path starts at hardware I provisioned.
→ CCNA1 · bare-metal → runtime
Here are some things I made for myself.
-
baker
A single-binary static site bundler and HTTP server in Zig. Brotli + gzip, ETags, 304s, hot reload via SIGHUP — bake a site into one
→ github.com/Linh35/baker · Zig.binfile, then serve it. The same toolchain that publishes this portfolio when I'm not pointing at GitHub Pages. -
wiki-art-downloader
Bulk-downloads an artist's catalogue from WikiArt as JPGs. Node 18+, zero dependencies — global
→ github.com/Linh35/wiki-art-downloader · Nodefetch, walks the eight CDN shards, parallel with configurable concurrency, dry-run, and resume-by-skip. Written so I could archive a painter's collection without clicking 400 thumbnails. -
ssw
Multi-tab state, no ceremony. A signal store with a SharedWorker as the single source of truth and a live mirror per tab — write
→ github.com/Linh35/ssw · TypeScriptstore.count++, an optimistic update reconciles across tabs over a batched ack protocol. ~3.5 KB gzipped, store-shaped API, tested end-to-end against MessageChannels — no jsdom. -
number-helper-extensions
Ergonomic helpers on
→ github.com/Linh35/number-helper-extensions · JSNumber—(6).minutes(),(3).times(i => i*2),clamp,ordinal,ago()/fromNow(). The prototype is touched only when you callextendNumber(); every helper is also exported raw for anyone who won't.
The rest of the workshop lives at github.com/Linh35.
If a team treats the work like this, I'd love to talk. About · linh@lelinh.dev · github.com/Linh35 · LinkedIn