Ted Neward has some great advice about how to review a technical manuscript that I wanted to highlight.  I'm using my 4-hour train commute to review a technical book that I'm pretty excited about.  Ted's article was helpful.  He also has a great way of looking at technical books - positioning books as a deal between a book and a reader:

when I write a book, I'm offering the reader a deal: "You trade me $40 of your hard-earned cash and roughly 40-80 hours of your non-refundable time, and in return, I will give you something you didn't have before, some knowledge that you find useful." If my book doesn't keep my end of the bargain, the reader takes it back to the store, but can never get back the time spent, and so is left feeling cheated and upset. In some books, the classics like "Design Patterns", or K&R, or "Rapid Development", the deal is so obviously lopsided in the reader's favor that these books go on people's shelves right next to the monitor, for frequent perusal. But the thing to realize is that it's all about the deal. Does the book fulfil its end of the bargain?

Searching for and finding books that keep their end of the bargain is one of my key passions.