Very much so; QSM especially (originally a 4-volume series, JW has reissued them in ebook format along with other titles).

missed by the meal-replacement manufacturers

"How does it compare to Slim-Fast" seems a relevant question here.

write better routine software than your average programmer

The average programmer already emulates the Watson algorithm - search Google for answers to "how do I" (sort a list, create a new Qt window, rotate a cube in OpenGL) and slap together any likely-looking chunks of code in a language that might compile. It's even automated already.

The only problem is, of course, GIGO.

Linus Torvalds invented Linux and probably knows everything.

Doubt that very much. Linus is the creator of a kernel, which is only a small (though important) part of the whole shebang people call "Linux".

For most people, it probably doesn't matter all that much whether your "stack" includes Linux or FreeBSD or any of the other kernels you can find.

Similarly apache is going to be largely invisible to people who use a web framework at a higher level of abstraction than CGI (that would be most of today's frameworks).

Bottom line - I agree that describing one's "stack" in the above form is uninformative. Say not the names of products you had to memorize; say the things you can make them do.

I heartily recommend pretty much all of Jerry Weinberg's books to all software developers. The Quality Software Management series is awesome; a lighter but still impressively useful starter book is Are Your Lights On, which teaches how to ask the right questions when you have no freaking clue what is going on. Secrets of Consutling is another good one.

You won't find a line of code in these books. What they tend to teach you (well, me, anyway, YMMV) is how to gain an understanding of the non-technical essence of a problem. In 99% of cases the technology isn't the issue anyway; the problem-solving skills (or lack thereof) of the people involved are.

For the remaining 1%, pick a few products or frameworks that appeal to you and become intimately familiar with them, at the "critiquing a work of art" level. Then attempt to build something equally challenging; a virtual machine, an emulator, an OS kernel, a compiler, a whole video game, a web framework, that sort of thing. Deep expertise in any given thing will transfer well, if you have also mastered the art of problem-solving in general, i.e. when you have (to start with) no clue what is going on.

I used to be a decent Java expert, but nowadays I'd go to some lengths to having that kind of label slapped on me; the pay is much better working on problems at a higher level of abstraction.

Software developers have to repeatedly and continually learn massive number of new concepts, procedures and techniques related to the latest languages, frameworks and technologies up and down the stack.

Do they? That sounds kind of wasteful.

IMNSHO the best software developers are those who spot the underlying patterns, so that they don't have to continually relearn new stuff that will be obsolete (but sadly still need to be maintained) in five years.

Read books that address the deep stuff, you'll save lots of time.

I'm still reading 10:23 in the body of the post and in the meetup sidebar.

That's a time lag (rather than something more sinister, e.g. something fundamentally flawed in the LW code base's understanding of integers); the rankings are not recomputed on a real-time basis, but the scores are.

I'll be there at 2pm.

The "how" is more important than people usually guess. You can get higher quality results by using tools such as exact matches and searching by date, over a naive Google for basic search terms.

One technique I use often is inspired from "stemmatics", I've got a short write-up with worked example on G+. Another example is my results for this question on LW.

Another useful technique is knowing how to exclude some search results; NOT operators can be incredibly useful, eg when one of your search terms is very common in a domain not related to your query's domain.