“Designer” quietly implies someone else builds it. “Developer” quietly implies someone else decided what it should be. Both titles assume a handoff — a moment where the thing leaves one person’s hands and enters another’s. And that handoff is exactly where a lot of the interesting work now falls through.
“Creative technologist” gets mocked for sounding like a title assembled to dodge a decision. I think it’s the opposite. It’s a title that refuses to pretend the two lanes are still separate, because for a growing amount of real work, they aren’t.
The lanes stopped being separate
Consider the background animation on this site’s homepage. You cannot fully judge whether it’s well designed without understanding why it costs nothing when nobody’s interacting with it — that restraint is the design. And you cannot build it well without knowing what it’s supposed to feel like when a cursor drifts close. The design decision and the engineering decision are the same decision, wearing two hats.
Split that across two people and two handoffs, and you reliably get one of two failures: something beautiful and slow, or something fast and forgettable. The single idea that made it both beautiful and nearly free had to live in one head. (The full build is in Building a Cursor-Reactive Particle Field, and the site it lives on is written up as its own case study.)
Three titles, honestly compared
| Designer | Developer | Creative technologist | |
|---|---|---|---|
| Owns | What it should be | How it’s built | The whole distance between the two |
| Quietly assumes | Someone else implements it | Someone else specified it | No one is handing off |
| Common blind spot | Ideas that can’t be built well | Building the wrong thing beautifully | Spreading too thin to master either edge |
| Best when | The problem is mostly taste | The problem is mostly execution | The idea and the build are the same problem |
This isn’t an argument that everyone should work solo, or that specialists stopped mattering — they didn’t, and deep single-discipline mastery is still its own kind of rare. It’s narrower: the title should describe what you’re actually good at, and “good at carrying an idea into implementation without losing it in translation” doesn’t fit cleanly under either half alone.
The real test is the seam, not the résumé
Here’s how to tell if this title genuinely describes you, rather than being two skills stapled together on a CV. It’s not “can you design and code.” Plenty of people can do both adequately and are still, correctly, one or the other.
The test is whether you can feel the seam. Can you tell, unprompted, when a design decision is secretly a performance problem? When a technical constraint is secretly a design opportunity hiding in plain sight? That instinct — living in the gap between the two disciplines — is the thing single-discipline titles don’t think to look for, because it’s nobody’s job to look there. If that’s where you’re most useful, you already are one, whatever your business card says.
How to Proceed
- Look back at your best piece of work. Ask honestly: did its quality come from the idea, the execution, or the fact that one person held both? If it's the third, note that — it's your actual value.
- Next project, catch one moment where a design choice was really a performance decision (or vice versa). Naming one is proof you work in the seam.
- Don't claim the title to avoid depth. If you're a strong specialist, own that — it's rarer and clearer than a vague hybrid.
- Build one thing end to end, alone, with no handoff. It's the only way to find out whether the seam is where you're strongest or where you struggle.
- Describe yourself by the problem you solve, not the tools you hold. "I carry ideas into working things" beats any list of software.