JavaScript Training Sucks

I’ve been interviewing JavaScript developers for jobs on a fairly regular basis since 2010. I have helped scale apps from zero users to millions of monthly active users. Through all of that, there is one common theme: almost everybody knows a little JavaScript, but almost nobody really understands JavaScript.

99 out of 100 JavaScript developers I interview lack the skills required to hit the ground running on a scalable production JavaScript application.

This is a very real, very serious problem.

Understanding JavaScript is Vitally Important

JavaScript is the standard programming language of the web platform, and increasingly, all software is becoming web software. Productivity apps, mobile apps, games, wearable computing, cloud services, IoT devices… you name it, the trend is the same: They’re all relying more and more on JavaScript.

npm is the largest programming language
package repository in the world.

We all Depend on JavaScript

Software is eating the world, the web is eating software, and JavaScript rules the web. You can code in other languages, of course, but Node.JS is taking over the server side, and compile-to-JavaScript languages make up a tiny fraction of the programming language popularity rankings. Npm, JavaScript’s standard package repository, is the largest package repository in the world, and it’s still growing very quickly.

The fact is, most of the world’s software infrastructure is heavily dependent on JavaScript: perhaps the world’s most misunderstood programming language.

I recently wrote a pair of articles on JavaScript: The Two Pillars of JavaScript part 1 and 2. In those articles, I describe what I consider to be the two most important features of JavaScript: prototypal OO and functional programming.

The Myth of the 10x Developer

It’s very common to hear about developers who are ten times more productive than average developers. The problem with this fuzzy math is that it assumes that the average developer hire is a productive hire. The truth hurts, so brace yourself:

If you hire average developers without an adequate supply of senior developers to monitor commits and mentor them, you are slowing down the productivity of your whole development team. I’m not just talking about a short-term effect that lasts the duration of the developer’s employment. I’m talking about lasting effects: technical debt that will still be causing your team pain potentially long after the average developers move on.

The trouble is, the average developer may close tickets quickly. Managers sometimes confuse them for 10x developers because they blindly charge forward and get things done: but they leave serious damage in their wake.

You’re paying people to
slow the rest of the team down.

A 10x developer doesn’t have to be very good to be 10x better than average. They just have to be competent enough to avoid leaving heaping piles of technical debt in every part of the code they touch, and (if you’re really lucky) competent enough to clean up other people’s technical debt when they find it.

Of course, everybody has to start somewhere, and every developer is going to pass through average developer territory before they become good, productive developers.

Here’s the problem: Most of the developers I interview have at least 1–3 years of experience, and 99 out of 100 lack a basic understanding of the fundamentals: the two pillars of JavaScript.

If you’re one of the 99, it’s time to level up. I’ve seen newbies progress past this stage in less than a year, and go on to be much more productive assets than those who don’t bother to learn this stuff. You want to be better than 99% of other developers at your job? First, assess yourself:

The Interview

Lots of JavaScript interviews will ask questions about basic JavaScript idioms, syntax, and quirks. Questions like “Do you know what hoisting means?”

I used to do that. I used to also include questions about things like event delegation, `this` context binding, the effects of `setTimeout()`, etc…

I don’t ask any of those questions anymore. I start (and frequently end) every interview with two questions that every JavaScript developer should have ready answers to:

Can you show me an example of prototypal inheritance?

When I ask this question, I’m looking for a basic understanding of the essence of prototypal OO. What is it? How is it different from classical inheritance? What are the advantages?

An entire section of my book, “Programming JavaScript Applications” (O’Reilly) is dedicated to this topic. Understanding the pros and cons of various forms of inheritance is vitally important to scalable application development and the usable life of the code you write.

Depend too much on classical inheritance,
and you will be on the fast-track to a painful rewrite.

Can you show me two example use-cases of closures?

Interestingly, this question doesn’t necessarily test functional programming. What it does tell me is whether or not the candidate has a good grasp of one of the things that makes functional programming a usable paradigm in JavaScript. In order to get good at functional programming in JavaScript, you must have a good understanding of closures.

Closures are the key to encapsulation in JavaScript. They enable true data privacy for objects, and protect against function side effects.

Ironically, having a poor understanding of how closures work can cause tight coupling and side-effects when they’re misused, which quickly leads to unmaintainable code and a breeding ground for bugs.

Functional programming can be taught, but only after the developer has a good grasp of closures.

In order to get good at functional programming in JavaScript,
you must have a good understanding of closures.

Learning The Two Pillars of JavaScript

I rate prototypal OO and functional programming as the two most important features of JavaScript. They’re essential components of all JS application architecture. Both prototypes and closures are very heavily used in every large-scale JavaScript app I’ve ever laid eyes on.

99 out of 100 candidates bomb
at one or the other, or both.

In JavaScript, it’s literally impossible to be really effective at asynchronous programming without understanding closures and the negative impact of side-effects. The problem? All JavaScript applications depend heavily on asynchronous programming skills.

Likewise, effective processing and organization of data relies heavily on working with objects. If you don’t know what a prototype is, how to use concatenative inheritance effectively, and how to avoid the pitfalls of class-based programming, it’s going to cause problems.

JavaScript Training is Great… at First

Most JavaScript books and training programs are great at teaching you the basics of imperative and procedural programming. Those are important fundamentals to grasp, to be sure. The problem is that they frequently drop the ball there, or proceed to teach you how to mimic classical inheritance in JavaScript, which is frequently problematic.

It’s problematic even if you don’t realize it. Class related problems tend to sneak up on you, and frequently, programmers familiar with classes don’t even recognize the pain it causes until it’s gone. When I switched from C++ and Java to JavaScript and stopped using classes, it was like coming out of a dark tunnel into the light.

Once you’ve learned about (and practiced) variables, arrays, object literals, loops and if statements, it’s time to crank it up a notch and learn about concatenating objects, callbacks, higher order functions, transforming arrays with `Array.prototype.map()`, and so on.

Most JavaScript books suck at teaching you the essence of prototypes and functional programming: fundamental building blocks of modern web applications.

In order to address these issues (and broader questions like what concerns are important to think about when you build an application), I wrote the book “Programming JavaScript Applications” (O’Reilly).

It’s designed to help somebody with 1–3 years of JavaScript experience level up and become a more productive application developer, and it’s a great resource if you want an overview of what’s involved in programming scalable, production applications.

The trouble is, you only get so much depth from a book. I didn’t spend much time telling war stories about real production apps that I’ve built. I didn’t spend a whole lot of time explaining any particular concept in depth. I feel pretty guilty about how I skimmed over functional programming and didn’t really give the reader new to functional concepts a good grounding.

It’s still the best resource I know of to introduce you to JavaScript application architecture and topics that are frequently neglected in most other programming books, but we can do better.

A New Approach to JavaScript Education

Because of the enormous void in the extremely crowded and confusing JavaScript education space, I’ve spent the past year or so developing a different type of educational experience for people who want to learn JavaScript.

Learn from the mistakes of others.

It seems most JavaScript training programs lean too heavily in one direction or another to impart both practiced skills and wisdom. There are two ways to become a wise programmer: Make a whole lot of mistakes in your own code, or learn from the mistakes of others.

I find the best way to transmit wisdom is to tell stories. If I only tell you that classical inheritance is bad, you probably won’t believe me. If I tell you stories about how it’s wreaked chaos in projects I’ve been involved in, it gives you the opportunity to feel the pain and gain a real understanding.

For story telling, few mediums work as well as video. It’s high bandwidth. It transmits audio, video, body language, vocal inflections, and a lot more. It helps drive home points more easily than you can with text alone… but most of the video based programming lectures I’ve seen rattle on and on without giving students the chance to really absorb things. After about 15–20 minutes, students start to get distracted and their attention drifts.

The best way to learn how to code is to code.

Students need an opportunity to practice a concept before moving on to the next one. Information needs to be soaked up gradually, a little at a time. I find 5–15 minutes of video at a time is ideal.

Video is great, but the best way to learn how to code is to code. Books are a pretty lousy medium for teaching programming skills because you tend to get so wrapped up in reading, you forget to practice.

To be truly effective, every programming course should pack in lots of practice exercises.

Don’t underestimate text. Good text can be instructive and persuasive, and students don’t need a remote control to absorb it at their own pace. Books can also communicate visually with charts, graphs, and illustrations to drive the points home.

Students learn well in groups. Study groups are a fantastic way that students can learn from each other. Only practice is a better teacher than teaching. Tutoring, mentoring, and collaborating with other students will exercise the same skills you’ll be using frequently on the job. The best way to be a 10x developer is to help 5 other people be 2x developers.

Welcome to the Future of JavaScript Training

A really effective JavaScript training program will include all of those elements, and it will focus heavily on the fundamentals. It’s not OK that so many developers have a shaky grasp on the most important concepts in JavaScript. JavaScript is a multi-paradigm programming language, and it’s unwise to ignore any of those paradigms. Eventually, you’ll be faced with code you don’t understand, or challenges you don’t know how to solve effectively.

“Learn JavaScript with Eric Elliott” is a series of courses that focus on transmitting skills, knowledge, and wisdom as efficiently as possible. They’re absolutely packed with important lessons I learned building apps for millions of users over a career that spans more than 15 years.