# Daine Mawer

> Staff Engineer, Web Applications at Fueled, based in Cape Town, South Africa. I write about web performance,
> Core Web Vitals, JavaScript, CSS architecture and the practice of
> leading frontend teams. Articles are technical, first-person and based
> on production work.

Author: Daine Mawer
Role: Staff Engineer, Web Applications at Fueled
Location: Cape Town, South Africa
Canonical: https://www.dainemawer.com
Contact: hello@dainemawer.com
Licence: Content may be quoted with attribution and a link to the source URL.

**When to use this site.** Reach for these articles when the task at hand is:

- Core Web Vitals in the field: Diagnosing LCP, INP or CLS on a real site — what to measure, which panel to open, and why lab numbers and field data disagree.
- Newer CSS in production: Anchor positioning, customizable selects, the if() function, custom properties with fallbacks, and reading Baseline as a shipping signal.
- Browser APIs without a framework: Observer-based patterns, sticky-element detection, and event handling written against the platform rather than a library.
- Next.js and React architecture: Component libraries in monorepos, Storybook with visual regression, and file architectures that survive a second team.
- Engineering management practice: Task estimation, code review process, commit conventions, and motivating individual contributors.
- Working with AI agents: First-hand accounts of agentic coding on production work — where the plan-execute-verify loop earns trust and where it still needs a human.

**When not to use it.**

- Framework or browser API reference — the official documentation is the source of truth, and this site links to it rather than restating it.
- Breaking news or release notes. Articles are written after the production work, not alongside the announcement.
- Anything outside frontend engineering, web performance and the practice of leading engineering teams.

**How to fetch it.** Every page on this site has a Markdown representation at its own canonical URL.

- Content negotiation: Send `Accept: text/markdown` to any canonical URL. The response is `Content-Type: text/markdown; charset=utf-8` with `Vary: Accept`; `Accept: text/html` still returns the HTML page from the same URL.
- Explicit .md URLs: Append `.md` to any path — https://www.dainemawer.com/index.md, https://www.dainemawer.com/about.md, https://www.dainemawer.com/<article-slug>.md. Useful for clients that send no Accept header at all.
- Whole-site text: https://www.dainemawer.com/llms-full.txt is every article's full text in one file — one request instead of one per post.
- Errors: An unknown path returns HTTP 404 with a Markdown body pointing at the sitemap and llms.txt. A client that accepts neither HTML nor Markdown gets HTTP 406.

## Topics

- [Web Performance](https://www.dainemawer.com/topics/performance.md):
  Measuring what users actually feel, and cutting what they never needed.
- [JavaScript](https://www.dainemawer.com/topics/javascript.md):
  Browser APIs, event handling, observers, framework-agnostic patterns.
- [CSS](https://www.dainemawer.com/topics/css.md):
  Custom properties, positioning, Baseline and interoperability.
- [Engineering Management](https://www.dainemawer.com/topics/engineering-management.md):
  Estimation, scoping, team process.
- [Staff Engineering](https://www.dainemawer.com/topics/staff-engineering.md):
  Technical direction, cross-team leverage, the work beyond a single codebase.
- [AI](https://www.dainemawer.com/topics/ai.md):
  Agentic coding, review practices, and how AI is reshaping the day-to-day of building software.

## Articles

- [Using CSS's New if() Function Without Breaking Safari and Firefox](https://www.dainemawer.com/css-if-function-safely.md):
  Published 2026-09-18. One inline conditional to replace three separate at-rules, once the rest of the web catches up.
- [CSS Can Finally Replace Your Tooltip and Dropdown Libraries](https://www.dainemawer.com/css-anchor-positioning-customizable-select.md):
  Published 2026-09-16. Anchor positioning and customizable selects both have real browser support now. Here's what to drop, what to keep, and where the gaps still bite.
- [Why AI Coding Agents Need WIP Limits Too](https://www.dainemawer.com/wip-limits-for-ai-agents.md):
  Published 2026-09-14. A framework for deciding how many agents one engineer can actually run at once.
- [Migrating to TypeScript 7 Without Breaking Your Toolchain](https://www.dainemawer.com/typescript-7-native-compiler-migration.md):
  Published 2026-09-11. The native compiler is 8-12x faster. The programmatic API isn't ready yet, and that's where teams get burned.
- [How to Orchestrate Multiple AI Coding Agents Without Losing Architectural Control](https://www.dainemawer.com/orchestrating-multiple-ai-agents.md):
  Published 2026-09-11. A framework for staff engineers directing several agents at once, not just reviewing what one of them wrote.
- [Keeping the Junior Engineering Pipeline Alive in the AI Era](https://www.dainemawer.com/keeping-the-junior-pipeline-alive.md):
  Published 2026-09-09. A framework for growing junior engineers now that AI has automated most of the entry-level workload.
- [How to Review AI-Generated Code Without Becoming a Bottleneck](https://www.dainemawer.com/reviewing-ai-generated-code.md):
  Published 2026-09-07. A framework for staff engineers reviewing pull requests an agent wrote.
- [Leading With AI: What Helped Me Through the Hard Parts](https://www.dainemawer.com/leading-with-ai.md):
  Published 2025-10-05. How I used AI through the Monocle.com rebuild.
- [The Rise of No-Code and Low-Code in Frontend Development](https://www.dainemawer.com/no-code-low-code-frontend.md):
  Published 2025-01-15. Benefits, challenges, and the role of AI.
- [Using CSS Custom Properties with Fallbacks for Efficiency](https://www.dainemawer.com/css-custom-properties-fallbacks.md):
  Published 2024-05-06. Less boilerplate, fewer surprises.
- [What Is Google Baseline and Why Does It Matter?](https://www.dainemawer.com/what-is-google-baseline.md):
  Published 2024-04-28. Interoperability across browser vendors, explained.
- [How to Determine When a Sticky Element is Stuck in JavaScript](https://www.dainemawer.com/determine-when-a-sticky-element-is-stuck.md):
  Published 2024-03-14, updated 2026-02-09. A small JavaScript function for the pseudo-class CSS never gave us.
- [Mastering Task Estimation with the FATE Framework](https://www.dainemawer.com/mastering-task-estimation.md):
  Published 2024-03-12. Accurate timelines, and a happy client.
- [Enhance Your React App's Scalability with Storybook and Chromatic](https://www.dainemawer.com/react-scalability-storybook.md):
  Published 2024-02-05. Component libraries and visual regression testing.
- [Understanding Chrome's Coverage Panel](https://www.dainemawer.com/understanding-chromes-coverage-panel.md):
  Published 2023-11-27. Leveraging its insights to optimise performance.
- [Setting Up Next.js with a Component Library Using Monorepos](https://www.dainemawer.com/nextjs-component-library-monorepo.md):
  Published 2023-11-20. A component library, Storybook, and Next.js, all in one workspace.
- [10 Techniques for More Effective Code Reviews](https://www.dainemawer.com/effective-code-reviews.md):
  Published 2023-02-21. Practical ways to make code review less painful and more useful.
- [4 Tips for Properly Using the Return Statement in JavaScript](https://www.dainemawer.com/using-the-return-statement.md):
  Published 2023-02-13. A few rules that keep return statements from causing quiet bugs.
- [Enforcing Consistent Commit Messages with CommitLint](https://www.dainemawer.com/leveraging-commitlint.md):
  Published 2023-01-19. A style guide for commits, and a hook that actually enforces it.
- [5 Frontend File Architectures for Better Code Organization](https://www.dainemawer.com/frontend-file-architectures.md):
  Published 2023-01-18. Flat, hierarchical, modular, component-based, and feature-based, compared.
- [How to Motivate and Inspire Individual Contributors](https://www.dainemawer.com/motivate-individual-contributors.md):
  Published 2023-01-09. Five things that actually move the needle, beyond an annual review.

## Developer resources

- [llms.txt](https://www.dainemawer.com/llms.txt):
  Structured index of every article, topic and feed.
- [llms-full.txt](https://www.dainemawer.com/llms-full.txt):
  The index plus the full text of every article.
- [agents.md](https://www.dainemawer.com/agents.md):
  This page, as Markdown.
- [index.md](https://www.dainemawer.com/index.md):
  The homepage article index, as Markdown.
- [sitemap.xml](https://www.dainemawer.com/sitemap.xml):
  Every canonical URL, with last-modified dates.
- [rss.xml](https://www.dainemawer.com/rss.xml):
  RSS 2.0 feed of new articles.
- [feed.json](https://www.dainemawer.com/feed.json):
  JSON Feed 1.1 equivalent of the RSS feed.
- [robots.txt](https://www.dainemawer.com/robots.txt):
  Crawl rules, plus a Content-Signal header: search=yes, ai-input=yes, ai-train=no.

## Optional

- [Full archive](https://www.dainemawer.com/index.md):
  Reverse-chronological index of every article, as Markdown.
- [About](https://www.dainemawer.com/about.md):
  Work history, speaking, and how to verify who's writing this.

## Full article text

### Using CSS's New if() Function Without Breaking Safari and Firefox

CSS's if() function picks a property's value based on a media, feature, or style condition, replacing separate @media, @supports, and container style query blocks with one inline declaration. It shipped in Chrome 137, but Firefox and Safari don't support it yet, so ship it as a second declaration after a plain fallback, not a replacement for one.


CSS has had conditional logic for a while now: `@media` for viewport conditions, `@supports` for feature checks, `@container` for context based on an ancestor. Each one works, and each one asks you to write a separate block, usually with the same selector repeated, just to change one value.

`if()` collapses that pattern into a single declaration. It shipped in Chrome 137 in 2026, and it's worth understanding now, both because it changes how you'll write conditional CSS once it's everywhere, and because it's genuinely usable today if you know where the edges are.

## What if() actually does

The syntax is a list of condition-value pairs, separated by semicolons, evaluated in order, with an optional `else` at the end:

```css
.button {
  padding: if(media(width > 700px): 1rem 1.5rem; else: 0.75rem 1rem);
}
```

The first condition that evaluates to true wins. If nothing matches and there's no `else`, the property behaves as though it was never set, falling through to whatever the cascade would otherwise apply.

That's the whole model. What makes it useful is what counts as a condition.

## Three condition types, one function

`if()` accepts three kinds of tests, and you can mix them in the same declaration.

**`media()`** checks a media feature, the same conditions `@media` accepts, just written inline:

```css
.hero-title {
  font-size: if(media(width > 1024px): 3rem; else: 2rem);
}
```

**`supports()`** checks feature support, the same thing `@supports` does, but scoped to one value instead of a whole rule:

```css
.layout {
  display: if(supports(display: grid): grid; else: flex);
}
```

**`style()`** checks the computed value of a custom property, which is the part that used to require a container style query and a separate block:

```css
.card {
  padding: if(style(--density: compact): 0.75rem; else: 1.25rem);
}
```

Set `--density: compact` anywhere up the cascade, on the element itself, a parent, a data attribute selector, and every property using that `style()` check picks it up. No `@container` wrapper, no naming a containment context, no duplicated selector.

## What it actually replaces

What matters is the collapsing, not the syntax on its own. Here's the same responsive padding rule, before and after.

Before, with a duplicated selector:

```css
.button {
  padding: 0.75rem 1rem;
}

@media (width > 700px) {
  .button {
    padding: 1rem 1.5rem;
  }
}
```

After, as one declaration:

```css
.button {
  padding: if(media(width > 700px): 1rem 1.5rem; else: 0.75rem 1rem);
}
```

Same result, no repeated selector, and the condition sits next to the value it controls instead of in a separate block somewhere else in the file. That's a small readability win on one property. On a component with five or six conditional values across breakpoints, states, and containers, it stops being small. You stop hunting through `@media` and `@container` blocks trying to reconstruct what a single element actually renders at a given width.

## Browser support today

This is the part that matters before you touch it in production. As of September 2026, `if()` works in Chrome 137 and up, along with Edge and Opera, since all three share the Chromium engine. Firefox support is still in progress, and Safari has it listed on its roadmap for 2026-2027, not shipped. MDN currently marks `if()` as limited availability rather than Baseline, which means the usual rule applies: don't ship it as your only source of a value unless your audience is genuinely Chromium-only, an internal tool or an Electron app, for instance.

The [State of CSS 2026](https://2026.stateofcss.com/en-US) developer survey found `if()` among the least-used features respondents reported, and browser support gaps around `if()` and the related `@function` mixins proposal came up repeatedly as the reason. That tracks. A feature that only works in one engine family isn't something most teams reach for on customer-facing work yet, whatever the syntax looks like.

## Shipping it safely today

The good news is that CSS has handled this exact situation forever: a browser that doesn't recognize a value just discards that one declaration and moves on. You don't need a `@supports` wrapper around the whole rule to use `if()` safely. Write the plain value first, then the conditional version as a second declaration for the same property:

```css
.card {
  padding: 1.25rem;
  padding: if(style(--density: compact): 0.75rem; else: 1.25rem);
}
```

A browser without `if()` support parses the first line, fails to parse the second one because it doesn't recognize the function, and keeps the first value. A browser with support parses both and the second declaration, being later in the cascade, wins. No feature query needed, no branching stylesheet, just the same fallback-then-enhancement order you'd use for any newer CSS value.

If you do want to gate a larger block of styles on `if()` support specifically, rather than fall back one property at a time, `@supports` still works for that:

```css
@supports (padding: if(style(--density: compact): 1rem; else: 1rem)) {
  /* if()-dependent styles that need more than one property to make sense together */
}
```

Reach for that version when several related properties only make sense as a set. For a single value, the two-declaration pattern above is simpler and doesn't need a nested block at all.

## Where this is heading

`if()` is part of a bigger CSS Working Group effort to bring conditional logic and reusable logic natively into stylesheets, alongside the related mixins and custom functions proposal. None of it replaces a preprocessor's full feature set yet, but it closes a real gap: today, expressing "this value depends on that condition" usually means either a duplicated `@media` block or reaching for JavaScript to toggle a class. `if()` makes that a one-line answer, once the browsers you actually need to support catch up.

Until then, treat it the way you'd treat any Chromium-first feature: real value on Chromium-only surfaces now, a fallback-first pattern everywhere your audience includes Safari or Firefox users, which for most public sites is still most of your traffic.

## Further reading

- [MDN: if() CSS function](https://developer.mozilla.org/en-US/docs/Web/CSS/if)
- [Chrome for Developers: CSS conditionals with the new if() function](https://developer.chrome.com/blog/if-article)
- [Can I Use: CSS if() function](https://caniuse.com/css-if)
- [State of CSS 2026](https://2026.stateofcss.com/en-US)


### CSS Can Finally Replace Your Tooltip and Dropdown Libraries

CSS anchor positioning (Chrome 125+, Safari 26+, Firefox 145 behind a flag) and appearance base-select (Chrome 135+, Safari 27+) now let native CSS handle floating tooltips and styled dropdowns without a JS library. Both degrade gracefully behind @supports, so you can adopt them now for new components and drop the library once support catches up.


For years, two of the most common UI patterns on the web, a tooltip that stays attached to its trigger and a select dropdown you can actually style, have both needed a JavaScript library to do properly. Popper.js, Floating UI, and Tippy.js exist because CSS had no concept of "position this relative to that other element, and flip sides if it would overflow." Custom select components like react-select exist because the native `<select>` popup has always been a black box no stylesheet can touch.

Both gaps are closing. CSS anchor positioning and `appearance: base-select` now ship in real browsers, not experimental flags in one engine. Neither has full three-way parity yet, but both are far enough along to change what you reach for on the next component you build.

## Anchor positioning: tethering without a library

CSS anchor positioning lets you tie one element's position to another using three pieces: `anchor-name` on the element being anchored to, `position-anchor` on the element being positioned, and the `anchor()` function inside its `top`/`left`/`right`/`bottom` values.

```css
.trigger {
  anchor-name: --tooltip-trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --tooltip-trigger;
  top: anchor(bottom);
  left: anchor(left);
}
```

That's the whole job Popper.js was built to do: compute a floating element's position relative to a reference element, expressed as three CSS declarations instead of a runtime library recalculating on every scroll and resize event. `@position-try` goes further, letting you define fallback positions the browser switches to automatically when the default would overflow the viewport, the flipping behavior that made Floating UI's `autoUpdate` necessary in the first place.

The browser support picture, per [Chrome for Developers](https://developer.chrome.com/blog/anchor-positioning-api) and [OddBird's ongoing anchor positioning coverage](https://www.oddbird.net/2025/10/13/anchor-position-area-update/), looks like this: Chrome shipped it in version 125 and it reached Baseline Newly Available in January 2025. Safari added support in version 26. Firefox shipped an implementation behind a flag in version 145, which means it isn't Baseline Newly Available across all three engines yet, only in the two that ship it unflagged.

That's close enough to use, not close enough to rip out a mature tooltip library across an entire app in one pass. The realistic move: reach for anchor positioning on new floating UI, wrapped in an `@supports` check, and keep the JS library only where you already depend on it for edge cases anchor positioning doesn't cover yet, like elements inside a virtualized list or a deeply nested scroll container.

```css
.tooltip {
  display: none;
}

@supports (anchor-name: --x) {
  .tooltip {
    display: block;
    position: absolute;
    position-anchor: --tooltip-trigger;
    top: anchor(bottom);
    left: anchor(left);
  }
}
```

Anchor positioning is also one of the named focus areas in [Interop 2025](https://web.dev/blog/whats-new-in-web-io2025), the annual cross-browser effort Chrome, Firefox, and Safari's engineering teams use to close exactly these kinds of gaps. That's a reasonable signal that the remaining Firefox flag is a matter of time, not a stalled proposal.

## Customizable selects: styling what used to be a black box

The second gap is the `<select>` element. Its trigger has always taken CSS fine. Its popup, the actual list of options, has never been reachable by a stylesheet, which is why teams have spent a decade reaching for `react-select`, `downshift`, or a hand-rolled combobox any time a design called for anything beyond the browser default.

`appearance: base-select` changes that:

```css
select,
::picker(select) {
  appearance: base-select;
}

::picker(select) {
  border-radius: 8px;
  box-shadow: 0 8px 24px rgb(0 0 0 / 0.15);
}

select option:checked::before {
  content: '✓';
}
```

Setting `appearance: base-select` on both the `<select>` and its `::picker(select)` pseudo-element opts the control into a fully stylable mode. The element is still a real `<select>`, which matters more than it sounds: keyboard navigation, type-ahead, focus management, and the accessibility tree all keep working the way a native form control's are expected to, none of it needs reimplementing the way it does in a from-scratch listbox component.

Per [Chrome for Developers' announcement post](https://developer.chrome.com/blog/a-customizable-select) and its [follow-up findings from developer feedback](https://developer.chrome.com/blog/rfc-customizable-select-findings), the feature is available starting in Chrome 135 and Safari 27. Firefox doesn't support it yet, but it fails safe: an unsupported browser just ignores the `appearance` value and renders the ordinary native select, unstyled but fully functional. That makes it one of the lowest-risk progressive enhancements available right now, closer in spirit to a CSS fallback than a feature you need a JS shim to polyfill.

What matters more than the styling freedom is what you don't have to rebuild. A hand-rolled combobox has to reimplement arrow-key navigation, type-ahead-to-jump, `aria-activedescendant` wiring, and the focus behavior a screen reader expects from a listbox, and it's easy to get subtly wrong in ways that don't show up until an accessibility audit. A `<select>` styled with `base-select` is still the same element under the hood, so none of that behavior needs rebuilding or re-testing. You're styling a native control, not a `<div>` dressed up to look like one.

## How to actually adopt these

The mistake to avoid is waiting for full three-engine support before touching either feature, or the opposite mistake of ripping out a working library across an entire codebase before the gaps close. Neither serves a team well.

Gate both behind `@supports`. `@supports (anchor-name: --x)` and `@supports (appearance: base-select)` ship the CSS-native version to browsers that support it and fall back cleanly everywhere else, with no user-agent sniffing required. Start with new components rather than retrofits: a new tooltip or a new filter dropdown is a much safer place to try anchor positioning or base-select than reworking an existing, load-bearing component library in one migration.

Keep the JS library where it's actually earning its place. Complex collision detection, virtualized-list anchoring, and multi-select comboboxes with custom filtering logic are still legitimately harder in pure CSS today, so don't delete a dependency you still need just because a newer primitive exists. And track the Firefox gap rather than the calendar. Firefox 145 shipping anchor positioning behind a flag is the signal to watch, not a fixed date. Once it ships unflagged and base-select lands in Firefox too, the remaining case for the JS dependency in most apps disappears.

Neither feature is a wholesale replacement yet. Both are further along than most teams have noticed, and the components built today are exactly the ones that'll benefit from being written the native way from the start, instead of migrated off a library later.


### Why AI Coding Agents Need WIP Limits Too

Running several AI coding agents in parallel fails the same way understaffing does, too much work in flight for the verification capacity behind it. Cap agents per engineer to what they can actually review, write a checkable definition of done before any agent starts, and set an autonomy budget matching task risk before kickoff.


Most engineering teams still plan agent work the way they planned a single assistant helping one person type faster. That model broke sometime in the last year. The actual unit of work now is one engineer directing several agents at once, each on a different task, each generating output faster than any one person can read it.

Nobody built a process for that. Most teams just kept adding agents until something gave, and the thing that usually gives is review. [LinearB's 2026 analysis of more than 8.1 million pull requests across 4,800-plus organizations](https://linearb.io/blog/8-million-prs-engineering-productivity) found that AI-authored pull requests wait 4.6 times longer for a reviewer to even start looking at them, despite being reviewed about twice as fast once someone does. The queue is the bottleneck, not the reading speed. That's exactly what happens when the number of agents in flight outruns the number of people who can actually check their work.

This isn't a review-technique problem. It's a staffing problem, and it needs the same tool every staffing problem needs: a limit on how much can be in progress before you start the next thing.

## Name the actual constraint

The instinct is to think of agent capacity as a compute problem, run as many as the machine and the API budget allow. That's the wrong constraint to optimize. The real ceiling is how much output one engineer can verify closely enough to trust, and that number doesn't move just because you added a fourth agent.

Verification capacity is roughly fixed per person, per day. Adding agents past that point doesn't produce more finished, trustworthy work. It produces a longer queue of unreviewed diffs sitting exactly where the LinearB data says they sit, waiting for a reviewer who's already behind.

## Set a WIP limit per engineer, not per team

Kanban solved this same problem for tickets decades ago: cap how many things can be in progress at once, and don't start the next one until something finishes. The same cap works for agent tasks, applied per engineer rather than per team, because verification capacity is an individual constraint, not a shared pool.

A workable starting point is capping concurrent agent tasks at whatever one engineer can review the same day, not the same week. If a task's diff is still sitting unread after a full day, that's a signal to lower the cap, not a signal to add another agent to keep busy while the queue grows. The number will differ by task complexity and by engineer, and it should move based on what the review backlog actually shows, not on a fixed number picked once and never revisited.

## Write the definition of done before kickoff

A vague prompt is the single fastest way to produce a diff nobody can verify quickly. "Add validation to the signup form" leaves an agent free to touch six files across three features, and now the reviewer has to reconstruct the actual requirement from the output before they can even start checking it.

The fix happens before the agent starts, not after. Write down what "done" checkably means for this task: which files should be in scope, which behavior has to hold, what the acceptance test looks like. This is closer to writing a ticket a new hire could execute without asking a follow-up question than it is to writing a prompt. The upfront cost is real, but it's smaller than the cost of a reviewer reverse-engineering scope from a finished diff, and it's the same cost teams already pay for well-scoped human tickets. Agents just make the corner-cutting version of skipping it visible faster.

## Give every task an autonomy budget

Not every task deserves the same leash. A scoped bug fix in a file the agent already touched an hour ago can run for a few minutes before a check-in. A new feature with real architectural surface area needs a shorter leash, not a longer one, because the cost of an hour spent diverging on the wrong approach is much higher than the cost of an hour spent on a contained fix that's easy to throw away.

Decide the autonomy budget when the task starts, not while it's running. Minutes for a narrow, low-risk change. A scheduled check-in partway through for anything with real design surface. A hard stop and human review before anything touches auth, billing, or a data migration, regardless of how long it's been running or how confident the output looks. Deciding this upfront removes the worst version of the decision, made mid-run, by someone who's already read enough of the output to feel invested in seeing where it goes.

## Decide kill criteria before you're invested

The hardest moment in any agent-heavy workflow is the one where a task has clearly gone sideways, but stopping it means throwing away work that already exists and looks almost right. That's a sunk-cost trap, and it's worse with agents than with people, because agent output arrives fast enough that a lot of a work day can disappear into a task nobody decided to kill in time.

The fix is the same one good incident response uses: decide the criteria before the situation, not during it. What does "clearly off track" look like for this specific task, a wrong file touched, a pattern that doesn't match the rest of the codebase, a test the agent quietly rewrote instead of fixing the code to pass it. Write that down at kickoff, next to the definition of done, so the decision to stop is a checklist item instead of a judgment call made under the pull of work that's already 80% written.

## Track verification hours, not agents launched

Throughput metrics get worse, not better, once agents are in the picture, because agents launched and PRs merged both go up regardless of whether anyone actually verified what shipped. Neither number tells you whether the team is keeping up or quietly falling behind on the part of the job that actually determines whether the output is safe to trust.

Track verification hours per engineer instead, and watch it against the number of agent tasks in flight. If verification hours are climbing while WIP stays flat, that's a sign the work is getting harder to check, not that the team needs to slow down agents across the board. If WIP is climbing faster than verification hours can plausibly keep pace with, that's the queue LinearB's data describes, forming in real time, on your own team, before it shows up as a missed deadline or a bug that made it past review because nobody had time to look closely.

## The actual shift

None of this is really about agents. It's the same capacity planning discipline that's always applied to a team doing more work than its review process can absorb, just applied to a resource that produces output faster than any previous version of the problem did. Agents didn't create the need for WIP limits, checkable scope, and honest capacity tracking. They just made it obvious how much teams had been getting away with skipping those, back when the work in flight moved slowly enough to hide it.


### Migrating to TypeScript 7 Without Breaking Your Toolchain

TypeScript 7's native Go compiler is 8-12x faster on real codebases, but it ships without the stable programmatic API that custom transformers, ts-node, typescript-eslint, and ts-morph depend on. That API lands in TypeScript 7.1. Until then, alias TypeScript 6 for anything using compiler internals, and migrate `tsc` itself separately from the rest of your tooling.


TypeScript 7 shipped in July 2026 as a full rewrite of the compiler and language service in Go, and the number everyone's repeating is real: [Microsoft's own benchmarks](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) show full builds running 8 to 12 times faster. On the VS Code codebase, a full build went from 125.7 seconds to 10.6 seconds, an 11.9x improvement, with aggregate memory use down around 18%. Opening a file with a type error, previously a 17.5-second wait in a large project, now takes under 1.3 seconds.

None of that is marketing exaggeration. It's also not the part of this migration that determines whether it goes smoothly.

## The number that matters less than you think

A compiler rewrite in a systems language is, by now, a familiar shape. Turbopack replaced parts of webpack in Rust. Meta's React Compiler moved from JavaScript to Rust for the same reason. Every one of these ships with a benchmark slide and a smaller, quieter note further down the page about what didn't come along for the ride.

For TypeScript 7, that note is the programmatic API. The Go-native `tsc` type-checks and compiles your code just fine. What it doesn't do, at least not yet, is expose the compiler internals that a chunk of the JavaScript ecosystem was built on top of without much fanfare. Custom AST transformers, editor plugins, and anything that imports `typescript` and reaches into its guts for diagnostics, source maps, or program information, isn't guaranteed to work against the native port. Microsoft has said a stable version of that API is coming in TypeScript 7.1, not 7.0.

That's not a footnote. It's the actual scope of the migration.

## Who this quietly breaks

The compiler API was never a headline feature, which is exactly why so much depends on it without anyone noticing until it's gone. A few concrete examples:

- `ts-node` and similar tools compile TypeScript on the fly by calling into the compiler API directly. Their compatibility with the 7.0 native port varies by tool and version.
- `typescript-eslint` uses TypeScript's own type information to power type-aware lint rules, which means it needs the API surface, not just a working `tsc`.
- `ts-morph` and other codemod tooling are built entirely around programmatic access to the AST. There's no faster-compiler story for them until 7.1 lands.
- Any in-house script your team wrote three years ago that imports `typescript` to check types programmatically, generate types from a schema, or build a custom lint rule falls into the same bucket. It's the one nobody remembers exists until CI breaks.

The pattern across all of these: none of them are edge cases. They're ordinary parts of a mature TypeScript setup, which is exactly why the migration risk is bigger than "upgrade a devDependency and watch it get faster."

## A migration that doesn't gamble on CI

The fix teams have converged on doesn't wait for 7.1. It splits the upgrade into two separate tracks and lets them move at different speeds:

First, upgrade `tsc` itself wherever nothing else depends on importing it programmatically. That's most local development, most editor type-checking, and any CI step that just runs `tsc --noEmit` and reads the exit code. This is where the 8-12x number pays out immediately with close to zero risk.

Second, alias `typescript` to a TypeScript 6 compatibility package for anything that touches the compiler API. The pattern several teams are documenting looks like this in `package.json`:

```json
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
```

That keeps `typescript` resolving to the 6.0 API for anything that needs it, `ts-node`, `typescript-eslint`, custom transformers, while the native binary runs your actual type-checking pass under a separate name. It's not elegant, but it's a real bridge, not a workaround built on hope.

Third, audit before you assume. Grep the codebase for `import * as ts from 'typescript'` and anything similar before deciding the migration is "just a version bump." That search takes ten minutes and tells you how big this migration actually is for your specific repo, which is a very different number for a team running a lint config off the shelf than for one with five years of internal tooling built on compiler internals.

Frameworks are moving at different speeds here too. Check whether your specific stack, Next.js, a monorepo tool, your test runner, has published its own TypeScript 7 compatibility notes before assuming the ecosystem caught up uniformly. Some have; several hadn't as of the 7.0 release.

## The lesson that outlasts this specific migration

The interesting part of this isn't TypeScript. It's what a staff engineer should take from watching this pattern repeat: Turbopack, React Compiler, now this. Every toolchain rewrite in a faster language ships with a real benchmark and a real compatibility gap, and the gap is never in the part of the tool everyone thinks about. It's in the part that became load-bearing infrastructure without ever being designed as a public contract.

The actual skill here isn't reading the changelog. It's the habit of asking, before adopting any faster rewrite of a tool your team depends on: what's built on top of this that was never meant to be an integration point? A linter plugin, a codemod script, a build step someone wrote in 2022 and nobody's touched since. Answering that before the migration, not during a broken CI run, is the difference between an easy 10x speedup and an afternoon spent figuring out why `ts-node` stopped working three sprints after everyone forgot the upgrade happened.

## Bringing it together

TypeScript 7's speedup is real and worth having. The migration risk isn't in the compiler, it's in everything wired to its internals without anyone tracking it: `ts-node`, custom transformers, `typescript-eslint`, `ts-morph`, and whatever in-house script imports `typescript` directly. Split the upgrade into two tracks, fast `tsc` now, an aliased TypeScript 6 for anything touching the compiler API, and audit your own codebase for that dependency before you find out about it in CI. The stable programmatic API lands in 7.1. Until then, treat this as two migrations wearing one version number.


### How to Orchestrate Multiple AI Coding Agents Without Losing Architectural Control

Running several AI agents in parallel breaks the single-PR review habit built for one agent at a time. The fix is treating orchestration as its own skill, decompose the problem before delegating, give each agent an owned slice of the codebase, define one integration checkpoint, and track coordination overhead so directing agents doesn't cost more than doing the work.


Six months ago, the interesting problem was reviewing a pull request one agent wrote. That's still worth doing well. But teams running more than one agent at a time have already moved past it, into a harder problem: directing three or four agents working in parallel on pieces of the same feature, without the whole thing turning into a merge-conflict factory nobody signed up for.

That's orchestration, and it's a different skill than review. Review asks whether a finished diff is any good. Orchestration asks how the work got split in the first place, who owns what while it's still in progress, and where a human actually needs to look before the pieces get stitched back together.

Anthropic's own [2026 Agentic Coding Trends Report](https://resources.anthropic.com/2026-agentic-coding-trends-report) names this exact problem the delegation gap: developers now run AI through roughly 60% of their work, but can fully delegate only 0 to 20% of tasks without close supervision. Running more agents in parallel doesn't close that gap. It just spreads the remaining 40 to 100% of judgment across more places at once, and if nobody's tracking where those places are, the judgment quietly stops happening.

## Decompose the problem yourself

The instinct is to hand an agent an ambiguous feature request and ask it to split the work across two or three sub-agents. That produces splits that look reasonable and aren't. An agent divides work along file boundaries or naming similarity, not along the seams your architecture actually has, because it has no view of the seams that matter until you give it one.

Do the decomposition first, as a human, the same way you'd break work into tickets for a team of engineers. Ask which module boundaries already exist, which pieces can be built and tested independently, and which piece is genuinely shared state that shouldn't be split at all. If you can't describe the boundary between two agents' work in a single sentence, they don't have a real boundary yet. They have a raffle for which one edits a given file first.

## Give each agent a slice it actually owns

Two agents touching the same file at the same time produce the same conflict two engineers would, except neither one can look up from its editor and ask whether the other is also in `orderService.ts` right now. The conflict just shows up later, fully formed, once both have already finished.

Assign each agent a set of files or a directory it can work in without another agent's changes landing on top of it mid-task. Shared interfaces, a type definition, a utility function, an API contract, get decided and frozen before any agent starts, not discovered as a merge conflict after two agents have already built against different assumptions about the same shape.

## One integration checkpoint, not four green checkmarks

Four agents whose output each passes its own tests doesn't mean the feature works. It means four isolated pieces pass isolated tests. Whether they compose into the thing you actually asked for is a separate question, and it's not one CI answers for you.

Define a single point where a human reviews the assembled result before it ships, rather than four separate approvals for four separate diffs. That checkpoint is where the actual risk lives: does the data shape one agent produced match what another agent consumed, does error handling agree across the pieces, does the whole thing behave like one coherent feature instead of four agents' best individual guesses at one.

## Track coordination overhead like a budget

Orchestrating agents costs real time: writing clear boundaries, checking in on progress, resolving the disagreement that shows up when two agents made different assumptions about a shared piece. That cost is easy to undercount, because none of it looks like writing code, so it doesn't show up on the burndown chart the way "in progress" does.

If directing three agents through a feature takes longer, wall-clock, than one agent working through the same feature single-threaded would have, the parallelism isn't paying for itself yet. Track hours spent coordinating the same way you'd track review time creeping past what it used to cost. A number that keeps climbing is a process problem worth fixing, not a reason to add a fourth agent to the mix.

## Know when to collapse back to one agent

Not every task benefits from splitting across agents. A tightly coupled change to a single service, a bug fix that touches one function, anything where the shared-state problem above can't actually be avoided, these are all cheaper single-threaded, and pretending otherwise just manufactures coordination work that wasn't necessary.

A few signs it's time to collapse back to one: coordination overhead exceeding the time the split was supposed to save, agents repeatedly stepping on the same files despite an assigned boundary, or a review that spends more effort reconciling three different approaches than reviewing one coherent diff would have taken in the first place.

## The skill that actually scales

Running more agents at once isn't the skill. Deciding, correctly and early, whether a piece of work is genuinely parallelizable, and holding the architectural line while agents fill in what you've already decided, is. That's project management applied to a team that never gets tired and never pushes back on an unrealistic split, which means all of the judgment about scope, boundaries, and correctness stays exactly where it has to: with the person doing the orchestrating, not the agents being orchestrated.


### Keeping the Junior Engineering Pipeline Alive in the AI Era

AI has cut entry-level hiring by automating the boilerplate juniors used to learn on, and Stanford research shows a real employment gap for AI-exposed workers aged 22-25. Keeping the pipeline alive means redefining junior work around auditing AI output, protecting AI-free practice time, and measuring learning velocity instead of ticket count.


Every engineering leader wants a senior engineer right now. Almost none of them are budgeting for the junior who becomes one.

That's not a new complaint, but it's a newly urgent one. Stanford's Digital Economy Lab has been tracking employment for workers aged 22 to 25 in the occupations most exposed to generative AI, and as of its most recent update, [that group sits about 19% below where employment would be](https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/) if it had kept pace with older, less-exposed workers. Experienced workers in the same fields show no comparable gap. The researchers are careful to note this isn't a wave of layoffs. It's a collapse in hiring: the openings that used to exist for people just starting out simply aren't appearing.

For engineering teams specifically, that tracks with something a lot of managers already feel but haven't named. The tasks a junior engineer used to cut their teeth on, a CRUD endpoint, a first-draft component, a straightforward bug fix, are exactly the tasks an agent now does fastest and most cheaply. The old training path wasn't "give juniors the easy work while they learn." It was "the easy work is how they learn." Automate the easy work away and you haven't shortened that path. You've removed it.

None of this means the answer is to keep hiring juniors into a role that no longer exists and hoping the old apprenticeship pattern holds. It means the role has to be redesigned around what's actually left to learn.

## Name what actually got automated

Before redesigning anything, it's worth being specific about what disappeared, because "AI took the junior work" undersells how much of that work was also how judgment got built.

Writing a first-draft implementation taught a junior what the codebase's conventions actually were, not just what the style guide said. Debugging a boilerplate CRUD endpoint that quietly failed on an edge case taught them to read a stack trace and actually think about state. None of that was really about the task. It was about the friction the task created, and friction is what built instinct.

An agent removes the friction along with the task. That's the part worth being honest about before reaching for a fix: the loss isn't just fewer tickets for juniors to pick up, it's fewer chances to get stuck and work their way out of it.

## Redefine junior work around judgment, not output

The fix isn't protecting juniors from AI. It's changing what they're accountable for once AI is doing the typing.

A 2026 junior engineer's actual job increasingly looks like this:

- **Auditing AI-generated code for bugs**, rather than writing the first draft themselves. This is a genuinely different skill from writing code, closer to what a reviewer does, and it's one juniors need regardless of who or what wrote the code they'll eventually inherit.
- **Evaluating two or three competing AI-generated implementations** of the same feature and explaining which one they'd ship and why. This forces an opinion about tradeoffs earlier than the old path did, where a junior usually just wrote one version and waited for a senior's review to learn what was wrong with it.
- **Understanding a system before prompting an agent to change it**, rather than prompting first and hoping the result fits. A junior who can describe what a service actually does and why, before asking an agent to touch it, is building the same mental model a senior needs. One who can't is just generating plausible-looking diffs faster.

None of these require slowing an agent down. They require holding juniors accountable for the reasoning an agent doesn't produce on its own, which is exactly the reasoning a senior engineer is paid for later.

## Protect real no-AI practice time

Judgment about AI output still needs a baseline to judge against, and that baseline doesn't build itself by osmosis.

Set aside deliberate stretches, a kata, a small internal tool, a bug in an old low-stakes part of the codebase, where a junior works without an assistant. Not because AI is untrustworthy, but because the struggle of getting stuck and working through it is where the underlying instinct actually forms. Skipping that struggle doesn't remove the need for the instinct it builds. It just defers the moment someone discovers it's missing, usually during an incident, at a worse time than a scheduled practice session.

This doesn't need to be a large share of a junior's week. It needs to be protected and non-negotiable, the same way teams protect on-call rotations or testing time, because it's the first thing that quietly disappears under deadline pressure otherwise.

## Pair juniors with seniors on reviewing agent output, not just their own

The traditional mentorship model has a senior reviewing a junior's pull request. That still matters, but it's no longer where most of the judgment transfer happens, because a growing share of what ships was drafted by an agent, not the junior.

The higher-leverage version is a senior and a junior reviewing agent-generated output together, out loud, on real work. Not a training exercise, an actual PR the team needs reviewed anyway. The senior narrates what they're checking for and why: does this fit the architecture, does the happy path actually cover the edge case the ticket cared about, would this pattern cause problems eighteen months from now. That narration is the part a junior can't get from working alongside an agent alone, because an agent has no opinion about your codebase's conventions and won't tell a junior when it's improvising near one.

This costs a senior's time up front. It's also very close to what staff engineers are already being asked to spend more time doing as [agents shift their own value from writing code to validating it](/reviewing-ai-generated-code). Structuring that review as a paired, narrated exercise rather than a solo pass turns an existing cost into a training opportunity instead of pure overhead.

## Measure learning velocity, not throughput

Ticket count and PR volume were always imperfect proxies for how much a junior was actually learning, and AI makes them worse, because both numbers go up regardless of whether a junior understood what shipped or just approved what an agent proposed.

Track something closer to the thing that actually matters: can this junior explain, unprompted, why a piece of code they touched last month works the way it does. Can they anticipate what an agent's next suggestion is likely to miss, based on a pattern they've seen before. Are they catching more in review than they were last quarter, not just producing more.

None of that fits neatly into a burndown chart, which is exactly why it gets skipped in favor of metrics that do. It's worth tracking anyway, because it's the actual signal for whether the redesigned junior role is working or just looks busy.

## The counter-signal worth watching

Not every organization is cutting junior hiring. Some, IBM among the more visible examples, went the other direction in 2026 and increased junior intake while restructuring around AI rather than in spite of it. That's not proof the pipeline problem is overstated. It's a signal that the collapse in junior hiring is a choice some organizations are making under pressure, not an inevitable consequence of the technology itself.

Whether that choice pays off in five years is exactly the question worth sitting with. A staff engineer or engineering manager senior enough to read this piece almost certainly came up through the old path, real problems, real friction, a senior watching over their shoulder often enough to catch the near-misses. If that path is genuinely gone for the cohort starting now, the honest question isn't whether AI can do junior-level work. It's who's going to have the judgment to do senior-level work a decade from now, and whether anyone is deliberately building it.


### How to Review AI-Generated Code Without Becoming a Bottleneck

Reviewing AI-generated code means checking whether it should exist, not just how it was built. Read the diff for its plan before going line by line, run the feature instead of trusting a green CI check, and hold agent-authored code to the same architectural bar as anything else. Never let clean-looking code earn a faster review.


Something changed in the last year of code review, and it's not the volume. It's what a bad pull request looks like now.

A human engineer under time pressure writes code that looks rushed. Inconsistent naming, a missing edge case, a comment that says `// TODO: fix this properly later`. You can smell it in the diff before you've read a single line. An AI agent under no pressure at all writes code that looks finished. Consistent style, sensible variable names, a clean commit message, tests that pass. It can just as easily be solving the wrong problem, and nothing about how it reads will tell you that.

That's the actual shift for staff engineers right now. Review used to be about how something was built. Increasingly, it needs to be about whether it should exist at all.

This isn't a niche problem. Adoption of agentic coding tools roughly doubled in the first half of 2026, with [JetBrains reporting](https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/) around 39% of professional developers using tools like Claude Code at work by mid-year, up from 18% in January. That's a lot of pull requests where the author isn't a person, arriving faster than most teams' review habits were built to handle.

## Read the diff for a plan, not a translation

The instinct with a large diff is to go top to bottom, checking each line. That works when the code was written slowly by someone who might have gotten tired halfway through. It works less well against an agent that generated the whole thing in one coherent pass, because line-by-line reading misses the thing most worth catching: a confident, well-structured solution to a requirement the agent misunderstood.

Before reading a single line, ask what problem this diff claims to solve, and whether the shape of the change matches that problem. A ticket asking for "add validation to the signup form" that comes back touching six files across three unrelated features is a signal worth chasing before you look at indentation. So is a one-file diff for something you expected to touch shared state.

Once the plan makes sense, then go line by line, but weight your attention. A helper function with a descriptive name and a single return statement needs a glance. Anything touching auth, payments, or a database migration needs the scrutiny you'd give it regardless of who wrote it.

## Run it before you trust it

Passing CI proves the code satisfies the tests that already existed. It says nothing about whether those tests covered the right behavior, and agents are decent at writing code that makes existing tests pass without necessarily writing new tests for the parts that matter.

This is the step that's easiest to skip when a PR looks polished, and the one most worth keeping. Pull the branch, run the feature, hit the edge case the ticket actually cared about. A signup flow that handles the happy path but silently drops a validation error on a duplicate email will pass a test suite that never checked for a duplicate email. It won't survive someone actually trying to sign up twice.

## Hold the same architectural bar, on purpose

An agent has no opinion about your codebase's conventions unless you gave it one, and it will happily introduce a new pattern next to three existing ones that already solve the same problem. A new API client wrapper when there's already a shared one. A bespoke date formatter when the codebase has a utility for it. None of this shows up as a bug. It shows up eighteen months later as the reason nobody can explain why there are four ways to fetch data in the same app.

The fix isn't reviewing agent output more suspiciously than human output. It's reviewing it exactly as carefully, without the unconscious discount that comes from code looking tidy. Treat a clean-looking diff from an agent the way you'd treat a clean-looking diff from a new hire who hasn't seen the rest of the codebase yet: probably fine, worth a specific check for whether it reinvented something that already exists.

## Watch where the time actually goes

The promise of agentic coding is that engineers spend less time writing and more time on judgment calls. That only holds if review doesn't eat up the hours writing used to take, without anyone noticing it happened. If a feature that took a day to write now takes ten minutes to generate but ninety minutes to review properly, the team hasn't gotten faster. It's moved the bottleneck and made it less visible, because "review" doesn't show up on a burndown chart the way "in progress" does.

Track review time per pull request the same way you'd track anything else you're trying to protect. If it's climbing while merge counts go up, that's not a sign to review less carefully. It's a sign the team is generating output faster than it can verify it, which is a staffing and process problem, not a code quality one.

## The actual skill that scales

Prompting well is a skill, and it's useful. But it's not the skill that determines whether a team's agent-heavy workflow holds up under scrutiny six months from now. That skill is judgment: reading a diff and knowing whether it fits, running a feature and knowing whether it actually works, and asking whether a clean-looking solution solved the right problem in the first place.

That judgment doesn't get automated by better prompts. It's the same senior-engineer instinct review has always needed, applied to a category of author that's gotten very good at looking like it doesn't need it.


### Leading With AI: What Helped Me Through the Hard Parts

AI acted as a sounding board through the Monocle.com rebuild in five concrete ways. Validating technical decisions before looping in the team, scaffolding MVPs fast without burning out, speeding up hard-to-diagnose bugs, helping with unfamiliar backend work, and calming down messages written under pressure.


_Real moments and hard-won lessons from leading the Monocle.com rebuild._

The new [Monocle.com](https://monocle.com) site launched recently, the result of a long stretch of highs, lows, frustrations, and wins across every discipline. It stands out as one of the most challenging projects I've worked on at [10up](https://10up.com), not just for its technical complexity, but for how the team worked together. The process, the resourcing, and the sudden surge of conversation around AI all made it a genuinely unusual experience.

I've always been fairly pro-AI. I don't see it as a threat to my role. I see it as a tireless teammate that helps me work smarter, move faster, and do better work. In this post I want to share how I actually used AI throughout the Monocle project, not just in engineering, but in the parts of the job that go beyond code.

Here are five ways AI genuinely helped, with real examples, since I'd rather show that it works than just claim it.

## Gut-checking technical decisions

One of the hardest parts of leading a team is making decisions under ambiguity, quickly. I used AI as a sounding board to test my thinking when navigating an unfamiliar pattern, an edge case, or a genuinely murky technical call. It gave me something like a second brain to bounce ideas off, which cut down on decision fatigue and let me move forward with more confidence.

The real value wasn't landing on the right answer. It was not having to interrupt someone else just to get a gut check. We've all had the moment where you want to ask a web engineer "does this make sense?" and hold back, not wanting to slow them down or add pressure. AI closed that gap. By the time I brought a question to a teammate, I'd usually already sharpened my thinking enough to have a better conversation.

**Experience:**

During the Monocle build, we integrated a fairly new headless ecommerce platform called Swell. It needed to talk to Piano for user authentication, and on the frontend we were layering in Alpine.js for reactivity. I had a solid grasp of Alpine's model, but the orchestration between Swell and Piano wasn't immediately obvious.

Before jumping on a call or writing up a pile of questions, I used AI to get more context on both systems: their stacks, how their APIs worked, the general approach each team seemed to favor. Then I asked it to generate a minimal, working example of how the two platforms could integrate. That was enough context to mentally map the interaction and move forward with confidence.

## Rapid MVPs without burnout

On a high-pressure project like Monocle, there's rarely time to spare, especially when a new feature exists just to help drive a decision or unblock another team.

Rather than burn hours on something that might get thrown out after one stakeholder review, I started using AI to scaffold MVPs. I'd describe what I needed, a saved-views panel, a reactive dropdown filter, a basic TypeScript schema, and get back a clean starting point I could tweak and wire up quickly.

That wasn't about cutting corners. It let me save my energy for the parts that actually needed deeper thinking or polish, without losing momentum on the rest.

**Experience:**

The team requested a custom ad unit inspired by Wimbledon's Rolex sponsorship, specifically a live ticking clock face synced to the user's local timezone. Looking at the Rolex example, I realized how much was actually involved: real-time sync, timezone logic, animation performance, accessibility, and more.

With AI, I broke the feature down quickly, explored a few animation strategies, and had a working MVP. It helped us estimate more accurately and kept pressure off me, while still delivering something that mattered.

## Faster debugging with AI

Everyone's had that bug: subtle and completely undocumented, the kind where you open ten tabs hoping one 2013 StackOverflow post has the answer.

AI changed how I debug. I could describe the issue, paste a snippet, and get back pointed analysis, sometimes an edge case I'd missed entirely. It saved time, but more importantly it helped me understand _why_ something was breaking faster, and that's the part that actually counts.

**Experience:**

Monocle needed a horizontally scrollable component, a pattern I've come to dread on the web. Unlike mobile, the browser ecosystem is full of quirks that break even a clean, careful slider implementation.

I built a CSS-only version with some JS layered in for accessibility. It worked well until Safari started misbehaving. Instead of falling down a rabbit hole, I asked AI to help diagnose it. Within minutes it pointed me at a known 100vw rendering issue in Safari. That single call saved hours of trial and error.

## Stepping into backend territory

Frontend engineers usually turn data into UI. On Monocle, that line blurred. With backend engineers stretched thin, I stepped in more than once: writing PHP, digging into unfamiliar parts of the theme, trying to help without slowing anyone down.

AI acted as a guide here, helping me understand Fueled's backend conventions, structure logic properly, and write code that wouldn't need heavy rework later.

**Experience:**

For a few weeks I stepped up, not as a backend engineer, but as a frontend engineer willing to help where needed. I've worked with PHP and WordPress APIs for years, but Fueled's standards keep evolving, and every project gets a bit more abstracted and refined than the last.

I wanted to contribute something real, so I asked AI to walk me through Fueled's conventions and help with a small feature I was building alongside Konstantinos. I was nervous about that PR. It passed without a hitch. Small win, but a real reminder that with the right support, it's possible to stretch into unfamiliar territory and still ship solid work.

## Clearer communication under pressure

Leading a long, demanding project carries real emotional weight, and that stress has a way of creeping into how you show up in Slack, code review, or a project update. I didn't want that, for myself or the team.

So I started running my messages through AI before sending them. I'd write them raw, then ask for help making them calmer, clearer, and less reactive. Not fake, just clearer. It turned into a small but genuinely useful habit.

**Experience:**

This might be a slightly uncomfortable thing to admit, but relationships are complicated and communication is hard, especially when the team's tired and a client keeps moving the goalposts.

I had plenty of support already, credit to Gabe, Lily, and Brent for that. What I actually needed was clarity. AI helped me take a breath, tighten my language, and keep frustration from bleeding into how I communicated. I ramble when I'm stressed, and AI helped me cut the noise and get to the point. I even picked up a few better ways to say something difficult without it landing harshly.

## Final thoughts

Looking back, AI didn't replace the skills I already had. It reinforced them. It helped me move faster when time was short, get unstuck when a problem was genuinely murky, and communicate more clearly when the pressure was on.

What surprised me most wasn't the technical help. It was the quiet confidence it gave me. Whether I was gut-checking a feature, scaffolding a tricky integration, or rewriting a message before hitting send, AI became a steady presence in the background that made me a better lead.

None of this was about shortcuts. It helped me show up better, and get the job done well.


### The Rise of No-Code and Low-Code in Frontend Development

No-code tools like Webflow and Framer speed up marketing sites, prototypes, and lead-capture pages significantly, since a designer can ship a change without a dev cycle. They don't replace custom development for complex, scalable products. They're genuinely good for roughly 80% of the work, and that last 20% still needs a developer.


I started learning frontend development a bit over a decade ago, back when responsive design was still new and the [960px grid system](https://960.gs/) was the norm. Not quite the era of `<center>` tags and tables for layout, but we're still talking at least 14 years back.

In the early 2010s, Photoshop shipped a feature that split developer opinion: exporting parts of a design straight to code. The output was rough, messy and inefficient, but plenty of us tried it anyway, hoping it might save some time.

That particular feature never delivered on the promise, but the idea stuck around. Photoshop, Sketch, and Figma all eventually built in design-to-code exports of their own, and that groundwork helped platforms like Webflow and [Framer](https://www.framer.com/) become genuinely useful: tools that bake in real frontend best practices and let designers build and ship directly, without a developer in the loop for every change.

That shift cuts both ways. Designers get more autonomy. Some frontend developers see it as a threat to their role. Either way, it's changed how a lot of web work actually gets done.

## Where no-code actually saves time

**Webflow** and **Framer** cut out a lot of the overhead. Changes ship without touching CI or pushing to GitHub, which meaningfully [shortens time-to-market](https://webflow.com/blog/agencies-accelerate-time-to-market) for simple sites. Fewer redundant development hours also means it's genuinely cheaper for straightforward work. And because designers can build and iterate on layouts themselves, developers get to spend their time on the harder problems instead of pixel-pushing a marketing page.

## What it does for designers specifically

The upside for designers isn't just speed. It also removes a lot of the friction between "what I designed" and "what actually shipped," since there's no handoff step where something gets lost in translation. And using a tool like Webflow tends to teach real CSS along the way, which makes the eventual conversations with developers a lot easier.

## Where it falls short

No-code has real limits, and they show up fastest on complex projects:

- Custom code is still more flexible than anything a no-code tool generates.
- Scaling a genuinely complex design system is where these platforms start to strain.
- The generated code is proprietary and rarely as clean or standards-based as something a developer would write by hand.
- The [80/20 rule](https://en.wikipedia.org/wiki/Pareto_principle) applies directly here: no-code handles the first 80% of a build well, and the remaining 20% usually needs custom development anyway.

## Where AI fits into this

AI is layering on top of the same tools rather than replacing them. Prompt engineering, getting good, specific output from a tool like ChatGPT, has become a real and useful skill for both designers and developers working this way. And features like Webflow AI are already speeding up the mechanical parts: generating a first-pass layout, refining a design, moving faster through the parts that used to take longest.

## The bottom line

None of this replaces custom development on anything genuinely complex. What it does well is speed up delivery and cut cost on marketing sites, prototypes, and lead-capture pages, and it opens the door for non-technical people to contribute directly to work that used to require a developer for every change.

The right approach is integration, not replacement: use no-code for the straightforward work, and keep custom development for anything that needs to scale or hold up under real complexity. Treated that way, it's a genuine addition to the toolkit, not a threat to it.


### Using CSS Custom Properties with Fallbacks for Efficiency

CSS custom properties get more useful with a fallback value: `var(--button-bg, var(--color-primary))` instead of just `var(--button-bg)`. It makes a property optional per component instead of redefining every value in every variation, which means less CSS shipped and less boilerplate to maintain.


Most of us are used to CSS custom properties by now. Since they landed in 2017, custom properties (CSS variables) have cut down on boilerplate and given engineers a lot more control over the values inside a rule.

They can still be tricky to work with, and they're not always as intuitive as you'd hope. Used well, though, they cut a surprising amount of boilerplate.

The approach below isn't perfect, but it holds up well in real projects.

## Why use CSS custom properties

In my experience there are really only three reasons to reach for one:

- You want to reuse a value in more than one place
- You know a value will change later and want to avoid a big refactor
- You need to store a dynamic value set from JS

Point three isn't really the focus here. Points one and two are the ones that matter. Let's look at the classic example: a button.

## The infamous button

Buttons are notoriously hard to style consistently, even though they're one of the simplest HTML elements around. Maybe it's because they carry so many states and variations. Either way, it's usually the first component a frontend engineer touches on a fresh build. Here's a typical way to style one with custom properties:

```css
:root {
 --color-primary: purple;
 --color-text: black;
 --color-text-inverted: white;
 --color-border: gray;
}

.button {
 --button-bg: var(--color-primary);
 --button-color: var(--color-text-inverted);
 --button-border: var(--color-border);

 align-items: center;
 background-color: var(--button-bg);
 border: 1px solid var(--button-border);
 color: var(--button-color);
 display: inline-flex;
 line-height: 1;
}
```

Technically, this is fine. It's clean, and it'd get a 👍 in a code review. But can it be tighter? Yes.

The `var()` function is more capable than most people give it credit for. We tend to use it in a one-dimensional way, rendering out a single value, but it can do more than that with a **fallback value**.

Take the same example and rewrite it:

```css
:root {
 --color-primary: purple;
 --color-text: black;
 --color-text-inverted: white;
 --color-border: gray;
}

.button {
  align-items: center;
  background-color: var(--button-bg, var(--color-primary));
  border: 2px solid var(--button-border, var(--color-border));
  color: var(--button-color, var(--color-text-inverted));
  cursor: pointer;
  display: inline-flex;
  line-height: 1;
  padding-block: 0.875rem;
  padding-inline: 1rem;
}
```

That's cleaner, and it produces the same result with less boilerplate. Overriding a property inside a variation effectively makes every locally scoped custom property optional. Now a variation only needs to define what actually changes:

```css
.button:where(.button-secondary) {
  --button-bg: orange;
  --button-border: teal;
}

.button:where(.button-tertiary) {
  --button-bg: teal;
  --button-border: orange;
}
```

None of this is revolutionary, but it matters how much compressed text ships over the wire. A smaller CSS file is a smaller CSS file: fewer lines, less to parse, less to maintain. The first example needed almost double the code to do the same job as the fallback version.

That adds up. Less CSS means a small but real performance win, and it's easier to read besides. If you want to poke at it yourself, here's a [CodePen](https://codepen.io/iamdainemawer/pen/NWmQZMz) to fork.

## Browser support

Fallback values in `var()` have been baseline since April 2017, per [Google Baseline](https://web.dev/blog/introducing-baseline), so they work in every browser worth supporting today. I wrote more about [what Baseline actually means](/what-is-google-baseline) if you want the full picture.

If you do need to check for support explicitly, this is the statement:

```css
@supports(--css: variable) {}
```

## Further reading

- [Can I Use: CSS custom properties](https://caniuse.com/?search=CSS%20Custom%20Prop)
- [CSS Specification: CSS Nesting Module](https://w3c.github.io/csswg-drafts/css-nesting/)
- [MDN: Using CSS custom properties](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties)
- [CSS Variables Polyfill](https://github.com/aaronbarker/css-variables-polyfill)


### What Is Google Baseline and Why Does It Matter?

Baseline is Google's cross-vendor scorecard for web features. It tells you whether something is stable across Chrome, Firefox, Safari, and Edge without checking each vendor's docs separately. A feature is either "Newly available" (just landed everywhere) or "Widely available" (stable for 30 months or more), so you know at a glance whether it's safe to ship without a fallback.


For years, checking [caniuse.com](http://caniuse.com) was the default way to figure out whether a feature was safe to use, whether for backward compatibility or to check if modern browsers had caught up to a newer spec.

In 2023, Google introduced [Baseline](https://web.dev/blog/introducing-baseline). It's a way to check whether a feature or API is stable enough for production, aimed at making cross-browser support easier to reason about at a glance.

## Why Baseline exists

Browsers update monthly, more people are contributing to specs than ever, and the dialogue between vendors (Safari, Firefox, Chrome, Edge) is more open than it used to be. That combination makes it genuinely hard to track which new features are actually stable everywhere. Baseline exists to make that easier.

As new features land in browser engines, engineers still need time to ramp up, refactor, or plan a rollout. Google has acknowledged it's partly responsible for the pace problem here, since Chrome is often first to ship cutting-edge features. That's part of why the Chrome team built [web.dev](https://web.dev) and [developer.chrome.com](https://developer.chrome.com), and Baseline has pushed further documentation and interoperability-focused conferences since.

New features mean new documentation too. Google has put real effort into keeping MDN current as newer technologies land in Chrome.

## Closing the vendor gap

The core problem engineers deal with is inconsistent feature behaviour across browser engines. It's a genuine pain point, and one that often demands its own planning and workarounds just to route around a specific engine's gaps.

For the last few years, [Interop 2022](https://web.dev/blog/interop-2022) and [Interop 2023](https://web.dev/blog/interop-2023) have been the community effort to close that gap and push toward a more consistent web.

## What is Baseline?

Baseline is a status flag: it tells you whether a feature is fully stable across the major browser vendors, checked against each vendor's most recent two versions. It gives engineers one place to check instead of cross-referencing several.

## How Baseline works

You can check Baseline status directly on [MDN](https://developer.mozilla.org/), [web.dev](https://web.dev), and [caniuse.com](http://caniuse.com).

Baseline also tracks what became stable year over year. [Baseline 2023](https://web.dev/blog/baseline2023), for example, covers everything that reached that bar during the year.

Baseline uses two labels:

- **Newly available**: the feature just reached support across all four major engines. It works everywhere, but hasn't been around long enough to be considered a safe default without checking your specific browser support targets.
- **Widely available**: the feature has been supported across all four for 30 months or more. At this point it's generally safe to use without a fallback or polyfill.

The vendors Baseline considers:

- [Safari](https://www.apple.com/safari/) (macOS and iOS)
- [Firefox](https://www.mozilla.org/en-US/firefox/new/) (desktop and Android)
- [Chrome](https://www.google.com/chrome/) (desktop and Android)
- [Edge](https://www.microsoft.com/en-us/edge/download?form=MA13FJ) (desktop)

## Effect on engineering teams

The biggest win for teams is cutting out the guesswork before adopting a new feature. Say a frontend engineer wants to use CSS Grid's [subgrid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Subgrid) feature. Baseline gives a fast, confident answer on support instead of a research task.

Subgrid lets you define a grid inside a grid for finer layout control. [caniuse.com](http://caniuse.com) puts global usage at **87.42%**, which sounds decent, but doesn't tell you which vendors support it, partially support it, or don't. That's where Baseline fills the gap: caniuse now shows a Baseline badge marking subgrid as "newly available across major browsers." MDN's subgrid docs carry the same badge, and the [web.dev writeup](https://web.dev/blog/baseline2023) confirms it landed in Baseline in 2023. Three sources, one consistent answer.

## A word on evergreen browsers

This doesn't get talked about enough. For most users, manually updating a browser is a thing of the past. Chrome, Firefox, and Edge auto-update. Safari is the outlier, still requiring a manual update or an annual OS upgrade.

Even so, more users than ever are running the latest browser version. Graceful degradation still matters, but it's less of a hard requirement now and more of an extra layer of safety.

## Useful links

- [Google Baseline](https://web.dev/baseline)
- [Google Baseline introduction](https://web.dev/blog/introducing-baseline)
- [Baseline 2023](https://web.dev/blog/baseline2023)
- [Interop 2022](https://web.dev/blog/interop-2022-wrapup) / [Interop 2023](https://web.dev/blog/interop-2023)


### How to Determine When a Sticky Element is Stuck in JavaScript

CSS still has no way to ask whether a sticky element is currently stuck. I solve it with a small JavaScript function instead. Cache the element's computed `top` value once, then compare it against `getBoundingClientRect().top` on a throttled scroll listener and toggle a class when they match. IntersectionObserver is the faster option, but only works if the sticky element is the very first thing on the page.


Using `position: sticky` is a handy CSS positioning property that sticks an element to the top of its relative parent on scroll. It's a solid step up from the older approach: tracking a scroll offset and manually switching an element to `position: fixed`.

## Why CSS can't detect a stuck element

CSS still won't tell you whether a sticky element is currently stuck. That's annoying, because sticky headers often need a different look once they've stuck: a shadow, a smaller logo, a background colour. A `:stuck` pseudo-class would fix this outright. The spec just doesn't define one.

So I use a small JavaScript function that watches the element's position and toggles a class once it's stuck:

```javascript
let stickyElementStyle = null;
let stickyElementTop = 0;

function determineStickyState(element) {
  if (!stickyElementStyle) {
    stickyElementStyle = window.getComputedStyle(element);
    stickyElementTop = parseInt(stickyElementStyle.top, 10);
  }

  const currentTop = element.getBoundingClientRect().top;

  element.classList.toggle('is-sticky', currentTop <= stickyElementTop);
}

window.addEventListener('scroll', throttle(determineStickyState, 200));
```

## How the function works

`determineStickyState` takes the sticky element and gets bound to the window's scroll event through a throttle helper, capped to once every 200ms. Scroll fires a lot more often than that. Without throttling, this function would fire on every single delta. That's wasted work: the user never notices the difference either way.

The last line does the actual job: it toggles a class called `is-sticky` if `currentTop` is less than or equal to `stickyTop`. Most engineers don't know that `classList.toggle()` takes a second `force` argument. Passing true or false turns it into a one-way operation instead of a toggle, which is exactly the behaviour this pattern needs. Per MDN:

> If included, it turns the toggle into a one-way-only operation. If set to false, the token will only be removed but not added. If set to true, the token will only be added but not removed.

The two unscoped variables, `stickyElementStyle` and `stickyElementTop`, exist to cache the expensive part. `window.getComputedStyle` is costly to call on every scroll event, so it only runs once, the first time the function fires. After that, the cached `top` value (run through `parseInt`) gets reused.

`getBoundingClientRect().top` and `getComputedStyle().top` are easy to mix up. The first returns the element's current rendered position. The second returns the CSS-defined top value it's sticking to. Once the current position reaches that defined value, the element is stuck.

## Why IntersectionObserver doesn't work here

IntersectionObserver would be the more performant choice. It skips a scroll listener entirely. The catch: detecting a sticky element with it needs a hack, setting the element's `top` to `-1px` so the observer fires at the right threshold. That only holds up when the sticky element is the very first thing on the page.

Mine wasn't. The sticky element sat further down, behind an already-sticky site header, so its effective top needed to be a positive number that accounted for that header's height. IntersectionObserver can't express that. The scroll-and-throttle approach above works no matter where the element sits.

The full code is up as a [Gist](https://gist.github.com/dainemawer/e233dc5b3ea82caa3a984cf34c6b339f).


### Mastering Task Estimation with the FATE Framework

FATE breaks task estimation into four categories, in reverse acronym order. Engineering (the actual coding time), Technical (code review), Admin (task boards, meetings, overhead), and Feedback (QA and client review rounds). Estimating each separately, instead of lumping everything into "coding time," is what actually produces a timeline that holds up.


Task estimation is something every frontend engineer and engineering manager has to get reasonably good at. Most estimates only cover the coding, though, and that's usually why they end up wrong. I put together a small framework, FATE, that covers the parts people tend to forget: **F**eedback, **A**dmin, **T**echnical, **E**ngineering.

The letters aren't in a particular order. It reads better reversed, since Engineering, Technical, Admin, Feedback roughly matches the order the work actually happens in.

## Engineering

Coding time should account for the complexity of the work, how familiar the team is with the stack, and the dependencies and difficulties likely to show up along the way.

Break the work into small, manageable chunks and put a realistic timeframe on each one rather than estimating the feature as a whole. Factor in the experience and risk profile of whoever's actually doing the work, not just the work itself.

## Technical

Code review is where quality gets checked, bugs get caught early, and knowledge actually spreads across the team. It deserves real time in the estimate, not whatever's left over. That includes time for the author to act on feedback and iterate, not just time for a reviewer to read the diff. Senior engineers reviewing junior work should factor this in especially.

## Admin

This part sounds tedious, but it's real time: updating task boards, documenting progress, attending meetings, the general overhead of running a project. Estimate for it explicitly. Good tooling and workflows cut the admin tax down, which frees up more of the estimate for actual development.

## Feedback

Plan when testing happens, across devices, browsers, and real user scenarios, and lean on automation for the repetitive parts so there's still time for manual testing where it matters. Cover functional, usability, performance, and security, not just "does it work."

Build in rounds of client feedback, with time between each round to act on it. Set up clear communication with the client so feedback comes back on schedule, and be willing to adjust the estimate when feedback changes the scope. Involving the client in the estimation process itself tends to produce estimates that actually match what they expect.

## Why this is worth the extra structure

Skipping any of the four usually shows up the same way: a coding-only estimate that looked fine on paper runs over once code review, admin overhead, and feedback rounds all turn out to need time nobody budgeted for. That's what erodes client trust, not the code itself.

Estimating all four separately takes a bit more upfront thought, but it's the difference between a timeline you can actually defend and one you're hoping holds up.


### Enhance Your React App's Scalability with Storybook and Chromatic

Storybook lets you build and document React components in isolation, outside your app's routing and state, so a component library stays usable by other projects instead of blocked by app-level decisions. Pair it with Chromatic for automated visual regression testing on every commit, and UI bugs get caught before production instead of during manual QA.


Storybook is genuinely useful for engineers, product owners, and stakeholders alike. It lets frontend teams build component libraries without being blocked by bigger project architecture decisions, since components get developed and reviewed in isolation.

It runs as a standalone app alongside your project, documenting components and their variations. Storybook ships with a lot of configurable features. Here's what I actually use day to day: installing and configuring it in a Create React App project, adding addons, writing stories, generating docs automatically, and publishing it to the web.

## Set up and configure Storybook

#### Installing Storybook

Storybook fits into a lot of different project types. The most reliable way to get started is installing it into an existing app and running one command from the project root:

```bash
npx storybook@latest init
```

That inspects your project's dependencies and figures out the right way to install itself. If you're unsure whether your project is supported, check the [Frameworks page](https://Storybook.js.org/docs/react/configure/frameworks) in the docs.

You can install it manually, but that tends to produce dependency mismatches and errors that aren't worth the trouble.

#### Configuring Storybook

Getting Storybook to line up with your actual tech stack is the harder part. Most of that configuration lives in `main.js`: documentation presentation, UI addons, even extending Webpack directly.

TypeScript works out of the box. CSS needs its own setup, though most common approaches are supported, see the [Styling and CSS docs](https://Storybook.js.org/docs/react/configure/styling-and-css) for specifics.

Spin up a Create React App instance to follow along:

```bash
npx create-react-app my-scalable-component-library
```

This bootstraps a basic React app. [Create React App](https://create-react-app.dev/) is what I'm using here, though other frameworks work too. Confirm it runs with `npm run start` before moving on.

Install Storybook next, from the project root:

```bash
npx storybook@latest init
```

It'll detect that you're using CRA and prompt you to confirm a few updates. Accept them. If everything goes well, Storybook launches in your browser on its own dev server.

Worth checking at this point: Storybook adds a `.storybook` folder for configuration, and a `stories` folder inside `src`. Each story is generally backed by three related files, more on that shortly.

Your `package.json` and `package-lock.json` both get updated with new dependencies, plus two new scripts:

```javascript
"storybook": "storybook dev -p 6006",
"build-storybook": "storybook build"
```

`npm run storybook` starts the dev environment. `npm run build-storybook` produces a publishable build.

Run `npm run build-storybook` once, the output lands in a `storybook-static` folder, a "published" Storybook ready to be made public. At this point Storybook and CRA are fully wired together. Add `storybook-static` to `.gitignore` if you don't want to track the static output.

You'll also notice a handful of example components got added to your project. Safe to remove, though I'd keep them around as reference for a while. Before moving on, here's what `main.js` actually looks like:

```javascript
/** @type { import('@storybook/react-webpack5').StorybookConfig } */
const config = {
  stories: [
    "../src/**/*.mdx",
    "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)"],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/preset-create-react-app",
    "@storybook/addon-onboarding",
    "@storybook/addon-interactions"
  ],
  framework: {
    name: "@storybook/react-webpack5",
    options: {},
  },
  docs: {
    autodocs: "tag",
  },
  statistics: ["../public"],
};

export default config;
```

A few things worth knowing: `stories` tells Storybook where to look for component stories, update it if your file structure changes or stories quietly stop showing up. `framework` varies by project type. `docs` turns on automatic component documentation.

The [Configure page](https://Storybook.js.org/docs/react/configure/overview) in the Storybook docs covers everything else `main.js` can control.

## Decide on Storybook addons

Addons are essentially plugins: pre-built packages that extend Storybook's core APIs, whether that's integrating a JS/CSS framework or changing Storybook's own default behaviour.

There are two rough categories. UI-based addons change Storybook's own appearance and behaviour. Preset-based addons integrate other technologies, TypeScript, Tailwind, and so on. The [Integrations page](https://Storybook.js.org/integrations/) has the full catalogue.

**Note:** some addons are maintained by the Storybook team directly, others by the community. Community addons can behave unpredictably or lag behind the latest Storybook version.

Before adding more, it's worth knowing what ships by default:

```javascript
addons: [
  "@storybook/addon-links",
  "@storybook/addon-essentials",
  "@storybook/preset-create-react-app",
  "@storybook/addon-onboarding",
  "@storybook/addon-interactions"
],
```

Say you want to add the accessibility addon:

```bash
npm install @storybook/addon-a11y
```

Then register it in `main.js`:

```javascript
addons: [
  "@storybook/addon-links",
  "@storybook/addon-essentials",
  "@storybook/preset-create-react-app",
  "@storybook/addon-onboarding",
  "@storybook/addon-interactions",
  "@storybook/addon-a11y"
]
```

Save `main.js` and restart Storybook with `npm run storybook`. An "Accessibility" tab now shows up on every story, already flagging real a11y issues in your components.

UI-based addons like this one are usually low-effort. Preset-based addons tend to need more: extra webpack config, PostCSS plugins, or other build-level wiring specific to your stack. That can get genuinely fiddly depending on your framework, so go in carefully and check that whatever you add stays in sync with how your actual app is built.

## Write and document component stories

A story is tied to a component and its variations, written in React, Markdown, or a mix of both. Stories take parameters that map to whatever props the component accepts, and those props can be tweaked live inside the Storybook UI.

Here's the Button story Storybook bootstraps by default:

```javascript
import { Button } from './Button';

export default {
  title: 'Example/Button',
  component: Button,
  parameters: {
    layout: 'centered',
  },
  tags: ['autodocs'],
  argTypes: {
    backgroundColour: {
      control: 'color'
    },
  },
};

export const Primary = {
  args: {
    primary: true,
    label: 'Button',
  },
};

export const Secondary = {
  args: {
    label: 'Button',
  },
};

export const Large = {
  args: {
    size: 'large', label: 'Button',
  },
};

export const Small = {
  args: {
    size: 'small',
    label: 'Button',
  },
};
```

The default export is always the main configuration. Most of it is self-explanatory, but a few keys are worth calling out specifically:

- `parameters`: static, named metadata about a story, generally used to control Storybook features and addon behaviour.
- `tags`: drives automatic documentation generation per story. More on [AutoDocs](https://Storybook.js.org/docs/react/writing-docs/autodocs).
- `argTypes`: controls or annotates how args behave. More on [arg types](https://Storybook.js.org/docs/react/api/arg-types).

Every named export after the default is a variation, each just an object with an `args` key matching your component's props. Each shows up under the same component in Storybook's UI, ready to interact with.

Decorators matter once stories get more complex. A decorator wraps a story in extra context or functionality, set via the `decorators` key:

```javascript
decorators: [
  (Story) => (
    <div style={{ margin: '3em' }}>
      {/* Decorators also accept a function. Replace <Story/> with Story() to enable it */}
      <Story />
    </div>
  ),
],
```

Here, a `<div>` wraps the component and gives it 3em of margin.

Stories can also consume components from other stories, though how well that works depends on how your components render and how much detail you're layering into the app overall. The docs cover [sub-components](https://Storybook.js.org/docs/react/writing-stories/stories-for-multiple-components) in more detail.

#### Writing a story for a real component

Let's add a `Footer` component to prove this out. It needs three files in `src/stories`: `Footer.jsx`, `Footer.stories.js`, and an optional `footer.css` if you want it styled. Here's `Footer.jsx`:

```javascript
import React from 'react';
import PropTypes from 'prop-types';

export const Footer = ({ siteOwner, showCopyRight }) => (
  <footer>
    <div className="footer">
      {showCopyRight && (
        <div>
          <span>
            <span role="img" aria-label="copy">©️</span>
            2018 {siteOwner}.
          </span>
        </div>
      )}
    </div>
  </footer>
);

Footer.propTypes = {
  siteOwner: PropTypes.string.isRequired,
  showCopyRight: PropTypes.bool,
};

Footer.defaultProps = { showCopyRight: true, };
```

It takes two props: `siteOwner` and `showCopyRight`. Here's the story:

```javascript
import { Footer } from './Footer';

export default {
  title: 'Example/Footer',
  component: Footer,
  tags: ['autodocs'],
  parameters: {
    layout: 'fullscreen',
  },
};

export const WithSiteOwner = {
  args: { siteOwner: 'Jane Doe', showCopyRight: true, },
};

export const WithOutCopyRight = {
  args: {
    siteOwner: 'Jane Doe',
    showCopyRight: false,
  },
};
```

A contrived example, but it shows how little effort a story actually takes. Save this as `Footer.stories.js` and you get an auto-documented, multi-variant story where the props are fully interactive.

Try changing `siteOwner` directly in the story controls. To style it, import `footer.css` into `Footer.jsx` and reference the class names. To see it inside a real React app instead of Storybook:

```javascript
import { Footer } from './stories/Footer';
// ...
<Footer siteOwner='Daine Mawer' showCopyRight />
```

That's a component and its story, done. Next: getting it published.

## Publish your Storybook

Running Storybook locally works fine for engineers, since the config lives in version control anyway. A published URL is a lot more useful for non-technical stakeholders who just want to look at the components.

A production build of Storybook outputs static files to a build folder, and it's a single command:

```bash
npm run build-storybook
```

The build fails outright on any build error, so there's no risk of publishing something broken. From there, you need somewhere to host it: GitHub Pages, Netlify, and S3 all work, some with more setup than others.

If Chromatic isn't part of the plan, GitHub Pages is the simplest option. A [GitHub Action](https://Storybook.js.org/docs/react/sharing/publish-Storybook#github-pages) handles most of the configuration for you.

## Set up Chromatic for visual regression testing

Chromatic runs alongside Storybook and is maintained by the same team, so wiring it into an existing app and CI pipeline takes very little effort.

The payoff is real: visual regressions and interaction bugs get caught before they reach production, and it gives a team a shared, visual way to review UI changes together rather than relying on someone spotting a regression manually. It's free, with usage limits.

To hook it up to a published Storybook: sign up for a Chromatic account and grab a project token, then install the package:

```bash
npm install --save-dev chromatic
```

Add a script to `package.json`:

```javascript
"scripts": {
  "chromatic": "chromatic"
}
```

Add a `.env` file with `CHROMATIC_PROJECT_TOKEN` set to your project token, then run `npm run chromatic`. That publishes your Storybook to Chromatic, where you get a proper UI for reviewing component changes.

The catch: run manually like this, you have to remember to do it every time a component changes. For anything beyond a small project, wiring this into CI on every commit is the better call, Chromatic integrates directly with pull requests.

On GitHub, add a `workflows` folder under `.github` and follow [Automate Chromatic with GitHub Actions](https://www.chromatic.com/docs/github-actions/) to get it running. From there, every commit to your components runs UI tests and a visual review automatically.

## Where this leaves you

Storybook and Chromatic together give a team real confidence shipping component changes: features and fixes move faster, and the product stays documented, scalable, and easy to extend as it grows.

_Read the original article on [Sitepoint](https://www.sitepoint.com/scale-react-app-storybook-chromatic/)_


### Understanding Chrome's Coverage Panel

Chrome DevTools' Coverage panel (More tools → Coverage) shows exactly which loaded CSS and JavaScript never actually runs on the page, colour-coded red for unused and green for used, with a byte count and percentage per file. Use it to find what's safe to remove, split, or defer instead of guessing at bundle bloat.


When a project gets complex, JavaScript and CSS get away from you fast. Before you know it, thousands, sometimes tens of thousands, of bytes are being transferred and executed in the browser, and most of it isn't even needed.

## What is code coverage?

Code coverage comes from an older computer science concept called test coverage. From Wikipedia:

> Test coverage is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run.

High test coverage means most or all of a codebase runs during unit testing, which implies fewer undiscovered bugs.

Coverage works a bit differently for CSS and JavaScript in the browser. You can still write unit tests for JavaScript, but in a browser context, coverage means something more specific:

- **CSS:** what percentage of CSS actually gets used once it loads? More precisely, what percentage of CSSOM nodes match a node in the DOM?
- **JavaScript:** what percentage of the loaded JavaScript actually executes?

Once you know how much of your referenced JS and CSS is actually used, you can refactor or reimplement files with that in mind. Load only what a page needs, and bundle size, transfer size, and paint time all drop with it.

## Auditing code coverage in Chrome

Most Chrome users have never opened the Coverage panel in DevTools. To find it: open DevTools, go to the overflow menu, click "More tools," and select "Coverage."

Once it's open, you can either reload the page to capture coverage from load, or hit record to capture coverage for whatever you do next without reloading.

After a capture, the panel lists every JavaScript and CSS resource that loaded. Click a line item and you'll see the source with a vertical bar down the left, coloured green or red. Red means the code loaded but never ran. Each line item also shows total unused bytes and a percentage.

## How to handle poor code coverage

Fixing poor coverage is genuinely hard, and it can push you toward a full refactor. I grimace at that word, so let's start with some easier wins first.

## CSS wins

A few tools already do a solid job of getting CSS coverage close to 100%. PurgeCSS, the tool Tailwind uses under the hood, strips unused styles well, and you can drop it into any stack, not just a Tailwind one.

Even WordPress Gutenberg shipped a filter that only loads block-library CSS when a block is actually on the page.

Modern CSS approaches help here too. CSS Modules, Vanilla Extract, and Linaria can all cut down the impact of unused CSS in a React codebase.

## JavaScript wins

The wins in JS execution are smaller, and mostly about how and when a feature runs, not the code itself. Planning and architecture do more here than any single optimisation.

Worth looking into: route-based code splitting, tree shaking, dynamic import, facade patterns, and import-on-interaction or import-on-visibility.

## Build tool wins

Webpack handles code-splitting and tree-shaking well, and both help coverage numbers directly. This space moves fast, so it's worth checking whether a newer build tool gets you further with less effort.

## Dead ends, not worth the effort

Two things will stop you cold no matter how much you optimise.

Third-party scripts are the first. You have almost no control over how they execute, and really only three options: retain the script, remove it, or find a way to defer its execution.

Frameworks and libraries are the second. Even the fastest ones carry code you can't selectively strip out.

It's worth keeping this in perspective, too. Chasing coverage on code that barely affects real performance isn't worth the time.

## Planning and refactoring

Your stack and architecture matter more than any individual fix. Each one expects something slightly different from you when it comes to shipping only what a page needs.

High code coverage is a long-term path to solid performance, not a quick win. Write JavaScript to good performance practices, get your build configuration right, and plan features with this in mind from the start, and the coverage numbers tend to follow.

## Conclusion

High code coverage is one of the more reliable ways to keep a site lightweight. There are plenty of tools to help you find and fix the gaps. Just know that your options shrink fast once third-party scripts and heavier frameworks are in the mix.

100% coverage across both CSS and JS is unlikely on any real project. A genuinely complex site may need a large payload, and that's fine. The goal is removing clear waste, not chasing a perfect number.


### Setting Up Next.js with a Component Library Using Monorepos

NPM workspaces (v7+) let a component library and a Next.js site live and develop together in one monorepo, so the library can be built with Storybook and imported into Next.js like any third-party package. The one wrinkle is that Next.js won't transpile ES6 from outside its own folder by default, so you need transpileModules in next.config.js pointing at your workspace name.


A monorepo is a single repository holding multiple related packages or projects. With NPM workspaces, you can build a component library that several applications consume, all version-controlled together in one place.

I've worked with monorepos in production for over a year now, and I'll say this much: they beat git submodules. A typical monorepo holds several closely related packages, and it gets you away from initializing a repo within a repo, or manually linking local packages from elsewhere on disk and keeping them updated by hand.

NPM has supported workspaces (v7 and above) for a while now, which gets you most of the way to a proper monorepo structure.

I recently built a component suite for a Next.js project. The goal: develop components actively with Storybook, and have my Next.js projects consume them directly, the same way I'd import any third-party library. Next.js has always supported a `components` folder, but it's scoped to the app itself. A monorepo lets you treat your component library as its own real package instead.

## Set up the project structure

Start with a folder for the monorepo:

```bash
mkdir my-monorepo && cd my-monorepo
```

Bootstrap a package.json:

```bash
npm init -y
```

That gives you something like:

```json
{
  "name": "my-monorepo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
```

Before installing dependencies, add a `workspaces` key so NPM knows where your projects and packages actually live. NPM has a built-in command for this, run the following and follow each prompt:

```bash
npm init -w ./packages/component-library
npm init -w ./projects/monorepo-site
```

This runs `npm install` for you too. Here's the first real difference from a normal repo: a `package.json` now exists at the root and inside every workspace, but there's only one `node_modules` and one `package-lock.json`. Everything gets managed from the root.

## Install workspace-specific dependencies

`npm install` still works, but it needs to run from the root with a `-w` flag pointing at the target workspace. Here's Next.js going into `monorepo-site`:

```bash
npm install --save next react react-dom -w monorepo-site
```

Run that from the root, where `node_modules` and `package-lock.json` live. The value passed to `-w` has to match the `name` field in that workspace's own `package.json`, in this case, `monorepo-site`.

If it worked, you'll see the dependencies land in `projects/monorepo-site/package.json`:

```javascript
"dependencies": {
  "next": "^13.0.6",
  "react": "^18.2.0",
  "react-dom": "^18.2.0"
}
```

Repeat this for whatever `packages/component-library` needs too.

## Set up components and Storybook

This isn't a full Storybook setup tutorial, just enough to prove the monorepo wiring works. Since Storybook isn't a dependency of either workspace, install it at the monorepo root:

```bash
npm install --save-dev @storybook/react @storybook/manager-webpack5 @storybook/builder-webpack5 @storybook/addon-postcss
```

Add the build commands to the root `package.json`:

```javascript
"storybook": "start-storybook -p 6006",
"build-storybook": "build-storybook"
```

Create a `.storybook` folder at the monorepo root with two files.

`main.js` handles Storybook's configuration:

```javascript
module.exports = {
  "stories": [
    "../packages/component-library/**/*.stories.jsx",
  ],
  "addons": [ {
    name: '@storybook/addon-postcss',
    options: {
      styleLoaderOptions: {},
      cssLoaderOptions: {
        modules: true,
        sourceMap: true,
        importLoaders: 1,
      },
      postcssLoaderOptions: {
        implementation: require('postcss'),
      },
    },
  }
  ],
  "framework": "@storybook/react",
  "core": {
    "builder": "@storybook/builder-webpack5"
  }
}
```

This tells Storybook where to find component stories, wires in `@storybook/addon-postcss` (with PostCSS Modules enabled via the extra options), and configures `framework` and `core` to use Webpack v5.

`preview.js` gets a decorator:

```javascript
export const decorators = [
  (Story, context) => {
    return (
      <div style={{
        padding: '1rem',
        display: 'flex',
        justifyContent: 'center'
      }}
      >
        <div>
          <Story {...context} />
        </div>
      </div>
    );
  }
];
```

`preview.js` lets you customize how stories look without touching the component logic itself, hence "decorator." This one just centers things with some basic padding.

Add a `Button` component inside `packages/component-library` next, a component file and a story file are enough to prove the setup works. The exact implementation doesn't matter here, what matters is importing it into Next.js.

## Set up the Next.js project

Add a `pages` folder to the Next.js site, and the standard scripts to its `package.json`. In `projects/monorepo-site/package.json`, replace the scripts field with:

```javascript
"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint"
}
```

Add `pages/index.js`:

```javascript
const Home = () => {
  return (
    <main>
      <h1>Hello! This is a NextJS + StoryBook Monorepo</h1>
    </main>
  );
}

export default Home
```

## Add the component to Next.js

Import the Button into `projects/monorepo-site/pages/index.js`:

```javascript
import Button from '../../../packages/component-library/Button/Button.jsx'
```

Run `npm run dev` and you'll likely hit an error: Next.js doesn't transpile ES6 JavaScript from `node_modules` or any other folder outside its own reach by default.

Fix it with a `transpileModules` entry in `next.config.js`:

```javascript
export const nextConfig = { transpileModules: ['component-library'] }
```

Note that this takes the workspace name, `component-library`, not the folder's path on disk. Restart the dev server after adding it.

At this point your Button component lives in both Next.js and Storybook, and both are tracked in the same repo.

One gotcha: Next.js 13 will ask for React 18. This walkthrough was written against Next.js v12 and React v17.0.2, so adjust versions if you're starting fresh today.

## A couple of convenience scripts

Without a shortcut, running a build means `cd`-ing into every project or package individually. Add these to the root `package.json` instead:

```javascript
"scripts": {
  "build": "npm run build --workspaces --if-present",
  "dev:monorepo-site": "npm run dev -w monorepo-site"
}
```

`npm run build` at the root fires the build script in every workspace that has one, and quietly skips any that don't. Scale this out to three production sites sharing one library, and one command builds all of them.

`npm run dev:monorepo-site` is narrower: it targets exactly one workspace and runs whatever script is defined there, so you can spin up that dev server from the root without navigating into its folder.

## Where this leaves you

A monorepo structure built on NPM workspaces, a component library and a production site sharing it through Storybook and Next.js, scripts that make the whole thing manageable from the root, and every dependency managed in one place instead of juggling submodules.

From here, adding another site, extending the component library, or bringing in packages for CMS integrations or API support is all straightforward. The structure scales with however far you want to take it.


### 10 Techniques for More Effective Code Reviews

Code review breaks down for the same handful of reasons every time. Reviewing only once at the end, no defined process, and feedback aimed at the person instead of the code. Review in stages instead of one final pass, define the process in writing before a project starts, automate what a linter can catch, and phrase feedback as questions or suggestions rather than instructions.


Code review is as routine as any other part of shipping software. It's central to quality, standards, collaboration, and how a team actually learns from each other.

How to do it well is a lot less settled. A code review sits at the intersection of human judgment and machine code, and that's exactly where it tends to go wrong. People already have a hard enough time talking to each other, let alone talking about code neither of them fully agrees on. Reviews can turn personal, hold up a sprint over a stubborn disagreement, or leave someone dreading their next PR notification.

None of that is inevitable. Here are ten things that actually help.

## Review a feature more than once

A common misconception is that a feature only needs reviewing once, right at the end. That's a bit like arriving somewhere with no idea how you got there. Constant review of the same code isn't efficient, but staying close to a feature as it develops is.

Check in at 25% and 75% complete, for example. That gives room to course-correct early, and it helps you understand what the engineer is actually trying to build, not just what they eventually submit. Junior engineers especially tend to appreciate it: it feels like building the feature together rather than being graded on it at the end.

A quick look at a draft PR at each checkpoint is usually enough. Save the deep review for when the engineer considers the feature done.

## Define a clear process upfront

Before development starts, settle a few basics as a team:

- Who reviews what?
- Which automated tools are in play?
- How often does review happen?
- What actually happens during a review?
- How are reviews assigned?
- How should a branch be prepared before review?
- What's the merge strategy, and are branches deleted after?

Write the answers down somewhere the team can refer back to. Once everyone's agreed on it, stick to it, and if it changes, make sure the whole team knows why.

## Focus on the code, not the person

Written feedback is easy to misread, more than most reviewers realize, especially across language and culture. A comment meant as neutral can land as blunt or even hostile.

A few things that help:

- Keep some of it light. A joke or an emoji goes a long way.
- Lead with empathy, not correction.
- Suggest rather than instruct: "perhaps this would work better as..." instead of "you must stop doing..."
- Aim at the code, not the person: "a clearer understanding of the CSS cascade would make this more efficient" instead of "you don't understand the cascade."
- Treat every comment as a two-way teaching moment, not a verdict.

## Ask questions instead of assuming mistakes

Asking a question instead of pointing out a mistake disarms a review almost instantly. It's a lot less confrontational than telling someone their code needs refactoring. A few ways to phrase it:

- "Can you walk me through how this function works?"
- "Why is this a string here but an array over there?"
- "What's this variable actually for?"

It also puts the reviewee in the position of explaining their own logic, which tends to build confidence rather than dent it, and it usually gets you a clearer picture of what they were going for.

## Automate what you can

Don't spend review time calling out things a linter would already catch, especially if the tooling exists and just isn't wired in yet.

GitHub Actions can run these checks automatically on push or PR. Husky or lint-staged narrow that further, running lint scripts only against changed files. Between the two, most styling issues and careless mistakes never need a human eye at all.

Worth automating specifically: CSS and JS code style, framework conventions, unit tests, and performance or end-to-end tests. Automated tools won't catch everything, but they'll catch most of what wastes a reviewer's time.

## Encourage open dialogue

The reviewer/reviewee dynamic already tilts the conversation, and a PR thread isn't always the right place to work through something in depth. Some things are worth taking offline.

Worth paying attention to while you do:

- How much of your time is actually going into mentoring versus reviewing.
- Whether the reviewee is treating feedback as a learning opportunity rather than something to get defensive about.
- Whether less senior engineers feel able to push back on a suggestion. That needs active encouragement, whether in a 1:1 or a team session, depending on what they're comfortable with.

## Do more than just review the diff

A thorough review usually means more than reading a diff. Depending on the change, that might mean:

- Pulling the branch down and running a production build locally.
- Testing the feature in the browser and checking it actually matches what stakeholders expect.
- Doing some light QA on the feature yourself.
- Suggesting concrete improvements, not just flagging problems.
- Thinking through whether this change could ripple elsewhere in the project.

As the reviewer, your approval is the signal this is ready to merge. Treat it that way.

## Use concrete suggestions, not just comments

Feedback lands differently depending on experience level, and a comment that's obvious to a senior engineer can be genuinely confusing to someone more junior.

I've been on the receiving end of feedback I didn't fully understand, where a concrete example would have saved a lot of back-and-forth. GitHub's Suggested Changes feature exists for exactly this: propose the actual code change alongside the comment. Linking to a relevant doc or article works too, and tends to teach more than a comment alone.

## Pick your battles

Some engineers get stuck on things that don't matter much: tabs versus spaces, a variable name, formatting preferences. As a senior reviewer you can override this, but it's worth asking whether it's actually worth the back-and-forth.

Prioritize what could cause real damage. Naming and style nitpicks can wait if they don't affect functionality or break lint.

## Use a review checklist

A checklist in the PR description keeps reviews consistent, especially for the parts that are hard to automate. Worth including:

- A link to the ticket.
- A description of the technical approach.
- Links to designs.
- Screenshots of the feature.
- Instructions for testing.
- A place to confirm functionality or flag open questions.

Kept up consistently, this becomes a useful record over time, especially when tracking down where a bug actually came from. GitHub's PR templates make this close to automatic once it's set up.

## Bringing it together

Getting good at code review takes time for senior and junior engineers alike. Done well, it changes how a team ships, not just how clean the code looks. Open communication, feedback aimed at the code rather than the person, review that goes beyond the diff, and automation for everything that doesn't need a human, that's most of it.


### 4 Tips for Properly Using the Return Statement in JavaScript

Four rules make return statements more reliable. End a function explicitly rather than relying on an implicit undefined, return the type your caller actually expects, return the value your function's name promises rather than whatever's in scope, and use multiple return statements for early exits instead of nesting conditionals.


The return statement doesn't get much attention, but it's easy to get subtly wrong. It specifies the value a function hands back to its caller and marks the end of that function's execution. Get it wrong and your code can still run without erroring, just not the way you expect. Here are four things worth knowing.

## 1. Use return to end a function or method

Return signals the end of a function. The moment it's hit, the function stops:

```javascript
function sayMyName(name) {
  console.log(name);
  return; // ends the function, returns undefined
}
```

Worth knowing: return is affected by automatic semicolon insertion (ASI). You can't put the value on the next line and expect it to come along:

```javascript
// Wrong. ASI inserts a semicolon after return, so this returns
// undefined and never touches `name`.
return
  name;

// Right. The parenthesis stays open across the line break, so
// ASI doesn't insert anything.
return (
  name
);
```

## 2. Return the correct data type

Return the type your caller actually expects. Get this wrong and your program will still run, just not correctly, thanks to JavaScript's [type coercion](https://developer.mozilla.org/en-US/docs/Glossary/Type_coercion) quietly patching over the mismatch until it eventually causes a real bug somewhere downstream.

```javascript
function add(a, b) {
  return a + b; // correct, returns a number
}

function subtract(a, b) {
  return a - b; // correct, returns a number
}

function multiply(a, b) {
  return `${a} times ${b} is equal to: ${a * b}`; // wrong, returns a string
}
```

## 3. Return a value that's appropriate for the function

Think about what your function's name actually promises, and return that, not just whatever happens to be in scope. If a function is meant to calculate an average, returning the sum isn't correct, even though the sum is right there.

```javascript
function average(numbers) {
  let total = 0;
  for (let number of numbers) {
    total += number;
  }

  return total; // wrong, this is the sum, not the average
}

function average(numbers) {
  let total = 0;
  for (let number of numbers) {
    total += number;
  }

  return total / numbers.length; // correct
}
```

## 4. Use multiple return statements if it helps

Sometimes you want to return immediately once a condition is met, whether that's inside an if statement or a switch.

```javascript
function options(option) {
  switch (option) {
    case "DnD":
      return "do-not-disturb";
    case "Silent":
      return "silent-mode";
    default:
      return "no-option-selected";
  }
}

function getOptions(option) {
  if (option === "DnD") {
    return "do-not-disturb";
  }

  return option;
}
```

In `options`, returning directly inside each case means no `break` keyword and no temporary variable to hold the value. It reads better and uses less memory.

In `getOptions`, you always get a value back regardless of which branch runs: the return inside the `if` fires when the condition is true, and otherwise the function falls through to the final `return option`.

None of this is complicated, but getting it wrong tends to produce bugs that only show up later, once something downstream trips over a value that isn't what it expected. [Read more about the return statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/return) on MDN.


### Enforcing Consistent Commit Messages with CommitLint

CommitLint checks commit messages against a style guide, usually Conventional Commits, and rejects the ones that don't match. Install it, run `commitlint --init` for a starter config, then wire it to Husky's commit-msg hook so a bad commit message gets caught before it lands instead of sitting in the history forever.


CommitLint is a small package that lints Git commit messages against a style guide you define. Commit messages tend to get sloppy over the life of a project. CommitLint catches that by rejecting anything that doesn't match the convention.

## Why use CommitLint

A few concrete reasons to add it to a workflow:

- A consistent style keeps commit history predictable across a team, and makes generating changelogs or release notes far less manual.
- Structured messages (a JIRA ticket number, a clear type prefix) are easier for someone unfamiliar with the change to parse later, including future you.
- It also catches basic mistakes: inappropriate language, or a message written in the wrong language for the project.

## How to set it up

Install it with npm from the root of your project:

```bash
npm install commitlint --save-dev
```

Then generate a config file, which is where the actual rules live:

```bash
npx commitlint --init
```

That creates `commitlint.config.js`. Edit it to change which rules CommitLint enforces.

To run CommitLint automatically on every commit rather than by hand, install [Husky](https://typicode.github.io/husky/#/) first:

```bash
npm install husky --save-dev
```

Activate Husky's hooks:

```bash
npx husky install
```

Then wire CommitLint into the commit-msg hook:

```bash
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'
```

The [local setup guide](https://commitlint.js.org/#/guides-local-setup) covers this in more depth if any of these steps behave unexpectedly.

## Configuration options

`commitlint.config.js` supports a wide range of options. The ones you'll actually touch:

- `rules`: an object where each key is a specific rule, set to on or off.
- `parserPreset`: which parser CommitLint uses to read commit messages.
- `formatter`: how CommitLint's output gets displayed.

The [full reference](https://commitlint.js.org/#/reference-configuration) covers everything else.

## Running it in CI

Add CommitLint as a step in your pipeline so a message that slipped past a local hook still gets caught. In Travis CI, for example:

```yaml
script:
  - npm run lint:commit
```

That runs CommitLint against every commit in the build, so nothing merges without a message that follows the convention.

## Conclusion

CommitLint doesn't do anything glamorous. It just enforces a style guide consistently, which is exactly the kind of thing humans are bad at doing by hand over a long project. The payoff is a commit history that's actually useful to the next person who has to read it.


### 5 Frontend File Architectures for Better Code Organization

There are five common ways to structure a frontend project. Flat (everything in one folder), hierarchical (grouped by file type), modular (grouped by self-contained module), component-based (grouped by UI component, the React/Vue default), and feature-based (grouped by product feature, like blog or cart). Which one fits depends mostly on project size and how your team works, not a universal best answer.


Picking the right file architecture early can save a lot of pain later, especially once a frontend project starts to scale. There are several common approaches, each with real trade-offs. Here are five of them, and where each one tends to hold up or fall apart.

## Flat architecture

```text
|- index.html
|- style.css
|- analytics.js
|- about.html
|- modernizer.js
```

The simplest option: everything lives in a single directory. It works fine for micro or small projects, but the moment a project grows, file count and file types tend to spiral out of control.

Without any explicit hierarchy, collaborators carry a higher cognitive load just finding things, which tends to lead to disorganized, ad-hoc additions over time.

**Benefits**

- Quick and simple to get started
- Hosts easily on GitHub Pages or Amazon S3
- Simple version control
- Almost no overhead in understanding how the project is organized

**Downsides**

- Scalability is seriously limited
- File types end up mixed together with no real order
- Finding where a piece of functionality actually lives gets harder over time

## Hierarchical architecture

```text
|- css/
|- javascript/
|- assets/
|- images/
|- fonts/
|- index.html
```

Here, a project is split across multiple directories, generally by file type: CSS, JavaScript, and assets like images and fonts. That makes it easier to reason about where a given piece of code lives.

Each folder can go a level deeper into more semantic groupings. The CSS folder, for example, might look like:

```text
|- css/
  |- base/
  |- components/
  |- typography/
```

**Benefits**

- More scalable than flat architecture
- Clearer organizational semantics
- Less overhead since file types are grouped
- Predictable, logical structure

**Downsides**

- More complex to set up
- Opinionated. There's no single "right" way to structure it
- Can be slower at scale if traversal across many nested folders adds up

## Modular architecture

```text
|- index.html
|- modules
  |- ExampleModule
    |- components
    |- tests
    |- helpers
    |- mocks
    |- services
    |- types
```

Each module is self-contained: everything related to it, components, types, tests, helpers, lives in one folder. That makes updating a module's various pieces faster, since everything relevant stays close together.

It also gives a high-level view of what the site actually does, which helps new contributors get oriented faster.

**Benefits**

- Encourages reusable components
- Scales cleanly since new modules slot in on their own
- Easier to test and maintain long-term
- More natural opportunities for code splitting

**Downsides**

- Can get complex as the module count grows
- Usually depends on a build tool or task runner
- Only works well if developers keep components standardized
- Somewhat steeper learning curve

## Component-based architecture

```text
|- src
  |- components
    |- Header
      |- index.jsx
      |- Header.module.css
```

Familiar to anyone who's built with React: components are grouped by their own folder, each one self-contained and reusable. Larger features get built by composing smaller components together. This pattern fits frameworks like React or Vue that are built around components in the first place.

**Benefits**

- Reusability is the whole point
- More efficient to maintain and extend over time
- Easy to test
- Better performance potential through code splitting and dynamic loading
- Familiar developer experience, quick to pick up

**Downsides**

- Can get complex fast with a build tool like Webpack in the mix
- Fairly steep learning curve
- Easy to over-engineer
- Navigating the codebase can feel scattered when functionality is spread thin across many small files

## Feature-based architecture

```text
|- src
  |- features
    |- blog
    |- shop
    |- cart
    |- components
    |- pages
    |- services
```

Here the codebase is organized around features rather than file type or component. Each feature, blog, shop, cart, gets its own directory containing everything it needs, with further sub-folders as needed. That tends to make it easier to see how the product's functionality fits together.

This works especially well when a team's roadmap is organized around shipping discrete features. It's still common in more monolithic frameworks like Laravel and WordPress, where it gives a clear, orienting structure.

**Benefits**

- Easy to find related functionality in one place
- Features can be added or removed cleanly
- Straightforward to test and maintain long-term
- Better overall developer experience
- Isolation between features protects functionality from bleeding into unrelated code

**Downsides**

- Steeper learning curve for new developers
- Needs a standardized approach to design patterns to stay consistent
- Risk of over-engineering
- Shared functionality can still cause overlap between features
- Can produce a lot of smaller files that each do very little on their own

## Choosing one

There's no simple formula here. Scalability should come first, but developer experience, how often features get built or extended, and how easily things can be added or removed all matter too. The stack matters as well: what works well for a React project won't necessarily be the right call for a WordPress-based one.


### How to Motivate and Inspire Individual Contributors

Motivating individual contributors mostly comes down to five things. Clear goals, SMART ones plus personal ones, not just project ones, regular feedback instead of occasional check-ins, real investment in their career even if it eventually takes them elsewhere, recognition that's public and covers more than just good code, and a work environment where mistakes are safe to make.


Individual contributors carry a lot of the actual weight in a team, and an engineering manager's job is largely about leading them toward good outcomes while keeping the work sustainable. Most managers were individual contributors themselves not long ago, which helps: it's easier to empathize with a role you've actually done.

Everyone brings a different personality to the table, so motivating people well means adjusting your approach as workload and pressure shift, not running the same playbook on everyone. A few things consistently help.

## Set clear goals and expectations

People need to know what's expected of them. It gives them a sense of security and a reason for being there, and it's the starting point for understanding how their work fits into the team's success.

SMART goals, specific, measurable, achievable, relevant, time-bound, are a reliable way to frame this so contributors know what "done well" actually looks like.

Project goals matter, but personal ones matter just as much. Individual contributors usually want to learn things beyond whatever the current stack happens to be, and it's worth remembering that as a manager. Setting yearly personal goals alongside team ones helps someone feel like they're building their own career, not just delivering the roadmap.

## Give ongoing feedback and support

Continuous, genuinely positive feedback is what actually helps someone thrive, more than any single review cycle.

That can happen daily, weekly, or monthly, through:

- Async check-ins on Slack
- 1:1 meetings
- Quarterly goal realignments

Rapport makes this easier. Ongoing support helps someone see their own strengths and weaknesses more clearly, and gives a manager a natural way into mentorship when it's needed.

The part that matters most is following through. Don't promise to help someone hit a goal and then not mention it again for six months. Trust is the whole point here, and it erodes fast if it's not backed up. When things get hard, staying calm and steady matters more than having the perfect answer.

Some days, support has nothing to do with goals or output at all. Sometimes it's just someone having a bad day, and what they need is empathy, not a plan.

## Support career development, even beyond this job

An individual contributor's career goals won't always line up with the company's. That's normal, and worth respecting rather than fighting. Taking a genuine interest in where someone wants to go tends to motivate them more than almost anything else on this list.

A few things that help in practice:

- Professional development budgets
- Sponsored conferences and trips
- Encouraging upskilling that benefits both the person and the company
- Giving people responsibility on projects that actually build the skills they want

Conversations about a career path that leads outside the company can feel awkward, but most individual contributors will move on eventually. The time they spend on your team should leave them better prepared for whatever comes next, not just useful to you while they're there.

## Recognize and reward contributions

Recognition moves morale more than reward does. Public recognition, in front of peers or non-technical stakeholders, carries real weight. And it shouldn't be reserved for good code alone: strong teamwork, going above and beyond, or a genuine effort to improve all deserve the same treatment.

Someone putting in that extra effort is usually a sign they care about the role, and that's worth acknowledging on its own terms.

## Build a positive, inclusive environment

Keep hard conversations honest but inclusive. Transparent communication across the team, regardless of seniority, helps people feel respected and included in decisions that affect them, technical or otherwise. It closes distance between people faster than almost anything else.

Make space for mistakes people can actually learn from, and take feedback seriously when it comes back to you. A team that feels genuinely close-knit is one people want to show up for, not just one they're obligated to.

That's the start of a real culture, not a stated one, and it's usually what separates a good team from a great one.