I've fallen in love with a book again. why is the phone on fire? is Sherlock Holmes for geeks and should be required bedtime reading for students in POE (the Olin class that says "here, a microcontroller; go build something mechatronic"). It's a collection of tales involving electrical engineers at a fictional consulting company trying to figure out embedded bugs (the bugs are based on real-life fiascos).

There are occasional code snippets and prompts telling the reader to stop and take a glance to see what they can figure out before proceeding with the story, but instead of making the book feel hokey, they actually make you stop and appreciate it more (and grimace at some of the code; Lisa Simone has included some realistically icky pieces of C in order to demonstrate how good and bad code "feels" - thankfully, that particular chapter involves refactoring the ugly mess.)

My favorite character is Li Mei, the bright-but-hesitant team newbie who's fresh out of school. She knows stuff by the book but is less versed in the unwritten tricks of the trade, and contributes (not always correct) guesses in a combination of timidity and enthusiasm that reminds me a lot of... well... myself. She's eventually taken under the wing of Josie, the cool, experienced engineer who serves as the right hand (wo)man of Oscar, a blunt and efficient ace debugger who's just been promoted and is still getting the hang of managing people rather than components. A young, quick, but just a mite too independent hardware hacker named Ravi is the last member of the quartet. Eduardo from testing (formerly a programmer) makes occasional appearances and shows just how far you can get in debugging without having to look at code.

Some comments:

(1) Holy cow female electrical engineers that aren't token minority inclusions. Josie and Li Mei actually think, talk, and act like female SparkEs I know - in particular, Li Mei's hesitation (I'm not the only one that worries about wasting my coworkers' time and overcompensates with perfectionism?) and Josie's slightly protective, gentle approach to mentoring (she asks Li Mei how she's doing which gives her "permission" to respond - in contrast, Oscar assumes Ravi will speak up with the inevitable questions about what he doesn't know how to do). It's not that different from how male SparkEs act, but I appreciate that the two characters aren't just male engineers with larger breasts and higher voices.

(2) Engineers are people too. The ones in this book get frustrated, cheer each other up; their work is affected by how they're feeling, they get angry at each other, they rejoice together, they socialize over dinner and beer at the pub down the street, they make mistakes, miscommunicate, get cranky when they're tired, their eyes light up in realization right when they're on the verge of fixing a tricky bug. It's a neat view of life in an engineering department. If you haven't gone out for an engineering internship yet, read this book first. I sure wish I'd had it before my stint in Continuum.

(3) Neat pedagogical tricks for hacks you usually don't find in textbooks. Instead of throwing an explanation of PWM in the appendix, we see Josie explaining it to Li Mei during a site visit where a temperature sensor's gone awry (complete with diagrams and Li Mei asking those questions you always wanted to but felt stupid to say out loud). Instead of a dry footnote about checking processor speeds when porting to different hardware, we see Oscar showing Ravi an old Pong game he'd written in 1993 and how it's been rendered unplayable by the orders-of-magnitude-faster CPU of a new computer. By following Li Mei through drawing a flowchart, we learn how to make one ourselves. By watching over Oscar's shoulder as he tiles "DEADBEEF" into flash to check where a program is storing its data, we learn about memory fill patterns.

(4) Code and problems that look real. They're messy. Sometimes they're ugly. They're confusing. Sometimes they' not thoroughly tested or well documented. Customers are irate. Emails are written in caps. Variables don't get initialized. Long strings of if statements show up where switch statements should be. Off-by-one errors pop up in array indexes. Receivers don't receive what the transmitters say they've transmitted. Equipment needs to be debugged on the factory floor, not by dissecting the intermittently failing machine (which is still in operation) but by talking to the non-technically-trained foreman, whose answers need to be translated into engineerspeak. At least these have nicely explained answers at the end for those who want a sanity check on how they did.

(5) It's fun to read. This above all - it's well written and actually keeps you up all night turning the pages. It may be slightly unfair for me to say this, since I tend to get more absorbed in books than most, but oh! Would that other writers of electrical engineering textbooks could take a cue from Randall - with some intro tutorials and a ramp-up series geared towards raw beginners (Oscar teaches his twin middle-schoolers about the AVR Butterfly?) this might be the kind of thing we need to get more kids interested in electrical engineering. I wish there was a regular column of these coming out - I'd totally subscribe.