Embedded - 64: Making Making Embedded Whoops

Episode Date: August 21, 2014

WHOOPS! We didn't record Elecia's mic this week and are taking a track direct from Chris' computer mic. Sound quality is not up to our normal standards. Sorry! Chris (@stoneymonster) hosted the show, asking Elecia (@logicalelegance) what it was like to write her Making Embedded Systems book. (Thanks to Chris Svec for the request!) Put in your idea to O'Reilly Write a novel this November with NaNoWriMo Come hear Chris and Elecia talk about writing software that can kill you at Hacker Dojo in Mountain View on Monday September 8, 2014, 7pm. Sign up! Also, bonus quotes: "Either write something worth reading or do something worth writing." - Benjamin Franklin "Almost anyone can be an author; the business is to collect money and fame from this state of being." - A. A. Milne

Welcome to Embedded, the show for people who love gadgets. I'm Christopher White, my co-host is Alicia White, and today we're going to talk about writing a book. That'd be my book. Yes, your book. One of our listeners, Chris Beck, asked, I wonder if you could share a bit about how you came to write Making Embedded Systems. He's considering writing a book and he wanted to hear your experiences and he suggested a title for the show recursive make

making making embedded systems which rolls right off the tongue um and we're not trolling you we're swapping roles this week because it's more natural for me to ask questions of her about her book than for her to just pontificate. But I could have pontificated. But you certainly could have just pontificated. I could have gone on and on. So without any further ado, I think the first place to start is what prompted you to decide to write a book. It's something you hadn't really done before, right?

Well, I did NaNoWriMo, which is the National Novel Writing Month, and I wrote that pretty awful novel. But, no, that was really separate. I mean, that at least gave you the opportunity to do a lot of typing in a short amount of time. It gave me the confidence to say, yes, writing is not the problem. All of the other things can be problems. What am I going to put in it?

How am I going to phrase it? How am I going to put it together? That can all be a problem. But you can't tell me that putting words together is a problem. It's a different experience with a technical book versus a narrative kind of. Well, with a technical book that, I mean, I was showing it to people whom I respected and who I didn't want them to think I was an idiot. But with the novel, all along...

You didn't respect any of those people. Well, kind of. Why would you read my novel? I don't respect you. No. Well, my mom only gave it four stars on Amazon. So, yeah. It wasn't a good novel, but it was NaNoWriMo. You're supposed to write a fairly terrible thing because you're supposed to do it in a month.

It's about quantity, not quality. Exactly. So I got over the quantity hurdle, which I think a lot of people who are like, oh, I want to write a book book they haven't gotten over the quantity hurdle yet and that's hard if you if you can't keep up a blog once a week for a month yeah that's tough and NaNoWriMo it's 2,000 words a day is the goal and so you get used to okay what do i have to cut out of my life to make my word goals? That actually played a big part in writing a technical book,

because I could set word goals, and I couldn't always meet them. But the goals were more like 1,000 words a day, and knowing that I would end up editing yesterday's down to 600, 800 words, as well as writing today's stuff um but you asked me why that that's you know that was enough to get into the fact that you had confidence that you could at least crank out the material but yeah why why this book what what drove you to say this this is a this is a subject that needs exploring and hasn't been done in a way that satisfied you?

Well, there were, there were two, two kind of pivotal moments. One that had happened years before and lied buried in my psyche. And one that, well, let's see, I had just quit a job because I wasn't happy and I hadn't really found a new one. Usually I managed to line up the second ones before I finished the first ones. And I was wondering, actually I was wondering with the manager I had just quit to, and we were talking about his junior engineers and building a library.

He had a bunch of embedded software engineers who were good, but hadn't quite made the hurdle into senior, and hadn't quite made the hurdle out of hacking together things for college. And they all had gaps in their knowledge. And some of them had come from mechanical engineering, some from electrical, some from software. And he wanted to build a library that people could learn from, learn the areas that they didn't know.

And you felt that, if I recall back then, you felt that embedded systems weren't a subject that was taught well, in school at least, and I think that's still kind of the case. You take computer science classes classes you might take electrical engineering classes but unless you're on like a robotics team yeah the robotics system or or or there's some specific class for systems integration that kind of thing it really it's a difficult subject to synthesize all of those fields together into into a a classroom situation and so most of us end up learning on the job well it's true of any job yeah but yes i mean usually you at least know the theory behind what you're doing i think people

come out of computer science departments able you know a lot of them have done databases and these kinds of things and they end up being able to just drop into a web situation. But if you drop your average CS student into a, build this medical device with motors and sensors, that's a different proposition. So were you trying to kind of bridge that gap a little bit too? Very much. And when I talk about my book, you know, I talk about how its goal is to bridge that, to whether you came from hardware and want to know software, whether you came from software and want to know hardware, you already should know half of what's in the book. And so it shouldn't be a super difficult read for you.

It's not a concrete wall of new information, which is how I'm finding some of Linux right now. But yeah, so there's the bridge. And when we were talking about building the library, we were talking about all the books that had affected us. I mean, Michael Barr's Embedded Systems book was pretty good when it came out. And then O'Reilly added a lot to it that was very timely,

very specific to what was going on in the field then. And I don't know how involved Barr was with that. It got a co-author at that point. And I don't know, it just wasn't a book I wanted to give to anyone anymore. Katsuli's Embedded Hardware was good if you were a software engineer and needed to understand a little bit more about hardware, but it didn't help hardware engineers understand software. And giving hardware engineers the Gang of Four Design Patterns book was just kind of mean. Well, that's useless to them.

I mean, it's like dropping them into an advanced CS theory course on language or something. And it's all the times I've picked up the art of hardware, art of electrical engineering. Art of electronics, I think. The silver book. The silver book. The silver book that lives in the living room

and now gets paged through whenever I'm interested. But it's pretty inscrutable if you haven't got a good basis. I mean, okay, so how do I get from Ohm's Law to... Well, four years of college. Yes, exactly. So I think a lot of us are trying to have shortcuts to the end. And there are shortcuts. And your book, I think, getting ahead of ourselves,

but it does provide some of those, okay, give me the punchline. I try. And I don't want this podcast to be an ad for my book because it's really about the process yeah so let's get back to that so but so so we wanted to build a library for his junior engineers and we kept hitting this wall of okay well that's a good book that should be in the library for sure but you need an introduction to that. And, oh, yeah, that book for sure, but you can't start there. And so he eventually turned to me. We kind of agreed that somebody needed to write a new embedded systems book that was introduction but more a ramp to everything else you needed to know.

And then he said, well, you know, you have some free time. Why don't you do that and i laughed and told him that yeah in my copious free time realizing i had just quit so but i i didn't plan on doing anything about it um but it kind of percolated and a couple days later i might as well riley's got this slush pile you just fill out the form and you you send them like a paragraph of idea and pragmatic press wanted you to have written many chapters and have a really concrete outline but o'reilly was more well hold your hand through it and i did did come from the CS side. Having an animal book, I wanted that.

So, yeah, but, I mean, is that all you had at that point? Was a paragraph kind of outline? Or had you had – how much planning for the proposal had you done? I mean, did you know all the subjects you were going to cover in the proposal? Or did you just say, what was your proposal to O'Reilly? Initially, the proposal was just an email and i think it's limited at like 200 or 500 words or something okay and it's just here's my idea and it was embedded systems design patterns hardware but not not about any particular processor i didn't want to write an arduino book i didn't want to write any specifics i wanted introductory material that was suitable for

for moving on um and and then they send you an email that says yeah okay so if you spelled our name wrong you shouldn't have submitted, which I found hilarious because my name is so often spelled wrong, that they were like, yeah, so this was one of the things you should do when you're writing a book proposal. Did you spell it wrong? No, no, I didn't. But I was amused by their form letter of here's the top three things people do

that's just wrong. And maybe that was in the before i emailed them but um and then but the response letter did say uh yeah this is the slash pile you knew that when when you saw the when you saw the web page so it's like applying to a job on hr it was totally like send my resume to Google and hope for the best. HR at Google.com and then they called the next day. That was probably the

oh my god, what have I gotten into sinking feeling. This was not really what I meant. I was hoping you guys would say that was coming out next month not will you talk to a vp and and so we talked and then and then he said yeah let's do this and i started writing an actual proposal now wait a minute wait a minute wait a minute he doesn't know you from anybody at this

point doesn't even know if you can write so how do you how did they go from well the yeah let's do this was yeah let's write a real proposal okay okay a 10 page outline with um with not a whole they didn't want whole chapters done right but they wanted enough detail that they could look through and say yes this is what we what we were talking about. And they wanted some other writing. I don't remember what it was. I guess I should have pulled that up before. Some sort of sample. But it was some sort of sample.

And it was like, oh, what do you care about? And I minored in theories of learning. And so I really care about how people think. And I know O'Reilly's got this book line that's head first. Right. And it's all lots of different example types and different games, and the books end up being really thick, but the information is much easier to digest.

And so I have this idea of I want to do that sort of thing, but I didn't want to do a headfirst book. Those are even more work. Why not? Because you have to design all of these interactive games to work with people to really, I mean, like word searches, which isn't really a critical part of learning embedded systems. But, okay, learning the jargon actually is kind of important,

and word searches make you think about the jargon. So, yeah. But all of the other headfirst things are pretty webby. Okay. And so it was easier for them to say, oh, and then go run this code. I see. And I didn't want to sign up to write a whole bunch of code myself because it always gets out of date so fast.

So I wrote the big proposal. And I passed it by the manager friends that had started all this. And he had a lot of suggestions. It was really great. And you had a lot of suggestions too. I don't remember. And so I passed it on to my friends and then I sent it back and I was assigned an editor. No, I think I hadn't been assigned an editor yet.

But they got it and they said thank you and then they said no. Yeah, how did this... They said no, you know, embedded systems just don't really do that well for books. So did it get to a different level where they hadn't seen it? Because everybody else

sounds like they were excited about the topic. Well, i kept talking to different people and i think i think o'reilly has this internal politics and i can be i can talk to one person who's very excited about embedded systems like oh yeah that's that's what's coming and definitely solid con this year indicated those people are winning right now. But their previous embedded books, the Katsoulis book and the Michael Barr book, hadn't done that well, not compared to, like, Python. Well, it's not a fair comparison at all.

It is to a publisher. Yes, I guess that's true. But everybody uses Python. It's like the maximal example of how much reach will this book have. And it's going to reach 95% of all software developers. You know, on the website, on the embedded side, on the operating system side, everybody uses Python for scripting. But to compare that against embedded systems, which know it's an it's a niche well then

embedded systems are arguably a bigger topic it's a python it's a bigger topic but with fewer people so no i understand where they're coming from but yeah that's so they said no and and that's the end you know okay well this has been systems wait no we changed the name i forgot already so they said no and then no and then and and he was very nice about it and he said you should talk to pragmatic programmers because this is a good idea it's just not for us and they were super nice about it and so i went and i looked more at pragmatic press i think it's the actual name and and they actually you know they pay more but they want more done ahead of time they do a lot less hand holding o'reilly really wants to hold your hand through the whole process editing

on a weekly basis as a first-time author that's not oh that's nice um but he caused it was 24 hours like to the hour later he said have you sold it yet i was just like you must be kidding me this is harry potter this is not no in fact i've barely looked at the pragmatic website and even that was done in a huge flunk of depression so no um yes it was a bit of a roller coaster so but but he called you back and said they changed their mind and they changed their mind and they were already in and uh and then we did a little bit more on the proposal because what he wanted was to be able to defend the proposal in his editorial board meetings. Okay.

And then that worked. And he went off and he said, okay, I think it's going to work. Give me like six weeks, we'll get a contract together. And then my life fell apart. Right. Our lives fell apart. Briefly. My mother passed away and then I got sick enough to be in ICU for a week.

So by the time O'Reilly got back to me, I was just like, yeah, book. You want me to what? You want me to do what? You want me to do something that doesn't involve watching television for nine hours a day? I know. We did go through a whole December of films and just TV all the time. Um, and that was,

I think that was probably the most disappointing thing looking back was that I should have still been so cracked. So happy. I don't think that that's ridiculous. And that's, and I wasn't, I was like, Oh God,

maybe I should turn them down. I don't want this to be a chore so okay I don't really remember what happened after that well I was at that point got assigned an editor Andy Oram and he's a really great editor

very software oriented and I talked to him for a while. I said, I don't know if I can do this. And he said, well, we're going to give you half the advance now, and if you say in a month we don't have to do this, just don't cash the check. It's not a big deal.

Just, you know, we'll try a chapter or two. We'll see how we work together, and we'll go on. And then from that point, I never really looked back. you know, we'll try a chapter or two, see how we work together and we'll go on. And, and then from that point, I never really looked back. And once, once you get started, I knew what I wanted to say. I knew what I wanted to do. That wasn't a lot of research, actually. Um, I did, I did a couple of things, research, not sure that I knew the best way, but, uh, mostly from there there it was, how do I present this in an information in a way that doesn't bore the crap out of people? And how do I present this in a way that is amusing?

Cause I want it to be funny. So that's what I wanted to get into is some of the planning, because at this point you've only done the proposal and, and I have an outline that says I want to have something in an outline, 10 chapters. done the proposal and and i have an outline that says i want you have something of an outline 10 chapters and i want the chapters to be like bootloading and optimizations and so how much time did you spend doing that sort of planning i mean sitting down and saying i mean presumably you didn't say okay this is a list of topics I want to cover and then put them

down in order and then shift them around you had some overarching kind of connected idea for how to present this information right so how did you go about developing that I had a lot of topics I wanted to cover I mean like state machines Do you cover state machines within, like, planning your system? Or do you cover state machines within their own chapter? Or do you cover state machines within, like, a deep dive into drivers? Right.

Because those are all very reasonable places to talk about state machines and how you go about writing one. And so I had opened to topics like that. And I wrote them down on post-it notes and i kind of oh i remember that the weekend and i i got kind of nerdy on it and i color coded them um there were pink ones for things i wanted to cover that weren't specific topics like how do you do design how do you do block diagrams like state machines and like how to do drivers like how to

just do an interface to a driver interfaces was another like tactical thing and then there were was another color for design patterns because I found a lot of value in knowing that there are these things out there that other people recognize as lego blocks and I wanted to make sure people knew they existed whether or not they used them I don't really care about that but I wanted it to be more than just here are some terms. It's like here are some terms and there are other ways to solve this, so make sure you at least recognize that you're not alone. And then I tried to shuffle them until I could get a consistent story in each chapter that was a combination of some tactical information, some theoretical information.

So you really storyboarded the technical book. Yeah, I really did. I didn't have an idea of my diagrams at that point except for a couple. And the diagrams were probably, thinking about the diagrams was probably 25%, 30% of thinking about the book. But the storyboarding yeah and i ended up with like four different versions and uh and then i i took pictures of the different versions and i typed them up as different specific more detailed outlines and then you know in that process i cut it it down. And I think I had two.

Did you go back and forth for the editor with that? When I got down to two, I went back and forth with the editor about whether or not optimization and math should be the same chapter. Okay. And I'm really happy now that they aren't because the math chapter is one that I think people don't read. And I don't blame them because it's painful until you need to use that thing. And now you should go out and use one of the many free libraries.

Yeah, but I mean, for tiny devices, sometimes you have to use that stuff. I found that chapter useful. But in planning a book or even software uh one of the things people i think one of the things that goes wrong a lot of times is people produce a list of the things they want to do a list of features they want to have in a particular piece of software and they get excited and tack more and more on and i think what separates good design from bad design often is taking things out and saying, well, I'm not going to do this. For the first version, we're not going to have this feature because we don't have time. We can't do it justice.

Maybe we'll do it later, but let's pare things down. For a book, this is a similar process, right? Because you could have written this book forever. Embedded systems is a giant topic. so how did you decide what not to do and and were there things that you regretted not doing or were there things that you in retrospect maybe shouldn't have done um but how do you how do you decide not to do well there were a lot of things that i i managed not to do? Well, there were a lot of things that I managed not to do that Andy wanted me to because I absolutely didn't want it to get out of date in a year. Okay.

It didn't, despite the fact that I was current on some TIDSPs and Cortex-M0 and some of the Atmega line from Atmel. I guess Cortex-M0 and some of the Mega line from Atmel. I guess Cortex-M3s, yeah. I didn't want to talk about any of those. I didn't want to talk about the specifics of those because that was going to change. And I didn't want to talk. There was a long discussion of if we should have a chapter about embedded Linux.

I'm like, no, you should have four books about embedded Linux. Not just one, but four, because it's a giant thing. Right, because the most you could have said is, hey, there's embedded Linux. Well, and then we talked about, what about if we just talk about the commonalities of operating systems? And I was like, how about we talk about bare metal and no operating systems? And that was a big choice. That was a big choice. You've gotten some criticism that, hey,

you don't talk about RTOSs at all. And I do use them. I find them valuable. But I like to know what's happening. And there was no way to cover an RTOS in 50 pages. That was one of the ways that i cut things out is that as an introductory book if i can't cover this topic in 50 pages i need to just put a pointer in and say it's a big topic go find it yourself and so there was a lot of of cutting things out because i can't

couldn't cover everything they also gave me a kind of crazy deadline, and they were up front with... Was it six months, start to finish? They wanted written six months, and then edited for three, and then post-processing for another three. So I got my proposal signed in December, and the book came out in the following November, which is pretty fast. Yeah, that's really fast. Um, but I didn't really understand that they tell everybody this and nobody does.

It was one of those cases where they gave me a deadline. I said, Oh crap. Okay. And what I should have said was, Oh, that's a nice suggestion. Well,

it's certainly motivating. I mean, if you're the right personality to be motivated by a deadline of that sort then that's that's great i mean some people would take that and probably fall apart and and and not do it i i i guess i'm trying to get to how did you how did you find that did you find that it was motivating did you I seem to recall you got up every morning pretty early and went and wrote for a couple of hours even though you had I think at that point you had had a three-quarter time job and there was you know you had a lot of discipline yeah um i wrote i got up 6 30 or 7 and because that is the time that is the clearest for me i'm definitely a morning person i wrote until 11 every morning um and i think we would occasionally take a sunday off but not always and definitely i wouldn't take sat Saturdays off. And then often

Saturday afternoon was editing, looking back at the whole week, trying to figure out if I missed any glaring things. Having such a good and detailed outline was helpful for that, but it was still possible if I wrote like chapter two and chapter six sequentially, because I didn't write them all like one, two, three, four. But if I wrote chapter two and then six,entially because I didn't write them all like one two three four but if I wrote chapter two and then six then when I went got around back to three I would end up repeating stuff and it was just weird so I had to be careful about that and a lot of it was you know you have to load a bunch of information into your brain to make sure you don't copy stuff and it's funny uh they use SVN or they they did then, I think they used Git now,

to keep track of the XML files. And it was all written, I would write in Word. Yeah, what are the mechanics of this? And they would, then it would go into this XML editor thing. And I guess a lot of books are written in XML, but this editor is kind of dead and it was super annoying to use I don't remember the name of it but it was super annoying to use uh and and what was the XML for like layout and and references and so kind of like LaTeX except for

it was very LaTeX like yeah okay Okay. And so I would write in Word, and then I would hand-sketch the drawings I wanted, usually in pencil. And then I'd put it, once I was happy enough with it, I would put it into XML and start inking some drawings to go with it. And I'd scan in my drawings or take pictures of them and link them and then I would send it off to the editor.

And he would usually say, wow, I can't read your drawings at all. And so I'd redo those and then he would ask me questions about the material. Like, I don't understand how you got from linked lists to recursion. And I would be like, i'm sorry i will explain better actually i don't think i talked about recursion in the book at all but it was stuff like that that he was like so you made this leap and i suspect anybody who already has your skills would know why you made this leap but i don't did you did you find yourself having to put yourself in your reader's shoes and say okay how do i people who are experts at things often are terrible at explaining them

and how did you get over that sort of self self-evaluation of is this is this being presented in a way that makes sense to a newbie or somebody without my expertise well happily that was one area that i was pretty good at because i identified a couple of people as my target audience and it's sad because in svn it emerged somehow this section of the intro got mushed and not copied over. But I identified my target audience as a couple of people. And one of the people I didn't list is myself. It was very much a book for when I had been working at HP and got transferred over to labs to work on embedded systems but i didn't even know what i was doing the manager who had hired me was just like okay so this person keeps writing software and she keeps getting lower and lower into the system she doesn't even know what

the word firmware means i'm gonna hire her and tell her what it means and then we're going to have a good time and that worked out really well, but I needed an introduction. So I was writing it to me. And putting myself in those shoes weren't as difficult. Past you. Past me. Yeah. Because I could remember, I remember the time, God, it was so annoying.

We were talking about transfer functions. And I had a lot of transfer functions because we did systems engineering in college. And a lot more transfer functions in Fourier than any CS person usually gets. And I didn't know the same words he was using. The plant. Right. Well, yeah, I guess now thinking about it, yes, we used that term like once. And then ever after, we just called it the transfer function or the system or the input or the output.

And we didn't use all of these other terms. And he thought I was just totally making things up. And it was so annoying and it was just because I didn't I didn't have the same terms for the same things and that was what I wanted to be able to tell people that's not the hard part the hard part is not jargon jargon the hard part is getting the discipline to put it all together into a framework that makes sense. So I knew that, and I knew I wanted to really work on what the user would get out of it. And when I read books, when I read technical books, that's probably the worst thing, is when I want to go up to an author and say,

Dude, really? How am I supposed to get from here to there without going off to read an entirely separate book? And I didn't want anybody to say that to me. I don't know if I was successful. That's fair. I think embedded is one of those areas where people who are tinkerers get into it without knowing that that's what they're doing.

Oh, yeah. I had a woman tell me at a conference about making robots with Arduino with her kids and how much fun she was having. And she asked me what I did, and I said embedded systems, expecting the conversation to go on amusingly. And she said, what is that? And I was kind of gobsmacked.

It's what you're doing. Yeah. You have plenty of experience with it. Well, I think coming to a book like this, people from that viewpoint or that experience might recognize things. Oh, okay, this is stuff I've been doing all along and this is what it's called. And this is going to be a professional. Getting back to the jargon, you know. Oh, I know how to do this.

I learned it on my own and made it up. I don't know what you people call it, but I call it, you know oh i know how to do this i just i i learned it on my own and made it up i don't know what you people call it but i call it you know well that's what a lot of my electrical engineering is is i don't know what you people call it and for most of the that was the research that i did most it was me trying to get the electrical stuff did you did you do much research i mean i don't remember what your bibliography looked like but um, you know, you didn't just sit down and open your brain up and interface it into the computer. I did a fair amount of that, actually.

On the idea that I was still back to thinking about my old manager's libraries. What did I want them to know? And since I had already trained a few embedded systems engineers, and I've been a manager and director myself, I knew what those first few months of, here's what you should be doing, is like. And it was a lot of opening my brain and trying to get it all out onto paper in a way that made sense.

But the electrical, I made sure that I was getting that at least correct. And it kills me that there's still an error in one of those diagrams. But it was, I guess I did do a lot of research, but I did a lot of research more for the library. Going back to the library concept, every chapter had not a bibliography, but I said I wanted it to be ramps so that you know where to get the other information. And then I tried to make sure that there was other books you could go to to get more information. And so I wanted to make sure that i had good other books i did a lot of reading for making sure the library notes were good did you and that did affect the writing some did you

you say the library did you look at those books with a notion of well i don't want to repeat or overlap necessarily what these books cover or say? Well, it was more like I wanted to have a paragraph version of their 200-page book. So there was no way I was going to overlap. Okay. All I could do was introduce. And I don't, I didn't, I don't,

still don't have a term for what kind of book that, I mean, is my book a bibliography then? No. An annotated bibliography of other people's books? I know. It isn't really, but. Yeah. I, I guess that wasn't really my question.

It was how much, I don't want to say the word competition, but how much did you survey what was out there in deciding what yours was going to be like? I surveyed a few things and I remember finding out that there was an Intel title called

Design Patterns for Embedded C or something and that was a bit of a oops it had just come out and i was afraid to even look at the table of contents uh and so there was i guess i was a little afraid of spending too much time looking at other people's stuff and in my writing and even vocally uh if i hang out too much with someone else i I will start copying them. Oh, yeah, yeah.

I've been listening to a podcast lately where the person stutters a lot, and I've started stuttering. Yeah. But if I've been reading really technical books, I will write really technical, even in emails and casual stuff. Yeah. So I was a little afraid of that. Okay.

But I did a fair afraid of that but I did a fair amount of research just for the library stuff and I think that did trickle down into the writing to make sure that if I was going to ramp up to talk about James Grannion's Testrum and Development

that I had some basis to say this is a good book not only by reading it, but also by saying, you've got to be thinking about how you're going to test stuff. Even as you're designing it, you have to think about it all the way through. It's not enough to say, oh, look, Lego blocks. Let's just stack them up. You don't know whether you're getting Lego blocks or House of Cards.

So let's think about this from the very beginning. Yeah, I guess I did do a lot of research. If I don't think about the research necessary to figure out exactly how to determine what resistor to attach to an LED, that's a different kind of research then. I want to make sure I cover these things adequately as an introduction. Okay. Staying on mechanics just for a little while longer. So a lot of us have not written books.

The process of editing might be a little mysterious to people. How much time did you spend between meeting with your editor or having things checked with your editor? Did you go away for a week, write a week's worth of stuff, and then dump it over there and have him come back? Or was it a continuous integration kind of thing where you would check stuff in and he would just periodically catch up and send you comments and was it maybe explain what editing is when you're writing too because i think some people probably think it's oh look out for my typos and you know make sure my sentences are grammatically correct versus well this doesn't fit with the flow of the book

correctly so how much what was going on what at that stage where you're writing in terms of editing andy is not a copy editor um that came a lot later so a copy editor copy editor is the person who added all of the commas to the book that needed because apparently i'm comophobic and i don't hope your keyboard was just broken yeah we'll use that uh but all of all of the uh typos are handled later okay in in a process that has got to be the worst thing ever you think wow i've written this book i must be pretty good at like writing now and then somebody comes along and you're like what what? No. There's a rule for that? No. Andy would occasionally hassle me about verb tenses

because a personal quirk is that I tend to just switch between present and past and future tense sort of randomly. Are you unstuck in time? I am. But mostly, no, Andy was more the material. And we would talk every week. Conversations were funny. We're both not super extroverted.

And so there were a lot of silences as we were basically just on the phone reading what each other had said over email. This is all remote because he was based in Boston, right? Okay. And he would send me email comments. Usually I would try to get something done before, you know, this week's call. And he would try to get his notes from last week's call done which was a little strange because you okay so you're writing now you're editing from the last couple of days you're getting comments from your editor for two weeks ago and you're incorporating those in and

making sure you're not totally tweaking things around so there was a I mean there was a reason I was sort of unstuck at time. Yeah, and his comments were, I don't understand this part. This diagram doesn't make as much sense to me as it does to you. I don't think we can cover this in an adequate amount of information

or adequate amount of space. I don't think you're covering this enough. Was there anything that he removed from the book? I don't think so. He really wanted more specific information for different processors and different operating systems. And I really didn't. And I think that was our biggest bone of contention.

And I think we're both reasonably happy. I think he still would like to do more Linux, more stuff in there. But as a general book, I'm happy. It talks about a few processors, but it was because I needed examples, not because I was giving an introduction to a processor and not in such a way that as time goes on if those processors fall out of favor that they're going to be anachronistic because you've gone through a huge amount of detail and this is very important to this example

this is a processor that fits that well then he wanted me to use a real data sheet in a chapter on reading data sheets no a dinosaur data sheet was great okay so you've written the book in the chapter on reading data sheets. Oh, I'm glad I sorted it. It seems great. Okay, so you've written the book. Okay, so in six months, I've written, it was something like 80,000 words

plus a diagram every four pages at least. And then we did the library. 80,000 words is pretty i mean it's a pretty good like book compared to 20 compared to a novel for example 50,000 and no 50,000 is a very short novel it's 120 page novel okay um But a technical book of double that length is... Yeah. That's a lot of content. And, oh, and Andy didn't get the interviews section. Right, right. Until about chapter three, at which point he was like totally in favor of them.

Because we were talking about he wanted to have questions at the end of each chapter. And I said, sure said sure yes we're going to do that and and then i was talking about how it's important to move professionally from being the junior engineer to being senior and one of the things that's the criteria is knowing how to interview people not how to be interviewed we get that we get that in school they train us on that but interviewing people and so where andy was like having this plan that we were going to be like talking about detail and now with your system put together this sort of logging system exercises traditional exercises right and then when he got that first interview

question he's like i thought this was going to be something different. Remember we did the interviews and he didn't really like it that much, but I was pretty forceful about it. And I said, well, you know, we can go back and add questions if necessary, if you decide you don't like this but in the end he was very amused because it was a good way to review the chapter but it wasn't it wasn't normal right yeah i think it's interesting that you took it from the standpoint of this is these are questions that get you thinking about the kinds of things you need to discuss in an interview not hey if you're out looking for a job you might want to know how to answer this question. Yeah, if you haven't read the book, at the end of each chapter,

it poses an interview question, one that generally I have asked in an interview, and then it talks about what the interviewer looks for. And some of the questions, it doesn't answer the question. It just talks about what the interviewer looks for and so you have to work through the question to figure out whether or not you got it quote right and that was fun and that was one of those things that having trained so many engineers i put myself in their in their shoes i put myself in my early years and said, well, what was hard?

And learning to interview people and being able to talk at interview sessions, you know, the post-session and say, well, I liked him versus, well, I really liked him personally, but when I asked him about pointers, he was kind of weak. And I'm not sure that was offset with his ability to do database management. Suddenly, I mean, that's such a great skill. Right. And it's a skill that people don't acquire.

They don't train for it. They learn by doing. I mean, there's not usually a lot of feedback, so you don't actually learn by doing. You just do a bad job of it forever. Well, in that part, let me involve some of my friends. Because I was still kind of recovering from being sick and everything else,

I needed a little help getting my friends back into my life and asking them about their interview questions and talking it through and all of that. I guess it sounds very cold, but it was fun having Phil come over and talk about what his favorite methods for torturing software engineers.

Let's see if that's cold exactly. Well, I was sort of using their information, but I was providing beer and pizza. So, you know. Yeah, that's a problem. Just one more question on the process through there. Once you started writing the book, they said they gave you an advance, but beyond that, did they give you the whole advance up front, or was it doled out as you wrote the book? They didn't pay you anything else as you wrote the book.

Right. So they gave me an advance in two parts maybe three but it was it was not a lump it was not a lump sum and each lump was about a week's worth of salary so it wasn't a lot it wasn't enough to live on uh and they gave it to they gave me the first one when I started the book, and then at the halfway point, and then at the end, I think. Okay. I think there were three. Okay.

And so about six months after I started, I finished with the writing, and I was pretty burnt out of the grind at that point. And that's when we started with the writing and I was pretty burnt out of the grind at that point and that's when we started with the technical editing and Andy knew some people who could read the book and talk about it and a couple people gave me really great comments um right you had a whole review board that they put together and then he wanted me to find people to do this. And that was hard because I had had some friends read certain chapters or talk about certain things. But asking someone to read a whole technical book that isn't finished yet, I don't know. I lucked out. I asked some friends from college who turned me down but said, you know, somebody else is just talking about the same problem.

And I ended up talking with Matt Hughes, and he had a whole team he was trying to do this with. And they read it together. And, I mean, just a whole bunch of people. I think there were four or six of them. They gave me all sorts of comments from both matt's perspective of being the teacher and the trainees perspective of being the student what worked and what didn't so that was just fantastic i i'm sure that these people are thanked in the acknowledgments but it was important to have a technical group. And now I have been asked to read a couple of books. And it's hard.

It's hard to read something. It's a different kind of reading because you're actually trying to make constructive comments at all levels. Everything from typos to checking the diagrams. So you can't just skim through it and read it like you naturally would. You have to look very closely. And I found a bunch of typos in one of the books, and I corrected them, but then it was tough to transmit them back to the author. And if the author hadn't asked me like four times, I would never have sent them

because it was just so, I don't know, such a pain in the ass. Yeah. So, yeah, technical editing really matters, and all the errors that remain are still mine but they did a good job and they mostly that's something to keep in mind though right that's something to keep in mind when when you look at when you get a book and you find an error in it it's already been through the primary editor several technical editors the copy editor so if an error comes through it's been through a half dozen to a dozen people who didn't see it and it's it's it's kind of amazing actually talk to me about my errata

um i guess at that point we had mostly done the diagrams. And the diagrams were done by a woman who did not know the material. And it was... Because she was a graphic artist. She was a graphic artist. And I never met her. I never even talked to her except over email. And even that was usually filtered through somebody at O'Reilly and so trying to explain why the stack needed a bunch of turtles was just so strange and she would take my my ink at my you know comic book pencils and then inked drawings

and try to recreate them and you know the difference between a one and an L is just impossible, at least with my handwriting. And so I would, I would often use all caps and that didn't work very well either. Cause then she would use all caps and that would be weird. So the art, I think, I think if I was doing it again, I probably would say I'm doing the art.

Not because she didn't do a fantastic job, but because that process was as difficult as learning to use GIMP really, really well. And it was difficult in a way that wasn't fun.

You know, writing can be difficult, but it can be rewarding too. But trying to explain I don't know, writing can be difficult, but it can be rewarding too. But trying to explain, I don't know, trying to explain names on figures and chip indicators and schematics and why schematics look this way and not the way you drew them, it was just really hard. It's odd that they would have somebody who was completely not clued in to technical diagrams,

writing a book that are working on a book that requires that kind of, at least, at least to know what questions to ask or to say, this doesn't look right or I'm not sure how this should be. I think, I don't know whether it was because my drawings were kind of strange they did kind of they did cross from highly technical schematics to adorable pictures of dinosaurs and i maybe i was just too all over the place

but it if you were thinking about writing a book and you have this fantasy that someone is going to come in, swoop in and do all your drawings for you, get over your fantasy. That, that is going to be something that causes problems. On the other hand, all of you people were thinking about writing new books who don't plan on

having diagrams. That's kind of a problem too. Yeah. Code snippets are not diagrams. It's hard to have a technical book without a diagram imagine in your mind a series of boxes, the boxes are connected with lines, box A

in the upper left hand corner, yeah doesn't really work so this is an O'Reilly book so there's always got to be the question of how did you or they come up with the cover art? Because they're famous for the little,

the animals, the weird woodblock style animals on every, every book. My animal, by the way, is a great, no, great eared,

great eared goat sucker or nightjar, depending on which history you read I prefer of course the Nightjar I don't see why and he's great he's great eared he's got these incredibly

serious expression and incredibly silly ear tufts and he makes a good a good totem for the book, which tries to combine the seriousness and the silly. But he wasn't what I wanted. I wanted a dinosaur initially. Ah, but O'Reilly doesn't do... O'Reilly said no extinct animals. No extinct animals.

And then I wanted E. coli. What? Which I knew was going to gross you out. But I was like, any amoeba or bacteria will do. And they said no. I'm like, but embedded systems are ubiquitous. It'll be cool. And they said no.

And then with my third wish, because they said, you only get really three requests here. My third request was, oh, my God, please don't give me dust mites, which is what Michael Barr had on his embedded systems book. And I just did not want disgusting little bugs. Really? I'm sorry. I have to look this up. I have to look up the mites book. Yeah. And it's funny.

I was talking to the author of Wireless Sensors, and he got dachshunds on his cover, and I'm jealous because dachshunds are very cool. They're ridiculous dachshunds. And, oh, you found them? That's a great face. Those aren't dust mites. Those are ticks.

Oh. whatever they were I didn't want them in my book isn't that horrible? they're ticks because they're embedded ew oh my god

yuck so yeah I wish I had dachshunds but apparently he wishes he had a bird so let's move in and I'm just glad that I don't have that

I couldn't look at the cover of that book it was so poor Mr. Barr and embedded programming embedded systems so yeah I did not get to choose my animal and most people don't. Okay.

That's kind of sad. How is it done? Is it up to the graphic designer? Do they give you any explanation for why they choose what they choose? No.

They didn't give me any. That's weird. They have themes. There are the green books and the pink books. choose what they choose? No. Okay. They didn't give me any. That's weird. Um, they have themes, you know, there's green books and the pink books, and then they have different subcategories. They like to say it's planned, but I haven't seen any of the making books be particularly similar.

And I mean, saying everything is going to be birds is not limiting it to a female right um yeah i don't know what the thing was but i used my third wish to just no creepy crawlies no no creepy crawlies um and they did give me the diet the cover about nine months in we were we were almost done with all the drawings and we had started the copy editing process okay copy editing that's copy well it's a little hard when you've got a technical book that the copy editor is doing all these English professor sorts of things but not really understanding

the material. So that was cool too. It was, no, no, no, no, really. It's the way I want it. And I learned stat. Which means, leave it alone. I don't care what your editing foo says to do. The author says, leave it alone. don't care what your editing foo says to do the author says

leave it alone it's like a error intended yeah i meant it this way i meant it this way okay so you're done you finished the book so yeah nine months ten months in presumably at that point you're you know your hands off they're gonna go print it did they give you a release date how did this all i mean there was some period between finishing and shipping did anything happen during that period or are you just kind of waiting for the books and boxes to show up on your doorstep um yes things happened then uh o'reilly said things like you should now start a blog or Twitter feed. And I said things like, how are you going to be promoting this? So we were both totally talking past each other. I decided to...

They were basically saying, go promote your own book. Yes. And you were saying, you're going to help me with that, right? Because O'Reilly is primarily software. And maybe I should have tried to be in their make division when that was all part of O'Reilly is primarily software. And maybe I should have tried to be in their make division when that was all part of O'Reilly too. But they weren't too into hardware, and having my book advertised in their normal catalog wasn't that great for me.

I did throw a party at one of the local computer only bookstores computer literacy and that was fun but mostly my friends showed up it wasn't like it was random stranger and o'reilly sent me a few books uh now oh let's see what else did we do then i started the twitter feed and i tried to understand what in the world twitter is on about and now i've almost caught it but still sometimes i look at twitter and go you must be kidding me this is not real uh and i get what else happened then i felt i mean i guess i was kind of bored and tired of working on a book all the time. Yeah, and I think at some point you were getting a new job or something, or you had started a new job around that time.

Oh, yeah. And they wanted you to do some webinar stuff, right? Oh, right, right. And I did two webinars, one about how to interview people and one about introduction. And I did a couple other lecturing things. There was one we went up to UC, no, we went up to the University of San Francisco, did one about how applications matter.

And that was really fun because they were, it was just a CS, computer science seminar. So, but it was, it was hard to expect you to do a ton of promotion at the end of this long process when,

you know, at that point, didn't have a lot of followers in the industry of any kind, right? So it's, I didn't have a podcast for sure. You didn't have a podcast.

You had a blog that wasn't read by anybody, pretty much. No, my blog is pretty much here. 20 Twitter followers. Very local people. So it's a bit odd that they would take somebody and expect them to go out there and find ways to promote. And I gather... Because they've got the megaphone.

They're right. Yeah. But their megaphone is pointed in a different direction. Yeah. So I think they did the best they could and my very first review from the electronic copy on the o'reilly site was bad yes and the very first amazon review was also bad oh no i don't think so well oh no no no you're right this is a different please post you had some reviews that were from folks that you gave review copies to,

but that's fair. Yes, I'm looking at this other review. It was from 2012, which is one of the greatest things ever. The Amazon review? Yeah, yeah, yeah. Shall I read it? Oh, yes, please. That's one of my favorites. One star out of five.

November 27th, 2012. So it had just come out. Title, one of the worst books ever. That's my favorite part of this review because that means I'm up there with James Fenimore Cooper. One of the worst books ever. Read like a bunch of notes that somebody had and decided to put them all together. No practical information that could actually be used i don't understand the other glowing reviews this book went right into the burn pile for me

i mean this person really hated the book biggest waste of money and i i that's fantastic that they felt that strongly about anything you've done i don't think anybody's ever felt that strongly about anything you've done. I don't think anybody's ever felt that strongly about something I've done. So I think you can take that as a victory because, wow, they really hated this book. They really hated it. And I think if you're going to declare that something is one of the worst books ever, you probably need to do a lot more reading. Yeah. The burn pile, which is always a good thing to say about books is that you're going

to burn it and that there was no practical information whatsoever i mean i wonder if they had sent him a misprint that was just empty pages i don't know but anyway not to back on this because but you did get a negative your first review review on O'Reilly was also quite negative. It was a one-star from somebody who, it turns out, always leaves one-star reviews on O'Reilly. Yeah. And O'Reilly saw that, and I said I was really stressed about that. Yeah, you were pretty stressed. I was pretty unhappy.

And they sent out a bunch of review copies to people, not to get high reviews, just to get more reviews yeah and uh and it's funny one of those people reviewed finally reviewing the book in amazon a few weeks ago and he liked it but it was only three years later that's quite the uh pile by your book bed but i think you know the psychotic people aside because i think you're gonna speak entirely in uh hyperbole through your review maybe you should question yourself a little bit but i think people don't realize you know i'm not saying you should go out and review every book highly because that's useless, but I don't think people realize what reviews do to the people who are being reviewed.

Oh, my God, yeah. There are ways to leave negative reviews without questioning people's heritage or questioning their worth, and I think it's very hard. I tend to have the attitude that I'm just not going to review something if it's not positive, unless it did something, you know, I think, if it's a device or something that's dangerous, then I'm going to say, well, this did this, and here's why. To warn people for like a book, you know, it's hard. Yeah, I don't, you do want people to know whether a book's useful or not,

but a technical book, especially it's going to be useful to some people and not to others, depending on their background. And a book like this, of course, you know, if you're an expert embedded systems engineer, you might not find it useful.

No, for an expert embedded systems engineer, what I hope they get out of it is, Oh good. It's something I can throw at somebody who needs some education. And I did get some, I mean, I shouldn't moan too much. I did get some great reviews. No, most of them.

From people who I didn't know, I'd never met, or I met them afterwards. But those don't matter. Or who bought the book. Those don't matter. The five-star reviews, you don't notice. It's very much you don't notice. Well, what's worse is I... I'm being sarcastic, of course.

Six months after the book came out, I had gotten a job because of the book. The VP of engineering of this company had read it and asked if I had any availability, and I did, and it was so exciting. And then I was in the office, and some new person was being considered for being hired. And we went out to lunch and he said, so what do you, what do you do? And I failed to say, I wrote Making a Bedded System. It's like, I forgot. Well, and you had trouble introducing yourself as an author of any kind in other contexts right you

you did that once we were someplace where it wasn't you know it was like we were at bed and breakfast and you didn't really want to talk about technology so you introduced me as an author and i just was like is there somebody else around here with my name it's so weird so we're gonna have to wrap things up here because we've run a little long but um i do have a few more questions so we're gonna go ahead and run a little long okay uh was it worth it it depends on what your uh what your metric is financially i could have made more money uh but you knew that yes i being a contractor the number of hours i could have made more money uh but you knew that yes i being a contractor the number of hours i could have made more money well riley does still send me checks i get i get uh the yeah monthly royalties monthly

royalties so it's not zero and it's not zero i mean it's you know a nice out to dinner maybe sometimes three okay uh and and yet so i said were, you asked me why I wrote it, and I said, I mentioned the manager, but there was another thing that happened years ago, probably three years before the book was really started. I went to a conference, and I ended up sitting with a bunch of professors, and we went around the table, what you do what do you do and they were they all kind of knew each other and i said i was there presenting shot spotter so i talked about

gunshot location systems they said what else have you done i said toys and race cars and dna scanners and we talked about signal processing and software design and running the company and and then at some point later in the dinner i said something about yeah sometimes i think about getting a phd but i haven't really figured out what i want to do it in and the professor i don't remember her name except she was from australia said it sounds like you already have a phd you just need to write a dissertation and other people have, other mostly O'Reilly authors that I've talked to, have talked about how this is your

practical dissertation for your industry PhD. And that's what has brought me. I mean, I'm working at Xerox PARC now, which is, I mean, getting into HP Labs when I was young was cool. Getting into Xerox PARC is also pretty darn cool.

And that's because I kind of have an industry PhD. And it's led to other jobs and other opportunities. It's given me the confidence for the podcast. And every once in a while while I want to say, you know, you get into these conversations, and it's like, well, who are you? Well, I wrote the book on making medicines. That doesn't sound self-important at all.

I've never managed to actually say that seriously. That's probably to your credit. It would be cool. It sounds so cool. I literally wrote the book. It sounds cool in your head. It sounds something else. So are you going to write another one?

Ah. Poof. Blech. Blech. That sounds like a yes. When can we expect it? I don't know what I'd write another one about. I really care about getting junior engineers into embedded systems,

and I really care about them being happy and comfortable here because I think it's a great environment, a great thing to be into. It takes a lot of passion to write a book, and it takes a lot of time, and it's not a blog post. It's not even a whole blog about this. It's a book, and it's not a blog post it's not even a whole blog about this it's a book and it's it's hard so i have to find something i love that much and other than you i don't know what that would be you can write a book about me didn't you read the novel right right

um so we got started with all this because of a listener question and they wanted to know what the process was like um advice because he's considering writing a book right so i think you know your advice comes through and everything we've already talked about but is there anything else that you specifically wanted to to throw out there it's tough yeah i i don't think people it's one of those self-motivated jobs that's that's hard to do for some people and it's it's easy to pick up and it's easy to put down and then never pick up again right it's It's the second picking up that gets weightier every time you put it down. So you have to be motivated. And if you're doing this for love instead of money,

which should be why you're doing it because it's not for the money, then what difference does it make if you have an animal on the cover? Think about writing a blog it's pretty important i disagree with you there it's pretty no i information is becoming more free and one of the things i like about o'reilly is they're going to open source my book yeah um i mean they're going to wring as much money as they can from it but as soon as it's not making enough for them to worry about, they're going to open source it. And I was all on board with that. And when they do, I am just going to promote it even more because that's exciting.

So if I was going to do it again, I think I'd have a podcast or I'd have a book. Or, you know, somebody asked if we had ever considered kind of summarizing all the podcasts into a book. Oh, my God. Yeah, I know. Wasn't that kind of terrifying? I the podcasts into a book. Oh my God. Yeah, I know. It wasn't that kind of terrifying. It was a prior.

I still listen to people. I know. I listen to them sometimes. And I think that would be fun, but it would be fun like for about three episodes. So I don't know if I'm going to write another book. And the advice is it's hard, but it is kind of worth it. But it's self-motivating and hard.

All right. Well, on that note, I think that's a good place to leave it. And so that wraps us up for the week. Just a reminder that on September 8th, both of us will be speaking at Hacker Dojo in Mountain View on software for things that can kill people.

It's going to be kind of a podcast-y conversation about... We're going to record it too. Yeah, that's what I'm saying. It's a follow-up from the Jack Cancel Show. Jack Cancel Show? Right, right. The podcast. Jack Cancel Show sounded like something on TV or Vaudeville. Anyway, we've both worked on FDA and FAA-certified products,

and we have a ton of opinions on how to make things safe, or at least make your software development process so that you're not making things unsafe. So we'll talk about stuff like the sudden acceleration and toyotas and medical devices gone awry and all sorts of things so that'll be uh three dollars i think and that that all goes to formula sa racing team at san jose state university so they can do more stuff and i think it buys pizza. It may go toward pizza. So we'd love to see you people there if anybody wants to come and

ask us softball questions. Oh yes, please, the softball questions. As always, if you have comments, questions, suggestions, thoughts, hate, love, email us at show at embedded.fm or hit the contact link on embedded.fm which goes the

precisely the same place but you can be anonymous that way uh and we always like to see reviews and about the only place we can get reviews is itunes so if you think about it be so kind go there and you don't even have to write anything just click some number of stars that you like, preferably not one. Come on, you've listened to the whole podcast. You're really going to do one now. If you're going to do one, then make sure it's a good, really forward-looking one. A really ironic, sarcastic one-star review after listening to all this, yes. And, yeah, don't review this particular episode with a one because this is the one I'm hosting and I'm very sensitive.

So, since I'm still in taking over the podcast mode until the last sentence, I will do our final thought for the week. All right? All right. Final thought. Oh, wait, there's three. I have to choose one. You don't think I actually managed to make them topical, do you?

All right. Well, I'm going to go with this one because it's good for writing. Substitute damn every time you're inclined to write very. Your editor will delete it and the writing will be just as it should be. Mark Twain. That's a good one.