DEV Community: Jamie Wright

Zed: Pro tips

Jamie Wright — Wed, 05 Aug 2026 08:00:00 +0000

The setup article in this series got you installed, configured and pointed in the right direction. This one assumes you've been living in Zed for a few weeks, the honeymoon speed rush has settled, and you're ready for the features that don't announce themselves. Zed hides its best ideas behind unassuming names, and the biggest one is first.

Multibuffers are the whole point

If you learn one thing from this article, learn this. When you run a project-wide search in Zed, the results don't open as a list you click through. They open as a multibuffer: one editable surface containing every matching excerpt from every file, stitched together. You edit the results directly, right there, across fifty files if that's what matched, with full multi-cursor support, and saving writes every change back to its source file.

Once this clicks, whole categories of work collapse. Renaming something a refactor tool can't reach: search, edit everywhere at once, save. Reviewing every TODO in the codebase: search, and now they're one scrollable document. And the pattern goes beyond search. The diagnostics view is a multibuffer of every error and warning in the project, editable in place, so you can fix a whole linting sweep without opening a single file by hand. The git diff view is a multibuffer of your changes. Zed's bet is that "a set of places across many files" deserves to be a first-class editing surface, and it's the feature the other editors in this series can't follow it on.

Make the pickers do the walking

The file finder and text search both show live previews as you type, so navigation becomes a matter of glancing rather than committing. Learn the symbol layer too: jump to any function or symbol in the file, or search symbols across the whole project, and keep the outline panel open on wide monitors as a live table of contents. The habit shift is the same one Sublime taught a decade ago: the file tree is for orientation. Navigation happens through fuzzy search, and Zed's implementations are quick enough that you stop thinking of files as things you open and start thinking of code as one continuous place you jump around in.

Tasks, and the keymap that makes them yours

Zed has a task system: define your build, test and dev-server commands once in a tasks.json, run them from the command palette, and rerun the last one with a single binding. Wire your test command to a key and the edit-test loop tightens noticeably. While you're in configuration territory, open the keymap (zed: open keymap) and claim the bindings you use most. Zed's keymap is JSON, supports context-specific bindings (a key can do different things in the editor, the terminal and the agent panel), and ships with VS Code-compatible defaults, so you only need to define your deviations. Ten minutes here repays itself for as long as you use the editor.

Collaboration is built in, and nobody notices

Zed contains a real-time collaboration system: channels you can join with colleagues, shared projects, following another person's cursor around a codebase, voice included. No plugin, no screen-share smearing, actual shared editing on the actual code. It's one of the most complete features in the product and comfortably the least used, partly because remote pairing habits calcified around screen-sharing years ago. If you pair regularly, or you onboard people to unfamiliar codebases, try one session of follow-mode walking someone through the code. Screen-sharing an editor feels primitive afterwards. SSH remoting rounds this out: open a project that lives on a server as if it were local, with your local editor, settings and keymap intact.

Drive the AI, don't ride it

The setup article covered switching the AI features on, off, or somewhere in between. The pro layer is precision. Edit predictions can be constrained rather than binary: keep them eager in the languages where they earn their keep, quieter where they don't, and learn the preview-before-accept flow so suggestions become something you glance at rather than obey. In the agent panel, the discipline that separates useful from chaotic is scope: point an agent at a specific, reviewable task, read the diff it produces like you'd read a junior developer's pull request, and use the ability to run parallel agents for genuinely independent jobs rather than as a way to generate merge conflicts at scale. And remember everything lands as ordinary edits: your review tools are the same multibuffers and git views as always, which is precisely why agent output in Zed stays inspectable. The editor's oldest features turn out to be the guardrails for its newest ones.

The meta-tip

Zed ships updates weekly, and features arrive quietly: pickers gain previews, git panels grow new views, settings migrate into friendlier homes. The genuinely pro habit is skimming the release notes each week, thirty seconds, because in an editor moving this fast the tip that changes your workflow might be four days old. The rest of us find out by accident, months later, usually from someone smug. Read the notes. Be the someone smug.

Ultimate web developer setup 2026: Zed

Jamie Wright — Wed, 29 Jul 2026 08:00:00 +0000

Last of three setup guides, after VS Code, the default, and Sublime Text, the survivor. This one is the newcomer, although "newcomer" undersells the lineage: Zed was started by Nathan Sobo, one of the creators of Atom, and it reads like an act of atonement. Atom taught the world that editors built on web technology feel heavy. Zed is what happens when the same people rebuild the idea in Rust, rendering on the GPU, with performance as the founding principle.

The short version of why Zed matters in 2026: it hit 1.0 in April after five years of development, it's free and open source, it runs on macOS, Linux and Windows, and it's the first mainstream editor where AI assistance is part of the architecture rather than an extension wearing a lanyard. Startup is near-instant, keystroke latency is imperceptible, and memory usage is a fraction of an Electron editor's. If VS Code's honesty section (the bit where it's slow) bothered you, this is the article you skipped ahead to.

Install and first run

Download from zed.dev or install via your platform's package manager. First run offers to import your VS Code settings and keybindings, and you should accept: the migration is decent and it removes the main friction of switching. Platform note worth knowing before committing: maturity runs macOS first, Linux close behind, Windows last, with Windows support the newest of the three. It's stable, but the roughest edges live there.

Sign-in is optional. The editor is fully functional without an account; you only need one for the hosted AI features, and you can skip those entirely by bringing your own API keys or running local models. More on that below, because it's the part of the setup with actual decisions in it.

The bit where there's no extensions section

Here's the structural difference from the VS Code article: the extensions list is nearly empty, on purpose. Language servers for TypeScript, JavaScript, CSS, JSON and friends are built in or auto-installed when you open a relevant file. Prettier-style formatting: built in, on by default via the language servers. Git: a native panel with staging, committing, blame and history. Terminal: built in. Vim mode: built in, and one of the better implementations outside Vim itself. The inline-error display you install Error Lens for in VS Code: built in.

Zed does have an extension system, mostly themes and additional language support, and the catalogue is roughly 800 strong against VS Code's tens of thousands. For standard web work you may install nothing at all beyond a theme. That's not a poverty; it's the design. Everything in the hot path is native code, which is where the speed comes from and why the correct instinct here is the opposite of VS Code's: don't look for an extension until you've confirmed the feature isn't already there.

The gap is real at the edges, though. Niche language tooling, database explorers, that one internal extension your company built for VS Code: if your workflow depends on the long tail, check it exists before you move in. This remains the honest reason most developers haven't switched yet.

Settings worth changing

Configuration is JSON (zed: open settings from the command palette), with a settings UI arriving for the common cases. A sensible web-development baseline:

{
  "buffer_font_family": "JetBrains Mono",
  "buffer_font_size": 14,
  "format_on_save": "on",
  "autosave": "on_focus_change",
  "vim_mode": false,
  "inlay_hints": { "enabled": true },
  "git": { "inline_blame": { "enabled": true } }
}

Inlay hints put inferred TypeScript types inline where they're useful; switch them off if you find them noisy. Inline blame is GitLens's headline feature, here as a config flag. Set vim_mode true if that's your religion, and note that Zed also speaks Sublime-style multiple cursors fluently, so the muscle memory from either of this series' other editors transfers.

The AI decisions

This is where Zed's 2026 setup genuinely differs from the other two articles. AI here isn't one assistant; it's a set of choices. Edit Predictions gives Cursor-style inline next-edit suggestions, with a monthly allowance on the free plan and unlimited on the paid tier, which at $10 a month undercuts most rivals. The Agent Panel runs conversational and autonomous coding agents against your codebase, and since 1.0 can run several in parallel. And the part that matters strategically: Zed supports the Agent Client Protocol, an open standard for plugging external agents in, plus bring-your-own-key for the major model providers and local models via Ollama. You are not locked into anyone's model, including Zed's.

The recommended setup, then, is deliberate rather than maximal: switch on Edit Predictions and see whether the suggestions earn their keep in your codebase; wire the Agent Panel to whichever provider your team already pays for; and if you want none of it, there's a single toggle to disable all AI features, which Zed added because enough people asked. An editor that makes abstaining a first-class setting is an editor being unusually honest about the moment we're in.

Where Zed loses

The ecosystem gap, covered above, is the big one. Debugging shipped with 1.0 but is younger than its rivals' offerings. The Windows build trails the other platforms. And the project moves fast, which cuts both ways: fixes land weekly, and occasionally so do regressions.

So the recommendation splits cleanly across this series. Deep extension dependencies or maximum stability: stay with the VS Code article. Pure editing speed with no AI in the building: the Sublime Text one. But if you want the modern feature set, native performance, and AI treated as architecture with an off switch, Zed is the first new editor in a decade that's earned the word ultimate. Atom's creators finally shipped the editor Atom was trying to be. It just took a different language, a different decade, and, apparently, the death of the first attempt.

Ultimate web developer setup 2026: VS Code

Jamie Wright — Wed, 29 Jul 2026 08:00:00 +0000

This is the first of three setup guides, one per editor worth your attention in 2026. The other two cover Sublime Text, the fast one you pay for, and Zed, the new one built by Atom's creators as an apology. We start with VS Code because, statistically, you're already using it.

VS Code won the editor wars years ago, and it won them the boring way: free, cross-platform, good enough at everything, with an extension for anything. Which is exactly why the "ultimate setup" for it in 2026 is not what it was in 2019. Back then the game was addition, stacking extensions until your editor could do everything. VS Code has absorbed so many former must-have extensions into the core product that most setup guides are recommending you install things it already does. The ultimate VS Code setup is a fast one, and fast means minimal.

First, uninstall

Before adding anything, audit what you've accumulated. Open the Extensions panel and be honest. Auto Close Tag and Auto Rename Tag: built in for years (editor.linkedEditing handles the renaming). Bracket pair colourisation: built in, and the native version is dramatically faster than the old extension. Path autocomplete for imports: largely built in via IntelliSense. Every extension you keep runs code in your editor's process, and a bloated VS Code gives away the one advantage it has left over the two faster editors in this series. If you haven't invoked an extension in a month, it's not part of your setup, it's bloat.

The extensions that still earn a place

Six, for a typical front-end or full-stack web workflow:

Prettier , set as your default formatter with format-on-save. Arguing about formatting is a hobby; Prettier is a decision. If your project uses Biome instead, install that and skip Prettier, but pick exactly one.
ESLint , wired to your project config, so problems appear where you're typing rather than in CI twenty minutes later.
Error Lens , which prints errors inline at the end of the offending line instead of hiding them in hover tooltips. The single biggest quality-of-life extension on this list.
GitLens , mainly for line-by-line blame and history. The free tier does everything most people need.
Tailwind CSS IntelliSense , if you use Tailwind. Non-negotiable if so, pointless if not, which is a decent summary of Tailwind generally.
Code Spell Checker , because recieve in a variable name will otherwise outlive your employment.

That's the lot. Notice what's absent: no Live Server (Vite's dev server replaced it in any modern project), no themes-of-the-week, no AI extensions beyond whatever your team has standardised on. Copilot is built into the product now and switched on or off in one place; treat AI assistance as a team decision, not an extension impulse buy.

Settings worth changing

Everything else lives in settings.json. The defaults are sensible; these are the deviations that pay rent:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.linkedEditing": true,
  "editor.stickyScroll.enabled": true,
  "editor.fontFamily": "JetBrains Mono",
  "editor.fontLigatures": true,
  "files.trimTrailingWhitespace": true,
  "explorer.compactFolders": false,
  "workbench.editor.limit.enabled": true,
  "workbench.editor.limit.value": 8
}

Sticky scroll pins the current function's signature to the top of the viewport while you scroll its body, and once you've had it you won't go back. The editor tab limit stops the fifteen-open-tabs situation that everyone claims not to have. JetBrains Mono is free and easier on the eyes across a long day than the default; Fira Code if you prefer your ligatures more stylised.

One structural feature worth adopting in 2026: Profiles. VS Code lets you keep separate named profiles, each with its own extensions and settings, so your writing setup doesn't load your debugging toolchain and vice versa. It's the sanctioned answer to extension sprawl, and almost nobody uses it.

Learn the editor you already have

The ultimate setup is mostly the ultimate user. Four things that repay an afternoon: the command palette (Ctrl/Cmd+Shift+P) for everything you currently hunt through menus for; Ctrl/Cmd+D to select the next occurrence of the current word, which turns most repetitive edits into one fluent motion; Ctrl/Cmd+P to jump to any file by fuzzy name, because the file tree is for orientation, not navigation; and the built-in source control view, which handles staging, committing and conflict resolution well enough that you may not need a separate Git client at all.

Where VS Code loses

Honesty section, because every editor in this series gets one. VS Code is an Electron app, and no amount of tuning changes that. On a big machine you won't care. On a modest laptop, you will feel the weight: slower startup, higher memory, occasional input latency at exactly the moments you're most impatient. The two companion articles in this series exist because of that paragraph. If what you want is the fastest possible pure editing experience and you'll pay for it, that's the Sublime Text article. If you want VS Code's modern feature set rebuilt natively for speed, with AI designed in rather than bolted on, that's the Zed one.

But if you stay, and most of you will, stay deliberately. The default editor deserves better than a default setup, and in 2026 the best VS Code setup is the one carrying the least. Install six things, configure ten lines, learn four shortcuts, and delete the rest. Your editor was never the problem. Your 2019 extension list was.

Ultimate web developer setup 2026: Sublime Text

Jamie Wright — Wed, 29 Jul 2026 08:00:00 +0000

The second of three setup guides. The first covered VS Code, the editor you're statistically already using; the third covers Zed, the new one from Atom's creators. This one covers the editor that outlived every obituary written for it.

Sublime Text should, by all the usual logic, be dead. It costs money in a market where the dominant player is free. Its extension ecosystem is a fraction of VS Code's. It has no built-in AI assistant, no company burning venture capital on it, and no marketing beyond word of mouth. And yet in 2026 it remains the answer to a question a meaningful number of developers still ask: what is the fastest, most reliable way to edit text, full stop? Open a 200MB log file in VS Code and then open it in Sublime, and the licence fee starts explaining itself.

That's the honest positioning. Sublime Text in 2026 is not trying to be your everything. It's a precision tool for people who want the editor to disappear, and the setup below leans into that rather than fighting it.

Buy it, and why that's the point

Sublime Text 4 costs $99 US for a personal licence, which includes three years of updates and works across all your machines and operating systems. You can evaluate it indefinitely with a periodic nag, but buy it if you settle in. Partly because that's fair. Mostly because the business model is the feature: you are the customer, not the engagement metric. No account sign-in, no strategy pivot where your editor becomes a funnel for someone's cloud service. In 2026 that arrangement is rare enough to be worth £80-odd of anyone's money.

Package Control and the short list

Setup starts with Package Control, installed from the command palette (Tools > Install Package Control, then Ctrl/Cmd+Shift+P for everything after). Sublime's ecosystem is smaller than VS Code's, but the web development core is covered by five packages:

LSP , plus the language servers for your stack: LSP-typescript, LSP-css, LSP-json, and LSP-eslint cover most front-end work. This is the package that changed Sublime's fate, bringing the same language servers VS Code uses, so you get real completions, go-to-definition and inline diagnostics without giving up the speed.
Emmet , for expanding abbreviations into HTML and CSS. Sublime is where many people met Emmet; it still belongs here.
Terminus , a terminal inside the editor, for those who've been VS Code-trained to expect one.
A File Icon , purely cosmetic, but the sidebar is easier to scan with file-type icons and there's no performance tax worth mentioning.
SublimeLinter only if your workflow needs linters outside what LSP provides; otherwise let the language servers do it and keep the install lean.

Git needs no package at all for the basics: Sublime Text 4 shows inline diff markers natively, and if you want a full Git client, Sublime Merge is made by the same company, shares the licence philosophy, and is quietly one of the best Git GUIs available on any platform.

Settings worth changing

Preferences are a JSON file, and the deviations that matter are few:

{
  "font_face": "JetBrains Mono",
  "font_size": 13,
  "save_on_focus_lost": true,
  "trim_trailing_white_space_on_save": "all",
  "ensure_newline_at_eof_on_save": true,
  "index_files": true,
  "hardware_acceleration": "opengl"
}

save_on_focus_lost is the sleeper: combined with a dev server watching your files, tabbing across to the browser saves and rebuilds in one motion. Hardware acceleration is worth switching on for high-refresh displays, where Sublime's rendering goes from fast to genuinely luxurious. The Mariana colour scheme and Adaptive theme ship in the box and need no replacement, though the theme community will happily disagree.

The features that are the actual setup

More than either other editor in this series, Sublime's ultimate setup is muscle memory rather than configuration. Three things to drill. Goto Anything (Ctrl/Cmd+P) is fuzzy navigation to any file, and with @ appended, to any symbol within it; Sublime popularised this pattern and its implementation is still the snappiest. Multiple cursors (Ctrl/Cmd+D to take the next occurrence, and mouse or keyboard to place cursors freely) originated here, and using them fluently converts most refactor-shaped drudgery into a single edit performed everywhere at once. And Project switching (Ctrl/Cmd+Alt+P) makes hopping between codebases instant, because the editor starts fast enough that "closing everything" costs nothing.

That last point is the theme. Sublime opens in well under a second, handles files that make Electron editors wheeze, and never asks you to wait for it. The setup above deliberately adds nothing that compromises this, which is why the package list stops at five.

Where Sublime loses

Everything said, the gaps are real and worth naming. There's no built-in AI assistance, and while LSP-copilot exists as a community bridge, anyone whose daily workflow is agent-driven will find Sublime a poor host for it; that workflow belongs in the Zed article, where it's native, or VS Code, where it's official.

Debugging support is thin compared to both rivals. And the ecosystem, while sufficient, is maintained by a small community, so the newest tooling arrives here last, if at all.

Which resolves to a clear recommendation. If your work is agent-assisted and integration-heavy, read the other two articles in this series and pick between them. But if what you value is an editor that opens instantly, handles anything, respects you as a paying customer and then gets out of the way entirely, Sublime remains, fifteen-plus years in, the sharpest knife in the drawer.

Some tools survive every hype cycle by simply being excellent. This is one, and the ultimate setup for it is mostly the restraint to leave it alone.

What I actually use AI for as a PM

Jamie Wright — Mon, 27 Jul 2026 09:00:00 +0000

A lot of people out there are writing about how AI will transform project management. Here's what I actually use it for on a Tuesday (because most of every Monday you're stuck in a meeting).

Meeting notes

I used to spend twenty minutes after every call writing up notes, decisions, and actions. Now I get to 80% in three minutes and spend five cleaning it up. That's time I don't get back in some abstract sense; I actually use it on the next thing.

First drafts of comms

Project updates, stakeholder messages, launch announcements. I write the rough shape of what I want to say, ask AI to expand it, then cut it back down to what I actually want. Faster than starting from a blank page. Slower than I'd like, but faster than before.

Sprint backlog syncing

I have a scheduled task that pulls items from our project boards and surfaces what needs attention. It runs without me. I look at the output.

Documentation (I've been putting off)

The handover doc for a project I've been running in my head. The process write-up that would let someone else run the launch without calling me. These are things that are genuinely important and genuinely easy to deprioritise when you're busy. AI makes them faster to produce, which means I actually produce them.

What AI doesn't do:

Make the judgment calls.
Decide which P0 is really a P0.
Know when a stakeholder's 'yes' will become a 'no by Friday'.
Read the room before a difficult conversation.

The tedious, mechanical parts of the job are getting faster. That's not a threat. It's a gift, if you spend the time it frees up on the parts that actually require you.

AI made me a developer again. Kind of.

Jamie Wright — Mon, 20 Jul 2026 11:08:00 +0000

I spent years moving away from building things with my hands.

Started as a Web Designer / Developer. Moved into hybrid project management. Dropped the code entirely when I became a full-time project manager. That was the right call, and I want to be clear about that before the rest of this article appears to argue with it. No regrets. The move was deliberate, it suited me, and I'd make it again.

...then AI came along and quietly gave the building back.

Vibe-coding (a term I use under protest)

I've been vibe-coding. The term genuinely makes me want to throw up, and I'll be using it anyway, because it's what everyone calls it and inventing a more dignified name would fool nobody.

Let me set the boundaries first, because this is where the sensible version of the story lives. Nothing production-critical. I wasn't building Mews's payment infrastructure in my spare time, and if I ever suggest I should, someone stage an intervention. What I've been building is the other category: small tools, internal apps, things that would have required an engineer's time and now require an afternoon of mine. The page request scoping app I built in Lovable, which regular readers have already heard about. Workflow automations. Scripts that used to live on someone's backlog gathering seniority.

That last group deserves a moment. Every team has them: the small, useful, unglamorous ideas that everyone agrees would help and no engineer can ever justify prioritising, because there's always something production-critical to do instead. That backlog of good-but-never ideas is exactly the territory AI-assisted building opens up. Not the crown jewels. The stuff that was never going to get built at all.

The old mental model is the new advantage

Here's the strange part, and the actual reason I'm writing this. The developer mental model, the one I thought I was leaving behind when I moved into delivery, turns out to be exactly what makes AI-assisted building work well.

Knowing how systems fit together, so the thing you ask for is a thing that can exist. Knowing when an AI-generated output looks wrong or right, which is a skill you only earn by having produced plenty of wrong output yourself, by hand, over years. Knowing what to ask for and how to check whether you got it. And most importantly, knowing how to think about the edge cases that will break it, before it's in production and someone actually hits them. What happens when the input is empty. What happens when two people use it at once. What happens on the date boundary nobody thought about. The AI will cheerfully build you something that works right up until it doesn't, and the difference between a useful tool and a future incident is usually whether anyone asked those questions before shipping.

None of that is coding ability, exactly. I'd struggle to sit down and write from scratch what these tools produce for me. It's something one level up: the accumulated suspicion of someone who has watched software fail in all the traditional ways. That suspicion, it turns out, doesn't expire when you stop writing code. It just sits there, waiting for a reason to be useful again.

Trusting versus verifying

If I had to compress the whole argument into one line, it's this: non-technical people using AI to build things are essentially trusting it. Technical people using AI to build things are verifying it. That's a meaningful difference.

It's not a difference in intelligence or care. Non-technical builders can be diligent, and technical ones can be lazy; I've been both in the same week. It's a difference in what you're able to check. When the tool produces something, one group can read it, poke at its assumptions, test the unhappy path and know where the bodies are usually buried. The other group can only test whether it appears to work, which is a much weaker claim than it sounds, because "appears to work" is the natural state of all software immediately before it embarrasses you.

For throwaway experiments, trusting is fine. For anything a team will quietly come to depend on, and internal tools always end up depended on, the verifying matters. The scoping app looks simple from the outside. The reason I was comfortable putting it in front of my team is that I could check what it was actually doing, not just admire that it did something.

Should every PM do this? No.

I'm not suggesting every PM should pick up vibe-coding, and I'm suspicious of anyone who is. Most of the "everyone must build now" discourse is written by people selling either a tool or a course.

But if you've got a technical background and you've been sitting on the sidelines of the AI tools conversation, it might be worth reconsidering, because the maths has changed twice over. The barrier to building things is lower than it's ever been. And the background you thought you left behind, the one you may have half-mourned when you moved into delivery, might be exactly what makes you good at it. Not despite the years away. The suspicion aged well.

I gave up building things deliberately, and I'd defend that decision to anyone. I just didn't expect the tools to come and find me, hand me back an afternoon-sized version of my old job, and reveal that the most valuable thing I'd kept from it was the doubt.

I built an app to get the knowledge out of my head

Jamie Wright — Tue, 14 Jul 2026 07:00:00 +0000

I was the single point of failure on my own team and I hadn't noticed. Which, I've since realised, is the defining feature of being one. Single points of failure don't feel like failure from the inside. They feel like being useful.

Here's what it looked like. Every time we needed to scope a new page request, someone would ask me. Not because there wasn't a process. There was a process, a perfectly reasonable one, written down and everything. But the logic behind how I broke a request down, what subtasks were needed, what the dependencies were, that lived in my head. Not in a document. Not in a tool. In my head.

And the system quietly organised itself around that fact. If I was on annual leave, things slowed down. If I was at capacity, things queued. The team was capable, genuinely capable, but the knowledge wasn't accessible. They didn't lack ability. They lacked access to a database that happened to be walking around inside my skull and occasionally going to Tenerife.

How to spot one (possibly in the mirror)

The diagnostic signs are easy to list and strangely hard to see when you're the subject:

The queue test. Does work stack up behind one person's availability even though other people could theoretically do it? That's not a workload problem. That's a knowledge problem wearing a workload costume.

The annual leave test. When a specific person is off, does a category of work slow down rather than just their work? Congratulations, you've located the SPOF.

The quick-question test. Count who receives the most "quick question" messages, and what those questions have in common. Mine were all variations on the same theme: how would you break this down? I was fielding them daily and interpreting the volume as evidence of my value. It was actually evidence of a missing system.

That last mistake is the one worth dwelling on, because it's the reason nobody fixes this. Being the person everyone asks feels like job security. It's flattering. It looks, from the inside, like being indispensable. But indispensable and bottleneck are the same fact described in two tones of voice, and the project doesn't care which word you prefer.

Why the process didn't save us

We had a process, so why didn't it help? Because processes capture steps, and the thing my team needed wasn't steps. It was judgement. A process document tells you what to do. It almost never tells you how someone decides. The sequence was written down; the reasoning that turned "vague client request" into "these seven subtasks, in this order, because of these dependencies" was not, because reasoning is exactly the part that's tedious to write down and easy to postpone forever.

That gap, between documented procedure and undocumented judgement, is where most single points of failure live. It's why they survive audits, handover documents and "we should really write this up" conversations. The steps are covered. The thinking isn't.

So I built an app

Nothing particularly complex. I used Lovable, a vibe-coding tool, to build a page request scoping app that captures the decision logic I'd been carrying around for years. You enter the page type, the parameters and the context, and it outputs a structured breakdown of the subtasks required, and why.

That "and why" is doing the heavy lifting. A list of subtasks would have been a checklist, and we already had checklists. The reasoning attached to each one is what turned it from a document into something closer to a colleague.

The first thing someone said when I showed it to the team was, "Oh, so that's how you think about it."

Exactly. That sentence was the actual deliverable. The app is just the container. What the team got wasn't software; it was access to a decision-making pattern that had been privately mine for years without any of us agreeing it should be.

And the honest, slightly uncomfortable footnote: building it took an afternoon. The knowledge had been locked in my head for years, causing queues and slowdowns the whole time, and the eventual cost of fixing it was one afternoon and a vibe-coding tool. The barrier was never effort. It was that I'd misfiled the problem under "how I add value" instead of under "risk".

Liability or asset: pick one

Knowledge in someone's head is a liability. Knowledge in a system is an asset. That's the whole lesson, and it reframes what I now think the PM job actually is. It isn't just to make good decisions. It's to make those decisions scalable, observable and independent of you being in the room. A brilliant decision-maker who has to personally make every decision hasn't built a capability. They've built a dependency with a salary.

If there's something your team regularly comes to you for that lives only in your head, that's worth fixing, and the fix is more available than it's ever been. It doesn't require a team of engineers. It might just require an afternoon and the right AI tool. Start with whatever generates your highest volume of quick questions, because that's your reasoning being requested on a loop, and a loop is just a system nobody's built yet.

So, the question I ended the original version of this with, and the one I'd still ask: what would you build to get the knowledge out of your head? Whatever your answer is, notice how quickly one came to mind. You already know where your bottleneck is. Most of us do. We're just enjoying being flattered by it.

Score 100 on Google PageSpeed Insights

Jamie Wright — Thu, 06 Jun 2019 16:06:00 +0000

Fortunately, Google provides a handy tool called PageSpeed Insight which will measure the performance of a page on both desktop and mobile and generate a report of the findings. The report comes in the form of a performance score, alongside suggestions or “opportunities” on how you could potentially improve it.

Performance scores: Putting them into context

At the top of the report, PageSpeed Insights will present you with an overall score for the page’s performance. Google classifies a score of 0–49 as “slow”, 50–89 as “average” and 90–100 as “good”.

Before you panic, what Google considers to be an “average” score might actually be a “good” score for you; not all websites have the same purpose. A “brochure” website needs to impress and can be forgiven for having extra ‘gloss’, but if your website needs to sell then getting your pages loading as fast as possible should still be your primary focus.

“53% of users abandoned a mobile site if it took more than 3 seconds to load.”

~ According to research by Google

It’s also important to mention that not all the suggestions from the report will be feasible. Significant investment can be required with only minimal reward in terms of score change, but more on that later.

If your page has scored below 80 there will definitely be some worthwhile improvements you can make, but keep in mind how quantifiable the effects of these changes will be to your audience before you dedicate time and money to them.

Analysing the data

After your score is calculated you are then presented with six top-level performance metrics under the title of ‘Lab data’. Let’s run though each of these metrics:

First Contentful Paint This is the time when the first text or image is painted (visible). See screenshot.
First Meaningful Paint Similar to the above but this measures when the main content elements of your page are visible.
Speed Index Speed Index shows how quickly the contents of a page are visibly populated.
First CPU Idle This is the first point in time when the page has loaded enough for you to be able to use inputs / interact with the page.
Time to interactive This is the amount of time it takes for the page to become fully interactive
Max Potential First Input Delay The maximum potential First Input Delay that your users could experience is the duration, in milliseconds, of the longest task.

Assess your opportunities

The next section of the report shows the results of various performance tests. These will pass or fail. All failures are presented to you first, in a list of “opportunities”.

The tests your website has passed then appear in a collapsed list of “passed audits”. There will still be things that you can improve here, but in Google’s eyes they’re not having a significant enough impact on your users to be considered negatives.

Looking at the screenshot below you can see that the test for ‘Eliminating render-blocking resources” has passed but there is still a potential saving to be made.

Score 100

If you want to score 100 then you’re going to need to go through every fail and opportunity systematically. Every performance improvement will have a positive effect, but as I’ve said previously; decide how valuable each opportunity is to your website, and your users.

Page speed audits

Below you can view a real world example of a page speed audit that I collated for an e-commerce client while working for Engage. They came with a Wordpress site and were wanting to improve the site’s performance.

Whilst any references to the client, products, and costs are removed/censored I still believe it’s a resource worth sharing so that you can see a real example of putting scores into perspective and focusing on what you can do in real terms to improve the performance of your website.

Engage Performance review – Page speed audit (example)

15 Visual Studio Code extensions for faster web development

Jamie Wright — Mon, 20 May 2019 23:00:00 +0000

While I usually write about the perfect setup or just reviewing a code editor, I’m changing tack slightly. I’ve pulled together this list of extensions specifically to help you become a faster and more efficient web developer. Cut corners, keep your focus on the things that matter, spend time on the basics and make fewer errors.

This isn’t an exhaustive list of every extension you’ll want or need; it’s better that you search for those specifically related to the language or type of coding that you undertake day to day. There’s not much point me raving about how much the Twig for Craft extension speeds up my development when writing Twig, if you don’t use Twig or the Craft CMS.

You can also scroll to the end if you want some more opinionated extensions for Visual Studio code; this includes options for your choice of font, theme and file icons.

The following extensions I recommend installing have been grouped into relevant sections, as follows:

Enhanced visuals

Guides

Shown in the screenshot above - left. Enhanced version of the indentation guides that are provided by default, they let you see even quicker where nested blocks start and end by actively highlighting based on your cursor position.

Bracket Pair Colorizer 2

Shown in the screenshot above - right. Much like ‘Guides’ above, this makes your code easier to digest with a quick scan by colour coding your brackets either based on their nesting level or all completely independently from each other.

Color highlight

Shown in the screenshot above - left. See the colour behind your hex values and sass variables with a visual highlight.

SVG viewer

Shown in the screenshot above - right. Never leave Visual Studio Code to check an SVG again, with this extension preview an SVG in a new Code tab with a simple right click.

Beautify

Helps to keep your code tidy and consistent (if your whole team is on board then it doesn’t matter who authored the code originally, it should feel like your own).

DotENV

This adds Syntax Highlighting support for Environment (.env) Files.

Automation

Simple time savers through automation.

IntelliSense (SCSS Variables / CSS classes / Paths)

There are many IntelliSense extensions that will help you save time. These 3 adds autocompletion results for SCSS variables, CSS class names and file paths.

Paste and Indent

Such a basic concept and a massive time saver: intelligent indenting which matches the current indent when you’re pasting code.

Auto close tag & Auto rename tag

A double whammy of time savings, these extensions do what they save on the tin: add closing tags automatically and rename them if the tag is updated later on.

Keyboard shortcuts (from: Sublime Text / Atom)

If you’re not using Visual Studio Code right now, maybe knowing that there are extensions available to ease your transition would tempt you over? Add in your current text editors shortcuts and you’d be able to move over without having sink time into retraining your keyboard shortcut muscle memory.

Project setup & code responsibility

So while not everyone will be using version control, I think it’s a safe enough bet to includes the following extensions here:

Git project manager

This lets you open your repositories without having to specifically making a workspace or project for them, grabbing your project list automatically from your sites folder.

GitLens

Another simple time saver; when you’ve have a line of code highlighted, you can now at a glance see exactly who authored it, the commit message and date.

Bonus: Engage setups

After firing a quick message around the team, here are a selection of popular choices to give a try for your colour scheme, font and folder icons (with my personal recommendations top of each list).

Themes

They’re all highly subjective, literally everyone in the office uses a different theme so I’ve selected four of the better suggestions. Although, it’s worth noting that no one was crazy enough to suggest a light colour scheme.

Left: City Lights. Right Synthwave ’84

Left: Laracasts Contrast (part of Rainglow). Right: One Dark Pro

Fonts

File icons

Missing something?

If you think I’ve missed anything, send me a tweet @iamjamie.

5 modern snow effects you can add to your website

Jamie Wright — Wed, 16 Nov 2016 00:00:00 +0000

The future is now: Our top 5 snow effects

I’ve collected my favourite Codepen examples of modern snow effects for the more adventurous amongst you to add to your websites when the time comes (soon!). If you’re lucky enough to have some minions to do your festive bidding, then send this article over to them with your snow-related demands (and please direct any hate mail here).

Let there be snow!

You have lots of options these days. The one below features snow that not only falls from the sky (a pretty essential feature, I know), but it also avoids your cursor!

1. Snow that avoids your cursor

2. 3D snow effect

Next up with have a pretty standard subtle affair with multiple layers to give a pretty depth effect.

3. Snowstorm effect

Distant blurry snow flakes not your thing? Well, you're catered for, too. They come in bright and bold below.

4. Snow that moves with your cursor

How about being able to take control of the wind direction, with your mouse? Yes.

5. Blizzard!

So you've seen a lot of snow now, and maybe you're feeling a little underwhelmed. Lets go big, stick a blizzard on your site; what could go wrong?

It couldn't be more simple

Choose the right snow for you
Add the CSS & JavaScript to your code
???
PROFIT!

CSS animations: Bringing websites to life

Jamie Wright — Thu, 07 Jul 2016 23:00:00 +0000

Well here we favour a combination of CSS animations and JavaScript (usually GSAP) to get the job done and today I’m going to take a look at some live animation examples from some recent projects so you can see how they came together.

Yorkshire Tea

We relished the challenge of incorporating a travelling tea van: the ‘Little Urn’ into their new site. An animation that, after much deliberation, we called a “trundle”. The key part of this was the rotation of the wheels and how they link up with the distance the van moves. Without this all realism is lost, your eyes can’t help but notice if it’s even slightly off.

On the Yorkshire tea site you can see it drive by as your scroll the homepage. It’s fun, the client loved it, and I think it’s all down to the cheeky wheel spin before he shoots off the screen. Triggering it on the site by a scroll event also gives it a bit of a special feel, an interaction which means that it’s not just continually looping endlessly.

MOJO Bar

MOJO came to us last year asking for something special to mark Halloween on their site. It would have been easy to suggest changing the colour scheme to black and (pumpkin) orange, we had bigger ideas.

With a goal of not wanting to creep anyone out too much – We have more than one person in the office that is quite petrified of spiders after all! A spider crawling across their homepage was the only way to go, honest!

It’s the first time (and probably also the last) that I’ve had to detach the legs from a spider (illustration) so that they could be seperately animated to create the creeping effect, alongside a wiggle of the body.

While the legs are CSS only animations, we had to use TweenMax to move the spider along the path he takes across the page.

Beefeater Bar + Block

No one in the world enjoys watching a loader bar go from 0% to 100% but we’ve tried to change that with Beefeater Bar + Block. In this slick animation (consisting of 70 individual frames) you get the chance to learn all those tasty cuts, which will hopefully get users’ mouths watering before the content loads in.

Again, we used TweenMax for enhanced performance as well as giving more control over the timings.

#Beer

When we made our own beer at Engage, we decided that we wanted to animate the bottle when it came to the accompanying website! So we got photos of the bottle from all angles and with a bit of JS; stitched them together so that the mouse can glide over it to initiate a spin!

How many fonts is too many?

Jamie Wright — Fri, 28 Mar 2014 09:00:00 +0000

Great cross browser support for "@font-face" and the rise of online font delivery services like Typekit, fonts.com and Google web fonts has completely transformed the landscape of typography on the web.

You can't use that, it's not a web safe font!

Years ago, this would have been hurled across agency offices and on phone calls to clients frequently. There used to be a limited assortment of fonts that you could use on the web without having to worry about if all your users were going to be able to see the same thing. With the introduction of these now common practice techniques and services, you can literally use any font your heart desires (licence permitting).

As with everything, with this new found typographic freedom, there comes a new responsibility not to abuse these new powers.

So lets slow down…

You might have seen this great new font, and I'll agree it is pretty awesome, but before you just drop it into your next design, sit back and think.

“Is this extra font adding anything to the experience, or am I over complicating things?”

Realistically, there's no reason to use more than three fonts, in any piece of design (not just the web) that's it, no more, sorry.

One for your headings and one for body copy. When you add in bold and italics we're already looking at 4 variants of each, so that's more than enough to play with.

Three's a crowd

While there aren't really any definitive rules, it's best to keep that third font out of the picture and stick to two. Can you really justify introducing another font into the mix for your sub headings? Probably not but sometimes.

Now I'm not going to go away and cry in a corner if you use three, but you should really try to stick to two.

“Just because you can, doesn't mean you should, or that it's ok. Every decision should have a rationale behind it.”

Considerations

While I'm more than happy to admit that if you search google you aren't going to find any specific rule that states you can't use a million different fonts all in a single piece of design, there are many other factors to consider.

With each extra font introduced you need to consider that you're affecting:

Visual hierarchy

Although you can be forgiven for thinking that hierarchy is simply created using different weights and sizes, it can be complex. The crucial thing is contrast.

Even when you're dealing with just a single font in a design, any minor adjustments to, for example, the line height of your paragraphs or the letting spacing in your headlines can dramatically change the balance of the whole thing.

Adding in a different font can completely change the balance and tone of your design. So as with many things it's crucial for you to use your own judgement.

Page weight

Your average font is about 40kb, and that's per weight, then multiply that by 4 for the italic and bold variants I mentioned earlier and we're looking at adding 160kb to your initial page load for each non-system font that you decide to use.

Obviously this isn't set in stone, you might only need a single weight of a font for headlines, but even so, if that font is more of the more complex out there you could be running up to 80kb just for that. Definitely food for thought.

It's also worth mentioning if you're in the process of a website build and you come across a font used so infrequently through the site that the file size of the images needed is less than the size of the font itself then you shouldn't use it at all. Use an image replace technique in your css instead.

DEV Community: Jamie Wright

Zed: Pro tips

Multibuffers are the whole point

Make the pickers do the walking

Tasks, and the keymap that makes them yours

Collaboration is built in, and nobody notices

Drive the AI, don't ride it

The meta-tip

Ultimate web developer setup 2026: Zed

Install and first run

The bit where there's no extensions section

Settings worth changing

The AI decisions

Where Zed loses

Ultimate web developer setup 2026: VS Code

First, uninstall

The extensions that still earn a place

Settings worth changing

Learn the editor you already have

Where VS Code loses

Ultimate web developer setup 2026: Sublime Text

Buy it, and why that's the point

Package Control and the short list

Settings worth changing

The features that are the actual setup

Where Sublime loses

What I actually use AI for as a PM

Meeting notes

First drafts of comms

Sprint backlog syncing

Documentation (I've been putting off)

What AI doesn't do:

AI made me a developer again. Kind of.

Vibe-coding (a term I use under protest)

The old mental model is the new advantage

Trusting versus verifying

Should every PM do this? No.

I built an app to get the knowledge out of my head

How to spot one (possibly in the mirror)

Why the process didn't save us

So I built an app

Liability or asset: pick one

Score 100 on Google PageSpeed Insights

Performance scores: Putting them into context

“53% of users abandoned a mobile site if it took more than 3 seconds to load.”

Analysing the data

Assess your opportunities

We’re here to help

Make sure you know your users

Score 100

Page speed audits

15 Visual Studio Code extensions for faster web development

Enhanced visuals

Automation

IntelliSense (SCSS Variables / CSS classes / Paths)

Auto close tag & Auto rename tag

Keyboard shortcuts (from: Sublime Text / Atom)

Project setup & code responsibility

Bonus: Engage setups

Themes

Fonts

File icons

Missing something?

5 modern snow effects you can add to your website

The future is now: Our top 5 snow effects

Let there be snow!

1. Snow that avoids your cursor

2. 3D snow effect

3. Snowstorm effect

4. Snow that moves with your cursor

5. Blizzard!

It couldn't be more simple

CSS animations: Bringing websites to life

Yorkshire Tea

MOJO Bar

Beefeater Bar + Block

#Beer

How many fonts is too many?

So lets slow down…

Three's a crowd