Wow! Thanks for asking a great question. The short answer is: I don't have a secret!
More seriously, I have three prinicples that I follow for all books that I write.
First: Organization. I strongly believe that a good technical book is a well organized book. This means that topics must be presented in logical order, in which no feature is used until its explained. I believe that many otherwise good books are greatly harmed by disorganization, or are overly fragmented.
Second: It's the reader that matters! The only reason that anyone would spend good money to buy one of my books is because they want to learn how to program. Thus, my goal is to ensure that by the end of the book, that goal has been accomplished. Thus, the mission of each book that I write is to successfully teach the topic.
Third: Clarity. I believe that books must be clearly written and easy-to-understand. By easy-to-understand, I don't mean childish. I just mean that a good progarmming book should be readily understandable to its audience: other professional programmers, and people who want to be professional programmers. Towards this end, I spend a lot of time crafting sentences, getting descriptions just right, testing code examples, and re-reading my work before submitting to my publisher.
Actually, if I do have a secret it's this: Before a submit a chapter, I print it out on paper. Then, I wait a day and read through it one last time. This helps me catch any holes in the discussions, check the sequencing, and otherwise just make sure that the chapter feels right. Also, I still like writing last-minute changes in the margins of the printed copy. (Paper is a very old, but still a very good technology for interactive editing!)
Actually, taking the last read-through on paper helps me see the chapter from a slightly different perspective, which I find valuable. Frankly, these final read-throughs are a very important part of writing, as far as I am conerned.
For my latest books on Java, including my Java Programming Cookbook, see HerbSchildt.com