Last week on ShopTalk, Dave and I spoke with Mandy Michael and Lara Schenck. Mandy had just written the intentionally provocative “Is there any value in people who cannot write JavaScript?” which guided our conversation. Lara is deeply interested in this subject as well, as someone who is a job seeking web worker, but places herself on the spectrum as a non-unicorn.
Part of that discussion was about job titles. If there was a ubiquitously accepted and used job title that meant you were specifically skilled at HTML and CSS, and there was a market for that job title, there probably wouldn’t be any problem at all. There isn’t though. “Web developer” is too vague. “Front-end developer” maybe used to mean that, but has been largely co-opted by JavaScript.
In fact, you might say that none of us has an exactly perfect job title and the industry at large has trouble agreeing on a set of job titles.
Lara created a repo with the intent to think all this out and discuss it.
If there is already a spectrum between design and backend development, and front-end development is that place in between, perhaps front-end development, if we zoom in, is a spectrum as well:
I like the idea of spectrums, but I also agree with a comment by Sarah Drasner where she mentioned that this makes it seem like you can’t be good at both. If you’re a dot right in the middle in this specrum, you are, for example, not as good at JavaScript as someone on the right.
This could probably be fixed with some different dataviz (perhaps the size of the dot), or, heaven forbid, skill-level bars.
More importantly, if you’re really interested in the discussion around all this, Lara has used the issues area to open that up.
Last year, Geoff also started thinking about all our web jobs as a spectrum. We can break up our jobs into parts and map them onto those parts in differnet ways:
See the Pen Web Terminology Matrix by Geoff Graham (@geoffgraham) on CodePen.
See the Pen Web Terminology Venn Diagram by Geoff Graham (@geoffgraham) on CodePen.
That can certainly help us understand our world a little bit, but doesn’t quite help with the job titles thing. It’s unlikely we’ll get people to write job descriptions that include a data visualization of what they are looking for.
Jeff Pelletier took a crack at job titles and narrowed it down to three:
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).
Although those don’t quite feel like titles to me and converting them into something like “Front-end implementation developer” doesn’t seem like something that will catch on.
Cody Lindley’s Front-End Developer Handbook has a section on job titles. I won’t quote it in full, but they are:
- Front-End Developer
- Front-End Engineer (aka JavaScript Developer or Full-stack JavaScript Developer)
- CSS/HTML Developer
- Front-End Web Designer
- Web/Front-End User Interface (aka UI) Developer/Engineer
- Mobile/Tablet Front-End Developer
- Front-End SEO Expert
- Front-End Accessibility Expert
- Front-End Dev. Ops
- Front-End Testing/QA
Note the contentious “full stack” title, in which Brad Frost says:
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.
Still, these largely feel pretty good to me. And yet weirdly, almost like there is both too many and too few. As in, while there is good coverage here, but if you are going to cover specialties, you might as well add in performance, copywriting, analytics, and more as well. The more you add, the further away we are to locking things down. Not to mention the harder it becomes when people crossover these disciplines, like they almost always do.
Oh well.
Thank you for continuing this discussion. It may never end but at least it’s out there for people who don’t get how complicated this whole thing is.
I dont mean to step on any toes here. But a feel like titles and this sort of labeling is a very american phenomenon.
Nowhere i have ever worked has had any meaningfull title designation for anyone and i couldn’t care less what you businesscard says.
Is there something im not “getting”?
It’s not about business cards, it’s more about job offers and interviews.
I think the idea is, you have to call yourself something. I mean, it obviously matters if your business card says “front-end developer” or “SEO expert”. So there is some importance to the title.
But in terms of dividing up a single subject (in this case, front-end development), the problem lies with the assumptions that each comes with.
If we settle on “Front-end Developer” (FED) for every front-end related job, then everyone is going to assume each FED does everything, including JavaScript, accessibility, SEO, and maybe even design. But that’s simply not true. And it matters, because if someone’s hiring you, it could be misleading if you say you’re a FED but don’t write JavaScript, or don’t do design. Or if they assume you also do SEO, but you don’t.
So now we say things like “HTML/CSS Developer” or “JavaScript Engineer”, etc. to ensure that it’s clear. I mean, I’m glad to hear it wasn’t a problem in the places you worked, but I think it would be more of a problem in the hiring process, or for freelancers doing various gigs for different clients.
First, I’m not sure if you listened to the podcast or not but they go into more detail of the why. If you haven’t that’s cool.
The big reason for issues with job titles in the States or in general is the meaning has moved away from the original intent and as such you aren’t ever quite sure what the employer wants. When you see postings for front-end developer it typically means someone who is good at React, Angular, or some other JavaScript framework. It doesn’t necessarily mean someone who is proficient at HTML/CSS which it used to. You rarely, if ever, find a posting for someone who is proficient in HTML/CSS/JS(interactive js not framework js).
I think it is as much of an issue with JavaScript classification/naming as it is with title naming. JavaScript has moved so far in the spectrum beyond what it was ever intended to be. React, Angular, Ember, and Vue aren’t really full on front-end but their also not backend, they lay somewhere in the middle touching both worlds. I think we should reclassify the big frameworks as Middle Stack and then the job titles could be for middle stack developers, separating themselves between front-end and backend. Yes I know middle stack is not very creative but it’s descriptive but we can find a better name.
I don’t think anyone, well most, actually care what their title is after they get the job but more so what the job postings are classifying the job title as because the meaning has become so vague and moved away from the original intent.
I went to college to be a Graphic Designer, and then turned into a ‘Web guy’ and my co-workers dubbed me ‘theCSSguru’, so I use that name even on my resume, but my job titles have changed and evolved over 10 years, depending on the company. These are the titles I’ve held for the same type of job; Graphic Designer, Web Designer, Creative Director, Web Developer, Front End Developer, Lead Front End Developer, and UX Developer. I wonder what my newest title will be? I have the added bonus of having Graphic Design ability so maybe ‘Lead Front End UX Designer/Developer Director’. Yeah, I like that. LOL
Where I would fit? I work in a digital agency. Bachelors in IT, exposure to PHP /Java. But daily I do “HTML, CSS, responsive and WordPress theming.
I’m quite junior level and understand JS syntax
Somehow I’m still continually surprised when data tier application development is always left out of the “full stack” discussion. I do agree that the vast majority of “full stack” claims are grossly overstated. It seems though that most of the discussions I can find on Twitter/podcasts/blogs are very heavy on “consumer focused” web development. I’ve been a consultant in the insurance industry for several years now and worked on a handful of web portal and business management platforms that were primarily browser based, but more intranet than internet. Although I’m a bit new to the dev world of a front end heavy SPA, my prior roles have often been managing teams of data analysts, SQL developers (this does not mean select statements), systems integration / ETL development, business intelligence / data visualizations and reporting solution developers. In the enterprise space I believe there really is a nearly accurate term for “full stack”, but it becomes either Solution Architect or Technical Architect depending on strategic vs tactical planning. Someone in a DBA and/or SQL development role is intrinsic to building data centric critical systems at many larger companies. Just adding fuel to the fire here I guess, but only in the effort of pointing out that there is no such thing as complete or uniform definitions of titles/roles. I’d be happy to share a handful of other real-world examples if anyone wanted to discuss further.
I think this is a very important topic although there are two sides of the story to keep in mind. Its true that the web has become more demanding and Javascript/programming has become a concern to the point that in a lot of newer workflows it would be significantly more inconvenient to try and separate html and css as their own concern. On the other hand, this is definitely an industry that tries to lump people into categories rather than than seek out individual talents and creatively put them to use. It’s not really about titles I think, but more about weather you fall into an accepted bucket. Unfortunately, html/css has steadily disappeared as one of those acceptable buckets.
This is a real shame as pointed out here and in Lara’s article. I’ve followed probably a similar progression as I think Lara, and I think even Chris here, and probably many others in that I got started in the late 90’s as a graphic designer who could be a little dangerous with Dreamweaver. That evolved into CSS when CSS became big, then Joomla, Drupal and WordPress when they got big. I think even at that stage, I had some pretty formidable knowledge that certainly couldn’t be called programming, but I could get _ _ _ _ done! And it wasn’t hard to find work because I had an eye for detail. But then by about 2013-14 as Javascript was becoming popular and the web was becoming more demanding, handcrafted CMS work became much less lucrative. At that point, I knew I had to either completely begin the process of learning programming and CS skills, change my focus to UX only, or give up on the web. I chose the former. It was incredibly hard work. I literally would spend 40-80 hrs a week reading books, doing tutorials, and making practice projects. The problem was I didn’t start soon enough. The industry had already changed, and most companies didn’t give a lick about my (pretty darn good) html/css skills like they did just a couple years before. The work has by now finally been paying off, but I faced an amazing amount of discrimination while I was still learning.
The think is, even though I’ve come a long way to the point that I’m now doing full-stack work and much more confident, I still feel the pain of those couple years where so many companies/people rejected me, over and over, because I wasn’t yet strong in Javascript. I know beyond a doubt that it’s possible to harness a good css/html/general web person (who at least knows a modest amount of JS so they don’t mess things up), if you structure your team the right way. I don’t feel that it would be an act of mercy either, I think any time you utilize talents in a proper way its going to be good for the team. The problem I think is simple: putting things in buckets and sticking to the formula is the easy way out. The problem is people don’t work like that. They aren’t buckets!
Don’t see a way to edit my comment, but I just wanted to add that I think the main irony of the situation for html/css people making a transition to programming, is that you tend to be judged purely based on where you are at so far with CS and programming.
If you have 20 years of general web development experience, understood the HTTP lifecycle 15 years ago, know way better than the back end guy how to properly structure CSS, know the browser tricks, learned zillions of applicable lessons to any development job and have have a good general working and testing discipline,… pretty much none of that matters in most tech interviews. They tend to zero in and judge you purely on your raw programming skills. Many times it’s all about your ability to solve academic code puzzles that require practice on their own (since they’re rarely useful in the real world). I’m absolutely not knocking good programming chops, it’s just that I believe an artificial weight is put on them and that there should be a little more wiggle room for different types of talent. Esp considering there are a lot of good people in the industry that came to where they’re at from a different path than a CS grad.
Thanks for the article. As someone who is currently looking for work and equally passionate about the paper sketching/mockup half, and the HTML/CSS/basic JS half, this was a cathartic read. Seems everyone’s nominally interested in people who can do both, but front-end web developer positions are looking for angular/react and don’t mention design skills, and UX/UI design positions mostly just want a “familiarity with HTML/CSS”.
How do we feel about UX/UI developer?
It’s worth mentioning the “T shaped individual” term. That means you are capable of a lot of things, but you have deep knowledge in one thing. For example I’m very experienced with frontend development, that would be my “deep” part, but I also worked on backend for 5 years, spent 2 years just rewriting SQL to hibernate queries and creating endpoint in a service. I also did UX work for 1.5 years creating wireframes and doing interaction design. Also right now at my work I’m doing DevOps kind of work for a few weeks and I enjoy that too. I’m in love with frontend, but I have no problem joining in on some backend development if that comes. I find that the “T shaped” is the best representation of someone’s skill set. I know there are grey areas of course, as in everything ever :)
Its true that people that come to web development from design tend to get good at CSS more so than JavaScript, while people that come from a computer science background tend to focus on proper programming languages, including JavaScript. However, there are some backend people who are great at CSS (Rachel Andrew for example). There are also a lot of great Javascript developers that don’t do any backend at all (although that is changing with the rising popularity of Node). I don’t think its helpful to see it as a spectrum. I’d say the majority of front-end jobs involve no design at all. I just implement what designers give me.
I began building websites in 1999. For the past 17 years, I’ve built websites using varied combinations of HTML, CSS and JS/jQuery. The titles of my positions have been “web builder”, “web designer/developer”, “web developer” and “front-end developer.”
In the course of this work, I’ve had to focus a significant amount of time on browser- and device-compatibility, display consistency and UI/UX design. The deliverables typically need to function and display consistently in all browsers, on all devices (notably so when building things for global and “fortune” brands).
Having spent so much time building websites from .psd files, I can quickly spot flaws in design .psd files which arise from the designer’s inexperience and lack of knowledge building websites in HTML and CSS. I can write JS and jQuery, certainly more than a lot of “UI/UX Developers” can or would ever normally write, but not as much (or as complex) as a back-end developer can write.
In each role I’ve filled, for all of my employers, every brilliant back-end developer (or programmer, if you prefer that label) I’ve worked with who has to do anything on the front-end has enlisted my help to debug presentation-layer issues. Sometimes the issues I help debug are layout, other times it’s browser-compliance, or element-state confusion, but most commonly the issue is relevant to either CSS selector specificity or the cascade itself – inheritance problems.
For the last two years, following a layoff, I’ve performed freelance consulting work, but have also sought full-time positions, which brings me back to the topic at hand: “What is a ‘Front End Developer’ in 2017?” Judging by the listings I see on popular job-search websites, a Front End Developer is a full-stack developer with a focus on application development.
I’ve witnessed how the nuances of browser- and device-compliance, layout, and UI design are not well understood by the back-end developers I’ve worked with who are expected to be “full-stack” but who work primarily in the programming space (js, php, C#, jsp, et al).
And yet there are seemingly endless job-listings penned by tech recruiters who seem consumed by a need to only hire the “unicorn” developers for all positions relevant to “UI/UX” and “Front End.” Even worse than the “all developers must be unicorns” issue are the Front End Developer positions which list all the “typical” technical requirements, with the added requirement that said Front End Developer must also have graphic design experience in the form of PRINT PRODUCTION.
I had two recent interviews which both went GREAT until they were each ended by questions out of left-field. In the first interview, which was advertised as a “front end developer” position, the people interviewing me were clearly pleased by my experience and skills and what I could bring to the table on the front-end, and then they asked me if I was a full-stack developer. They were disappointed that I was only a “front end developer”, and I was disappointed that our time was completely wasted because someone advertised one role and then respondents were interviewed for an entirely different role – they could have avoided their disappointment (and mine) when they posted the ad. The second interview was similar – all-good on the front end capacity, until the “oh, by the way, we need you to have experience with print design for all manner of print media” requirement was finally mentioned.
Fun times.
I’ve been surprisingly happy with “Front-end Software Engineer” over the past few years. It covers the recent moves I’ve made into app development, and let’s me admit to some back-end experience without making it seem like I’m trying to be “full-stack”.
It is very simple really.
Front-End is related to any visual represtantation of content in a user-agent for human interaction.
Backend is related to access, save and churn data to deliver information to human or machine.
Operations is related to implement the platform for development, test and deployment.
The technologies used is incidental, it changes with time. Yesterday was “c”, cobol and a text terminal or printer, then it was Visual Basic and Java and Color monitors, today is JavaScript and HTML/CSS over desktop and mobile. Tomorrow some AI API.
At the end is just meaningful if there is a user at the other end of the line.
If full-stack developers are backend developers who can write frontend code, then what are frontend developers who can create a server using SaaS or express for their app when they have to?
You’re correct in surmising that my descriptions were not intended as titles, but as buckets responsibilities, and the roles that describe them. I think minimally recognizing there’s room for specialization at an organizational level should be a goal. The titles themselves are less important.
I think somebody should make a web app out of this.
Keeping it simple:
check all the things you can do from a list;
the app suggests a proper job title for you.
For someone like me it would be extremely useful, because I’m struggling to find a good – even decent – job title.
I label myself “Digital Designer”, but I’m thinking about dropping the “Digital”, because nowadays it has lost almost all meaning.
I mean, today you cannot design, say, just a “business card”, or “just a logo”. You have to think about branding as a system, so “designing for print only” is not a thing. Therefore, “designing for digital” is not a thing either.
Also, I develop websites in PHP with Laravel and WordPress. So even “Designer” feels restrictive.
Maybe “Designer & Developer”? I dunno.