Is front-end development having a identity crisis? — Part II Late in 2018 I wrote 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. Is front-end development having an identity crisis 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. We need to ask ourselves three questions: So what is a front-end developer anyway? — 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. 1. What platform are we developing for? — 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. 2. What language are we developing in? — 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. 3. What is my skill level and job title? 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 . 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. barrier to entry — 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? Honestly I had no idea what to tell him 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 Burnout 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 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. front-end developer. 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 . Organizations often don’t understand the roles they are hiring for and we are partly responsible for this. educate recruiters and organizations 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 dev.to, 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. We need to . Titles are muddy and lack hierarchy which can disable a developer’s authority. This has a direct impact on our compensation and career growth. call roles what they are I am really struggling with where I currently identify as a developer. I primarily do custom-built WordPress sites and am most fluent in HTML, CSS and JavaScript. A comment by Jenna Schultz on dev.to, Part I of this series Organisations and leaders need to make a clear split between front-end, back-end, full-stack and software engineering as titles. This will help us standardize roles and responsibilities; and ensures that compensation associated with roles are fair. We need to . Technical interviews are a necessary evil, but perhaps we should be testing the problem solving skills of a candidate rather than their memory. reconsider the way we hire Tech deep divers are off the table for me. I only do conversational style interviews. I try to feel them out as much as possible but if I get in an interview and it slips into deep-dive I just say “I don’t know” to everything and end it ASAP A comment by Sean Anderson on dev.to, Part I of this series Test candidates in an environment similar to the one they will be working in. Most developers work in an environment where they can use resources like StackOverflow to solve problems, so why do we expect them to solve problems blindly under immense pressure and scrutiny? Rather than testing candidates on a phone call, give them a problem they can solve in the comfort of their home with all the tools they’ll have access to at work. The problem doesn't have to be easy, but this will give you a good sense of the quality of code they write and their problem solving abilities. If you still need to do a telephonic technical interview, ask them questions that test their problem solving abilities rather than whether they can recite a for loop. Allow candidates to — lead them to success rather than expecting them to be rock stars from day one. learn on the job Lastly remember to . We are all eternal students and often face the same challenges — it takes practice and patience. Sometimes we just need to take a step back and remind ourselves to enjoy the journey. cut yourself some slack Follow me Medium Dev.to LinkedIn Twitter
