You cannot pinpoint who is at fault here. In my opinion, there seems to be a vicious circle in the outsourcing industry where certain patterns of required skills and known technologies have emerged from.
With the technology stack already settled for some time now, the profile for the perfect candidate is pretty obvious for both recruiters and those looking for a job in the field alike. This does a great disservice for experienced developers who can bring great value to a company no matter the technology they used in the past, but also to those who want to learn how websites are built.
Instead of making the baby steps needed to properly understand how the web works, they are encouraged to install countless dependencies on their machine, then jam all the HTML, CSS and JavaScript in a huge bundle.
Are job titles still relevant in the web development industry of today? Or were they ever relevant? I am going to make a case that they are not. You could make a valid point that there are some jobs that need highly specialised professionals to take care of them and that a job title is just a hint into what the job description would look like.
I would argue that most teams would value more an employee that can handle a variety of the jobs needed to be done in the frontend landscape then the ones with a limited skillset.
Front-End Developer, UX Developer, Web Designer, JavaScript Developer, Full-stack Developer. Do you feel like you fit in any of these categories? Are all or any of these roles present at the company you work for? If so, who is responsible for the continuous integration and deployment processes? Who takes care of accessibility, search-engine optimisation or cross-browser and cross-device testing?
Once upon a time on the Web
In the early days of the web, there was really only one job title you could have if you did business in this industry. You would’ve been the webmaster. The person who set up the servers, wrote code to handle the business logic on the back-end, decided how the website would look, throw in some HTML tables, mash some keyword-heavy content and you were done.
It was a time when design wasn’t valued as much as it is today, and the so-called front end of the website didn’t require that much work either. There was only one resolution your website had to look good on, that’s 800 x 600, and mainly only one browser to work with and test your website for.
It is true that many aspects of the process of developing a website were, in part, easier to handle than it is today. At the same time, it was expected that you, as a webmaster, understood how all aspects of the web worked, how they connected and how they came together. In the end, it right there in the name webmaster.
Slowly, as websites grew more complex and new technologies emerged, web developers started to divide into two distinct groups: backend developers who took care of setting up the server and create all the business logic behind the scenes, and frontend developers whose job was mostly to find all sort of hacks in order to make the website look as shiny as possible.
The frontend landscape today
Well, time passed by, CSS became a real thing, again new technologies emerged and the frontend field became a hell of a lot more complex. On one side, there were these many new interesting tools you could take advantage of like Canvas, SVG, but also many new aspects to take care of: support for new and legacy web browsers, accessibility, microformats, rich snippets and so on.
JavaScript started to look like a real programming language and that drew the attention from people who didn’t want to mess with HTML tables back in the day, or with CSS, or with spaghetti code in JavaScript. When solid frameworks like Backbone, Angular, React, Vue (you name it) which allowed classic programming patterns to be used in the frontend space, programmers also migrated to frontend.
In my opinion titles like those listed in the introductory part of this article should only be used to describe, you guessed it, jobs. In fact, it would be even better suited if it described specific roles at a company.
These days it feels, at least for me, that both recruiters and employees make a big disservice to the frontend craft by cramming everyone into buckets of people with specific sets of skills.
Roles we play at Pixelgrade
We’re a pretty diverse group at Pixelgrade. Not in the ethnic sense, but rather skill-wise. There are certain areas where our skills tend to overlap because we do value and encourage autonomy and independence at the job for everyone, but at the same time each and every one of us has certain areas where he or she excels.
That’s why many of the roles we’ve established at Pixelgrade evolved around the person instead of going the other way around of coming up with a role and then try to find a perfect fit for that in role inside the team or even outside it.
We have always had the space that people need to transform and grow, and if we’ve ever needed to fill a specific spot at our company, we’ve always looked inside the crew first. It won’t constantly be the case where you would find that person in the team, that’s for sure.
However, if you do, that person should have the confidence and mental space to do the job. And more so, at the end of the day, it’s not even about roles in an organisation. It can also be about specific jobs or even tasks that need to be done. That’s because we required the members to be flexible and to make it happen they needed to start exercising flexibility. Makes sense, right?
In order to have a team in the very real sense, you need every member of your team to be aware of all the aspect and inner workings of your company. You need them to know what everyone does, what challenges they face everyday, who they could help and who might be able to help them.
That is why, at various points in time we’ve encouraged people to get away from their day to day tasks and see if there are any other areas where their skills could be useful. And if they had done a good job they encouraged to it again.
We’ve had developers working on design projects, members of the support developing WordPress themes, newcomers taking care of the project managing side of things and so on. And when it happened it was a win for both the company and the individual.
We’re a small team here at Pixelgrade and we do a lot of stuff. We develop new products from time to time, we work on some side-projects, but we also have to maintain our website and all the other themes and plugins in our portfolio.
Keeping track of all these projects and making significant progress on some of them on day-to-day basis can become overwhelming pretty quick. But when you don’t have to wait for others to implement a specific feature, when you can trust the designer in your team that he can fix some of the bugs in the current milestone and when he trusts that you can implement a new feature without the need for a mockup, let alone a high-fidelity render, everyone becomes more confident and relaxed and everything seems a little bit simpler.
The struggle that doesn’t make sense to me
Today, there is a clear trend towards specialisation in the industry but that is not necessarily a bad thing. As I said, there is a real need for highly-specialised professionals in every area of the software industry. I am not baffled by the level of fragmentation in the field but rather by the way it is fragmented. Let me explain.
I don’t have a problem with the term JavaScript Developer per se. This is not a thing to be desired, but we’ve had roles that were describing the programming language most used at the job since like forever. We can’t all be Software Developers anyway.
What I cannot get to grips with is when people use a particular framework in their job title, like Angular Developer, React Developer, your favourite framework here Developer, you get the point. I just cannot understand why you would want to put yourself in such a small box.
What happens when you move to another project? Do you start by default with your favourite framework? Do you go with the latest and shiny technology that’s out there? And if you do change your technology stack, does your experience become irrelevant?
Maybe it’s just a way of marketing that works well for most of the clients, employers and employees out there.
Part of my frustration comes from a few series of interviews we’ve held at Pixelgrade when looking for a fellow developer to join us. We knew we wanted a person with an eye for design, a good understanding of how CSS works and the ability to implement simple features writing clean JavaScript code. Well, there should be a lot of frontend developers out there ready to take this job. Or should it?
I can tell you that most of those who we’ve reached were their favorite framework developers. Some of them knew their craft very well and had a good grasp of how JavaScript really works, they didn’t like CSS and would have done anything to avoid the mess it can make.
They really enjoyed what their favourite framework did for them and wanted to pursue that path. For others, their favourite framework was in fact their entry point in the frontend field and they still have a lot more to learn. Some of them were really nice people but they weren’t flexible at all and, most of the times was an easy pass for both sides.
My two cents
It seemed like we weren’t looking where we were supposed to. However, even though we’ve been developing WordPress products for more than seven years that doesn’t mean we should’ve been looking for a WordPress developer. I myself just wrote about how WordPress shaped my professional path in all these. However, I wouldn’t call myself a WordPress developer. It would defeat the purpose.
With each interview it become more and more obvious. It didn’t really matter if we had the same understanding of what Frontend Engineer, or a UX Developer, or a Full-stack Developer is. It was more important to find someone with a good understanding of how the web works, who is flexible, eager to learn and with whom we shared the same values and were able to connect to each other to bring everything to the next level.
Start the conversation