I saw this question on Zhihu recently, and the answer felt right enough that I wanted to leave a record of it here.

What makes a good front-end engineer?

Original post: http://www.nczonline.net/blog/2007/08/15/what-makes-a-good-front-end-engineer/

Nicholas C. Zakas wrote about this years ago. His point was straightforward, and it still holds up.

At a Yahoo! interview event, someone asked him: "What do you think makes a good front-end engineer?" He realized the question was too big for a quick interview-room answer, so he wrote it down.

First, you have to know HTML, CSS, and JavaScript well enough that you are not constantly blocked. You don't need to memorize every edge case of each language, but you have to be able to actually build things without needing to ask for help every ten minutes.

Second, you have to learn fast. The web does not sit still. If you only use what you know today, you will be obsolete tomorrow. A good front-end engineer just accepts that constant learning is part of the job description, and knows how to turn new things into working code quickly.

Third, front-end is not pure math. There is taste involved. The same visual can usually be built in three different ways, and none of them will throw a syntax error. A good engineer knows that just because a solution works doesn't mean it's the right one for that specific context.

Fourth, communication. Front-end engineers sit right in the middle of everyone else, and everyone else wants something different.

Product Managers care about whether the feature exists and meets business goals. They usually want everything.

UI Designers care about visuals, interaction, and feel. They want it to look perfect, even if the CSS is a nightmare to write.

Project Managers care about stability, deadlines, and risk. They usually want to avoid anything complicated that might break.

End Users just want to use the thing. Their feedback matters most, because if they leave, the rest of it doesn't matter.

So whose side do you take? All of them. The job is to balance those competing demands and find a way forward that actually ships. Sometimes you have to tell a product manager that their feature needs to wait. Sometimes you have to tell a designer that their interaction will ruin the page performance. You have to understand what each person actually cares about and explain things in a way they can hear.

This is why I always tell new front-end engineers not to just take a task and start typing blindly. When someone says "this is broken," ask what they were actually trying to do. When someone says "add a button," ask why. Adding a button is easy, but figuring out if a button is even the right answer is the actual job.

Front-end engineering is strange. It requires deep technical knowledge, some design sense, product thinking, and a huge amount of talking to people. Writing code might get you the job, but knowing how to build the right thing with other people is what makes you good at it.