The Front End Engineering Spectrum: The Roles

Following up on my previous post about the generic types of front end engineers, this post will deal with the common roles that I see people trying to fill. Unlike the previous list which was written solely from the perspective of a front end engineer, looking at the actual skill sets of the people whose resumes I’ve reviewed, people I’ve interviewed and folks I’ve worked with; this list is based on job descriptions and roles designed by people may not really understand what being a front end engineer means in 2011. Hopefully a few of those people (and maybe a recruiter or two) will visit this site and come away with a better sense of how to staff these roles.

I’ve seen examples of all of these over the past few years.

“The Hybrid”

This role includes some combination of User Experience/Visual Design and Front End Development. I see this one a lot. This combination was the prototype in the early 2000s and still has a lot of traction in a lot of organizations. Look around at the next An Event Apart you attend and you’ll spot more than a few Hybrids (including several people on stage.)

The Creative from my previous post is clearly the best suited type for this role.

The prevalence of this role drive me crazy, personally. Not because it’s an invalid role. Not at all. It’s a great fit for certain organizations and it’s a great role for a lot of people and a lot of companies are well served by it. What drives me crazy is the lingering effect this role has on hiring and perception across the front end engineering spectrum. The general trend of the front end engineering spectrum is expanding away from this type of role. With the emergence of JavaScript as a driving force on the web over the past six years, the definition of “front end” has shifted strongly over to the programmer side. Assuming everyone with HTML, CSS and JavaScript on their resume is still ready to bust out Photoshop to design some buttons is a mistake. Maybe in 2003 that was a safe(r) assumption. It’s not a safe one in 2011, so dig around a little bit to see if the person you’re talking to about a role like this actually does design.

“Soup to Nuts”

This role is on the rare side, at least in terms of the job descriptions I see, but does exist. The role is responsible for every aspect of site development from design to the server. Why include it here? This somehow gets classified as a “front end” role because a lot of what people are interested in these days is in the interaction layer, so the job descriptions are peppered with front end keywords (jQuery, HTML, CSS, etc.)

I understand the desire for this role. One paycheck for four roles! One person to yell at if something goes wrong. I don’t understand why anyone thinks this role is a good idea. The thinner you spread someone, the less likely it is that they’ll have the skills to do their job well and that their attention can remain high across all facets of a project.

There are some situations where it’s reasonable. A reasonably technical Creative should be able to work with something like WordPress, Expression Engine or Drupal where a lot of the heavy lifting is abstracted away. Beyond that it gets a little sketchy. I mean, are there many really good designers out there writing good SQL and Java? Not many. How many C# developers would you have run wild with Photoshop? Again, not many.

(yes, there are exceptions, but still…)

Of my previous types, a Core developer with a very wide skill spread is the best fit here.

“The Full Stack”

This is the opposite of the Hyrbid. This person takes PSDs or Fireworks PNGs and comes back a few weeks later with a fully functioning site. This role has grown organically over the past few years. The growth has come from two directions. As was mentioned previously, front end developers are skewing heavily towards being “programmers,” so expanding the “front end” role into doing server code isn’t that much of a stretch. There’s also been a similar expansion from the server side into the interaction layer. As JavaScript becomes more important (and more people realize how cool it can actually be to write), there’s been a steady drift from the server into the browser layer.

These days, the biggest hurdle with this role is figuring out how happy the individual is with actually doing the full stack. A lot of people get pushed into doing everything on a project and they might even have strongly developed skills across both layers. That doesn’t mean they’re happy doing that work. Some people are really happy to specialize, so just because there are a lot of acronyms on someone’s resume, that doesn’t mean they want to make alphabet soup for a living.

The Coder is clearly the archetype for this role.

“Markup Master”

Several years ago this represented the job description of 50% of the “front end developers” out there (mostly everyone that wasn’t a Hybrid.) This person takes PSDs and makes HTML templates out of them. That’s it.

There are less of these than there used to be. I evolved one Markup Master position out of existence myself. My role at Cramer was initially this kind of job and by the time I was done with building out the Presentation group you had to have solid JavaScript skills or else I wouldn’t have any use for you. That’s a long way from where I started. I was actually told there was “not any JavaScript” in the role when I was interviewed. Even then I was a bit confused by that. This was 2006 and I’d just spent several months building an Ajax application from scratch.

JavaScript had already made “the leap.”

Why I was so sure I could change the role, I’m not sure. I took the job anyway and my own skills and interests plus the growing demand for JavaScript quickly put the “markup master” job description there to bed.

The Creative is probably the closest fit for this role, but if you’re looking to fill this role the real issue is whether or not doing just HTML and CSS all the time is of interest to the candidate. There are a lot of people for whom that kind of work is a dream. Other people would get bored pretty quickly.

“Front End Developer”

Oh look, my job. This is the prototypical large team (read: agency) front end role. The Front End Developer is responsible for HTML, CSS and JavaScript templates and prototypes at the beginning of development and remains heavily involved with the integration and QA phases of a site build. This person is solely focused on the presentation layer. While one might occasionally help out with tasks on either the design side or the server side, 95% of the work done in this role is in the narrow band defined above.

The problem with hiring for this role, and here I speak from experience on the hiring side of the desk, is that it’s tough to fill. If you’re set up this way, with clearly defined strategy, user experience, visual design, front end and server side roles for teams of 6-10 (or many more,) the person you want to fill the front end role has to have really exception skills in HTML, CSS and JavaScript. I mean, when you have a bunch of specialists, sometimes with decades of experience, all playing mad scientist on a project it stretches your abilities pretty quickly.

This is either the Core or a Coder who’s happy to focus.


And that’s that for this little examination of the glamorous world of front end engineering. I’ve got more on interviewing, hiring, titles and team structure posts coming up, so keep your eyes peeled if you’re into that sort of thing.

16 thoughts on “The Front End Engineering Spectrum: The Roles

  1. Seeing my self as “the core” with a role some where between “Soup to Nuts” and “The Full Stack” I’m having a hard time figuring out what to focus on … Beeing a curious person by Nature i just want to suck up all the knowledge i can.

  2. to me it’s just a question of finding a balance between your interests, skills and a role. It took me a while to settle in on the agency role. Now that I’ve been doing it for several years it’s clearly where I’m most comfortable. For other people, it sounds like you, focusing so much on the core front end technologies might not be as much fun.

    At the end of the day the hope of this post is to get people on both sides of the process better understanding how all these things fit together to create more people who like what they do.

  3. That’s a good point. It’s not just a nice-to-have these days. Understanding, at the very minimum, the way that JavaScript works (the event model and DOM based triggers, for example) is important for back-end developers if just to smooth the conversation with the front end guys.

  4. One role that you may have missed here is the “interaction engineer” role, which is slightly diff. from the “front end developer” role in that they do nothing *but* Javascript (periodically touching related frontend/backend work), building out models and interactions in pure JS for complex webapps. Rich web email clients are one obvious example, but the rise of single page webapps is going to grow this role in the coming years.

  5. That’s a good call. I’d probably say it was premature to break it out by itself, but I think you’re right that there are going to be JavaScript specialists moving forward. When I’m used well, that’s basically what I do. It doesn’t always work out that way, but it occasionally does 🙂

  6. I am playing the “full stack” right now, and it is overwhelming to say the least. I only have about a year and a half of web experience. And while I’m a good hacker, and I can figure everything out just about anything I need to. All the context switching is brutal. Constantly having to dump your short term memory to load up on a different programming language, platform, paradigm etc. is exhausting. Any thoughts on how to do this in a sane fashion?

  7. Well, the good part is you can look on it as a great learning experience and a way to decide what it is you want to focus on when you’re done with your “full stack” tenure. The bad news is that it’s hard, especially when you’re still learning web development in general. My biggest suggestion would be to leverage every library/framework you can. While I’m not a huge proponent of always using a tool like that (there are all kinds of tradeoffs you make,) in your situation I’d suggest you offload as much of the cognitive burden as you can.

    you also speak to one thing that’s important, if you’re able to chunk out longer periods of working on one particular technology it might make things feel slightly more normal. I’m personally terrible in anything smaller than 4 hour chunks for context switching.

  8. An especially refreshing read in a time where roles/titles transform as rapidly as the technologies they embrace. I do hope some recruiters find this post – it could save a lot of answering machine tape.

    I’m particularly curious about the roles you played, prior to being the “Front End Developer”. You were the “Markup Master” at Cramer for a while – what other roles did you play before that? (Or what are some examples of roles you’ve seen depreciate since the start of your career?)

    Furthermore – based on current trends, where do you imagine the Front End Developer role going over the next 5-10 years? (e.g., Front End + Back End hybrids; segmentation between Creative and Programming foci, possibly due to the increasing demand for mastery of JS libraries; visual designers being pushed to pick up HTML/CSS knowledge; you name it.)

  9. I wish I could force this post in front of recruiters. On both sides of the table it would help. The candidates we see from recruiters with very specific needs are often pulled from a pool of people with widely variable skill sets. All that they have in common is some combination of HTML CSS and JavaScript on their resume.

    I never really worked as a markup master at Cramer. That was the job description, but I’d ask questions about why certain pieces of JavaScript were so horrible and then go about fixing them. The role there was designed like Ajax didn’t exist, I just pointed out that it did. Things changed rapidly.

    Before that, I’d played Front End Engineer, Hybrid and Markup Master roles, stretching back to the start of my career. I never really liked doing design, so I was only ever a Hybrid by the necessity of job descriptions at the time.

    As for the future, I think we’re going to see more specialization into a JavaScript Engineer role (As was mentioned a bit earlier in the comments), especially since you’ll have people doing JavaScript on both the front and back end (node.js.) Beyond that, I think the current roles will stick around for the next few years at least, with more of an emphasis places on people who can do serious interaction in the browser- especially on mobile.

  10. “(jQuery, HTML, CSS, etc.)”

    Saying “jQuery” when you mean “JavaScript” considered harmful.

  11. “(jQuery, HTML, CSS, etc.)”

    Saying “jQuery” when you mean “JavaScript” considered harmful.

    I specifically mean jQuery. Did you read the sentence? It represents a list of resume keywords that a recruiter would search for. jQuery would definitely be one of those.

Leave a Reply

Your email address will not be published. Required fields are marked *