This is the companion to "Dev or Designer. Why Choose If You Can Be Both?". That post is about the career decision. This one is about what it looks like once you have chosen. The real advantages, the real challenges that no one warns you about, and the operating patterns that keep you from burning out or being quietly discounted.
Most job descriptions ask you to be one thing. Designer. Developer. Front-end engineer. UX researcher. The organizational assumption is that these are separate disciplines that collaborate through a defined handoff: design produces specs, development implements them, QA validates. The assembly line model of software.
I've never fit cleanly into that model. I design the interface and then I build it. I think about user behavior while I'm writing TypeScript. I open Figma and VS Code in the same session. For a long time I thought this was a liability. That I was too spread out to be excellent at either. More than ten years later I see it differently. But I'm also not going to pretend it's been seamlessly positive. There are real costs to this path.
The Real Advantages
No Handoff Friction
The design-to-development handoff is one of the most expensive, most underestimated sources of waste in software teams. Designs come in that are technically impractical. Developers implement something slightly different than what was designed because a detail wasn't specified. Reviews go back and forth. Edge cases aren't covered in the design so the developer makes a judgment call.
When I'm doing both, that friction disappears. I know during the design phase whether an interaction is feasible and what it will cost to build. I don't design micro-animations that will take three days to implement in CSS for marginal user benefit. I make those tradeoffs in real time, with full context. The result: what I design, I build. What I build, matches what I designed.
Better Technical Decisions
Understanding design principles changes how I write code. When I'm architecting a component library, I think about it from a designer's perspective too: what variations will the design team need? What states, empty, loading, error, success, disabled, will every component require? What spacing tokens should be exposed as inputs vs hardcoded?
I've seen component libraries built purely by developers that are technically clean but practically unusable for design. Every prop is a technical parameter, not a design decision. Every variation requires a code change. A hybrid perspective means I build with the design use case in mind from the start.
Faster Prototyping
When I need to validate a design idea, I don't mock it in Figma and wait for a developer to stub it out. I write a prototype in Angular. It takes me about the same time it would take me to build a high-fidelity Figma frame, and the result is interactive, handles real edge cases, and can be given to actual users for testing. The feedback I get is much closer to real behavior.
The Real Challenges
Context Switching Is Expensive
The cognitive modes of design and development are genuinely different. Design thinking is expansive. You're generating possibilities, considering users, exploring visual systems. Development thinking is convergent. You're narrowing to a correct implementation, resolving ambiguity, managing constraints.
Switching between these in the same day is tiring in a specific way. I've learned to batch them. I do design work in the morning when my brain is fresh and more generative. I do development in focused blocks when I've settled into a focused mode. Mixing them within a single session produces mediocre results in both.
Being Undervalued in Both Camps
This is the thing nobody tells you: when you do both, some specialists in each field will subtly discount your expertise in theirs. Pure designers may assume your design sense is compromised by technical pragmatism. Pure developers may assume your code quality suffers because you spend time on 'soft' design concerns.
I've been in meetings where a pure UX designer is explaining something about user flows that I know very well, but because my title says developer I'm positioned as the technical person who needs to be educated on UX. It's a frustrating experience. The solution isn't to fight it in the meeting. It's to establish credibility through output over time. But it takes longer than it should.
The Depth Question
There are moments of genuine doubt about depth. Am I as skilled in Angular as someone who has spent 100% of their career on it? Am I as skilled in UX research as someone who has focused exclusively on that? Probably not, in raw absolute terms. What I have instead is a different kind of depth: depth in the intersection. I understand things that specialists on either side don't see because they haven't lived in the overlap.
Whether that's more or less valuable depends entirely on the context. In a large organization with dedicated design and development teams, pure depth may be more valued. In a product team that needs someone who can move fast across the full stack of the interface layer, the hybrid is often the most valuable person in the room.
What the Hybrid Role Looked Like at BMO
At BMO I was in a Senior Software Developer (Angular) role. My UX/UI background showed up in specific, practical ways: I raised accessibility problems in a design before I started building it. I worked within the bank's design system, which another team owned. When a design came in with missing states, I flagged them proactively rather than implementing an incomplete spec. I reviewed components through both a code quality lens and a visual consistency lens.
It's not a 50/50 split. In a large enterprise, the design function is more separated. But the background shapes how I work even when I'm purely in developer mode, and that makes me a better collaborator with the design team than someone who has never worked on their side of the table.
Operating Tactics That Actually Matter
After years of operating in this position, these are the specific practices that have kept me effective instead of exhausted. They are tactical, not philosophical.
- Batch your modes. Design work in the morning when the brain is generative. Implementation in afternoon blocks when it is convergent. Mixing them inside a single hour produces mediocre output in both.
- Signal your primary in every meeting. Pure designers and pure developers will subtly discount your expertise in their field if you do not. Open with what you were hired for, then let the second skill show up through what you catch that they missed.
- Keep a public portfolio that shows both. Most candidates show one or the other. Showing wireframes with rationale next to production code is the clearest signal that the hybrid is real, not aspirational.
- Choose environments that reward the overlap. Design systems teams, product startups, boutique consultancies, and developer-tool companies will pay for hybrid. Large enterprises with deep specialist ladders will not, except in specific roles like Design Engineer or UI Engineer.
- Time-box exploration of new tools and frameworks in both disciplines. Hybrid broadens faster than either specialist, which means you can end up shallow in all directions. A hard budget per quarter keeps exploration from eating into depth.
The interface between design and development is where the most interesting problems live. I decided to live there.
References
- Nielsen Norman Group. From Confrontation to Collaboration: The Developer-Designer Relationship. https://www.nngroup.com/articles/developer-designer-relationship/
- IDEO. Design Thinking. https://designthinking.ideo.com/
- Smashing Magazine. Bridging the Gap Between Designers and Developers. https://www.smashingmagazine.com/2021/10/bridging-gap-between-designers-developers/