Customer Reviews

A Baker's Dozen: Real Analog Solutions for Digital Designers

5 star:		(4)
4 star:		(0)
3 star:		(1)
2 star:		(1)
1 star:		(1)

 

 

Anyone who works in electronics outside of the RF field knows that analog circuitry is being eclipsed by digital. However, analog is not truly dead, and will never be. Baker shows that many digital systems can benefit from judiciously-applied analog circuitry. New engineers would also benefit from the many case studies that the author discusses, such as the tradeoffs associated with using a particular kind of A/D for a specific application. This book bridges the analog and digital worlds, and gives the reader a foundation for delving into more specific knowledge that may be needed, such as in/op-amps, or DSP. However, much of this material will be known to engineers that have been in the EE field for some years, so the book is really aimed at students who will soon graduate, and engineers that just got their first design job.

Doesn't anybody edit books before they're published anymore?

This book is a beautiful compilation of knowledge, wisdom and tips on the subject of analog circuit design. It's written by one of today's leading experts on the subject. I ALMOST enjoyed reading the book and digesting its contents. I mean, I read the whole thing, and I ALMOST enjoyed the experience.

There was just one problem with the book. It is very poorly edited.

From the front cover to the back cover, it seems like I've had to add a handwritten correction to every other page of the book. I will ignore technical errors for the purpose of this review (except that she got the two's complement notation for -2 wrong in the first couple of chapters - come ON!). All the rest are errors involving:

*spelling errors
*typographical errors
*homonyms and homologues
*word usage and sentence structure problems
*grammar mistakes
*awkward phrasing or misuse of common idioms
*noun-verb disagreement ("is/are", for example)

This is not the only technical book I've encountered with an editing problem. It seems like most, if not all, of today's technical books have serious editing problems. Sometimes they're total disasters, like those written by Myke Predko (don't take my word for it; go read the reviews on amazon.com and barnesandnoble.com), but more often they're books like this one, where the technical content is (mostly) accurate, but the writing appears ... um ... "sloppy" isn't fair to the writer ... more like poorly edited.

It simply looks as though the editor wasn't doing his/her job. If I had to guess at what happened, I'd say that the publisher assigned a non-technical editor to Baker's book, and the editor was so bamboozled by the technical content that she completely forgot about her own ability to manage the basic mechanics of writing.

It's also possible that Baker told her publisher she wanted to edit the book herself. In a world of word processors and automated spell checkers, I fear that this is becoming increasingly common, especially among engineers who think that with the right manual or tutorial and a week to study it, they can become an expert on any subject. (This is the "any engineer can become a ..." syndrome. You read it here first, folks.)

But folkloric wisdom points out the problems with being your own expert: The taunt "Physician, heal thyself" shows up in the Bible, and a more modern proverb asserts that "Any lawyer who chooses to represent himself has a fool for a client." Authors shouldn't be their own editors.

Or maybe Baker's publisher, tight on cash (or just plain tight), had laid off too many editors and assigned this book and five others to a junior editor or intern with a one-week deadline. The junior editor had to let something slide, and this was it.

Or maybe Baker's editor was a raging incompetent, whose own literary skills are not very far above those required to produce modern high-school newspapers and yearbooks.

Good editors, like good schoolteachers, are worth their weight in gold. They're an overworked and underpaid bunch, and they may feel like we expect too much of them, but a good editor can make the difference between a "good read" and a waste of paper. My editors have always done a fantastic job, making a huge difference in the finished product.

You can't just jack into a port on the matrix and download the skills necessary to become an editor. It doesn't work like that. Every author should have a competent professional editor. Lacking a competent professional editor, every technical author should have an author whose writing they admire, and who is not a member of their technical profession, to go through their manuscript and fix their writing.

(If you want a more mainstream example of the difference a good editor can make, then look at the quality of language in Tom Clancy's The Hunt for Red October and compare it with the quality of language in the Tom Clancy's Op Center books. Clancy didn't write the Op Center books; he just lent them his name. He should have lent them his editors. The Op Center series is overburdened with horrendous language errors, which repeatedly bring the story to a screeching halt and ultimately cause the reader to throw down the book in frustration.)

I would further suggest that every technical author should ask a colleague whom they view as a competitor, or with whom they share a mild animosity, to review their manuscript for technical errors. Who is better qualified to find errors in your work, than someone who doesn't like you in the first place? Asking esteemed colleagues and best friends to check your work is great, but your greatest asset as an author will be someone who will root like a truffle hound for your mistakes.

Want a counterexample? Horowitz and Hill's The Art of Electronics is not only a technical treasure and a bible among electrical engineers, but it's also beautifully written, an example of how well English prose can be turned to instruct in even the most technical subjects. It's always worth reading and rereading, not just for the technical education, but for the exquisite turns of phrase.

(Fair use: this review first appeared in my blog.)

So many errors/typos throughout, that no one could figure this thing out. I have used some of these circuits before, and understood them from a different perspective; trying to understand her explanation was like pulling teeth. I spent hours trying to figure out what the hell she was talking about. It is an expensive book, and merely shows a few random examples of circuits. Save your money for a box of donuts.

I don't have this book, but using the "LookInside" feature, I found many typos.
For instance, there are three typos in the first entry of the ADC Definitions,
i.e. Acquisition Time. There are several more immediately following.
It doesn't seem that anyone took the time to proof-read this book.

What can I say, Bonnie is simply the best. Her book is well organized, informative, practical and an excellent addition to even a seasoned designers book shelf. The information in this book is something any designer should know that is serious about understanding how to properly merge the digital and analog domains.

I have not yet read this, but this author's work in EDN magazine is second to none. If her book is as well done as her EDN articles, this book is a must-have.

This book brings together the analog and digital domains in a light-hearted and readable way. The author focuses on issues that come up in design instead of delving too deeply into theory. Very good job.