I was reading a year-end article by UX Trends, about the struggles of the swiftly expanding UX career path, and I see a lot of similarities to what we are facing as Frontend developers and engineers.
Like many other modern tech fields, there are hundreds of mini-specializations that come along with the work we do. More than just CSS, HTML, JS, or frameworks, I'm talking about things like CSS Architecture, HTML Emails, Serverless, Server-side JS, or the build systems for those frameworks. The more you specialize, the further away you can feel from some parts of the knowledge people assume you have (based on your job title).
Let's take the example of an Angular specialist. Someone that's comfortable sitting on that line between what's considered Backend or Frontend. They create components and also suggest API improvements. They understand how to model data, but also how to deal with User Interactions.
Now, let's imagine that specialist has the job title of Frontend Software Engineer. This fits what they excel at, and all is well. But then, suddenly, a new CSS feature is released, and the apps they build with Angular start to feel a bit outdated because they aren't taking advantage of this. Their clients begin requesting new features or redesigns that make use of this new feature, and our developer starts to feel like they are a bit of an impostor, not being up to date on the latest and greatest of the Frontend world.
Or, take the opposite side, someone that is a master of applying CSS across all versions of IE and Safari and beyond, but couldn't write a Node app to save a small puppy from freight train. This person might also be comfortable on the line between Frontend or Designer, and happily take on requirements without designs, trusting in their own skills to make the right decisions for layout and spacings.
But if their title is Frontend Software Engineer, they will likely be forced to deal with JS. And eventually, they will encounter the assumption that they know how to work with websockets, or setup a greenfield project with Webpack. And while I believe they can, that's not the same as their wanting to, or finding it easy.
Both of these personas are Frontenders. But both feel slightly misplaced. Worse, no matter how confident someone is with the things they love to do, when facing something they struggle with, impostor syndrome sets in.
Reading about it, it seems we're not the only ones facing this. UX-ers also cover a wide spread, from copywriting to video-editing to user-research to design systems. In both cases, we are feeling the pressure that the tech industry has often felt: Explaining what we do to the outside world.
Maybe it's time to stop worrying about that, and to embrace our spans. Especially when we work in bigger companies, you can be allowed to just be "that coder that designs", or "that designer that codes". But for this to work, your company has to have a way to know what you're best at and to use your skills in the right way.
At Netcentric (where I work), I think we're moving towards this model. We have Pathways (FE, UX, BE, etc), and currently everyone is part of just one. In the near future, I can see each employee instead being part of communities based on multiple pathways. We can do this because we have a system in place (our Badge System), that lets us gather proof of our specializations. If I'm good at Angular, I collect the badge for it, if I'm good at using Sketch, I collect that badge, and yes, overall, I'm mostly in the Frontend. But a colleague that's on the cusp of FE and UX, or FE and BE, can be given work for either of their spans, and trusted to do it well based on their badges.
I can see that this is idealistic, and a lot more thought and repetition would have to go into it before it becomes a standard for the tech industry. But if you're in a position to change your own mindset to this, to embrace your spans, then I think you can at the very least speak up and ask for the kind of work you know you're best at. And that might be the start of something new.