The bad news: you can't know what parts of what you don't know will be important. I can give you some recommendations, but so can everybody else, and they'll be

The bad news: you can't know what parts of what you don't know will be important. I can give you some recommendations, but so can everybody else, and they'll be different from each person. I'd look to high-level people in the field like Peter Norvig for recommendations, but that only narrows your options slightly. If you know what you want to do more specifically (i.e. security) try to find recommendations by an expert in that area (i.e. Bruce Schneier). But ultimately you're still hearing opinions, not facts. The good news: It probably doesn't matter that much. Different programming books will give you different strengths and weaknesses, and that's a good thing because teams need diverse skillsets. It's been years since I wrote production code in a strongly typed, statically typed language, but I did that for so long that I still think in types, and I bring that structured way of thinking to the table in Python/Javascript, which means I avoid a lot of the mistakes those languages allow you to make. I've worked with people who were very comfortable with metaprogramming, which always feels messy to me because it inherently muddles types. It's not a tool I ever reach for, and I push back when people add metaprogramming to codebases, which is a good thing, because too much metaprogramming can be bad. But sometimes, judiciously used, it can be very effective, so people with metaprogramming skill will solve problems that would be very difficult for me to solve. If we had both read all the same fundamental programming books, we'd never have these diverse skills that make our teams effective. TL;DR: Pick the first one from a reputable organization and do it. Time spent agonizing on this decision is time wasted.