The designs are "done". We've had the walk-throughs. Stakeholders have nodded along through a few rounds of feedback. The UI mocks look convincing enough that everyone can imagine the feature existing already. The mood in the room shifts to: "right, time to get serious and write the tickets".

On paper, you break the mock-ups down into tasks, put estimates on them, slice the work across the team, and press go. In reality, this is where everything starts to wobble. As soon as you try to write actionable tickets - slicing work to build the code paths, data flows, and tackle edge cases - you discover how much you don't yet understand.

Someone points out a pile of forgotten tech debt that has to be moved before anything else can fit. Someone else realises that the new flow contradicts another flow once you see them side by side. A stakeholder changes their mind the moment they imagine clicking through the screens for real. The illusion that the problem is "solved on paper" falls apart the moment you slice that paper into implementation pieces.

I've come to think of these moments, in cycle planning meetings, as the point where the fog becomes visible. Not because the meeting is the problem, but because it's the first moment where the team has to turn a convincing story into executable slices. That translation is still design work. Even with the best intentions in earlier review phases, you don't surface the unknown-unknowns until you try to actually do the thing.

The work is not what happens once that fog has been burned away. The work is moving through it.

The cabinet maker fantasy

Part of why this moment feels so uncomfortable is that it fails to match up with a storyline development teams find reassuring.

If you ask a cabinet maker to build you a piece they've made a hundred times before, they can usually tell you exactly what it will cost and how long it will take. They'll measure the space, pick the timber, do the cut list, and come back with a price. They have patterns, jigs, and muscle memory. They're not discovering a new object; they're repeating a known shape with small variations.

Many organisations instinctively treat software work like this. They want to know what they're going to get and when they're going to get it. They want to be comforted by the idea that someone, somewhere, is in control - that the hard thinking has already been done, the unknowns have been ironed out in discovery, and what remains is the cabinet-making part: skilled, but predictable.

You can see this in many forms:

• Roadmaps that read like delivery schedules.
• Requests for precise estimates before anyone has opened the codebase.
• Contracts that promise exactly which features will ship by which date.
• Agencies charging a premium for fixed scope work, because taking on that level of risk is expensive.

It's an appealing fantasy, and not entirely unreasonable. There are parts of software that do behave more like cabinetry: well-trodden integrations, familiar CRUD, boring but necessary plumbing. But most interesting product work doesn't feel like building the same cabinet over and over. It feels much closer to tackling a novel problem. Hidden complexity is the norm, not the exception.

And the painful bit is that we ask for a cabinet-maker level of certainty in a medium where the plan itself is a large chunk of the work. The line from "the idea" to "the plan" is often wiggly. If you invest huge amounts of energy up front to produce a perfect plan, you pay twice: once in the cost of doing the thinking far away from the code, and again when reality changes and the plan goes stale.

Treating software as repeatable craft is how you end up with everyone being surprised – and potentially annoyed – when the fog rolls back in at ticket‑writing time.

What the fog feels like

The fog of war isn't just the absence of a plan. It's what it feels like to do the plan-shaping work while everyone is pretending the shaping is already finished.

On the surface, things look tidy. The UI mocks tell a coherent story. Stakeholders are confident enough in the direction that they want to talk about timelines. The work is framed as: "how long will it take to build this?"

As soon as you start getting specific, the cracks show:

• New constraints appear the moment you try to map a design to actual data and APIs.
• Edge cases and awkward paths pop up that weren't obvious in a linear Figma prototype.
• Performance, accessibility, and interaction details start to matter once you imagine a real user actually clicking around.

If you're working on something strictly technical the pattern is the same. On a whiteboard, the refactor or new module looks straightforward: extract this, rename that, shuffle a couple of responsibilities. Once you take one webpage or one package and actually try the change, you realise how entangled things are, or that a concept you thought was cleanly defined isn't clean at all.

None of this means the design work was bad or that people weren't paying attention. It's just that you learn about the problem by working on it. Implementation is one of the main ways a team deepens its understanding. If you somehow knew, up front, every change that would be required in the codebase to make a solution real, you've already done most of the work in your head.

In a healthy team, you're not really assigning people to "build this solution". You're assigning them to a problem and a goal, with permission - implicit or explicit - to reshape the solution as they learn. The work naturally swings between discovery, refinement, and execution: talking to users, adjusting the concept or scope, changing the software itself, often in the same week.

The fog is simply what it feels like to be inside that loop.

Treating unknowns as first‑class work

One of the most useful shifts I've seen in culture and process is to stop treating unknowns as a sign of failure and start treating them as work.

Instead of asking "why didn't we catch this earlier?", you name the unknowns explicitly:

• What problem are we actually solving for this user?
• What happens if they try to do X that isn't in the happy path?
• What hidden technical constraints might shape what "good enough" looks like?

You put those questions on the table as things to be tackled, not as embarrassments to be swept away. In practice, that can look like:

• Framing work as "here's the problem space and direction; go explore and shape a solution", rather than "this design is final; estimate and implement it".
• Picking a time appetite first, then shaping scope to fit it (instead of treating scope as sacred because it was written down early).
• Time‑boxing learning on the riskiest unknowns, and only then committing to the long tail of implementation.
• Keeping tickets honest: some are for shipping, some are for finding clarity.

{/* If you want the practical version of this, I've written a follow-up: Making Plans for Unknowns. */}

I'm working on a companion piece for this article with more actionable details. If you want to catch it when it lands, subscribe to my RSS feed.

If you don't accept the fog, you often end up pouring huge amounts of energy into ever more elaborate planning phases, just so you can feel confident about perfectly executing the implementation. You have planning meetings, then end up with pre-planning meetings, then pre-pre-planning meetings. Developers spend more time scratching their heads to find convincing answers than building things to learn from.

Embracing the fog feels risky

None of this lands easily in organisations that are used to certainty.

Stakeholders and leaders quite reasonably want to reduce risk. They want to be able to tell customers and partners when something will ship and what they'll get. They want to believe that someone has already walked the battlefield and marked out all the traps. It's not surprising that classic waterfall and big‑up‑front design were attractive for so long: they promise that, with enough analysis, the fog can be banished before anyone writes a line of code.

Agile, at its best, is an honest admission that this isn't how development work behaves. You can only really see the next handful of moves clearly. You need to ship, learn, and adjust.

It's uncomfortable to say "we don't know yet" in cultures that idolise decisiveness. Senior people are used to being the ones with answers. Admitting that you're working in a fog can feel like losing authority. It's also hard to put on a dashboard. Velocity and throughput are easy to count; clarity gained and bad ideas discarded are not.

From the developer's side, there's a different kind of discomfort. Being honest about uncertainty can make you feel like you're letting people down. If you treat every estimate as a promise, then every burst of hidden complexity becomes a kind of personal failure. You start to dread the wiggly path.

The alternative is not to shrug and stop caring about dates. It's to be more precise about what you can and can't promise.

You can promise that you'll use the time well. That you'll surface unknowns early, rather than hiding them. That you'll keep something working and demo-able so people can feel the thing, not just look at pictures of it. That you'll make good-faith trade-offs between scope, quality, and time, instead of pretending all three are fixed.

You cannot honestly promise that you'll build exactly the picture in the design file, on exactly the date in the roadmap, without learning anything that might change your mind.

Naming the fog, doing the work

The more I work, the more I think the healthiest teams are the ones that are willing to say, out loud, "we're in the fog right now".

They don't treat that as a shameful confession. They treat it as a status update. They write down the questions they need to answer. They use tickets and spikes and prototypes as tools for learning, not just delivery. They measure success not only by features shipped, but by how much clearer the landscape looks than it did a week ago.

The work is in the fog of war, not in typing out a foregone conclusion. The sooner you name that, the less time you'll spend pretending to be a cabinet maker when you're really trying to chart a path through unfamiliar ground.

Over the years my personal website has taken many forms: a slapped-together portfolio to sell myself to an employer ahead of an interview; a random domain where I could anonymously post angsty poetry; and the beginnings of a blog, with the intention of regularly publishing thoughtful, provocative long-form writing. These ideas started with good intentions, but for reasons like a lack of time or motivation - or a desire for perfection - they ended up fading into nothingness.

Now I feel I've reached a critical mass in terms of confidence in sharing what I have to say, while keeping a light-hearted attitude towards a weird, imperfect work in progress.

I'm focused on carving out my own corner of the small web, and I'm more willing to throw things out and see what sticks. There is still some tension in deciding where my time goes: building the software versus writing and publishing, and aiming for something that is good enough for now rather than endlessly polishing. But I hope this website continues to grow and change over the long run.

Settling back home

For the first half of 2025 I was anticipating a move to San Francisco. The year began with the majority of my life packed up in preparation. Days turned into weeks, and weeks into months, waiting for the immigration office to issue my visa. My home was primed for hibernation and the act of making future plans was on hold; any day the word would come and my boxes and I would be off to occupy a new space.

Unfortunately the current administration seemed happy to ghost this white guy in tech, and that plan was scarpered. I was left stuck in place, with few plans and little direction. I responded like any normal person would… I took custody of my mate’s camper van and went off-grid for a few months to explore more of my country, ticking off the Edinburgh Fringe and Scafell Pike from the bucket list.

But now I am back at home. Having unpacked those boxes, I get to put some focus into making the place more homely and optimising it for comfort. For example, I've upgraded my home automations… now the colour temperature of the light bulbs follows the position of the sun! ;p

And I get to engage and explore once more with my home town… I'm currently on the lookout for this year's uncomfortable-creative-challenge, by finding an improv class.

Intentional consumption

I've accumulated a long backlog of stuff that I want to read, watch, or listen to. Yet I keep ending up back on algorithmic feeds. I've got a read-it-later list, notes on books I have an appetite for, and scattered reminders of recommendations I've been given. Intentional nourishment awaits - and yet, I dwell on my YouTube recommendations and Reddit feed. Why? Because it's easy: a quick route to juicing those neurons.

I miss the days when I'd fire up Google Reader and peruse a set of sources a past self had deemed worthwhile. It was curated by design: you chose what to subscribe to, and pruning the list - changing your mind and clicking unsubscribe - was part of the ritual. I miss the sensation of a slower, more deliberate mode.

I'm trying to make that curated approach as easy and frictionless as the commercial feeds. Transitioning back to using RSS is part of that. I've recently jailbroken my old Kindle, and now have the means to sync various content streams auto-magically onto this dedicated device. I'm working on ironing out the process of syncing my highlights and notes into my second brain.

Finding work

I have been out of full time employment for around 6 months now. Ever since the age of 13, I've basically always had some form of regular work and income - so this chapter has been pretty novel. I've tied myself over by doing a stint of contracting, as well as picking up some odd jobs for my existing freelance clients. However, now I must get serious about picking the next path in my career.

I'm toying with the idea of being my own boss. I found a couple of interesting people with some business and product ideas. We dabbled with the early stages of starting them up, but each one fizzled out because their commitment and intensity didn't match my own. I'm curious about finding a co-founder; committing myself to being a solo-entrepreneur sounds too risky.

I'm wondering if I can return to my freelance roots. I've put together an idea of trading under a new moniker of Friendly Computer. I have some strong views about how to effectively design, build and test new product ideas.

I think a likely outcome is that I will join a new company. I have started the hunt for a software development role that suits my skillset, as well as a team that share my beliefs and attitude towards organisation and collaboratively building stuff.

Please reach out if you have any leads!

Fixing the consistency and redundancy of my data

A few months ago I lost a laptop and, with it, some data - most notably, a chunk of my font collection. I did have a continuous backup system in place; however, I hadn’t included that directory in the source set. I was able to piece together most of the library - finding email receipts to re-download, and spelunking the backed up downloads folder - but the process was messy and arduous. The end result was losing some important files, and an inability to completely itemise what was lost. It was stressful and heartbreaking.

It left me with a new belief: I should live in a continuous state where any of my computers could spontaneously explode and I could simply grab another and continue where I left off. However, it quickly became clear that fulfilling a dream of perfectly backed up and accessible data would require me to pay back the debt of years of poor organisational habits.

Over time, my data had sprawled across machines and tools, with no clear rule for what to keep, what to delete, or where a new file should go in the moment. I'm glad to say I have nearly reached my data consistency, redundancy and accessibility nirvana over the last month by standardising on a repeatable setup (snapshots, off-site backups, and sync) and forcing myself to swap between machines to prove it works. It’s been a big project, but I'm already starting to see the system hold together as I enter the final stretch. My aim is to share notes on what I’ve learned, along with open sourcing the two utilities I’ve written.

Often, as a candidate, you’re dropped into a one‑hour call with someone you’ve never met, asked to summon stories about your past, and hoping to leave a strong enough impression that a group of strangers are willing to bet on you. On the hiring side, you’re also improvising: trying to build a picture of someone’s judgement, temperament, and craft from a handful of highly unusual hours.

I’ve been on both sides of this – designing hiring loops and sitting inside other people’s. Most of the teams I speak to are sincere when they say they want their process to “show what it’s really like to work here”. It’s a good instinct: candidates want to know what they’re signing up for, and teams want to see how someone works in the job's real environment.

But the experience often feels like classic interview theatre. And theatre isn’t a particularly good way to assess the things most teams care about: judgement, collaboration, craft, and the ability to make sense of messy problems over time.

So here’s the question I want to write about: if the job mostly happens through documents, tickets, and pull requests, why is it so common that hiring doesn’t look like that?

What would it mean to treat hiring as a facsimile of real work – a better simulation of what working life will be like together?

Why interviews feel nothing like the job

A fairly standard process goes something like this: a recruiter screen, a quick call with somebody senior, and then two or three one‑hour calls with different people from the team. Each call is a fresh performance: you start again with your story and try to calibrate your answers to a new person’s concerns and style. You share no context beyond a job description and a LinkedIn profile.

The questions tend to have a familiar flavour:

“Can you tell me about a time when you…?” “What’s your greatest strength… your biggest weakness… a moment you demonstrated…?”

These prompts come from a well‑intentioned place. The science says that past behaviour is the best predictor of future behaviour, so you ask people to replay their greatest hits. In practice, you’re asking them to do two conflicting things at once: recall specific situations from the past and, at the same time, narrate them in a way that reveals beliefs and thought processes. It’s cognitively heavy, especially under time pressure with strangers watching.

It also rewards a particular kind of person: someone who is good at telling neat stories about messy events. Someone who can sell you a pen – rather than the person who can design it, manufacture it, ship it, and keep it working.

For some roles and some cultures, that’s fine. If the work is mostly live meetings, quick alignment, and “talk it through on a call”, then a call‑heavy process is at least directionally aligned.

But for teams that deliberately choose async rhythms – who value preparation, written communication, clear handoffs and time to think – it’s an odd way to evaluate fit. You spend your actual working life reading documents, leaving comments, and thinking in the shower about a paragraph in a spec, but your hiring loop is dominated by live improvisation.

What work actually looks like in an async team

If I zoom out on a typical week in a remote, async product team, the rhythms look very different from a string of one‑off calls.

You see colleagues pruning the backlog and rewriting tickets so they actually make sense. You see engineers reading a PRD for a sizeable change, not quite getting it, asking a few questions, and later having an “oh, of course” moment while taking a walk. You see code reviews where someone admits they’re confused and turns that confusion into a learning experience for both sides.

Most of somebody’s personality and value shows up in their async writing persona: Slack messages with enough context that you don’t have to ask “wait, what are we talking about?”, comments that show curiosity and care rather than drive‑by criticism, and pull requests that tell a clear story instead of dumping a diff on your lap.

The work is less about one‑off performances and more about some recurring patterns:

• Continual collaboration on shared context. Over time, you build a mental map together and share trajectory.
• Time to sit with problems. People do their best thinking when they can come back to something twice: read, react, sleep, revise.
• Temperament that emerges in low-stakes moments. Enthusiasm, care, humility, patience, generosity - the little interactions that fill the week.

If this is what working life actually feels like, then a hiring process made entirely of isolated, high‑pressure calls is not a good proxy.

Simulating situations for real collaboration

Once you start from the reality of the work, a principle suggests itself:

If the job is mostly async collaboration, …the hiring process should contain async collaboration.

Instead of treating interviews as a chance to rapidly psychoanalyse someone, you can treat them as a small shared project. Rather than simply grilling a candidate with clever questions, you simulate working together on something that looks and feels like the real problems.

That might mean sending a realistic PRD in advance and asking for comments. It might mean having a discovery‑style call where confusion is welcome, then giving both sides time apart to think and write, then coming back together to make decisions. It might mean having two people from the team on the call so that feedback reflects a team perspective, not just one person’s vibe.

Real work tends to move in cycles of explore together → think alone → come back together. A good hiring loop borrows that rhythm. It’s less about squeezing truth out of an hour‑long interrogation and more about noticing how it feels to move through a few small loops with someone: reading, commenting, discussing, following up.

Designing the details is hard, but the principle is simple.

The risks behind hiring anxiety

Part of the reason I think we cling so tightly to traditional interviews is that hiring is genuinely risky.

There are a few different risks tangled up together:

• A false positive: you hire the wrong person – someone who quietly corrodes the culture, or simply can’t do the work at the level you need.
• A false negative: you miss someone who would have been wonderful to work with because they were nervous, tired, or just not very good at the peculiar game of interviewing.
• A time and energy cost: you don’t want to waste candidates’ time (or your own), so you compress everything into a small number of calls and hope you can extract enough signal quickly.

Most processes try to manage these risks by packing as much psychological signal as possible into a small number of calls. We search for clever, abstract questions that promise to reveal hidden truths. We watch for tiny “red flags” in how someone tells a story, or how fast they answer, and treat those as decisive.

The problem is that this pushes everyone into performance mode. Candidates tell the neatest stories they can. Interviewers over‑index on first impressions. Quiet, thoughtful people who do their best work in writing get compressed into an hour of speaking and are judged on how that felt.

Traditional character questions and gut checks are not inherently bad. There is still something to be said for first impressions and storytelling (Life’s a Pitch spells this out). The issue is loading those interactions with the entire burden of assessing fit, as if a handful of hours could ever tell you everything about what it will be like to share a mission, backlog, and codebase with someone for years.

What this looks like in practice

Take‑home exercises and code samples are one attempt to make hiring more work‑shaped. Even when they’re imperfect, they do at least create shared context: you both arrive with something concrete to look at, discuss, and respond to.

But shared context isn’t the same thing as collaboration. The thing I’m reaching for is real work: a problem over time that gives both sides a chance to show their best.

Here’s one abstract shape of a loop I like:

• A small artefact, sent ahead of time. A short PRD, a bug report with logs, an architectural decision that needs revisiting.
• Async comments first. “Leave notes in the doc as if you were on the team.”
• A call that welcomes confusion. The goal isn’t to defend an answer; it’s to explore the problem together.
• A short written follow‑up. “Write down what you think we should do, and what you’re still unsure about.”

I'm working on a follow-up about the specific techniques I've used when building hiring loops. If you want to catch it when it lands, subscribe to my RSS feed.

None of this needs to be long. Out of courtesy you should make sure to share at least a little feedback with candidates on what you noticed at each step.

Many teams already include touch-points like this in their process. The key is to weave a number of these exercises into your loop as a coherent arc, and design them to reflect the collaboration qualities you actually value.

Make space for arcs of behaviour

The alternative I see is not to pretend first impressions don’t matter, or to delete interviews entirely. It is to demote them from the whole story to one part of the picture, and to put more weight on short arcs of behaviour that resemble the actual job.

Instead of deciding everything based on a few intense hours, you notice how someone shows up across a few small, work‑like interactions. How they engage with a shared document asynchronously. How they handle ambiguity and confusion in a discovery‑style conversation. How they write up decisions and respond to open questions.

You still pay attention to the feeling of the calls – how it is to talk to this person, whether they listen, whether there is basic ease. However you get to observe those signals in a number of contexts, rather than a single style of performance.

A hiring loop cannot perfectly replicate the job. No process can remove all the uncertainty; probation and real work together are still where you learn the most. But it can be a much better facsimile for what working life will be like together.

Build your hiring process around the collaboration you actually value, and you won’t have to rely on exchanging stories to picture what working together might be like — you can just see it.

You’d see it in the footer and on 500 pages — “contact the webmaster” — a single person you could email about everything that happened between what the site was meant to achieve and whatever actually showed up on your CRT.

Somewhere along the way, we stopped saying it. The label faded as the web professionalised and platformed itself into something bigger than a handful of hand‑edited pages.

But I’m seeing the shape again: in people who can hold taste and implementation together. And in those who choose to take responsibility for their own corners.

Maybe webmasters are coming back.

When Nobody Else Knew How to Use the Web

The job was part sysadmin, part content editor, part designer, part miscellaneous web wizard. One person would keep the server alive, configure Apache, juggle FTP credentials, and hand‑edit a pile of .html files full of inline styles and hard‑coded layout.

They weren’t just keeping pages online. They chose how content was consumed — type, colour, layout — then made it real, wielding nested tables as their weapon.

The early web I remember was rough, chunky, and static: browser‑default fonts, hard‑edged form elements, table borders everywhere, the familiar “under construction” GIF. I’d wait on dial‑up to see pages load in IE6, then put in the effort to decode whatever clunky layout appeared.

For a while, the challenge was making the table cells line up — and hoping it worked in Netscape. Then CSS showed up: the web got more expressive. Perhaps that was the moment the webmaster’s grip started to slip. Remember the Space Jam website? It’s become a signifier for that era — we look at it now and laugh, but it’s a useful reminder that early “web design” mostly meant squeezing something — anything — onto a glowing rectangle with rudimentary tools.

Expectations were low, because the medium was new. Simply having a site online felt like an achievement. And the webmaster wasn’t just “implementing the design”. They were the person holding the whole thing — content, layout, aesthetics, accessibility, compatibility, and keeping the servers humming along.

To date myself, I joke that I’ve been “designing since IE7”. My first website was built with the Lycos page builder, proudly attached to an edgy teenage‑angst .tk domain. Around the same time, my dad’s mate handed me one of his PHP books and warned me not to order too many pizzas or start listening to Metallica.

From the perspective of that teenage boy — sat at a Windows XP computer, peering through the browser window — the webmaster was the mysterious being who seemed to know how the whole contraption stayed alive.

Absorbed by Web Apps and Roles

As the web matured, people wanted to do things online — and they wanted those experiences to feel intuitive, delightful, beautiful, blazing fast, secure, and reliable.

We didn’t just add a few features. Desktop tasks moved into the browser: spreadsheets for balancing the books, documents for collaborating, workflows that used to live in client apps. We turned websites into applications: front‑ends and databases, APIs and background jobs. Multi‑tenant SaaS deployments that require monitoring, scaling and reliability. The surface area exploded inline with the expectations.

The webmaster didn’t vanish because the role was trivial or misguided; it was gobbled up by the requirements of building and operating modern web software. One person could no longer reasonably understand a business domain, design rich new flows, keep servers healthy, and ship features at a competitive pace.

The old caretaker of a handful of pages suddenly found themselves in a new, foreign world of machines and tools they were never quite designed to tend.

So we pulled the role apart and turned it into an ecosystem: designers, engineers, product people, researchers, architects. We industrialised the path from idea → interface → implementation into something that looked clean on a gantt chart.

1. Product people decide what users do.
2. Designers make tidy mock‑ups of what users see.
3. Engineers work through tasks to make the picture real.

There’s a comforting clarity there. Phases are bound by role. Inputs and outputs are obvious. You can grade and track work.

But building good software that follows the grain of the medium doesn’t actually work like that. The moment a team tries to make something feel good — not just functionally correct — you loop. You learn things only once code is running. You adjust the design based on what’s possible, what’s legible, what’s accessible, what’s viable inside the business.

And you rewrite the implementation because building the thing changes what “desirable” even means. You learn; the target moves.

And we spent a couple of decades telling ourselves that ecosystem could still be sliced neatly between modes of “designing” and “engineering”.

Absorbed by Silos

The story isn’t just about how the web gets built; it’s also about where web life happens, and who owns the walls around it.

In the earlier days, the web was decentralised by default. People ran their own weird little websites on shared hosting, university servers, GeoCities, or a box under your desk. Each site was its own small artefact: somebody’s taste, ability, and curiosity frozen into HTML.

As platforms grew, more of everyday web life moved into central silos. Instead of tending a personal site, you posted into feeds. Having a presence on the web shifted from owning a corner to being a guest in somebody else’s product.

That made sense for a lot of people. It was easier than wrangling FTP, DNS, and CSS. But it also commoditised the experience of the web — and, over time, many of those platforms have “enshittified” the deal: more ads, more tracking, more engagement hacks, and less control.

In response, there’s been a growing counter‑movement — the IndieWeb, the “small web”, people once again hosting their own blogs and strange little sites.

That current reopens a question the webmaster once answered: who takes responsibility for having enough of the skills, taste, and patience to build and look after these individual corners of the web?

The Webmasters Among Us

Today, the web is in a strange place: both easier and harder to wrangle.

Easier, because mature frameworks, design systems, and hosting let a single person ship something robust without reinventing everything. Harder, because expectations are higher and the constraints are more vast and detailed — the web platform has grown a whole new set of APIs and capabilities.

Even in teams composed of heavily specialised minds, job titles and responsibilities are messy. People bleed over the edges of their boxes all the time, and the reality is usually a spectrum of overlap rather than tidy, isolated roles.

This is why I think High Dynamic Range Developers matter. By “HDR Dev”, I mean people with a wide field of interest and appetite for tackling awkward problems — people who can move between user needs, interface decisions, data, and delivery without panicking.

Within that definition, I see the “Design Engineer”: a web‑native subtype of the HDR Dev who treats the browser as their canvas.

• They hold a high bar and strong taste for the final experience, not just whether it “works”.
• They can empathise with users, and fold that empathy into flows, copy, and constraints.
• They can build real, running software quickly — not just mock‑ups.

A designer who can code. A coder who can design.

If the original Webmaster was a generalist out of necessity, the Design Engineer is a generalist on purpose — a deliberate, modern answer to the same question: can one person hold enough of the problem, the medium, and the stack to move things forward?

Why the Resurgence Matters Now

The resurgence of the webmaster isn’t just nostalgia. It sits at the intersection of a few currents:

• Teams are slowly warming to broader roles — “full‑stack” became normal; “design engineer” is following, for certain kinds of work.
• More people are valuing work that lives on its own sites again, and gravitating towards smaller, personal corners of the web.
• The tooling is better than it has ever been, which makes it realistic for one person to hold more of the arc from idea to production.

There are still limits. In teams building vast products — with complex domains and acute functionality — quality can become patchy if you spread design and product thinking thinly and nobody tends the overall coherence of the experience. A design engineer in the middle doesn’t replace deep specialists; some organisations genuinely need whole careers of research or security or infrastructure.

Even so, I think the direction of travel is clear. More roles will quietly ask for webmaster‑shaped skills, even if they hide behind other titles. The web isn’t going away any time soon — and as more of our lives happen inside it, the craft of building and tending small, vibrant corners of it matters more, not less.

An Invitation to the Webmasters in Hiding

If any of this resonates, you might already be a webmaster in hiding.

Maybe you’re a designer who can’t help but tinker with code, or an engineer who sketches flows, writes copy, and worries about how users respond to an onboarding email. Maybe you’ve been told, explicitly or implicitly, to pick a lane.

I know I’m romanticising the term “webmaster” a little. It’s a functional label — “who looks after this site?”. One of the many Tim Berners‑Lee’s little offerings to the world wide web. “Design engineer” is one of the labels that fits this shape today, and I like it, but I still have a soft spot for “developer” in its truest sense: someone who develops ideas into outcomes — messy, uncertain, human outcomes.

For me, arguing for the resurgence of the webmaster is mostly about permission. Permission to stop apologising for not fitting cleanly into “designer” or “developer” boxes. Permission to treat the web as a full‑stack medium to be designed for, not just a deployment target. And permission to be proud of having lots of quills for your bow, because someone still has to hold the whole thing in their head.

Calling myself a webmaster makes me feel quietly powerful, in all honesty. It probably doesn’t make sense for that title to show up on my LinkedIn, but it fits perfectly on my own weird little corner of the web — ideally while I eat pizza and listen to Metallica.