I think the difference between a junior and senior front-end developer isn’t in their understanding or familiarity with a particular tech stack, toolchain, or whether they can write flawless code. Instead, it all comes down to this: how they push back against bad ideas.
What I’ve learned this year is that web performance will suffer if you don’t say no to the marketing department because you’ll suddenly find yourself with eighteen different analytics scripts on your website. If you don’t say no to engineers, then you’ll have a codebase that’s half React, a quarter Vue and another quarter built in a language you don’t even recognize. If you don’t say no to designers, then you’ll have a ton of components that are very similar to one another and that will eventually end up confusing everyone in your organization. And if you don’t say no to project managers, then you’ll forfeit the time necessary to build an accessible, responsive, baseline experience.
What you need to build a great website is restraint.
But! The problem with working on large-scale projects with hundreds of people is that saying “no” can be political suicide. Instead, you have to learn how to say it without sounding like a jerk. You need to educate everyone about performance, responsive design, and accessibility. You’ll need to explain to folks what front-end development even is.
And that’s because the hard part is that saying “no” requires justification—even mentorship—as to why something is a bad idea when it comes to building a website.
The even harder part of all this is that front-end development is boring to everyone else, except us. No one cares about the three weird languages we have to write. And certainly, no one cares about performance or accessibility until things suddenly stop working for them. This is why the broken parts of the internet are felt by everyone but are mostly invisible to those who build it.
All of these lessons have reminded me of a piece by Robinson Meyer for The Atlantic about the threat of climate change and how the solutions are “boring as dirt”, or BAD for short:
The BAD problem recognizes that climate change is an interesting challenge. It is scary and massive and apocalyptic, and its attendant disasters (especially hurricanes, wildfires, and floods) make for good TV. But the policies that will address climate change do not pack the same punch. They are technical and technocratic and quite often dull. At the very least, they will never be as immediate as climate change itself. Floods are powerful, but stormwater management is arcane. Wildfires are ravenous, but electrical-grid upgrades are tedious. Climate change is frightening, but dirt is boring. That’s the BAD problem.
The “boring as dirt” problem exists in our industry and every organization we work with. For instance, the performance of a website is obviously a terrible problem for users when they’re trying to report a blackout in their area and the website can’t load because there are a dozen or more third-party scripts loading at any given time.
But fixing that problem? It requires going through each script, talking to the marketing department, finding out who owns what script, why they use it, what data is ultimately useful to the organization and what is not. Then, finally, you can delete the script. The solution to the problem is boring as dirt and trying to explain why the work is important—even vital—will get you nowhere in many organizations.
So, how do we avoid boredom when it comes to solving front-end development problems?
We must realign it with the goals of the business. We must mention our customers and why they need responsive interfaces when we talk about CSS. We should start a newsletter when we do a ton of great work that no one can see.
And when someone has a bad idea that hurts the web? We should, as politely as we can, say no.