I have a lot of pride in my work. Why shouldn’t I? I care about the entire process of building a feature from code quality to the accuracy of the implementation with the mock-ups. In other words, I don’t half-ass my work. Unfortunately, this pride is often besmirch by the frequent assumption that my work is easy.
I am not interested to get into the debate of which kind of engineering is harder. I acknowledge that every sector of software engineering has its own complexity (so does front-end development). This is about giving front-end engineering the respect it deserves which is lacking in the industry.
Often times when I’m reviewing FE code from potential candidates, I am told to lower my bar by the very same people who view it as easy in the first place. Doesn’t matter if the code is bad as long as it is rendered find by the browser. Readable/maintainable code doesn’t apply to mundane Javascript and the even more boring CSS.
What happens next? They ended up hiring the same kind of engineers—the ones that are strong on back-end—because there’s an imbalance on what they value. And all of the front-end work ends up on a single front-end engineer’s plate. But don’t worry, that front-end engineer can do everything because it is easy.
Why is it often seen as easy? A question that I often asked myself but never really get into writing it down. I have several assumptions on how this mindset is further amplified throughout the industry. Front-end development has a low bar to entry. It is easy to get something to appear on the screen immediately. It is very forgiving and it doesn’t complain right away if you are using an obsolete tool to achieve a certain task.
Will the browser complain if someone is creating layouts through tables instead of using recommended tools like CSS grid or Flexbox? Not really, even though it is not the standard of building layouts today. What if you used setInterval instead of requestAnimationFrame for your JS animations? Depending on what you’re doing, the browser won’t complain immediately but run those animations for some time and you’ll notice a lag in running the animation.
The complexity comes in having the right knowledge; knowing which tools are the right one for the job and understanding how to use it properly. In order to gain the right knowledge, one must be willing to invest the time in learning these tools. Most people tend to skip the learning part since they already have the assumption that the topic is easy in the first place. Why bother learning more when I’ve got it working?
I think it has something to do with CSS too. CSS gets a bad rep in the industry because many people don’t understand how the cascade works. They ended up writing bad CSS code and assume that CSS is broken. Since CSS is a big part of front-end life, I wonder if people just assume that front-end developers are just bad coders since they deal with CSS all the time?
The same people who can’t figure out how the basic cascade works are the same people who think CSS is easy are the same people who think CSS is broken are the same people who think CSS should be in JS…
— AMBER NO SCROLLJACK (@amberweinberg) September 9, 2018
There’s possibly some politics at play here but I rather not comment on it since I am not an expert in analyzing the politics of our toolings and how it affects our industry. Also, an attempt to analyze it will open a can of worms that I rather not go into. I think this post is already controversial enough as is. Or is it?
We can debate all day about the good and bad parts of CSS and JavaScript; they both have them. But JavaScript is forgiven, like a man, and CSS is marked like a woman. One ‘means well’; the other is the embodiment of sin.
— hey don’t 🌹 (@heydonworks) September 5, 2019
I believe that job titles help perpetuate this mindset too. Most of these engineers will have generic titles like software engineer or full-stack engineer which only reinforce the misconception that they can do both front-end & back-end really well. They are supposed to be comfortable working on the entire stack—most of the time, they are—but I have yet to meet an engineer who’s really good at both; their knowledge gap shows a strong preference towards one over the other. There is nothing wrong with this since no one can be good at everything. One stack shouldn’t be seen as more valuable than the other though.
There’s also a common misconception that because we love front-end, it is the only thing we know how to do. This couldn’t be further from the truth. At work, I have the opportunity to put on multiple hats. I work on purely front-end on one project and work on the entire stack on another. Although I see myself as a full-stack engineer, I am front-end dominant. Skills can be always be taught and learnt.
Front-end engineers aren’t the only casualty of this mindset though. Most of the time, I notice that designers are affected by it too. Since there’s a false assumption that most of these back-end dominant software engineers can either learn FE tools quickly or do it as well as an FE engineer (because it is super easy, mind you), the front-end tasks are assigned to them. As a result, designs are not implemented to a tee and designers don’t often get what they originally requested.
Design culture is pretty much non-existent since it is heavily dictated by engineering. Now, I think lack of time can be a reasonable excuse but this should be discussed clearly with the designers. This is an opportunity for the designer and engineer to work closely together in order to brainstorm better alternatives. This does not happen as often as it should though. Instead, shortcuts are taken without consulting the designers and features are shipped without getting any feedback from them.
If you haven’t experienced this kind of culture, good for you. My opinions are based upon my own experience working at several engineering-focused offices. That being said, it is not like this everywhere. I have been told by several friends that the mindset is slowly changing. Also, at Indeed (I currently work here), two front-end centered roles are created specifically to ensure that design is implemented accurately and that FE performance as well as accessibility is taken into account. Front-end developers are expected to partner as closely as possible with design teams.
However, if you’re a front-end engineer who is currently working at a place where you don’t feel valued, it can be very demoralizing. My advice is for you to start looking for opportunities where you can create value. In my experience, back-end dominant engineers who implement designs often overlook things like accessibility. This is definitely an opportunity for you to create value either by running a manual accessibility audit or even create a checklist on accessibility that everyone can refer to. And no, Google Lighthouse score on accessibility is not enough. It is a start but it shouldn’t stop there.
If you find code quality or test coverage to be subpar, perhaps create a guideline or rulings based on that. Overtime, such efforts will be recognized and will be seen as valuable to the team. There are many ways to create value; the idea is to make a critical contribution where no one has the skills or the motivation to do so.
It is also important to continue re-skilling yourself. We work in an industry that is constantly changing. It doesn’t hurt to continuously learn and upgrade your skills. Throw in a little bit of back-end knowledge too for good measure.
I don’t have a solution to this problem and I hope that the mindset in the industry is truly changing. I can only offer several tips that have worked for me in the past and I hope it will help you too. Respect is earned but it seems that front-end engineers need to earn that respect over and over again every time we found ourselves in a different environment. But remember that no job is perfect and this is one of the many mundane problems that we have to face.