Last week, one of my students asked me what makes someone a good front-end engineer.
This is a highly subjective topic, but I’m happy to share my very opinionated perspective on this.
The least important skill for a front-end developer
The least important skills for a front-end developer to have are technical ones.
With a solid foundation of other skills, the technical stuff becomes an implementation detail.
They can learned on-the-job. And as you get more technically proficient, they can be learned more quickly. Sure, it’s helpful if someone already knows your stack and the tools you use, but it’s way less important than everything else.
Critical skills for a front-end developer
If technical skills don’t matter all that much, what does?
This is, to me, the number one skill of a good developer.
All technical details are is the way you’ve chosen to solve a particular problem. Know how to work through the thing you’re trying to accomplish and figure out the right approach and combination of tools is the skill that helps you get there.
And problem-solving is a skill that translates across disciplines.
Being good at solving non-developer problems often means you’re good at solving code problems, too. So much of good problem solving is really just breaking a big thing into smaller parts and tackling them one at a time.
Like, for real.
I’m a senior developer. I manage dozens of open source projects, at least one of them C-list popular. My code has been used by organizations like Harvard Business School and Apple.
I Google how to do things—sometimes really basic things—every single day.
As you know, I share a ton of code snippets and helper functions in these articles. I have to look up my own code all the time.
I created an entire website of code snippets and helper functions just so that I wouldn’t have to keep Googling the same stuff over and over again.
Being able to craft a search term that gets to the root of what you want to do and finds valuable content online is a real, valuable skill.
So you Google how to do something, and get a handful of results. Some blog articles. Some Stack Overflow questions.
How do you decide which one to use?
Our industry pushes new tools and techniques at a break-neck pace. New frameworks. New libraries. New approaches. Yesterday’s best practices are today’s anti-patterns and vice-versa.
How do you decide what approaches and tools and techniques to actually use?
Being able to sort the signal from the noise and make more informed decisions is super important. It’s also a skill that you’ll suck at at first and get better at over time as you gain more experience.
This is one of the biggest failings of our industry.
We often focus so much on how to do things and (to paraphrase Dr. Ian Malcolm aka Jeff Goldblum from Jurassic Park) if we can, that we don’t stop to ask ourselves if we should.
We don’t think through our designs and our implementations from the perspectives of people who aren’t us.
Not all users have the latest browser (or can even replace theirs). Not all users have fast, powerful machines. Not all users have the latest smart phone (or a smart phone at all). Not all users have a reliable internet connection. Not all users can reliably use a mouse or see the screen or see colors. Not all users have the same cognitive abilities that you do.
But we build websites for a homogeneous audience of people just like us.
Empathy means being able to understand and share the perspectives and experiences of someone else. Empathetic web development means understanding that users bring many different experiences and abilities with them, and building things accordingly.
The developers who are most effective at working on teams are not always the best coders. They’re the best communicators.
They clearly document their work. They can explain what they did and why to people who don’t always have the same technical skills or background. They share what they know and elevate the entire team.
A developer who can communicate well makes the entire team better at what they do.
How many times have you tried to use someone else’s code, or make changes to it, and had no clue what to do or where to start? Think about how much time you’ve wasted trying to figure stuff like that out.
How much more efficiently would you operate if someone more clearly communicated how things work to you?
Communication is a critical skill.
If you haven’t noticed by now, the skills I think are more important for front-end developers have nothing to do with how quickly you can code something or how fast you can solve a white-board challenge.
The way we interview developers is fundamentally flawed. It often focuses on all the wrong stuff.
Technical skills. How quickly they can solve ridiculous trick challenges under pressure that won’t exist in their actual job. Memorizing pointless details you can always just Google later.
I use to work in HR, and after transitioning into web development, wrote a book on how to navigate the complexity of the hiring process.
Because you’re a reader of mine and you’re awesome, you can grab a free copy with the code
FREECAREER at checkout.