Frontend —what?
In July 2019, Brad Frost wrote about Frontend Development being overloaded with JavaScript these days. And he’s damn right.
Even though Brad’s article is mostly about learning the react framework, there are some bits I’d like to quote here.
He describes the role of a “Frontend Designer” and the tasks as follows: “Crafting semantic HTML markup, Creating CSS code, Authoring JavaScript that primarily manipulates objects in the DOM, Testing (and I assume also fixing) across browsers and devices, Optimizing the performance of frontend code, Working with designers, Working with backend & application developers.”
He says that it’s “…hard, nuanced work that requires a lot of thought, care, and attention. Frontend Design is a full-time job and should be treated as such.” I totally agree with that statement.
However, when it comes to the task “Working with Designers” with the following description: “[..] to ensure the brand, design vision, and UX best practices are properly translated into the browser”, I feel like this is not enough. In this situation “Working with Designers” kinda sounds like “you are the one that just executes the UX Designers commands”.
I worked with Frontend Devs who only do what the Designer dictates. I also happened to fix those outcomes later, because the Designer hadn’t thought about everything and the Frontend Dev didn’t put a deeper thought into it. Since I’m a hybrid between Design and Frontend, or Unicorn (some people think it’s controversial calling people like me that way), I simply can’t just execute commands. I always have to ask why and what. Why this, why that, what happens when? I believe that the person who does the frontend, regardless of having design skills or not, actually should put further thoughts into it, always asking why and what, especially when the Designer is sitting in a silo.
The Problem with Frontend
Robin Rendle wrote about an article about HTML and CSS being seen as a burden and that Frontend Development has a problem back in November 2018.
I totally agree here, too, when he states that “[…] HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.”
HTML & CSS is not a programming language, but that doesn’t mean that it’s easy. Especially nowadays. Developers tend to see HTML & CSS as something that is just early game code and that it doesn’t deserve very much attention. You’ll learn that very fast, it’s not difficult, it’s just HTML & CSS. Or: you don’t have to learn it, Figma will generate it for you. In fact, I know lots of Senior * Developers who can’t write either HTML or CSS or even both. I mean, what? For most of the Backend Developers, and also when using BEM in CSS or Bootstrap, HTML is basically the trash can of the whole project.
What I don’t agree with, is Robin Rendle saying that we don’t have a problem with Frontend Development nowadays. Frontend Development has indeed a problem that’s needed to be solved. It’s what Brad Frost wrote: Frontend Development today is basically JavaScript. And it’s what Chris Coyer wrote in the article “The Great Divide”: Two armies of “Frontend Developers” having the same job title but doing completely different things.
Frontend is JS here, JS there, JS everywhere. We even build our CSS with JS. SASS is amazing but it requires JS to compile the CSS. There is no job offer in the frontend world without requiring expert (or at least good) JavaScript knowledge or knowledge in JavaScript Frameworks like React or Vue. Is it all about Frameworks? Like Chris coyer wrote: “I heard that sentiment from Estelle Weyl who goes so far as to say she thinks of developers more as “framework implementers,” reserving the title of engineer for tool-agnostic problem solvers.”
So what do you do if you’re a pro in HTML & CSS who always has an eye on A11y and loves doing animation magic with transitions and keyframes? Are you a Frontend Developer? Or something else?
Frontend Developer, -Designer, or -Engineer? Or Creative Coder?
After endless headhunter messages for job offers as Frontend Developer or even JavaScript Developer that didn’t even fit my profile the slightest bit, I added “Not interested in JS job offers” to my Xing and LinkedIn description. As this doesn’t seem to help, I went big and updated my online CVs and changed all the job titles I have listed from “Frontend Web Developer” to “UX/UI Designer & Engineer”. I felt like the word “Engineer” is not so much construed with programming as the word “Developer”. I also deleted everything that has to do with JavaScript. Even though I’m hiding some skills I actually have, I was just sick of these JS job offers because I’m simply not a programmer and I’m never going to be one.
I haven’t chosen the title Frontend Designer brought up by Brad Frost, for two reasons. First: the word Designer is in my title already. Second: I don’t feel good with the title Frontend Designer because I do not really consent with Brad Frost here. Once I tried to cut the answer short when I was asked what I’m doing professionally by saying “I’m a Designer”. That didn’t end well because the questioner was then assuming that I’m a Fashion Designer. This is probably due to the fact that Fashion Designers always only say “I’m a Designer” as if there’s nothing else to be designed other than fashion. But “designing” something in general always implies that you are heavily focused on the visible part whereas the Frontend is equally focused on the visible and the architectural part like semantics, accessibility, and SEO.
What about Frontend Engineer?
So there we have the word “Engineer”. But is it really what I have thought of? I found an article about the difference between the terms “Developer” and “Engineer” from Aaron Semof on Medium.
He says that “There is a fundamental difference between the roles of Developer and Engineer.” and he describes the difference as follows:
“Traditionally, an Engineer, no matter the stream of engineering, is a person who is competent by virtue of their fundamental education and training to apply scientific methods and interpretation to the analysis and solution of engineering problems. What this means in simple terms, is that an engineer has a fundamental grounding through education in engineering principles, and through the application of engineering concepts they create solutions.
A Developer, on the other hand, tends to be more creatively minded applying patterns and practices learned through self-discovery, on the job, reading books and blogs, or courses focused on specific aspects of the development life-cycle without the fundamentals of scientific methods and engineering principles.
[…] a Developer implements. Focusing their talents often on a single area, a specific task, or within a specific environment, without looking at the “bigger picture”. While an Engineer architects, always looking at the “bigger picture”. An Engineer can assume the developer role, but an Engineer’s core focus lies within the architecture, designing, and planning.”
In this article, Jason Roos, Software Engineer at Sony Interactive Entertainment is quoted as:
“The term “Engineer” typically connotes a “Builder” of some sort whose design process is methodical, involving a deliberate application of established patterns and principles.
If I were wanting to demonstrate that I can think creatively, and develop logical solutions to modular problems, which is very much what Web Development in the creative communications industry is all about, I would much rather be called a Developer.
On the other hand, if I want to demonstrate that I can apply scientific and engineering principles to create an overarching solution at a higher level than describing the workings of the many modules that make up the whole, then I would want to be called an Engineer.”
Given these explanations, I’d still say that I’m both, though. But I am not a developer as the industry uses it. I am quite bad at math and my brain can’t handle recursion and stuff.
Now talk about Creative Coder.
The title Creative Coder isn’t really specified. It’s not just a job on the Web but the whole Digital world. This is nice and like UX that was expanded e.g., to CX, which is also not just relating to the web. But reading stuff on the interwebs about Creative Coder gives a lot of different explanations that can vary a lot.
Below are some excerpts from various pages:
“For us, the title Creative Coder rather describes a skillset than a specific job position. People who break silos in their thoughts define the future. And this is a Creative Coder for us.”
“Creative coding refers to the handling of programming languages and code as a design tool for media production. This is not part of the effort to understand software development as an engineering discipline, but groups practices that can be described as bricolage, tinkering, or hacking (in the original sense).”
“Creative coding has its roots somewhere between design and IT. For many developers, concept, code, and design were no longer irreconcilable trades.”
“Just quickly showing what’s possible. Get a quick first result. Agile processes, design thinking, and permanent beta are terms that shouldn’t be missing in our conversation about creative coding. Creative coding is not in any specifications. It’s more about problem-solving in an often quite lean team. In fact, it is often the freelancer/one-man shows with an IT or design background that show what is possible.”
I can relate to some definitions. Some definitions, like the first one, (IMHO) should always be done regardless of the position you’re working on. But for others, I think of programmers who studied mathematics and/or computer science to do some mad magic to create lightning effects for animated films like Pixar does. Or to create one of those amazing data visualisations. Since I am far far away from this, I don’t feel good using the title Creative Coder for myself.
I am Engineer!
I feel that I don’t fit into the role of THE “Developer”, even though I am overlapping parts of the skillset described above, the title “Engineer” fits way better to my skillset. Reason 1: Yes, I easily get stuck in details but I always have a look at the bigger picture, which is a key point in the description of an Engineer. Reason 2: I am a total failure when it comes to key aspects of typical Developer skills, like understanding mathematics.
So I am really happy to ditch the word Developer from my title by replacing it with the word Engineer. The word Frontend is heavily occupied by JavaScript Devs but as described in this whole article, they are Developers. I am the Engineer. I’m still awesome at what I’m doing, no matter what Title I print on it. What’s a matter of fact is that I have a niche skillset. And that gives me superpowers. heuuuurrgh!
I found this blog post in my drafts and I started to write this in July 2019. Since then a lot of things happened in the world, in my job, and personal life. So I think it’s time to finally finish it.
—Jessman5 in July 2021 It’s April 2022 now and I guess (or hope) I will finally finish this post and publish it.
—Jessman5 in April 2022 So now it’s January 2023. 3,5 years after starting to write this article I finally managed to finish this thing. I am lucky that the topic is still relevant. It teaches me a lot. For example, the next time I start to write a blog post I’m gonna get this thing done asap! Seriously, wtf.
—Jessman5 in January 2023