Full-Stack Developers
In my experience consulting with and workshopping with companies of all shapes and sizes, I always ask “who owns the frontend code here?” I help web teams create design systems and collaborate more effectively, so it’s important for me to get a solid understanding of who tackles frontend code, where they sit, which department they’re a part of, and where they fit in the team’s workflow.
On occasion, I’ll have the following conversation when I ask where the frontend people are:
“Who are the frontend developers?”
“Oh, we only hire full-stack developers here.”
“OK, so those full-stack developers craft all the UI code?”
“Yep”
“Ok, so talk me through some of the decisions you make about frontend strategy and architecture.”
“Uhhhh…yeah.”
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
Are there people out there that feel equally comfortable designing a flexible, performant, accessible card component UI, and also wiring up the API that will feed content into that card component? I have no doubts. But is that skillset a common occurrence? I doubt it.
I’ve discussed in other posts and in my book about how the role of frontend design is still being defined, and organizationally there’s still a lot of confusion about what to do with frontend designers and where they fit into the process. The divide between design and engineering is often designers = people producing static design artifacts and development = people who code. Frontend design often gets bucketed in with engineering because it’s technically code. So then UI code becomes just another task for already-busy engineers to tackle, and because HTML/CSS aren’t imperative programming languages it’s seen as “easy” work, not as much time and attention gets committed to it. Of course, the entire final product suffers as a result.
Frontend design is a critical part of the design and development process. Creating UIs that are responsive, performant, accessible, compatible, flexible, extensible, and resilient is tough work. That’s why it’s a good idea to treat frontend as a first-class citizen in your organization and dedicate some people that can really own frontend code. Frontend designers can straddle the line between design and development, serving as mortar that can hold the team together.
Now I understand that smaller companies often hire developers that run the gamut out of necessity. There simply aren’t enough resources to hire both backend and frontend developers. In my first jobs at small companies, I wrote the frontend code, got the SSL certificates working, handled the CMS integration, and fixed the router when the internet crapped out. While I did what was necessary and I benefitted from the experience, I’d never admit I was equally skilled at all of those things (especially the router fixing stuff).
Large organizations have the ability to hire specialists, which is why I get so confused why so many companies proudly declare they only hire full-stack developers. Having team members that can own the frontend experience is a good thing. Having team members that can own all things backend is a good thing. Having everyone work together to create successful products is a good thing.
I don’t think “full-stack developer” is necessarily a bad word, and there’s nothing wrong for individual developers to define their role in that way. But organizationally, when I encounter “we only hire full-stack developers” orgs I’ve only seen issues with their process and UI code.