Javascript Developer or Front-end Engineer?

This is going to be an opinionated article, but I believe there is a difference between a Javascript Developer and a Front-end Engineer. The difference is one of code quality. I’m not saying that to besmirch any javascript developers out there, but rather to highlight a shortfall found in a lot of them. The tone of this post may come off a little condescending in some places, but I don’t intend for it to be. This post’s main focus is on making us all realize that there are plenty of things we don’t know, no matter where we are in our career.

With the recent explosion in javascript development frameworks, the barrier to entry these days is so much lower than it was in years past. It’s easy for anybody to dive right into a framework and learn what they need to know to crank out a halfway decent site, at least on the surface. However, a lot of these sites are a nightmare under the hood, and in addition, the abstraction that frameworks provide means that even if people learn a framework well, even inside and out, they’re really only learn its API, and not the nuts and bolts of the javascript that goes on behind the scenes.

I find that a lot of javascript developers don’t bother to take the time to learn raw, low-level javascript because it’s just so easy to learn these APIs that handle it for you. Those that do have a pretty good grasp of the language don’t fully understand some of the concepts one should use when writing well-organized, scalable code. This leads to a lot of spaghetti code in the window object, a lot of repeated code amongst different files, callbacks being passed anonymously all over the place, lots of DOM manipulation, instance-level accessor functions, etc.

On the other hand, front-end engineers not only have a decent grasp of the language itself, but also an understanding of software architecture principles, and put those principles into practice when writing their code. This can mean any number of things: organizing functions into object namespaces; using closures to encapsulate and separate code; writing smaller, more cohesive modules that are bundled together to create more complex patterns; using object prototypes to minimize your code’s resource footprint in the browser; exposing all functions for automated testability; DRY principles; event delegation; MVVM/MVP patterns; literally too many to list here.

When we interview job candidates, one of the first questions I typically ask is for them to rate themselves on a scale of 1 to 10 in a variety of categories, with 1 meaning “I think I heard that word once before” and 10 meaning “I could write the spec from memory right now if you asked me to.” Most people realistically fall somewhere right in the middle. Even I wouldn’t rate myself higher than an 8 in any given category. However, even explicitly stating the extreme ends of the scale to our candidates doesn’t stop some of them from rating themselves a 10, even if they’re more like a 3 by the end of the interview.

This highlights a concerning disconnect, or a misguided sense of bravado, on the part of a lot of job candidates. Some probably just think they’re a lot better than they actually are. This typically stems from a person just not knowing what they don’t know. As I myself get better and better,  it becomes easy for me to recognize things that others may not know, but is still every bit as difficult to figure out what I still don’t know. The only way to combat this in myself is to read as much as I can (books, blogs, articles, other people’s code), and to continue to work and collaborate with other people in this industry. Never underestimate what you can learn from other people, even people you may think you’re smarter than. Nobody is truly smarter than anybody else, it all comes down to differing skill sets, areas of expertise, and perspectives. I’ve had plenty of “Aha!” moments from people under me at work, just by listening to them talk about something I hadn’t considered previously, or spinning something in a different way than I’m used to seeing it.

If there are any javascript developers out there that would like to become front-end engineers, hopefully this site can be one of many in your own learning process 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *