Whenever somebody asks what I do I tell them I’m a front-end developer (answer could change based on the person asking). A decade or two ago it was pretty clear what my job entails. I would write HTML, CSS and some Javascript for interaction purposes. Even though I spent most of my early career doing PHP and MySql work I still prefer to be perceived as such (more on the relevance of this information later). Around early 2010 this started to change. Javascript became a thing — a very big thing. Early last year I started meeting more front-end developers and I realize something. Front-end developers are no longer the front-end developers I traditionally knew.
The Problem Surfacing
Most of the front-end developers I met were talking and developing in JS frameworks/libraries. The hot topic for them were React, Webpack, Node.js and etc. I had no problems with this, as at the time I was a bit indulged in Angular and Gulp myself. The problem strikes me shortly after, I was to run the CSS portion of an interview for a front-end developer. The candidate’s biggest selling point for himself was that he worked in Angular and really proficient in D3. I was pleased — until I ran my CSS competency test. Basically, I show interviewees some CSS selectors and properties that ranges from basic to competently complex and they’re to describe what they believe the CSS is doing. This particular candidate did “ok” on the basic tests but anything moderately more advanced than basic stumped him. I didn’t pay too much attention to this until after a few more interviews with other candidates which yield similar results. I dug deeper into some of their portfolio work, and realize these “front-end developers” couldn’t style worth shit. Sorry that was harsh. It wasn’t that they were bad “front-end developers” just that they spent all of their studies and practices with JS or sometimes just Bootstrap (another story). They lacked the CSS experience and polish.
I realize this was happening everywhere. There was this project that we had designed and wanted to build a web prototype for a client. A front-end developer was given the task and the results were truly underwhelming. I can’t actually show the work so I mocked a wireframe to demonstrate what happened.
I tried to illustrate some of the issues I remember, from wrong font sizes to spacing to alignment. There was a lot more issues, but you get the point. To the developer this was fine because he was more concerned about the functionality and JS behind this and visually he believed it was “close enough”. Unfortunately, for this client (and any client IMO) would equally care for the aesthetics. This individual was extremely talented in JS builds and development but visuals and CSS weren’t his strength. On the flip side, I also worked with individuals who are truly amazing CSS developers but aren’t heavily invested in deep JS work.
Basis for Revolution
Fast forward to last November. I was working onsite with some coworkers. After work we sat around discussing this exact topic. It seems like we were all in an accord. The skills and responsibilities of front-end developers are becoming ambiguous. We entertained the idea of dividing up front-end developers into two categories. One for functional Javascript work which may include middleware, which we called the front-end engineer/architect. The other for visual work focusing on DOM structure/optimization, CSS and Javascript interaction work, which we called front-end styler/visualizer. The conversation ended with a few more beers and the waiter bringing us the check.
Casually Validating the Problem
Since then I started unofficially researching the topic. This meant looking at front-end job posting in Toronto, Vancouver, SF Bay Area, and Seattle on Craigslist and AngelList. I was observing what title recruiters were using for front-end developers compared with skills and responsibilities listed. I originally started with a nice spreadsheet then quickly transition to a notes document then a post-it note with tally marks (I’m terrible at researching). Regardless, it was clear that majority of the postings were generalizing “front-end developer” and sometimes simply “web developer”. Almost all of the postings require both Javascript and CSS (or variation of). Digging into the responsibilities I can sometimes figure out if this is more of a JS functionality or CSS visual heavy role. Sometimes it’s just too vague based on the job posting itself — and disgusting based on the 30k (CDN) salary. The question I was trying to answer with this “research” was, “are there room for more specific titles to distinguish skills and responsibilities?”. The answer was, yes!
Proposed Solution
Every now and then during my research I’d see an accurate posting show up. This was either “front-end engineer” or “front-end designer”. One of the front-end designer one was slightly “off”, but close. They were also looking for somebody who can design in Sketch or Illustrator, which was ok-ish — I guess? (I’m not opinionated about this). I really liked these two titles. Just reading the title I could guess what the job’s going to be and I was right (almost) every time I clicked in. What I am proposing with this is that front-end developers start labelling themselves with new titles depending on their mastery. The titles as follow:
- front-end engineer: front-end (maybe middleware) functionality developer,
- front-end designer: front-end visual/interaction developer, and
- front-end full stack developer: fully competent in both of the above.
When I tell people this two common questions arise from this:
- Wouldn’t this box people in? Eg. A front-end designer might know how to developer React components.
- Wouldn’t everybody just say they’re a front-end full stack developer to maximize their job opportunities — and ego?
For the first question, I don’t think so. As I have mentioned at the beginning of the article. I am quite confident in backend work, but my biggest assets’ on the front-end and I labelled myself as such. This has never limited my opportunity to talk or participate in the backend. Over the last few years I’ve done as much as architect my own database structure and workflows from scratch. The key is it’s not within my mastery or even my interest, so I don’t present it as part of my “portfolio”. The point is to outline where your strengths and interests are.
The second question is a maybe. Even without the divide on the front-end I still hear lots of people claiming they’re full stack developers — I guarantee they’re not. You’ll always get people like that, but I trust in those who are good with their craft to present themselves more accurately. I genuinely believe they’re very skillful front-end full stack developers and they should present themselves as such. For the rest of us, like decades ago where we organically sorted ourselves to the front and back end categories hopefully we can do the same here.
Conclusion
Once you’re on a team your teammates will most likely know where your skills reside (fingers crossed), but I’m talking about context beyond that. I’m talking about recruiters filtering out the right candidates, easily describing what you do (on a broad scale) when meeting other developers, and telling your mom what you “really” do. Maybe not the last thing because she’ll never understand, but you get the idea. I think it can start with us — “front-end developers”. If we start pushing for these new titles we can get conversations moving. That’s what I’ve been doing a lot at events now, presenting myself as a front-end designer. Maybe you can do the same.
Check out my unofficial follow-up to this article, Front-end development is like figure skating, it reward
