Is front-end development having a identity crisis? — Part II

Late in 2018 I wrote Is front-end development having an identity crisis as the first part of this series. I was surprised by how popular it was not because of it’s obvious click-bait title (guilty); but by how well it resonated with the community. When I gave Part II as a talk early in 2019, the nods in the crowd were almost unanimous — this is clearly something we need to talk about. Ultimately many developers feel the same: Front-end development as a role has become ambiguous.

A short summary of Part I

Species evolve into many variants or sub-species as a result of natural selection. These sub-species all have different attributes and qualities and ultimately make each of them unique.

Technology is no different. In a way, technology has given rise to hundreds of sub-species of programming languages, paradigms, frameworks and libraries, each with its own unique properties and challenges.

Take JavaScript as an example.

Credit to reddit user u/TheDoctorWumbology

JavaScript has evolved into several massive technologies for both the back- and front-end. The problem with this is that the lines between front-end and back-end, or application and website, or designer and developer, have become blurry. The concept of “front-end development” has almost lost its meaning.

So what is a front-end developer anyway? We need to ask ourselves three questions:

1. What platform are we developing for? — As developers we have the option of building for multiple platforms: Mobile, desktop, web or server. Front-end traditionally dealt with the user interface of an application but the rapid development of JavaScript has shifted the role into almost all of these platforms.

2. What language are we developing in? — This shift in platform contributed to the rise of technologies like React and Angular, each with their own set of rules and paradigms. Languages like PHP, Python and C# have also become part of the front-end stack in many organizations as they enable us to build services and APIs.

3. What is my skill level and job title? — The lack of clarity on platforms and languages result in a mixed bag of job specifications that takes away from our understanding of the title. Some front-end roles require back-end skills and some engineering roles require UI design skills. None of these roles are standardized.

So why does any of this matter?

Ambiguous job specs

In the example below, on the left, the developer is asked to know both Angular and Ionic. Granted there is some overlap between the two technologies, but they are both large frameworks each with their own nuances. Pair this with the graphic design requirement (which has nothing to do with front-end) and you’ve got yourself a very demanding role.

Example of front-end job posts on LinkedIn. You can read more about my findings in Part I.

The post on the right requires experience in Angular, Java, REST and MongoDB. This role is basically a full-stack, but the salary on offer is measly and the title of this role is front-end developer.

Barrier to entry

These job posts seem harmless, but they actually create a barrier to entry. Recently, a friend wanted to change his career path to something he felt was more future-proof— so he asked me how he could get into web development.

Honestly I had no idea what to tell him — the road to master front-end is long and full of terrors. Is there even any benefit in learning HTML and CSS when you’re just starting out, considering how demanding entry-level front-end roles are?

I look at this ES6 snippet and honestly question how a junior is meant to memorize and understand this level of code. The reality is that this level of understanding has become an expectation for front-end developers and my view is that this leads to developers getting burnt out.


In 2016 I came to the conclusion that I would become obsolete as a front-end developer unless I jumped on the React or Angular bandwagon. I spent some time learning React and realized that I would have to include Node in my stack as well. At one point in time I was learning ES6, Node and React at the same time.

This was hard.

My days turned to 15 hours as I was juggling training and delivering massive projects at work. I was getting up earlier and getting less sleep and the stress of it all compounded. Yes, a year later I knew React and Node, but I was paying the price. This burnout had a massive impact on my personal life and my work and in a way I am still recovering.

Technical interviews

Despite my burnout I was feeling confident in the skills I had learned so I started looking for new opportunities. React at the time was a rare skill in South Africa so I got invited to do interviews fairly quickly. The first interview is always easy, but I was not prepared for the technical interrogation that followed them.

I prepared for these technical interviews but still flunked anyway.

Technical interviews can be hard, especially if you are just starting out as a developer or if you are new to a technology. Technical interviews are important when hiring a developer, but they rely too heavily on our ability to remember technical jargon.

Job titles

Let’s say you ace your technical interview and get hired, now your title is front-end developer. You walk into your first meeting with stakeholders and the project manager asks the table to introduce themselves. Sally goes first: “I’m the head of digital and I look after the sales funnel of business unit X.” Joe goes next and introduces himself as “the product owner and project lead”. It’s your turn and you mutter “I’m the front-end developer” under your breath.

You instantly lose authority in that room.

The reality is that titles do matter. They carry authority and with that authority comes things like compensation and career growth. Often circumstances force us to accept titles that don’t necessarily fit our experience or outputs and this can quickly box us into a role.

How do we solve this?

Now that we understand the problem in a bit more detail, what can we actually do about it?

Firstly we need to educate recruiters and organizations. Organizations often don’t understand the roles they are hiring for and we are partly responsible for this.

Company leaders just hear stuff on YouTube or BuzzFeed and slap it into their job descriptions willy-nilly, not realizing that they’re seeking a brilliant, made-up unicorn employee. 
A comment by Ruth Reyer on, Part I of this series

As team leaders, it is our responsibility to educate our organization and ensure that their job specifications are accurate to the role it needs to fill. We are also responsible as developers for questioning our roles and responsibilities and making our leaders aware of these discrepancies.

Lastly we don’t challenge recruiters enough. They cast a wide net on platforms like LinkedIn and very quickly dismiss you based on criteria that they don’t even understand. I have personally found that recruiters are very open to hearing feedback on their job spec; and this feedback also positions you as an expert.

read original article here