Working on the front-end of the web has evolved quite a bit over the past decade or so. One challenge I’ve faced repeatedly is helping people understand just which areas of web work I excel at. It seems to be a rather common theme, because if you do a bit of web sleuthing, it starts to feel like we can’t even articulate very well what we do to ourselves, never mind the subsequent explanation to anyone who’s up above it.
Recently, I’ve been lucky enough to be contributing to defining roles and just where people like me will sit within our structure at work. It’s my hope that documenting a bit of my research will either serve as a resource others can refer to when attempting to make a similar appeal to define a new role within their company, or assist people who are in a similar position as I currently am: having to wear too many hats and feeling like there’s a better solution out there.
The questions I’m attempting to answer here are:
What should we call people in this role?
What should their responsibilities be?
As a side note, I just finished reading Brad Frost’s Atomic Design, which served as a bit of inspiration for my current endeavor.
First up, job titles. Job titles can be difficult, which is why I want to address them first. While I completely understand that job titles with web professionals can be hard to pin down, they do hold meaning (as words tend to), and subsequently people infer meaning based on them. I hold a degree in graphic design and spent an entire semester with Adobe Director in college (web degrees weren’t really a “thing” yet). Just like Brad Frost, I’ve never taken a course in computer science in my life. During my career, my job title has transitioned (each transition was at the same employer, each comma separates employers) from Web Designer to Web Marketing Manager (I promptly departed), from Web Designer to Web Developer, from Senior Front-end Web Developer to Senior Developer (notice the mysterious departure of “Front-end” and “Web”), and from UI Developer to UI Engineer.
If you’re paying attention, you’ll notice a trend of my job titles continually transitioning from starting closer to design and moving toward the computer science end of the spectrum. I’m not sure if it’s a result of being a 6'3" white male (we’re all aware of the gender bias in our industry), or that pay scales skew toward “developers”, so as I gain experience in the industry I have to move in this direction simply to move up the career ladder. Whatever the cause, the result is people generally want to categorize me as more technical, as the outsider’s assumption tends to lump everything “web tech” into the same ball of clay.
This is a common theme, and others do a better job at explaining it than I do. Here are a few.
Brad Frost does a great job of providing an overview, in his post on Frontend Design:
A front-end designer (who may also go by UI developer, client-side developer, UI engineer, design engineer, front-end architect, designer/developer, prototyper, unicorn, or Bo Jackson) lives in a sort of purgatory between worlds.
Jonathan Snook defines an entire new step in the process as “Design Implementation” in his post on Design Engineering:
When we examine the development process, there are three phases: “Design”, “Design Implementation”, and “Application Development”.
Probably the most well articulated post I’ve found discussing how our role has changed over the years comes from Matthew Gertner’s post on The Shifting Definition of the Front-End Developer. Here are a few great excerpts:
Now that single page apps have pushed a lot of the work that used to happen on the back-end tier into the browser, the UX-to-jQuery folks are suddenly being asked to do hardcore software engineering.
The world still needs developers who can synthesize customer requirements, work with graphic designers and navigate the ever more labyrinthine CSS standards to produce gorgeous, responsive and functional user interfaces.
The real problem is the perception that any code running in the browser is front-end code. This is patently no longer the case. Either we find another term to describe the UX-to-jQuery crowd or we redefine what we mean by “front-end”.
This last quote is particularly relevant, as it’s undeniable that code running in the browser is a blend of front- and back-end code. Jeremy Keith describes Angular as closer to a native SDK in his post on Angular Momentum:
Well, yes, technically Angular is a front-end framework, but conceptually and philosophically it’s much more like a back-end framework (actually, I think it’s conceptually closest to a native SDK; something more akin to writing iOS or Android apps, while others compare it to ASP.NET).
Jake Archibald also makes a great point in his post titled If we stand still, we go backwards:
No one can be an expert in the whole web. Surgeons aren’t experts in all types of surgery, scientists aren’t experts in all of science, web developers aren’t experts in all of web development.
To summarize, there’s a role that sits between the design and development teams, and there’s room for much more specialization in front-end web development. The web itself has only been around for a few decades. There hasn’t been enough time for us to recognize, nor reflect on the fact that specialization is necessary. You wouldn’t ask a paleontologist to provide you a detailed description of alpha centauri. Similarly, you wouldn’t fathom substituting a podiatrist for your surgeon on the date you’re scheduled to have heart surgery. It only follows that we should also not ask an individual who’s highly skilled at translating design prototypes into functional responsive web sites to jump in and write some logic for a service that makes calls via an observable to a REST backend.
Next up, responsibilities on the front-end, based on this research and my experience, seem to fall into three distinct areas:
Front-end Implementation (responsive web design, modular/scalable CSS, UI frameworks, living style guides, progressive enhancement & accessibility, animation and front-end performance).
Application Development (JavaScript frameworks, JavaScript preprocessors, code quality, process automation, testing).
Front-end Operations (build tools, deployment, speed: (app, tests, builds, deploys), monitoring errors/logs, and stability).
While the titles themselves are still works in progress (and I’d be very interested in others’ experience), the roles themselves are fairly distinct. Oddly enough, everything I put in the “Front-end Implementation” bucket seems to coincide with what Brad Frost considers parts of an overarching design system in Atomic Design, and is a role for people with a background in design. Application Development is fairly synonymous with a “JavaScript Developer” in my mind, and is a role for individuals with a background in computer science who have experience on the front-end. Front-end Ops Engineering was originally defined by Alex Sexton in 2013, and front-end operations work is best suited for individuals with a background in operations management.
Additionally, Micah Godbolt defines Front-end Architecture as touching pieces from all three of the areas I’ve outlined. I haven’t read his book yet (but will soon!), but I feel like the term “Front-end Architect” may be very useful, albeit if we refine the responsibilities a bit depending on an individual’s background.
So, the person working on front-end implementation is someone who sits between the designers and engineers, who works on design implementation (not design, and not application development), and is able to work with the design team to create user interfaces that reflect both the client’s requirements and the design team’s intent. This individual also understands enough about the frameworks used by the development team working on the production application to recommend implementation of their work in the current flavor of JS framework. They can incorporate best practices in a living style guide that is treated as a first class citizen in the the design and development process. Part of me really wants the title for this role to be “Front-end Executioner”.
This may be a case of “it depends”, in that the job titles and which teams they sit on depend very much on your specific team’s structure. Hopefully, this post will cast some light on the distinction between the responsibilities, and the delineation that the the front-end minimally requires individuals focusing on these specific areas. It’s my inclination that there’s likely much more fine-tuned specialization to come.