This is a very real, very serious problem.
npm is the largest programming language
package repository in the world.
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.
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:
I used to do that. I used to also include questions about things like event delegation, `this` context binding, the effects of `setTimeout()`, etc…
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?
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?
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.
you must have a good understanding of closures.
99 out of 100 candidates bomb
at one or the other, or both.
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.
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.
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.
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.