There’s a version of a developer’s job that looks like this: get a ticket, write the code, close the ticket. Repeat.
And honestly? For a long time, that felt like enough. You built the thing. It works. Ship it.
But the deeper I’ve gotten into development, the more I’ve had to confront something uncomfortable.
In projects where “it works” wasn’t the same as “it’s working for people,” I realized the code was never really the job.
The experience was.
Explore: 10 Things People Get Wrong About My Developer Job
The Story That Changed How I Think About This
A while back, I was working in-house on a project that came with a clear, reasonable objective to eliminate the manual audits that were choking the content team’s ability to scale.
The setup was this: we had a CMS (WordPress) pulling in data points that lived in BI platforms like Looker and Tableau.
Every time that data needed updating, someone had to go in manually, find the value, and replace it across dozens of articles.
It was tedious, it didn’t scale, and it was the kind of silent productivity drain that never shows up in a sprint retro but absolutely shows up in people’s energy levels.
The solution I architected was a tokenization system—a custom API middleware that served dynamic tokens to WordPress, replacing static values with real-time data pulled directly from the BI platforms.
No more manual audits. The data stays current automatically. Problem solved, right?
Not quite 😬
Here’s what happened next, and this is the part I want you to really sit with.
The “Aha” Moment
The tokenization system worked. Technically, it was sound.
But once it was ready, I did something that nobody asked me to do, and that wasn’t on any project plan: I put myself through the flow of the internal user staging the content.
Not as an engineer who built the thing and knew exactly how every piece connected.
I tried to strip away my familiarity and move through the experience the way a content editor would. As someone who stages articles in WordPress, doesn’t consume APIs for fun, and now has a growing list of tokens to reference and replace by hand.
What I found stopped me cold.
The number of tokens was already significant, and it was only going to grow as more data initiatives came online.
To use the system, a content editor would need to:
- Reference a custom API endpoint to look up available tokens
- Manually identify the right ones
- Replace values in the editor
For someone without a technical background, which was exactly the profile of the people who’d be using this day to day, this new system wasn’t just unfamiliar. It was a friction point waiting to become a wall.
I had solved the original problem. But in doing so, I’d quietly handed off the complexity to the user.
The Solution Nobody Asked For
So I kept going. Without anyone requesting it, without a ticket, without a deadline, I built two additional things:
- A custom WordPress dashboard that served as a centralized hub for tokens, their real-time values, and their usage across articles.
- A custom autocomplete dropdown inside the WP editor itself that surfaced token options with their live values as you typed.
The reaction from the team? First, “oh, cool.” Then, after a few days, thank yous.
That’s the moment I realized: the best code is the kind that makes someone else’s day easier without them even asking.
The Visible 20% vs. The Real Job
Most people picture development as the visible 20%: writing code, shipping features, and fixing bugs.
That part is real. It matters, and it takes skill.
But the part that determines whether what you build works for people lives in everything before the first line of code and everything after the last deploy.
And a lot of us, especially early on, never get taught that part.
We get taught to code.
We don’t always get taught to think in experiences.
Step 1: Diagnose the Friction, Not Just the Bug
See, the thing about pain points is that the one you can see is rarely the only one.
When the request came in to solve the manual audit problem, that was the stated pain point. It was real, it was measurable, and solving it was the right call.
But the stated pain point was a symptom of a larger experience problem: content editors were being asked to operate in a technical system that wasn’t designed with their workflow in mind.
This is the most important skill you can develop, and it has nothing to do with syntax or frameworks.
It’s the ability to read a user journey and identify where the friction actually lives—not just where the ticket says it lives.
And it belongs to every role on a technical team, not just the ones with “design” in the title.
The friction isn’t always obvious:
- Sometimes it’s performance: a page that loads slowly enough to erode trust.
- Other times it’s cognitive overload—too many options, not enough hierarchy.
Or, what I ran into: a technically correct system that quietly transferred complexity onto the person least equipped to handle it.
To find it, you have to do something that feels almost too simple to be worth saying: you have to go through the experience yourself.
Not as the person who built it, but as the person who has to use it.
Tip 💁♀️
Try what UX researchers call an “empathy walk” by moving through your own feature as if you’ve never seen it before. Better yet, watch someone else use it without coaching them. The places they pause, backtrack, or go quiet? Those are your friction points.
This isn’t about being a UX designer. It’s about being a developer who cares whether the thing they built actually works in the wild.
As a developer, if you’re not focused on the user’s needs, you are more likely to choose the option that keeps your code looking pretty or the easier option to develop. That’s the trap.
Clean code that creates messy experiences is still a mess.
Step 2: Map the Journey Into Components
Once you’ve found the friction, the next move isn’t to jump to a solution. It’s to break the experience down into its parts and understand where, specifically, the breakdown happens.
Think of the user journey like a chain.
Friction anywhere in the chain affects the whole experience, but the fix depends entirely on which link is weak and why.
In my tokenization project, I could have stopped at “the content editor needs to reference an API endpoint, which is inconvenient.” But that framing would have led me to a surface fix (i.e., maybe a better-formatted doc, a Slack message with the endpoint link).
The chain would still be broken because the experience had no interface layer built for the human doing the work.
The system was built for data flow. The person was an afterthought. That’s a different problem, and it requires a different solution.
You don’t have to run a formal UX exercise to use this kind of thinking. You just have to ask a few honest questions before you design your solution:
- Who is actually using this, and what’s their technical comfort level?
- What does their day look like before and after they interact with my feature?
- What do they have to know, do, or remember that they didn’t have to before?
- Where does my solution introduce new complexity, even if it removes old complexity?
That last question is the one most developers skip. And it’s the one that would have caught my tokenization problem before it shipped.
Note 👇
This kind of thinking applies equally whether your user is a customer on a public-facing product, an internal team member using a tool you built, or a developer consuming an API you designed. The user is always a person. The experience is always worth examining.
The Corporate Reality (And Why You Do It Anyway)
I want to be honest about something, because pretending this is easy would be doing you a disservice.
When I flagged the potential experience friction during the architecture phase of the tokenization project, it wasn’t treated as a priority.
And I get it. That’s corporate reality.
There are pressing objectives, deadlines, and a hundred things competing for attention, and “the content editor’s workflow when this scales” is not going to win that fight against “ship the thing that solves the immediate problem.”
What I knew, though, was that the issue would surface eventually.
Not as a dramatic failure, but as the slow, grinding kind where scaling initiatives start to stall because the foundation has a crack in it that nobody addressed.
Months down the line, when data initiatives intensified and the token library grew, the friction I foresaw would become impossible to ignore.
So I built the dashboard and the autocomplete anyway. Not because I was asked to, but because I could see where the road led, and I could smooth it now when it was still cheap to do so.
This is the part of development that doesn’t show up in a job description but shows up in every great developer you’ve ever admired: the willingness to see past the ticket and into the experience.
Not to go rogue or scope-creep for sport, but because you understand that what you ship lives in the world, and it affects real people, and you have the leverage to make it better right now.
Why This Matters More Right Now
AI tools can generate code. Fast, often clean, sometimes brilliant code.
If “writing the code” is your entire value proposition as a developer, that’s a shrinking moat.
But here’s what AI can’t do (at least not yet, not well): it can’t walk through your internal content editor’s workflow and realize that you’ve quietly handed off complexity to someone who didn’t sign up for it.
It can’t feel the friction. It can’t connect the dots between a technically sound system and a humanly broken experience.
That’s still a people problem. And developers who can solve people problems—who can diagnose real friction, map a user journey, and design solutions that account for the human at the end of the chain—are building something AI can’t replicate with a prompt.
Nobody’s asking you to become a PM or a UX designer. But the best engineers I’ve seen, and the ones whose work actually holds up, are the ones who build with the human at the end of the chain already in mind.
They think beyond the feature. They think about the person.
This is true whether you’re a solo developer, a junior engineer on a large team, a marketer who codes, an SEO specialist who builds tools, or a leader evaluating what your team ships.
The question isn’t “Did we build it?” The question is “Did we build the experience?”
Related: The Great AI FOMO: Why Keeping Up Feels Like a Second Job
The Full Picture: What the Process Actually Looks Like
So what does this actually look like in practice?
Here’s the process I’ve come to think about not as a rigid checklist, but as a mental model for approaching any new feature or problem:
1. Identify the real friction. Not just the ticket. Not just the stated problem. Walk the journey. Find where things actually break down. Is it performance, cognitive load, missing interface, or transferred complexity?
2. Map the experience into components. Who uses this? When? What do they know, what do they need to know, and what do they have to do? Where does the chain get weak?
3. Define the “why” behind the breakdown. Is it technical debt? A design-system gap? CMS structure? A system that was built for data flow but not for human use? Understanding the root cause shapes everything that comes next.
4. Research and ideate solutions. What actually solves the right problem? Not just the symptom. Is it a UI layer? A restructured data approach? An interface that didn’t exist before?
5. Build a POC and stress-test it. Don’t debate solutions in theory. Build the smallest version that demonstrates the idea and put it under real conditions.
6. Architect the rollout. What’s the migration plan? What breaks if this scales? What’s the risk? What’s the foundation you’re laying for what comes after?
7. Iterate with intention. Co-code, QA, accessibility audit, and performance profile. Refine. Optimize. Repeat until the experience is right, not just until the code passes.
8. Deploy and maintain. Because the experience doesn’t end at launch. It evolves, and your job continues alongside it.
Most of the leverage in this process lives in steps 1 and 2. Get those right, and every step after gets easier.
Get them wrong, and you’ll ship something technically complete that quietly fails the people using it.
It’s a Wrap
The code is the output. The experience is the mission.
That shift in framing, from “I build features” to “I architect experiences”, is subtle when you say it out loud and enormous when you actually live it.
It changes what questions you ask before you build.
It changes what you notice after you ship.
And it changes what you go back and fix without being asked.
The thank yous I got from that content team didn’t come because the tokenization system was technically impressive.
They came because someone thought about what it would feel like to use it and then did something about it.
That’s the job. And honestly?
It’s the part I love most 🙌
