That’s actually something I find particularly lacking: quality books on the topic. I think I’m fortunate to have been programming for two decades — over half that professionally — before I ever even heard of JavaScript. Now another two decades plus deep into using it, I’ve got the experience to make choices you generally won’t find in any book.

The best resource I can recommend isn’t a book, it’s a website. Mozilla Developer Network. They should be your go-to for most everything as they are “best in class”.

I don’t necessarily agree with how a lot of their examples are worded, but they are far better than most of the schlock you’ll find out there, particularly when in this age of “frameworks for everything” you pick up a book that says “learn JavaScript” on the cover and 99% of it requires garbage like jQuery to even function.

It’s very hard to convey what I’ve learned because it’s not something you’ll find between the pages of a book or in a simple tutorial. It’s decades of experience talking.

THAT SAID you want to know a really good way to self-teach? Solve other people’s problems! Go find a forums where people are having problems, then try to solve their problems pro-bono. You might not get the best answer, admit up front “this isn’t my thing I’m just learning”, and try to come up with new, different, or innovative ways of solving the issue. Part of why I’ve done so many free rewrites for people in the past wasn’t just to teach, but also for me to learn.

It’s very easy when all you do is solve your own problems to get into a rut, thinking you know what you’re doing and that your solutions are the best. Simple fact is other people often have problems that you don’t. They do different things from what you do. Trying to solve their issues teaches you problem solving and exposes you to thinks you’d never even try on your own.

I think that’s my biggest problems with most books and career educators. They seem bound and determined to make you rote memorize a handful of answers so that you can shoe-horn existing code into fixing every problem, rather than teaching critical thinking and actual problem solving. It’s why so many people prattle on about “Algorithms” and “Paradigms” when in point of fact, they’re just blindly copying the same “programming models” whether they fit or not.

I’m reminded of when in my mid ‘20’s I was sitting in a room full of geometry “experts” who were trying to implement a laser scanner that could match the curvature of the inner-eye as a new type of optometry tool… and they had this blackboard covered in complex sin/cos algebraic BS because it was how they were taught the math of it worked… and the hardware at the time simply couldn’t handle such math in real-time and hit the price target.

Being the raw rookie fresh hire in the room I was back-seated until I stood up, said “ENOUGH!”… walked up to the chalkboard, erased it all, and wrote:

distance := distanceArray[axisValue];

The math needed a distance of double precision (4 bytes) and had an axis granularity of 4096 motor positions… that’s 16k of data, effectively nothing even in the age where 4mb of memory was minimum spec. Use a lookup table!

And do you know why I thought of that solution that was escaping the more senior dev’s in the room? Because they learned in the big iron collegiate world, whilst a decade prior I had been writing games for the CGA equipped 8088… the 8088 had no hardware multiply/divide and instead ran a very slow microcode for those operations, so it wasn’t uncommon to use a lookup table for the Y-axis memory address rather than multiply by 80. The 4k required for the lookup table being a small sacrifice for a 4x speedup. I knew a technique they didn’t. That’s NOT on them, it’s on the fact we all bring different experience to the table. 99% of the math they were talking was WAY over my head and still is to this day… but my different experience brought a solution to the table they lacked knowledge of.

Don’t assume the book answers are right, or even where you should be starting. The best way to learn is by doing and thinking, not blindly copying.