I've come across a few of those "bare minimum you need to know to do X" posts on SO and on one hand I think they can be great pointers to the best reference material in a given field.

On the other hand I worry that these kinds of lists promote an impractical approach to mastering a field that is at odds with being a "Hacker".

Think of it as being like Waterfall Subject Mastery versus Lean Subject Mastery. In Waterfall Subject Mastery you try to anticipate what you need to know up front, learn a bunch of stuff, then try to apply it to a problem. There are two problems with this model: First, you really don't know what you need to know. Second, you won't really understand it as well in the abstract.

With Lean Subject Mastery OTOH, you pick a problem and crank on it until you run into a wall. Then do some learning until you can overcome the wall. At first the walls will be many and frequent. But over time your baseline of competency is increased and you actually become productive in the new technology.

What's great about the lean approach is that when it comes time to learn about a specific topic, you have a much better context for understanding it, and thus the effort to learn it is greatly reduced. And because you have an active project, you can put your learning into practice more quickly and thus retention is increased.

The secret, though, to making LSM really work well is to commit to learning a bit more than just what you need to get over the wall. This is the difference between truly learning and being an eternal cargo culter. Don't just start banging against the OAuth library; try to understand how OAuth works. Just do it in the context of a real-world problem.

Don't get me wrong. I'm not against education and learning for learning's sake, I'm just more for efficiency and getting stuff done.

Another advantage of just-in-time learning is that forgetting is less of a problem. You don't have to worry about forgetting in between the time you learn it and the time you use it, and the fact that you've used it both helps you understand it better and gives you a working example to use as a reference. (Am I the only one who looks at their old code to see how they did something?)

Probably the best is to sort of skim over the stuff you're supposed to know at first and then refer to it when you're reminded of it in your everyday work. Like the breadth-first approach Steve Yegge advocates for math: http://steve-yegge.blogspot.com/2006/03/math-for-programmers...

The only problem I've found with this approach in practice is that skimming makes me antsy.