Embedded - 28: A Lot of Wish Fulfillment

Episode Date: November 20, 2013

Author Laura Lemay (@lemay) spoke with Elecia (@logicalelegance) about writing books, APIs, code, and science fiction.  Laura wrote many of the Teach Yourself ... in 21 Days books: her bibliography on Amazon. Laura's blog includes short stories.  November is National Novel Writing Month, see the NaNoWriMo site Edward Tufte wrote the amazing Envisioning Information (among many other beautiful and informative books) Neal Stephenson wrote Diamond Age Laura suggests Patrick Ness' The Knife of Never Letting Go

This is Making Embedded Systems, the show for people who love gadgets. I'm Alicia White. Laura LeMay is joining me to talk about reading, writing, and being awesome. Laura, thank you for joining me. Oh, thank you for having me. You've written several technical books and science fiction stories. Actually, tell me about yourself. I am a writer. I'm a technical writer, which means that I work mostly in Silicon Valley for

companies that need documentation. As you mentioned, I've also written a number of technical books, although that was a long time ago. And I've always written fiction of all kinds and some science fiction, some fantasy. You say I'm a writer the way that I say I'm an engineer. It doesn't really matter what my job is. It's just what I am. Yeah, that's precisely the way I think of it is that I am a writer. End.

But you said it was a while ago, but there were a number of titles that have your Laura LeMay author in Amazon. Teach Yourself Java in 21 Days. Is that right? And then that, there's a whole series of those. There was a series called Teach Yourself in 21 Days, which was actually around before I got involved in it. And I wrote a book in that series in 94, which was web publishing with HTML. It was the first, actually it was the second HTML book that was ever published. So big deal. And then once that one took off, I ended up doing, actually I did a second HTML book, teach yourself more HTML in 21 days.

Um, and then wrote Java as well for that same series, teach yourself Java in 21 days. Um, and, uh, all of them were, were very, very popular. And there was Pearl in there too. I did. Yeah. Pearl in 21 days. It was, yeah, Pearl in 21 Days. That seems crazy. It was a consistent theme there for a long time.

It said 21 Days. How did you get into that? I was a technical writer in school, and I became a technical writer when I left school. But it's sort of the goal of really every writer to write a book, no matter what field, no matter what field you're in. So it was like, okay, I need an idea to write a book. I had always been thinking, I need to be able to write a book and I need an idea. And HTML came around. And it was like,

okay, well, maybe maybe I could do that. Did you learn HTML first? No. I learned just enough of it to do a book proposal. Actually, the guy who became my editor had posted on Usenet saying that he was looking for people to do technical books. And I was like, oh, yes, all right. HTML, I can do HTML. And the guy said, okay, yes, send me a proposal. So I learned enough HTML over the weekend to write a proposal. And then I learned enough of it as I was writing the book to be able to finish the book. So I had a vague idea about the scope of the problem, but I didn't learn it until I wrote about it. Well, there's some advantage to teaching people as you're learning it, because then you remember all of the things that don't make sense.

Yeah. And you know how to describe the things that don't make sense because you've figured out how to make them make sense. So, yeah. Sometimes just moments ago. You've had co-authors too. How much are they providing the technical information and you're providing the writing? Well, actually the, the dark secret of the whole coauthor thing with my books is that we never wrote together. It's, it's always either been, um, writers took over my books after I was done with them. So I've had a number of writers who have worked through the HTML book. Um, so like version two would get a co-author? Uh-huh. Oh, okay. Actually, for HTML, I wrote the first two or three, I can't remember exactly,

and then handed it off to someone else because I was doing Java. And then once I was done with Java, I handed that off to someone else as well. So even though both our names are on the cover, we never wrote anything together. They basically were just revising the stuff that, that I did. Um, in the case of Java there, I did have a coauthor there and mostly that was this, the last third of the book because it had Java was a really, really big thing for when it was first gearing up and we needed to finish the book within a certain time period and I couldn't do it. Um. So we brought in another author for the last week in order to do the more complicated parts. So it is learn in 21 days, not write in 21 days.

No. There was one book, the sequel to HTML, that I did in six weeks, and that was intense. There was nothing else going on in my life for that six weeks. So the teach yourself X in 21 days is a style. I mean, there's, it's kind of a formula. It's exactly a formula. Yeah. Did you particularly like that formula? Are there other formulas that have come up since then that you admire?

I liked the formula because it gives you constraints. I mean, you have to be able to split up the entire topic into 21 days or the entire larger topic into 21 shorter topics. Chunks, yeah. Yeah, and it's a tutorial style of books. So you have to start very easy and then build with every chapter into more complicated subjects and more complicated examples. tutorial style of books. So you have to start very easy and then build with every chapter into, into more complicated subjects and more complicated examples. Um, so it's, it's, I, I got the hang of it by the third book, uh, and figured out how to, to effectively plot these

books. Um, yeah, I guess it is sort of like a plot. Yeah. And I mean, I've, I'd written a couple books, uh, manuals when I was doing technical writing and that's a much, I mean, I've, I'd written a couple books, uh, manuals when I was doing technical writing and that's a much, I mean, basically it's as large as it needs to be. The chapters are as long as they need to be. So it's, it's, um, it's both easier and harder to work within the formula. Um, well with manuals, you assume more about the audience. with teach yourself x it's got to be you could have a beginner or you could have somebody just wanting to solidify their information um but a manual it's the user of your product yeah whatever that is although um in technical writing one of the very first rules of technical writing is that you, um, you should know who your

audience is. You should know the amount of background you have. You should know what other domain knowledge they have before they're coming to your manual, even, even if it's product technical writing. Um, Oh yeah. But there's, I mean, there's the broadness of your audience. Um, I, when I wrote my book proposal, I said hardware engineers who are suddenly writing firmware and software engineers who are suddenly writing firmware. And both of those groups, they're very different. Yeah. But it's the I'm writing firmware now and I'm going to teach you whichever half of that equation you didn't have. So I had a very actually a pretty small audience set.

But you've had to deal with much broader ones. Yeah. Yeah. Well, it's not that much broader i mean a number of years ago i was writing about a games framework um and in that case it's it's software engineers who are writing or working in games and so that's that's a specific bit of domain knowledge but i didn't have to explain concepts in game development because we assumed that they're game developers. They know this already, and we're just telling them specifically what they need to do in order to get X task done. Well, so have you seen the Head First books? I have.

And actually, I am Twitter friends with Kathy Sierra, who started the original Head First Java books. They are fabulous. I love them. I like O'Reilly puts them out, so I have some affinity for them just because I like O'Reilly. But they take a very cognitive approach. Yes. And they really try to make it something that will stick. Mm-hmm. try to make it something that will stick. Yeah, Kathy came to technical writing to books from

training, and also from from education and training. And she talks a lot about brain science. Whereas I came to technical writing from a very more traditional technical writing background, I was a writer first, and there's there was sort of a structure to technical writing background. I was a writer first and there was sort of a structure to technical writing that I came out of. So we came to the same problem from very, very different angles. And the way she composed those books was completely fascinating and utterly alien to me. It was very alien. Yeah. I minored in theories of learning and I could see how you could put this together that way. And it made sense from my cognitive psychology classes, but from my technical writing classes,

it was just, this isn't right. This is strange. You have like three conversations going on all the time. And it's it's mostly worked for me yeah i've only had one of those books that i was like this is nuts but we're not gonna talk about that yeah no they're they're really really wonderfully done books they they teach you in in terrific ways um but it's not something that i i mean again because i'm at core a writer. And if you talk to Kathy,

she will say she is absolutely not a writer. I am a writer. So for me, I always approach the problem from a writer standpoint. And I can't even conceive of doing it visually or doing it to the level that she does it. It's totally fascinating and I don't understand it. It's, it's, it's totally fascinating and I don't understand it. So you haven't been doing more books lately? No, I stopped doing them for a variety of reasons. Not the least is which is that I ran out of stuff to talk about. I mean, I went through HTML and I went through Java and at that point I had been writing and, and Perl. I had been writing books for seven years at that point and just writing books, just sitting in a dark room writing books. I can't even conceive of that.

So I could have taken on another subject and figured out how to write about it, but I wasn't as confident as I was with either HTML or Java. Um, just because I had been out of tech for so long or out of, out of working in companies and being around other technical people for so long. Um, and also I was just lonely. I mean, seven years alone in a room is, is hard. So, uh, so yeah, that's, I, I moved away from books. I decided to go back into technical writing for a while. Um, and I've pretty much stayed there.

Uh, once the dot-com crash happened, um, technical books sort of collapsed with it and they really haven't ever come back. Um, so yeah, it's, there was the, I was lucky enough to be publishing books during the real heyday of, of technical heyday of technical books. Yeah. Now you can find so much information online and get videos, although you still do. I mean, the reason I like the headfirst books and the reasons I did my book is it's hard to put the information together in an organized, sensible fashion.

And to get that off of Wikipedia isn't going to happen. So I'm hoping that I put it together so that somebody gets it, as opposed to just getting a piece of information. I also think books, I mean, I sort of regret seeing this, but I don't think people have the attention span for sitting down and reading a book anymore. I think the Internet has really changed that in a big way. And people want to know exactly what they need to solve right now and then move on, which is why sites like Stack Overflow and sites that just answer very, very specific questions about technology or about anything are so popular. It's because, well, if you can Google the answer, then you're done.

On one hand, that's great. It is really useful. On the other hand, that teaches us to look for small problems. Yeah. When maybe we need to be looking at big ones. Yeah. I don't know the answer to that. Okay. So you are now doing technical writing for a major silicon valley company and when you're say interviewing a tech writer i'm i'm gonna start up i'm gonna start at a startup on monday and we're gonna build a team it's terrifying but if i wanted to interview someone to be a tech writer what would i ask them? What qualifications do I look for? Do I look for samples? Do I look that they can communicate?

What do you need? There's actually two kinds of technical writers. There's sort of old school technical writers who write more user-oriented documentation or just general audience documentation. And there's developer technical writers who write programming, APIs, documentation. Is that where you see yourself? I am, yeah.

I am definitely a developer technical writer. I'm no good at product docs. But the general purpose technical writer, generally they can learn what they need to know on the job. So what you look for there is, is, um, communication skills. You want them to be able to interview engineers, uh, and interview the people that they're working with, um, in order to, to figure out the, what they need to write about. Um, being able to structure information is, is a good thing. And you get that from the samples, make sure that they're writing samples. They should have a lot of them.

And if the samples are boring, then that's maybe a clue. Yeah. Although these days, what's actually the state of the art in technical writing is, again, very, very topic-focused. So there will be one task, how to do this particular thing, and it will give you four steps on how to do that particular thing. And no background, no overview, overview no concepts or few concepts but know how to derive this from first principles because that's always the piece I want no it's it's technical writing has become a very

structured and rigid process these days so yeah you uh you said about interviewing engineers. I've heard one of the worst parts about being a technical writer is the engineers sometimes won't talk to you. Yeah, that's very common. How do you get them to tell you what you need so you can do your job? Me as a developer technical writer, it helps that I have not so much developer background, but I actually know something about programming and I can, I can get access to the source and build the source or run the source through a debugger. Um, and, um, so I can do a fair amount of homework before I go to talk to an engineer. And often I don't even need to, or rather I'll, I'll just have very small problems that I need,

or very small questions that I need answered from that engineer. And they're the questions that any developer coming up to this code would have. Yes. So your developer background really helps you. That's why I made the distinction between user technical writers and developer technical writers. It's because as a user technical writer, you can switch from financial programs to multimedia to games or whatever. You're sort of coming at it as a beginning user. Whereas a developer technical writer, you really have to be a developer or you have to really understand what developers are thinking. Yeah.

So, okay, that makes a lot of sense. I figured you must resort to bribery, but being able to actually look at the code yourself has got to go 75% of the way. Mm-hmm. That'll get you through most of the problems, and then you just ask questions about, well, why did you do this? Why is this api like this or or why is it this way in one place and another way in another place inconsistent api yes do you file bugs about that sort of thing oh yeah definitely yeah yeah and and

if the api is inconsistent i mean that's that's something that really that the value that a good technical writer can bring to to documentation is being able to point out issues in the api where API is inconsistent, I mean, that's something that really, the value that a good technical writer can bring to documentation is being able to point out issues in the API where it's going to be confusing for a new developer to come to your API and figure out how to use it. So a really good technical writer can push back and say, well, you need to do things consistently, and hopefully the good engineers will listen to you. I think tech writing is a pretty thankless task, especially since a great tech writer can make my product or API look so much better

than I can myself. I speak computer more than I speak human sometimes. So thank you, but the other side is, how can an engineer really help you what can we do to help you help us um consistent apis but yeah that you don't always see um well we we have um in technical writing we call it source material which is basically anything that the engineer has already written down. And actually, more recently, it's become a lot more common, especially with Agile and other processes like that, that engineers are actually writing a lot of stuff down.

It may be very small things, but it seems like they're doing a lot more writing and a lot more figuring out things before they actually code them. And so do you look at the tickets in the stories to figure out not only I mean, it's not only that there's the code. So you get both of those and try to sort out what you want. Yeah. And I'm constantly monitoring wikis, wiki page changes. I'm monitoring tickets. I'm monitoring code reviews. So I'm immersed in the whole process to figure out what's going on and if there are changes that are going to affect me. Wow, I've never had a tech writer that was that immersed in the process. That's pretty cool though. Do you end up with your API documentation being public or is it all internal for your company?

It depends on the job. I mean, right now I am working for a large company in which all the documentation either is or will be public at some point. So yeah, I prefer being able to publish stuff to the outside world and getting feedback from random people out in the internet. That's a lot more fun.

Oh, it is. Yeah. Being able to point to something and say, I made that is so much cooler. Even if, you know, mom has no idea what you were talking about. It's still much more fun. I've worked with a fair amount of code that's easier to rewrite than it was to read. I've even seen some books like that. Have you? Do you know what I'm talking about? Oh, yeah, I know exactly what you're talking about. There's, over the years, I've encountered a lot of programmers who are very good and

very fast, and they can do terrific, terrific products, but their code is a mess. Now, now these days, it seems like, again, now that people are working in more teams, and there's more process, that there's been more an emphasis on maintainability of code. So I think the code has actually cleaned up a fair amount. Um, at least the code that I see. Uh, so, um, a lot of the code that I'm working with these days is, is fairly easy to figure out. Although I've occasionally had to stick things into the debugger and just step through it step by step by step, tiny steps, in order to figure

out what's going on. But then on top of that, I mean, assuming if you're going from spaghetti code to maintainable code, sample code, code that you write for external developers to understand your API. It's in many ways a, you have to think even more about clarity and structure. Oh, yes. I've written example code. And it's hard because every line will be taken in the wrong way. I mean, it's not, it's like, you know, that email that you're writing and you know that you're writing to someone who just doesn't like you. So whatever you say, it's got to be so clear because whatever comes out, they're just going

to hate you for it. You know, it's like that with code. No matter what you write for an example, they're going to take it wrong. And they're going to say, oh, what do you mean you don't need four semicolons at the end? I'm like, oh no, that was just a typo. mean you don't need four semicolons at the end? I'm like, oh, no, that was just a typo. Really? You never need four semicolons. No, you don't need four semicolons on all of the lines?

No, I'm sorry. But you know what I'm talking about. Yeah, I've seen a lot of sample code which either was clearly just pulled out of the product and it's just impossible to figure out what's going on, or the sample code writer didn't really know, they didn't have a clear picture of who their developer was. So again, it's really, really unclear. When you write sample code, you have to make,

yeah, pretty much every line has to totally speak for itself. You don't do shortcuts you don't do clever things with code it's it's better to do everything as verbosely as possible to document as much as possible sorry comment as much as possible um and assume that that your developers are going to just copy and paste everything because they will and they do i mean i sometimes see this code and like this comment makes no sense and i trace through and it's from the the example code but the line would change like yeah five check-ins ago and it's so yeah yeah i see it yeah i worked for a while on a

on a web services api where the sample code had right at the top of the file it it said well username gets insert your username here and the minute that sample code went right at the top of the file, it said, well, username gets insert your username here. And the minute that sample code went out, it was like the support calls kept coming in. Whose username? I keep getting the error, insert your username here. What do I do? Let's see.

Have you considered inserting your username there? Mm-hmm. well let's see yeah have you considered inserting your username there it seems that if we want the code to be usable it should not be easier to write than to read we should take the time yes to think about it and even if it means it's harder to write therefore it's easier to read, then great. That was the equation you should have started with. Yeah. More time should be spent making code easier to read. Yeah, there's sort of a theory in the culture, I think, that, well, if it was hard to write, it should be hard to read.

It's corollary to the no one needs documentation on my code because the code is the documentation. I've met that guy. But the goal here is to respect people's time. I mean, yes, they can sit there and read through your code line by line or step through it in a bugger in order to try and figure out what you were doing. Or you could make it clear enough that it's immediately apparent what you were doing and that your code then is maintainable and expandable and other people can pick it up. And it lives beyond you. That was what finally clued me in with really making code that was usable by other people is you write things so that they're live beyond you so that it's greater than what you could personally do yeah and then you make it hard for other people

to use it that's silly make it so everybody use it make it make your line of code the one that gets into everybody else's code yeah um and i think people are under a lot of time pressure especially with startups these days so that it's hard to keep that in mind that your code is going to outlive you when you're just trying to do the fastest thing possible and get it done. But I think that does pay off in the long run to step back and do more planning or do more design. Not over design. You're laughing at me. No, no. I was thinking, I was thinking last week, I, I, I visited a client that I don't see very often. And, and he, one of, one of the engineers there sat down and said, well, you know, I'm the sort of person who, who always has time to do it

twice. Never have time to do it right the first time, but I always have time to do it twice. Never have time to do it right the first time, but I always have time to do it twice. And he was telling me this in this voice of, I accept this about myself and it's a fine thing. And I was like, you heard that wrong. The person who told you, you only have time, you never have time to do it right. You always have time to do it twice. That person was making fun of you. They didn't mean it as a compliment or a self-knowing thing. It was, no, it was a, you're doing it wrong. And yeah, I see that a lot. I wasn't laughing at you.

I'm just, he just, it was one of those bite your tongue and hope the client doesn't listen to the podcast. Okay. So do you program in your free time? You know, given that I've been sitting here giving advice on how to write code, no, I don't. I used to when I was more involved in technical books. Actually, I used to write a lot more code. I have never written like huge

huge programs but i'm real good at small ones and i'm good at scripting um but these days it's i mean when you get older and you own a house and you have other things to do it's it's there's not a lot of time chicken has to take care and there's chickens yeah that's it's they take up surprising amount of attention. But when I have time to sit down and do thinky things, I write. I don't program. So, yeah, I always have these great ideas that, oh, I have to write a blogging system that doesn't suck. Or I have to write another to-do list manager because every single to-do list manager out there is no good. So I have these itches that I would like to scratch, but it never rises up in my priority list behind writing or

above writing. Well, then if you're working with code at work on a daily basis, I find that I do more writing when I'm coding at work. Like I write at home if I'm coding at work. And if I'm writing at work, I code at home. And I don't, yeah, lately I haven't been doing many of my personal projects because I've been just so flat out trying to get things done. But you have been writing science fiction lately. I had one story that came out or that I put up on the internet for, I think it was like two months ago or something like that. Is it that long? Yeah. I write a lot, but I don't finish that

much. So when I actually publish a story, it's actually a very unusual thing. Or publish when I put it up on the internet. That's my main source of publishing is just my blog and my website. Why? Why don't you finish them? I have, this is such a cliche. I have perfection problems. I have the internal editor. I have the little voice that's saying, oh, this sucks. This sucks. This sucks. You're totally awful. So yeah, it's hard for me to actually get stuff to a stage where I think it's good enough for other people to see. And I know, I mean, like number one advice for writers is that, oh, you have to write the crappy first draft. You have to just get things down on the page in order to be able to finish anything.

And I have not managed to solve that problem yet. Well, it is November. And November is National Novel Writing Month. I found this out, oh, many years ago when Phil, electrical engineer who's been on the show a number of times, came into our shared office. And I was wearing my headphones, and he was blathering on about wanting to write this great American novel and blah, blah, blah, and I'm like, I'm working.

And he said, you know, November is National Novel Writing Month. I think I want to try it. And I said, if we can stop having this conversation, I will, if you will. And that was August. And, uh, and so I did National Novel Writing Month, which is colloquially known as NaNoWriMo. And it's 50,000 words during the month of November, 30 days. And it's a charity fundraiser actually. They raise money for building libraries, usually in Southeast Asia, although I don't know what it is this year. And it was super fun, but you had to turn off your internal editor. Yes, that's pretty much the key for NaNoWriMo is you've got 1,800, 2,000 words a day that you have to write.

Which is only five pages. Yeah. It's not really that much. It's not that big a deal, yeah. If you just concatenate all of your emails together, you get almost there, which I gather is a NaNoWriMo method. That's a technique, yes. And certainly some of the conversations we had at work ended up in my book.

Ah, that's a good plan. Yeah, yeah. So you said you haven't done it. I've tried it a couple times, and I think the most number of words I ever succeeded on was 10,000. I have trouble just sitting down and doing it every day and and then just spewing that much text is again it's it's the perfectionist in me that's that's like no this isn't gonna happen i uh yeah i don't have as much perfectionist in me i have a lot of get it done more than perfectionist. But I also wrote essentially wish fulfillment. Someone with a resume remarkably similar to mine ends up going to

space and saves the world from terrorists with the help of her rock star drummer physicist embedded systems husband. That's awesome. It wasn't as much wish fulfillment as the guy i sat next next to at the nano rhino rap party he wrote elven erotica oh so very popular you know parties end up weird uh-huh yeah really weird um i would I mean, anybody out there who's thinking about it, we're halfway through November. It's not a good time to start. But they do baby you through it a little bit. They realize that at day 10, you're starting to burn out.

Yeah. Well, the website is really good that way. They have pep talks from famous authors and all these little badges and widgets and things that you can earn if you write more words. And I didn't do that too much. And big forums with all the support and you get together at Denny's at 2 in the morning. You could spend all your time doing that and not writing anything at all. Yeah, yeah.

It really does take a lot of dedication, especially if you're working a full-time job. Although I have known people who wrote their nonNoWriMo novels at work in November. Like I said, I did take a few conversations from work that were relevant, but for the most part, it was after work. I also did a fair amount. My husband hates this, but I often will drink when I do the exercise bike, beer and the exercise bike at the same time. That never occurred to me, actually. It's awesome. It's very relaxing.

But I would do that and have a piece of paper to scribble on so I'd have my thoughts. All right. Yeah. It wasn't a good book. Well, that's not the goal of NaNoWriMo, to write a good book. It's to write 50,000 words, regardless of how crappy those 50,000 words are going to be. And, you know,

it actually helped me have the courage to do the book proposal for making embedded systems. Really? Oh, okay. Because I knew that writing the pages was not going to be the hard problem. Getting the words out wasn't the worst part.

Organizing it, planning for it, deciding what was in, what was out, those were all going to be information problems that I was interested in. But just the pure sitting down and writing, I knew I could do it. And that's a hard thing for a lot of beginning writers to get over is trying to figure out how to get all the words out. Yeah. Because it's a lot of words. A full book worth of words is a lot of words.

And you have to take off your internal editor and recognize that, you know, I actually did finish the book. I wrote the 50,000 words and then I spent the next year kind of poking at it editing it oh wow cool um it never it's it's not very good but uh it was it there were times when i was like i wrote that i don't remember writing that how best to be in the weekend and you could totally tell when i had a cold because i described what happens to snot in space in grand detail. But I think this is true for code too. I think that NaNoWriMo, one of the reasons I want to talk to you about technical writing is I think there's a lot of overlap with code. Not only can you write things badly in writing or in code, you can take the blinders off and accept that you're not going to do a perfect optimized job and sometimes just see if you can get something done i mean that's the

purpose of the hackathons that are so popular right now uh-huh 24 hours and you have to get something something done by the end of it so yeah it you just have to write write write write as fast as possible and not think so much about big, harder issues. I enjoy NaNoWriMo, but I can't imagine doing an all-night hackathon. Yeah. Maybe I'm too old. That's part of it. I mean, I used to stay up all night to write,

and it's just too hard now. There was an article in IEEE Spectrum, probably about 18 months ago at this point, that they said that engineers should read and write science fiction. Have you ever heard that? That recommendation for engineers? Yeah. I'm not sure I've ever known an engineer who didn't write,

or didn't read, at least read science fiction. That seems to go very closely together with the geek mind. Yeah, we're wired together. Yeah. Even most of my engineer friends will write some. They may not share it with anybody, but they'll admit that at some point in their life, they thought about writing.

Yeah. Oh, yeah. Oh, I think most people think about the life of writing. It's somehow romantic. It's not being alone in a room for seven years. Giving up your weekends to work with somebody else because that's the only time they have available. The Spectrum article

talked about finding your way outside the regular barriers, to think beyond what we know about physics, and that science fiction reading lets us do that. And I really liked that. I wish more people thought about it that way. Yeah. Well, science fiction is the literature of ideas, as I've heard it described. Nice and poetic. framework um it it makes you think about new things both when you're writing and when you're reading you you have to approach it approach the problem in in new ways with new ideas and make it all work out so it's it's yeah i i think it it again it matches with the geek mind very well and i think writing it especially it it helps work through those ideas it's i think writing some science fiction

has given me a better idea of how to get from here to there to work through it maybe making me a better architect uh-huh so yeah i don't know that i would share most of the stories that i write now well i think a lot of writing is the process. It's figuring out how to put the words down in the right way and how to make the story work out. There are a lot of things that you have to figure out in order to be able to write stories of various lengths and various complexity. So in many ways, it's sort of a form of mental exercise that you don't necessarily, you don't really need to have something to show at the end of it, although that's softly

nice. Um, but it's, it's just working your mind. It's, it's like practicing the piano, um, or practicing any musical instrument. Uh, you're not going to perform every single time, but you, you going through the motions teaches you things every time. I would have said that about drawing. I don't play an instrument. But yes, what you were saying really resonated.

I think it's doing any art, really. It's finding new places in your head and finding ways for your head to go in different places. And closing out the rest of the world. I maybe spend too much time on Twitter lately. That's a big problem with the internet yes the little little charges every time someone tweets you every time i push the button a kibble comes out it's not yes yes yes it's not conducive to to focus deep focus when when there's little messages coming at you every single minute.

But turning all that off and drawing or writing, it feels good in a way. There's real value to it, yeah. So the other thing I wanted to talk about was information presentation. Are you familiar with the Information is Beautiful books? No. Tufty? Oh, those books? No. Tufty? Oh, those books.

Yes, Tufty. I just mentioned the word Tufty. Yes. Oh, yeah. So Tufty is an author. Uh-huh. And he, I don't know if you've never seen one of his books or graphs, how to describe it, other than the way you say something is important. It is as important as what you are saying.

Well, a lot of what Tufte, at least I studied Tufte when I was in school, and he was at the time really big into infographics, that it's basically presenting data in a visual way. You say infographics, it makes me want to bang my head against the desk. But at one time, those were new and cool. And now they're just overused and trite. Yes. Now the word infographics is used as sort of a shorthand for cute, trite.

Frosting. Yeah. And it's actually the sort of stuff that you see in infographics these days is the sort of thing that Tufte really hated. He said too many colors and poor ratios of data. Yeah, there's not a lot of data, actual real data in today's infographics. Not a lot of info in the infographics. Well, yeah, they're meant to be shared on Facebook. They're really not supposed to specifically communicate.

I like the ones that list percents and then it doesn't add to 100. That was, yeah. And the ones that add to like 150 then it doesn't add to a hundred. That was, yeah. And the ones that add to like 150 and you're like, how is that a pie chart? Uh-huh. Yeah. Yeah. Uh-huh. I was thinking recently that those books should be added to CS curriculums. Yes, I agree. Um, one of the things that Tuft, one of the first books he put out, he described how the Challenger shuttle wouldn't have blown up if the engineers had known how to present the data. They knew what was wrong. They knew that it was going to be horrible, but they didn't know how to tell everybody else. And that's a horrifying thought to me.

That it was a communications problem and not a technical problem. Yeah. And I don't know how to fix that other than trying to put it into schools and to talk about it. Yeah. Yeah, that's another hard problem. It's institutional problems in education and problems in process at companies and at NASA or wherever, in big science-oriented organizations. And also there's – being able to communicate really well is not hugely valued in the industry. So I mean, it's really great if you can do it. And you're considered a fabulous person if you can do it, but it's not going to be the basis for you moving up in the world. It's that's more the sort of hard technical stuff that you can

actually do. So yes, I think it's probably a really good idea to put more sort of information design and communications type curriculums into engineering. And hopefully it will sink in. Well, and there's like Nathan Yao has flowing data, I think, and he talks about how statistics are misused a lot. It's another information presentation problem. But what other books, what other things do you think should be added to the computer science curriculum? Oh, God, I can't. Don't ask me that.

I couldn't even. I had a writing degree, actually. It's not strictly a technical writing degree, but it's a humanities degree. And I took science and computers on the side. So I really could not design a computer science curriculum to save my life. All right. That's fair. That's fair. Well, the other one that was on my list was Diamond Age, which is science fiction by Neil Stevenson. Which actually that is the, I think it's the only one that I haven't, one of his books that I haven't read. So I know nothing about it.

In the book, they design an artificial intelligent tutoring system, which strangely was my senior class project. And I read the book around the same time. So it was a little weird, but it's, it shows, it's one of those areas of breaking down the boundaries and showing not what's possible now, but what somebody who's really thought about it thinks is possible in 20 years or 50 years. And it was to some extent, some, even now I look, I look at some of those things that I found in that book and other such sci-fi books, even going back to Heinlein, um, and think, how do we get there? I want that. And try to figure out what are the steps between here and there. Yeah. And in this one, the young lady's primer, the tutoring system.

I had Jerry Ellsworth on a few weeks ago, and she had the augmented reality glasses, and I'm like, we are almost there. And so I think science fiction is really, it's really important. Well, you mentioned ideas that you had had then and back to Heinlein that ideas have come true. And I think part of that is the real value in science fiction is being able to look forward to extrapolate from the present because you influence people in the present. And then those people, it sort of closes the loop. Those people will try and make what you wrote about true. And I mean, it's heard, we hear it over and over and over again that science fiction inspires kids and teenagers and college students to do interesting things with science.

Well, yeah, Nokia just put on a tricorder challenge, as though that word wasn't plenty loaded by our science fiction banks. The word came from Star Trek, didn't it? Exactly. It wasn't a thing before Star Trek, and people had been trying to invent the tricorder since that happened. And by saying tricorder challenge, everybody knew what you wanted. You wanted something that would go around the body,

beep a few times, and give you your perfect health information. Yeah. And of course, yes, that makes sense. And science fiction gave us that word. Uh-huh. Well, part of that also is what used to be sort of fringy and geeky and weird

in terms of science fiction is now very mainstream. I think science fiction is is now very mainstream and geek culture is very very mainstream so so i mean the whole star trek culture everyone knows it now um and we don't get star trek and start wars confused as much as everybody used to yes so have you read anything really great lately you know when you put that into the notes and I had to go back into my list of, onto my Kindle and onto my Goodreads and it's like, well, what have I been reading? I read, I've been reading a lot of young adult fantasy because it's really easy to get through and it's usually fun and fast. I read the Knife, um, the,

the knife of letting go series, Patrick Ness, there's three of them. Um, they're really, really good. They're, uh, they're a very, very interesting, uh, series about a planet where, uh, the men on the planet have what's called noise. Their, their thoughts are basically broadcasted everywhere. Just the men, not the women. So, oh, and animals. Animals have thought. You can hear their thoughts as well. And they're less interesting than the men's. But it's a series of three novels. It's a terrific, terrific series. The first one is the best, I think. Okay okay what was the author of that patrick ness n-e-s-s okay excellent well i think we're about out of time do you have anything you'd like to leave us with no

i think that was your cue to say something like, keep writing. Yeah. Code more clearly. Respect your writers. All right. I'm going to stop torturing Laura, and I think we'll go get a beer. Yay. Thank you so much for joining me.

Oh, thank you so much. And listeners, I hope you have some new ideas. Thank you for listening. And thank you to my real drummer, physicist, embedded systems engineer, husband, and producer, Christopher White. Send comments and questions to us at show at embedded.fm or hit the contact link on embedded.fm. One last thought by Diane Duane. Reading one book is like eating one potato chip.