I'll admit it, i'm posting this as a question because i write it as an answer to another question and it was deleted. I think it's a really good question though. How do we pick books, how do we decide which ones are good. So i'm publishing this as a community wiki question.
First off, the reputation of the publisher matters. Not all books from a good publisher are good.
Right now i'd say the best books are coming out of Pragmatic Programmers, followed by O'Reilly, Addison Wesley, no starch, then Apress. So with no other knowledge of the author or subject, i'd choose a book in that order.
Beyond publisher, there's the reputation of the book. You know the book is good if it's got a name other than the title. For example, there's the Camel book, which is really titled Programming Perl. If a book is good enough to get a short hand name in the community, it's a canonical text. And of course if you want to learn that subject, get the book.
There are several primary styles of tech books being published today.
Manuals
There's the manual book, the classic is the Perl Camel book for example, it's not meant to teach you the language, but to document it, it's half walking you through learning, and half reference. In ruby the similar book is Programming Ruby, called the Pick Axe book. A manual is good to have, but won't hold your hand through learning a new language.
Quick Reference
Such as the Vi reference or the regular expressions pocket reference. These are short books which you keep at your desk because it's easier than pulling up another web page as reference. They're only useful after you've already gotten in to something. But on the plus side, they are usually cheaper.
The Tutorial Book
I'm personally not a great fan of this category. Agile Web Development With Rails and the Django book both fall in here as good examples, but so do all of the learn x in y minutes books. If you're not sure what to buy, buy one of these books. But NEVER NEVER EVER buy anything which tells you how long it will take to learn. They are always crap books which are packed with filler.
The Cookbook
A cookbook is organized around a series of recipes for how to accomplish a discrete task. There are cookbooks for every major programming languages and they are useful references, with the exception of the O'Reilly Python Cookbook which has way to many arcane recipes and not enough generally useful ones. In addition to languages, some frameworks and applications have cookbooks, I contributed a few recipes to the Rails Cookbook for example. A cookbook should NOT be the first book you get on the subject, rather it's the kind of thing you get later to fill out your understanding of an area.
The Picture Book
Not everybody learns the same way, so there are tech books aimed at different styles of learning. The picture book genre is relatively new, but can be a great way to learn a subject quickly. There are high and low brow tech picture books in the market. The high brow series are the O'Reilly Head First books and the low brow books are the For Dummies series. I personally quite recommend the Head First Design Patterns book as a compliment to the very academic and dry Martin Fowler books on the subject.
The Academic Style Books
The opposite of the picture books. The biggest academic style publisher in the tech space is Addison Wesley, all of the design pattern and agile development books are published by them. The fundamentals of computer engineering get written first here, then popularized in other styles of books. These are also the hardest to grok of all the tech books. A classic example is the The Art of Computer Programming which everybody owns but nobody reads, in part because all the examples are in pseudo assembly. If you're trying to brush up on your fundamentals you'll get more out of reading these books recommended by Martin Fowler than you'd get out of a 4 year CS degree.
About the Author
I tend to avoid books which are written by the creator of the technology being covered. The first English language Ruby book was written by Matz himself. It was terrible.
The best books are written by the serial authors who know how to cover a topic well. Take for example David Flanagan who's written best selling tech books on java, javascript, and ruby. These are the people who live two lives, one as professional developers and the other as authors and communicators.
What about everybody else? Well look at the blog of the author, is it good? Search for their name, are they a participant in the community. If they aren't, and all you can find are references to the book itself, the avoid it and choose another. Because if they aren't participating, they aren't connected, and if they aren't connected, they are going to make mistakes.
Read Reviews
Not all reviews are useful, one person will say a book is to technical while the next says it doesn't go in to enough depth. Particularly in the tech world we always have somebody who knows more about the subject. Everybody but the technology's core creator has gaps in their knowledge of the tech, and as i already said, the core creator is a very poor person to communicate how things work anyway.
Reading a few reviews can help you get a sense if a book is terrible or not. Mostly it's useful to figure out if a book from one of the better publishers is a lemon.
Read the book - Creative Commons
Many books are written either online as a process or released online under a creative commons license after the book has been published in print. I think this is great that people do this and it's a wonderful way to see if the book is right for you. Unfortunately reading a book on a computer sucks, so most of us who don't have nifty ebook readers have to get the dead tree versions anyway.
Buy lots of tech books
And i don't just say this because i'm an aspiring tech author myself. :-) Seriously, the cost of a book is about the same as going out to dinner, some books are a nice dinner with wine, some are a burrito. There is a lot written in tech books which simply isn't covered the same way in online documentation. A lot of work when in to preparing the book, editing, some fact checking, trying to put together a whole work which communicates an understanding of the subject.
In Summary
I think of it this way. A conference talk gives you a sense is what the technology is, it describes its shape. The blogs tell you wants going on now with it and how to solve many problems which arise. A book tells you how to use it. Look at the source tells you how it works.