256 RR Reading Code and The Architecture of Open Source Applications with Michael DiBernardo

00:00 01:03:01
Download MP3

01:42 - Michael DiBernardo Introduction


[This episode is sponsored by Hired.com. Every week on hired they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It's totally free for users. And when you're hired, they give you a $1,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you'll get a $2,000 instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/RubyRogues.]**[This episode is sponsored by Rollbar.com. If you need error and exception tracking in your application, check out Rollbar.com. They have a great UI and terrific tools for helping you track down the problems in your application and getting it back up and running as quickly as possible. You can find them at Rollbar.com.] **CHUCK:  Hey everybody and welcome to episode 256 of the Ruby Rogues Podcast. This week on our panel we have Avdi Grimm. AVDI:  Hello from Tennessee. CHUCK:  David Brady. DAVID:  A train from Chicago is heading west at 10:30am and traveling at a constant 30 miles per hour. At the same David Brady tells a poop joke in Saratoga Springs, Utah. Given a constant temperature of 20 degrees Celsius and a humidity of 40% and assuming the entire Rocky Mountain range is at sea level, when does this podcast start making sense? CHUCK:  I'm Charles Max Wood from DevChat.tv. Just a quick shout-out. We have Ruby Remote Conf coming up in June so if you're interested in that, check that out. We have a whole bunch of other ones at AllRemoteConfs.com. This week we have a special guest and that is Michael DiBernardo. MICHAEL:  Hi from Toronto. CHUCK:  Toronto, huh? So, these packets are crossing national borders. Wow. MICHAEL:  Yeah. I hope they don't have to run through any water. But we'll see how it goes. CHUCK:  Do you want to introduce yourself? MICHAEL:  Sure. I'm currently an engineer at a company called Wave where I work in payment systems. And prior to this I was actually pretty involved in the Python community here in Canada. So, this is an interesting stop for me today. So, I recently inherited a book series called 'The Architecture of Open Source Applications' which I imagine we're going to be talking about more today. And I'm excited to chat about the [inaudible]. CHUCK:  Yeah. We also have you booked to talk about code reading. MICHAEL:  Awesome. CHUCK:  So, which one do you want to start with? MICHAEL:  I guess I can give a bit of context to what the series is and how I got involved. And that should frame the rest of the conversation from there. CHUCK:  Sounds good. MICHAEL:  I got involved in the Python community here in Toronto in 2011, 2012, when my last business had failed and I was questioning whether I was still the kind of person who had an engineering mindset or not because I had done so many different things [inaudible] of that business. So, I started to get more connected with technical people here again. And I saw that they were trying to run a conference and were having trouble raising money. So, I signed on as Sponsorship Lead for 2012. And then in 2013 I was the Chair of that conference. And in doing so I actually met Jessica Kerr who was one of our speakers. And I remember her really well because the first time we ran the conference I was super stressed out. And there was somebody who kept laughing during the conference. And every time I heard that laugh I was like, “Aw, I'm so happy I'm doing this,” because that laugh makes me really happy. And I found out later it was Jessica's. CHUCK:  [Laughs] MICHAEL:  And it was audible from across several hallways and stuff. So, that definitely cheered me up during the course of that week. But Greg Wilson who is the founder of the book series we're talking about today, he also founded Software Carpentry. He helped us out a bunch with the first Python Conference here in Canada. And so, I got to know him a bit better. And the first two books in the series were released in 2010, 2011 roughly. And the topic material there was really, we got a bunch of reasonably famous or infamous open source contributors to talk about the history and the context in which they inherited their projects. So, the mandate we had for them was, “Can you talk about the architecture in the sense of where it started and how it evolved?” because we feel that a lot of engineers who are early in their career don't have that kind of context once they get out of school or whatever their first learning experience is. They go from their initial learning experience to working on systems that are maybe a couple of thousand lines of code. And then it's luck as to how to evolve from there, and maybe blog posts. And so, we were looking for something that was a bit more in-depth, especially that could possibly be used in an academic context in software engineering courses that there's not as much of a wealth of practical material for them to look at that's actually in textbook form. So, those are the first two. And then the third one was edited by an undergraduate student at the time named Tavish Armstrong. And that was on the performance of applications that had hit some kind of bog for the course of their evolution. And what we found from there, this is where I got involved because Greg started the fourth volume and Software Carpentry that he was running was also starting to take up more and more and more of his time. And so, he graciously passed the project off to me just as I finished running PyCon Canada 2013. So, my family was both vexed and thrilled to hear that this was happening. CHUCK:  [Laughs] MICHAEL:  So, the goal there was that the first three AOSA books, we had this idea of what the authors were going to be talking about. But essentially if you read those chapters it's very much like whatever they felt like talking about, which was great. We got to see the worst pain points and the biggest victories that they had as they were remembering the histories of the projects. But what we felt was that the level at which they were talking at was a little bit too high if your comfort zone is, “I can work on programs that are like a thousand to two thousand lines of code,” as a rough example. And I'm okay. But when I have to grow it beyond that boundary I lose control of my abstractions or what I can keep in my head or what I feel comfortable doing. And so, to read about the architecture of Bash of the underlying architecture of the GNU Haskell compiler, that's a lot. That's a big jump. So, we were trying to find something in the middle and that's where '500 Lines or Less' which is the current volume that I'm working on, was born. So, the idea here was that we would get some open source contributors to write a new program from scratch, maybe something that resembles something they've done in the past, and to keep it under 500 lines of code or fewer. The title, we kept the alliteration. It doesn't make much grammatical sense but we decided to keep it. And the goal there was really for them to talk about the lower-level design decisions they were making and the experience they brought with them from their past programming life that helped them make those decisions. So, that's the spirit of the current book. And so, in editing this book I've probably read now over a hundred code [inaudible]. We can get into the process a little bit later. So, I guess code reading is a pretty reasonable topic for this podcast in that sense. CHUCK:  Interesting. How much work can you get done in 500 lines of code? MICHAEL:  Surprisingly quite a lot. We actually had several contributions come in under the line limit because they got to the point where they're like, “I've shown what I wanted to show. And that's enough.” And I was… well, not everybody felt that way. We may sometimes had talked them in that direction. But there was a reasonable variety of languages used. Python made up the majority of it. I think that's largely because of the network we had when we started the book. The book was actually announced at a PyCon a few years ago and that sort of thing. So, it skewed in that direction. But we had one contributor write their project in Java which is not known as the most terse of languages. And they managed to get a fair amount done in the 500 lines, especially since they were focused on what they wanted to do. And there was a UI [inaudible]. It was an image filtering app. So, it's like Mogrify with a UI basically. They did a fair amount and explained a fair number of their decisions and actually focused a bit on unit testing as well in the context of that 500 lines that they had. So, it worked out pretty well. We had somebody write a functional oriented database in Clojure. And we started… it got to the point where we had scope creep where we started having to cut features that were like, “This chapter's going to be too big.” And I don't think they hit their line limit of 500 lines even. So, that was an exercise in the other direction. But by and large I was pretty happy with the authors. We didn't really have to talk them out of trying to be terse to the point of obfuscation because that would defeat the point. We were a bit worried at the beginning that when we set the line limit this would turn into code golf and we were going to have to encourage people to go in the opposite direction. But it seems like the authors who self-selected for this experience were also of the same sort of spirit that we had. CHUCK:  So, when you look at these examples, what exactly are you looking for? What are the things that you're trying to demonstrate that you can do in 500 lines of code? Is it about simplicity or is it about the power of different languages? MICHAEL:  Good question. Yeah, it was funny in the early weeks of this project seeing… we had a few people come onto their    various pull requests that the authors were opening just when they were writing their code. So, the process that each author had to go through to get a chapter into this book was they proposed a canonical problem in software engineering. So, you might write a mini-compiler. You might write a mini-template engine. As I mentioned we had some people, a couple of people work on database style projects. And the goal there was actually to implement something meaningful that had some sort of recognizable use. It's not just like a toy solver or something. It's actually a program you might use at your desktop or something that people have grown into bigger programs over time. And the goal there was to say, “Pick a feature set that you think you can implement in a small amount of code.” And then as you build it out, try to pay attention to the design decisions that you had to make in order to even accomplish this task. And possibly to think what you would need to do to get to the next set of features you anticipate this program needing. And let's document those. Let's see what your thought process was in what abstractions you picked, why you used those abstractions. And that sort of thing. So, that was the task that was given to them. And it was funny seeing some folks open issues on our repo who… I didn't actually have a really strong spirit for the book yet because I wanted to see what people were committing before I did that. And there were a lot of people who had their own internal idea of what the book should be very early and were opening issues saying, “This chapter is junk. I don't want to see code like this in the book because it seems to be defeating the purpose of what the book's mission is.” So, I paid really close attention to those ones because I wanted to see what people thought the mission was before we picked it. And so, for me it was really in the end to see: what is the current landscape as to how reasonably experienced engineers are tackling problems in their domain that they're familiar with? And what's the playbook or recipe book that they use based on their past experience and their community's experience when they go to build software in this area? So, we had a few folks working in computer graphics so they were doing 3D renderers, 3D modelers. And that's a big of a different domain than say a distributed systems problem that one of our authors tackled as well. So, seeing the kinds of abstractions that those people went to immediately. And the review process for the book was that the author would submit their code and we would have at least two technical reviewers plus myself look at it. So, there'd be one technical reviewer who came from somewhere in the community that knew quite a bit about the domain that the author was writing in. So, if you're writing in computer graphics it's a person who's worked in computer graphics before. And then we would also get somebody who was more junior and probably didn't know a lot about the domain. So, hopefully somebody two to three years in their programming career and working in web when they're reviewing a graphics chapter or something. And the goal there was to make sure that we were technically accurate and we were doing things that weren't incorrect but also to have the younger audience take a look at it and say, “I don't understand at all what you're talking about so I won't learn anything from this.” And then we did the same thing when they wrote the chapter based on that code. So, throughout those review processes we got to see what the reviewer was expecting to see when they came in and what the author actually wrote and how those differed. And to somehow try to meet in the middle so that hopefully these examples serve as a basis for people to talk about writing software in this domain, especially if you're new to it. So, that was where it ended up near the end. I don't think I had that clear of an image of what it was going to be when we started. And if you look at the early conceptions of what that book was, it was very much like, “Let's write perfect examples of things in only one language so that new engineers can come in and learn about the best practices in programming.” And I got about two months into it. I'm like, “This is a terrible idea. I actually want to see what people are doing on the ground for real in whatever they presume their day job to be and giving that experience to programmers who may not have that yet.” CHUCK:  I was actually going to go there. You mentioned that it was architecture of open source. And why open source? What makes open source different from stuff you write for your day job? MICHAEL:  Yeah, cool question. So, I think the open source moniker on this book is less appropriate than it was on the first couple. The difference with the first couple of books was that the authors there were people who had lived a project for a long time and were relaying their architectural observations and lessons that they learned throughout that project. And the hope there was that if you really wanted to, you could actually go look at the source of that project and hopefully look at the commit history and start to match what the author mentioned about its project's evolution, about their project's evolution and what was actually demonstrated in the code and the architecture documents that were there or whatever the artifacts were. Whereas if you were to document… so, the first Martin Fowler book, he has so many books that are patterns of things and enterprise-y things and whatever, but I forgot what the title of the first one is. But it was really a recipe book of patterns that he saw in different systems as we worked as a consultant presumably at ThoughtWorks. But you would never be able to go and look at the source of those projects to map out what you were seeing as the declared lessons learned and what was actually done. And I think that was more of the intent in the first ones, to give people access to the actual source so they could go take a look at what the author was saying versus what was actually done. For this book because they're writing it from scratch anyways, the fact that it's open source I think the best thing it got us was a ton of people chimed in with fixes or just suggestions to things that confused them, even if they weren't explicitly assigned as reviewers. And now, all of those reviews, the vast majority of them were done on GitHub. So, if you actually want to go back and look at how the code reviewers were implemented you can very easily. And I think if I had to do another book in the series that was divergent from this one, it would actually be more focused on the review process than it is on the artifact, because I think I learned more from doing the code reviews and managing them and the chapter reviews than I might necessarily have just by reading the book. CHUCK:  What are some of the things that you picked up from doing the reviews? MICHAEL:  [Chuckles] Yeah, how to be a really good human being was a big part early on. DAVID:  [Chuckles] CHUCK: I'm so bad at that. Can you be more specific? MICHAEL:  Yeah, I know. I will be more specific. I think when we first started assigning reviewers, especially when we had the domain experts coming in to review the author's code, there were so many things that [worked]. Like we had a lot of authors who were writing a chapter like this for the first time and were writing code for… the primary purpose of this code is inspection. You want people to come and use it as a good example. So, it's different than “I'm writing good code for whatever definition I think is good code for my day job. And I'm more concerned possibly about how it works and what it does than it being used as an example for people who come after me.” Whereas in this case they were explicitly writing code for people to use as a good example. And I think a lot of our authors had some nerves around “Who am I to say what is a good example?” And Greg has a speech he always gives which is if you spend a couple of days really, really digging deeply into something you're probably an expert relative to most people. And so, that's a good enough platform for you to start from. So, we really pushed that hard at the beginning. But I think the authors when they were finished, their initial contributions weren't actually sure, some of them, if what they had done matched what would be considered good practice for a program like that. They did the research. They did what they could. But there was that aspect of it. And then when we had people coming in there were so many levels at which different people expect a code review to be conducted. So, we gave some guidelines early on. And one of the ones I tried to implement early with was come up with some idea of what you expect to see in terms of how you expect things to be organized before you do the review. And then let's try to comment on the things that differed from your expectation rather than talking about, “This is bad. This is bad. This is bad. This is bad.” And the reason why we did that was because I was hoping it would encourage some of our reviewers to take a look at any sort of public documentation or just patterns that they'd used before and maybe give the authors some idea of how to reduce the surprise of people coming in to read their code for the first time. Because otherwise, what I found is that the focus became very low-level like “You could do this more efficiently or your variables are named poorly or this doesn't match what good style is in Python,” or something like that. Those are useful but that's not really why we wanted the technical reviewers there. We really wanted them there to help the readers get the best experience they could when going through the chapter and learning, “What is a set of higher level primitives I can expect to see in a program of this type?” DAVID:  Right. It's not the implementation of open source applications. MICHAEL:  Exactly. DAVID:  Where there any cases where the trade-off was… like the solution and the counter-proposal were both equivalent? MICHAEL:  [Chuckles] DAVID:  Like what they did was good but what was suggested was also kind of good? MICHAEL:  I feel like… the reason why I laughed there is because the first thing I thought of was that it felt like more than… this is a made-up number but it felt like about a quarter of the time the reviewers and the author were essentially saying the same thing. And it was the atoms of their vocabulary that were mismatched. And so, my job was really to get in there and say, “Hey, I wonder if maybe this word you're using over here and this word you're using over here are actually the same word. And I wonder if this means that we should just name it something in between or think of some alternate names.” And that came up a lot. And… CHUCK:  You keep using that word. I do not think it means what you think it means. [Chuckles] MICHAEL:  Something like that, yeah. Or I think you mean some variation of that that is I think we all think it means the same thing or something. But it happened quite a bit and that's really where my thoughts started to go in the direction of hoping that this book would provide people with a richer language to use when they cross domains other than just what their programming language gives them or what their set of known programming languages give them or whatever their lower level set of primitives is. Because I feel like as a programmer, until I work in a particular domain… and after I finished grad school I got really sick of everything I was doing in web so I started programming games for a while. Not because I thought I was a good game designer but because I wanted to know what it felt like to have to put something on the screen every frame. I didn't know what that felt like and I wanted to try it. And I started learning about scene graphs and all these different things in 3D graphics rendering that until I saw them I probably would have been thinking about them more in the context of just control structures and objects and not the higher level architecture until I went to read about it. And that's what I'm hoping we can do, is just show people who don't have a chance to take a survey course in 10 or 12 different pretty common programming domains about: what are the sort of abstractions that people use, not necessarily for reuse, but just for better understanding or better organization of what they're doing? And maybe: is this something that you can bring into your world that you work on every day to improve your own project that you're working on? CHUCK: It's funny that you talk about communication issues, because I wind up… I've been talking to a lot of new programmers and they're so focused on these technical skills and they're so focused on: how do I level up to the point where I can get hired? And I keep telling them, I'm like, “Look, the hard parts of programming are finding the right solution to the problem you have and the other hard problem is communicating well about abstract technical topics, which usually entail those solutions that you just came up with.” And the example I give is when I applied for my first programming job. I actually got the job. But it was interesting because the way that it went was I was on the phone with the developer that was doing the interview and he would say, “Well, do you know what,” for example, “design patterns are?” And I had no idea. Yeah, that's what your college degree gets you. I had no idea what design patterns were. Anyway, so he explains it to me and I turned around and I said, “Oh, kind of like this thing that I've done and this other thing that I've done?” I picked up the ideas on the internet but I didn't know that there was a formal name for it. And it's interesting that once we have a formal name for it and we all understand what the definition is, it makes it a lot easier to communicate about. But I also find it interesting that people who are deep into these areas of expertise were basically like you said, there was this crossing of the wires where somebody had a different term or a different way of explaining the same or similar ideas to people. And that really is in my experience the thing that will make or break a coding team, and that is communication. In other words, do we understand what we're talking about with each other and do we understand what we're trying to do? And if we can't communicate clearly about it, then that's an issue. MICHAEL:  It's neat that you mentioned that because what I found which I found I was very happy about, but what I found as I worked with some of the programmers that were more experienced in their domain is that they were more inclined to be picking abstractions or organizational techniques because they communicated intents strongly rather than for some idea of reuse or extensibility. And oftentimes… DAVID:  Nice    . MICHAEL:   They would choose that over future extensibility now knowing in which direction they would have to extend things. Because some of the early conceptions and statements of this book were like “let's show you how to write extensible software.” And when Greg showed me that, I kind of cringed a little bit. I was like, “[Inaudible] I'm going to delete this paragraph and let's see what people come up with.” And I did feel like more of the junior reviewers who came in were always thinking almost first of reuse. And reuse at a low level, and how does this get reused later or how can I predict where change is going to be? And how do I guard against that now? And a lot of more experienced reviewers in those spaces would be able to say, “Well, here's where we see change going normally. So, this isn't as high risk over here. And we feel like it's better to expose exactly what's happening in this direction so that you can come in here and know exactly… what you expect to see is what you get.” And in cases where we felt like that wasn't happening in the context of the chapter, I remember one chapter that I worked on with an author. We probably did five or six reviews just them and I trying to get to a point where we felt like people could read this and understand what was going on. And my favorite part of that is that we threw out a bunch of abstractions that were really there for “Maybe one day we'll use them and you could just add a line to this dictionary or something and it'll just work.” And we came up with something that more closely reflected the vocabulary of the space they were working in. And when we got to that the author was like, “Whoa, this is so cool.” And I was like, “Yeah, this is actually really cool. I didn't expect it to turn out this way.” And that was probably one of my top 10 happy moments in working on this book. DAVID:  That's awesome. One of the things that I'm seeing in the wild is more and more… we're actually seeing a genuine heresy where people are coming out and actually saying, “Is reuse just wrong? Is it a lie?” And I'm starting to become swayed to that camp. That yeah, don't write for reuse. Write for understandability and intuitive and make the software easy to maintain. If somebody needs to extend it or reuse it, if you've written it to be intuitive and understandable that's very easy to lift and reuse. But if you've written it for reuse it's very hard to make it intuitive and understandable after the fact. CHUCK:  Can I clarify something, Dave? DAVID:  Mmhmm. CHUCK:  I know some people just heard you say “Don't be DRY' and I know that's not what you're saying. DAVID:  No, no. CHUCK:  So, I'm going to let you clear that up because I can just hear somebody going “Oh, well if I'm not building it for reuse then I have the other problem that DRY solves.” DAVID:  Right. So, when I'm talking about reuse, I'm talking about designing your software in such a way that I'm going to solve this problem not just now but I'm going to solve it for all time. I'm going to solve not just this specific problem I have but the general case of this problem. And then if somebody else is going to in a completely different application, if they're going to try and solve this then they can reuse my software. And it never, ever works out that way. And for example, we recently had some code come through that had inversion of control pattern in it which is a very heavily reused oriented pattern. It's the strategy pattern taken all the way to the fossilized extreme. The strategies are embedded, hard-coded in the class inheritance tree. And as I was talking with the guy who wrote the code I pointed out to him that… for those who don't know the inversion of control pattern it's where you have a superclass that implements the algorithm, like pick a thing and transform it and then put it back in the stack. And now you can write anything that picks things, transforms them, and puts them in stacks. All you have to do is write a document picker stacker or you can go over here and you can write in a completely different class that's a packed re-orderer or whatever. They all do the same. And the child classes have, they have to implement the methods. They have to implement the pick method, the mogrify method. And in the class that I'm talking about, they're actually called mogrifiers and the method is actually called mogrify. That's fun. Naming things is hard. Anyway    [chuckles] the child class has to implement those three things. And so, once that's done then the parent class can just say, “Hey, I know I can pick. I know I can reorder and I know I can save back.” So, that's great. That can be reused by any child class. And I was talking with this other developer I said, “You’ve implemented the inversion of control pattern here. And I just want you to be aware that there's a trade-off that you are making and you're making it upfront and it sounds like you're making it for free like you're not really getting anything back for it, which is that the interfaces between the parent class and the child classes is very fixed. And it's cast in concrete and it's very hard to change. Which means if you ever have to change the algorithm of pick, transform, and place, if that ever has to change, you have to rewrite everything. You have to rewrite the superclass. And then all of the children classes have to be rewritten to accommodate the change in the algorithm.” And at the time I was speaking with this developer he was like, “No, no. it's fine. This will work.” And I'm like, “Okay. Just be aware.” Sometimes it's worth it to trade your cow for some beans. But you really got to want the beans more than you want the cow. And sure enough a week later, it turns out that the algorithm was wrong and had to be updated. And it had to be updated in a way that required a change to the interface, which meant that the superclass had to be rewritten. The interfaces between the superclass and the child class had to be rewritten and all the child classes had to be rewritten. Fortunately there were only two child classes at that point so it was early enough. It wasn't a massive legacy rewrite. But anyway, that's an example of reuse gone horribly wrong. And that's what I mean, is that if you aim for reuse, the chances that you're going to write code that's hard to modify, they go way, way, way, way, way, way up. CHUCK:  So, just to clarify, what you're advocating is solve the specific case and then add in the reuse where you need it. DAVID:  Mmhmm. Solve the problem you have today. Solve it clean and refactor it and make it neat and extensible. And then later on if you have to optimize it or if you have to maintain it or if you have to modify it, or if you have to reuse it or if you get to reuse it, it's very easy to do any or all of these things now. MICHAEL:  Yeah, a practice that… I work on a pretty small team. There are four of us at any given time and I really like the people I work with. I've in the past worked at bigger companies    where there are a lot of smart people and you don't really get to see what they're working on until it's pretty big. And they open a pull request or some kind of change set and you go to review that. And at that point, the inertia behind, or the momentum behind what they're doing is very high. DAVID:  Yeah. MICHAEL:  And I feel like it's harder to change minds, even my own, about what just landed on my lap sort of. So, here what we often do is if an engineer feels like the decisions they're making are going to have any sort of that higher level design behind it we'll try to just jam for 10 to 15 minutes and just think about as a group, where are some of the directions we think this might have to go in the future and are we relatively safe against that if we need to? And so, what's the simplest thing to do now? And so, I started rolling some of that into the reviews [we were doing on the book] as well, which is if an author was hung up on a direction they were going to take their chapter we might ping a couple of the reviewers to say “What do you think of the value of this just in terms of what we're going to show?” just to save them from maybe painting or coding themselves into a corner where… they're doing this for free. There's only so much time they can put into it. And we don't want to get into a point where you feel like the work to undo the decision I just made is so large that I just feel like it's better to ship it at that point. So, I wonder if in the average development process there's room to say, whatever you want to call it, design review or something like that, but is that actually… I'm wondering how many professional “code reviews” are the first time people get a chance to put input into what's being done and how valuable that process actually is. Because I feel like in a step before it can save a lot of grief and come up with something that's a lot better before you even look at the code basically. CHUCK:  So, I'm curious now. You've talked about 500 Lines of Code or Less and we've talked about some of the things you've learned from the review process. Are these things going into the book or do we need a book on the book? MICHAEL:  [Chuckles] CHUCK:  The other question I have related to this is what do you want people to learn from the book? MICHAEL:  [Whoa], those are heavy questions. I've been thinking. I look back at my notes from what I learned, because I've been doing this for about a year and a half longer than I expected to have to do it. And the head space I was in at different points of the book's inception were very different. And I've gotten to the point now, I think… we had one of our authors comment the other day when they were just wrapping up their chapter. They're like, “I don't know if this is common or something to this effect but I was hoping to get to the end of the chapter and feel like I accomplished something. I'm really grateful to everybody who helped me but really I just feel sick of it and I never want to look at it again. And I feel like what I've done is disgusting.” And… CHUCK:  [Chuckles] MICHAEL:  My comment was, I feel like most editors and authors feel exactly that way with everything they do. So, as we get to the end of the book I was a little bit worried that I'd be clouded on what had been done. Because I don't know if this is common but I always feel like when I get to the end of a project, the way it ended up wasn't quite how I intended. And I'm wondering if I missed the point or something, or if I missed the mark. So, looking at what we've done in the last even six months where we're just really tying up all the loose knots and trying to get stuff out the door, I looked at the variety of stuff that came out. And when I try to draw parallels among the chapters, I had a really hard time looking at that saying, “Yeah, there are commonalities here.” I think the commonalities that we saw were that each individual contributor had a set of things that they thought was very important. And a lot of those were implicit when they wrote that chapter. Like they had evaluation criteria that they were using to evaluate whether their own project fulfilled the design goals and whether that was good and why it was good. And I don't think all of those things were made explicit in all the chapters. So, what I would really hope, I'd be curious to see when people read the book, what surprised you in this chapter, what do you think about this chapter is actually bad in the sense that you don't agree with the engineering practice or you don't agree with the direction it was taken in and why? Because I think that would actually make an interesting subtext. And that again, I feel like this book is, if we had the time and the interest, there's a lot of artifacts that could come out of this by just using this as a foundation. The code reviews were one, because just seeing the evolution of some of these chapters is pretty remarkable and how they started, especially the ones that started way too big and we needed to get them down to size. That is in itself, is interesting. But we had programmers who come from academia who wrote a couple of chapters that were pretty mathematically heavy. And the kinds of things that they worry about in their architecture were very, very different than the kinds of people who were writing say web stuff. They were more focused on, is my class inheritance hierarchy going to save people from writing code later? Because a lot of scientists that I work with don't know how to write code well. So, I want to make it very easy for them to subclass this. That's such a micro-level of concern. And then you look at some of the bigger systems problems and we're thinking more about reproducibility. How easy is it to understand how the system runs in production under different failure modes? It wasn't presented at the beginning of the chapter that this is what we were trying to do. It was just sort of a hard-driven in assumption in the author that this is what you need to do to write code well in this domain. And so, I wonder now if going through and trying to draw large boxes around these domains and saying, “Hey, when you're in computer graphics programming we know that they were certain things that people thought were important. But here's what we're observing just based on what we see here as being core design tenets in this particular domain.” And the reason why I think that's interesting is because I think, because the title is software engineer or programmer, that sounds like that's your job and that's all it is. Programmer. But most people who've been programming for any amount of time develop some expertise in some style of it. I wonder if the discipline is coming to the point any time soon where we will be more concerned about, here is the extra level of domain stuff that you need to know to work in this domain. And it sounds vague because I still haven't quite worked this out yet. But I don't know that this book is going to be the one to do it. But to me it was interesting to look at this and say, 'I feel like there's a lot more that can be done in this direction that isn't properly addressed just by calling everyone programmer or engineer.” So, that's kind of where I want to go next. The other direction I'd like to go in is sort of, I hesitate to use the word soft skills but I think… I listened to a couple of podcasts in the series before coming on the show and one of the contributors here is writing a book called 'The Compassionate Programmer'. Is that correct? 'Compassionate Coder'? CHUCK:  I think Coraline might be working on that project MICHAEL:  Okay. Because I heard that title and like, “Yes.” That sort of feels like having gone through all these code reviews that were done in public and had 60 volunteers come in and on the whole be great people and just wanting to help. I feel like there were a lot of lessons that we could codify there, no pun intended, and say like, what's in this direction? Because I've lived a lot of different lives that aren't really what you could say were in engineering. I was a technical recruiter for a little while. Sorry. I ran my own business for a little while. I left engineering for a little while. And I feel like a lot of those skills that I learned there, I use a lot every day. And I don't know what that resource looks like. I'm sure there are a lot of helpful ones. But I kind of want to start exploring that side of things as well. Like if we're going to be well-rounded engineers, what are some of the hard skills we can learn there that are interesting to people and fundamentally make our lives better? AVDI:  I have a question about reading these books. I love the idea that more books are starting to collect the 'how we solved it' stories from many different projects. And I love the idea of learning from that. But one thing that I find as I spend more time just making myself go through books that I've been intending to read for a long time, is I've been thinking more about retention and realizing that I've just gone through a big section and I'm not sure that I retained as much as I really wanted to. And I'm curious if you have any pointers, any ideas, on how to read a book like this. MICHAEL:  So, something that we saw that was really awesome I think in the last year is that… so, this may not be super useful for you in particular but again a lot… these books, the initial idea was that hopefully we could get especially people in academia some readily-available teaching material that they might find more useful than the academic material in software engineering themselves. And so, we did see a class… I think it was a university in North America where they went through the first couple of AOSA books and then they picked open source projects that were either in the books or just arbitrarily out in the wild somewhere. And they wrote their own AOSA chapter in the style of what we had done before. And I thought that was a really cool project, especially the ones that replicated what we had already one. Because I think they went off… I hope they went off and did it without relying too much on what they'd read already and then seeing how they compare. See what the author comes up with relative to what you learned about the project yourself. I think that's pretty neat as an alternative. I think if you just read through these books and [inaudible] through them, like the first thing I did when I picked up the series was I read the first two books. And definitely the ones that were closer to my experience were helpful in incrementally teaching me something. Things that were completely foreign, I'm not sure how much I personally was able to take away from them without reading them over two or three times. So, I think certainly in academic context where the intention is that you'll probably do something like that, I think these books are [really] helpful. I think for somebody reading through it, again the exercise of going into a chapter like this and thinking ahead of time, “What do I expect to see here?” Like if I'm going to read a chapter on how to write your own template language for the web, what kinds of abstractions do I think I would come up with if I was going to solve this problem? How would I roughly design my architecture? How would I write the code? What kinds of design considerations would I think are more important? Is it performance? Is it consistency? Is it reliability? What is it? And then read the chapter and take a look at, okay, well what did this author decide? And keeping in mind that at this point probably five or six other people have reviewed it at least. And hopefully the level of surprise that you have going into that chapter or maybe the surprise is that it wasn't much, much different than what you expected, just going in there with a mental model first may help you to remember the incrementals better than just going in cold. So, that's what I've tried to do when I read the authors' chapters for the first time. And then when I read their subsequent drafts, that helped even frame my notes that I was taking in terms of [inaudible]. Like I expected to see a scene graph. I expected there to be these kinds of nodes. What I saw was, there's an event loop where I didn't expect it and there's no explicit scene graph. And now I'm confused so where do we go? Something like that. I feel like that helped me bring what I was picking up from what the author was trying to tell me better than just going in with my own brain being cold upfront. AVDI:  That makes sense. CHUCK:  So, about Jessica's laugh. I've been thinking about putting together a sound board. [Chuckles] CHUCK:  Jokes aside, does anyone else have questions or is there something that we should talk about with the book or the lessons learned that we haven't gone into yet? DAVID:  I'm still percolating. I kind of hate that we veered away from what you mentioned about soft skills and what soft skills are important. So, I kind of want to steer back to that a little bit. Unfortunately I don't have good commentary other than to just bounce the question right back to you, which is what have you seen through the process of building this book, about… you joked earlier on about being a good human being. And have you learned how to do that is I guess what I'm asking. MICHAEL:  [Chuckles] DAVID:  We all know you're a horrible person. But… MICHAEL:  Yes. [Chuckles] DAVID:  Here's the time to whitewash your reputation a little bit. MICHAEL:  [Chuckles] Yeah. Good question. So, I think the one thing that I found very helpful about I guess a quarter of the way through doing the code reviews was I'd been reading a bunch about negotiation. Because I felt like a lot of the people I was mentoring were getting into situations where they needed to diffuse tension between two people or they felt like they needed to get what they wanted to get their job done. And so, they were looking for ways to get what they wanted. And they really focused on that. And so, I read some things on negotiation. I don't even know how good they are. But 'Getting to Yes' is a book that I feel gets recommended all the time. And it just so happened that it was 80 pages long. And so, I was like, “Well, this one wins because it's short.” And so, I read that and a few other related works that I don't remember. So clearly, this was the one that won. And that felt like a tool that I could use to be fair and in the best interest of multiple parties. And so, I try to get folks that I was mentoring to sit down and say, “Let's try to think about A, a factual angle.” So, I think some of the recommendations in that book are: don't take a position. Look at the facts and encourage the party you're negotiating with to do the same thing. And maybe when you look at them together and frame this as a problem you're trying to solve together, you'll find solutions that you wouldn't have thought of if you've just taken a position in the first place. And so, when we got to code reviews I actually find myself doing that reflexively until I realized what I was doing which is I was seeing two people talking. And a lot of times they had taken a position. Like, “My position is that this is bad,” or, “My position is that we need this in there.” And my role would often be like, you'd see a series of GitHub comments that were 10 or 12 down and it was just a back and forth and I would always just try to summarize the arguments that I had seen so far and then just re-frame the question as, “What about X?” or “I wonder X.” And just silly little things that I started to learn about how to, I hope helped diffuse tension. I can't measure it because there's no replay function to go back and try it again while I was being… using a different technique. But even in my day-to-day reviews and self-critical work we do here at my day job, I do encourage people to do what I think some would perceive as silly things. Like, instead of saying 'You did this in your code,” say, “I wonder if we should do this.” It's not you, it's us. Because ultimately we're both responsible for maintaining this. And that was the mindset I tried to set both in the reviewers and in the authors. And then the other one that came up a lot in the context of this book specifically were trying to recognize situations in which you may be talking up to somebody. And by talking up I mean that you're at a communication disadvantage. So, I think that term comes from if you're a native English speaker for example and you have a friend who is a native Spanish speaker. And they come to visit you in an English-speaking country. If they have a bit of English in their repertoire but it's not really well-    practiced there's this innate feeling like they're just simple or they're cute or they're not very smart or something that we can't really help but feel. And it's because they can't express themselves in the way they would in their normal language. And so, there's this idea of talking up in the sense that you're at a higher cognitive level or something, which isn't true. It's just that's the impression. Like somebody objective who is English-speaking would observe that conversation. So, I try to recognize cases in which this seemed like it was happening in code reviews. Like there's a junior contributor and it seems like they're skirting around an issue or they're afraid to ask a question. Or they're saying something and the author is not getting it because the language that the person who is unfamiliar with the domain is using just doesn't match. And the author hasn't taken the time or even realized that “Oh, they're lacking concepts that I can't even think that I need to explain.” And that is a thing where I would try to bridge that communication gap as well. So, it's like you know how you have a facilitator in most retrospectives? I feel like it would be an interesting experience to have code reviews where you don't just have two parties in the code review. You have three. And one is a facilitator. DAVID:  [Chuckles] MICHAEL:  Because it's extra person power that has to be involved to get that work done. But this is something I've thought about trying here at work. And essentially what I did by default during the AOSA code reviews, which is let's try to make the most out of this review because you folks are putting in your time voluntarily. And I want to make sure that everybody has the best possible experience in doing this. DAVID:  Did you ever have a case where you can just say no if… MICHAEL:  [Chuckles] DAVID:  Obviously you don't want to name names because I'm going to ask you to provide a bad example. But if there was just one or two bad examples and the guilty parties would know who they're… I don't want to put you in that position. And actually, there might be a case where you can use a good example of this. But did you ever find a case where… and this hearkens back to where one side has a good idea and another side has a different good idea and they're not seeing… they're just talking past each other. Did you ever have a time when facilitating was really hard? MICHAEL:  Yeah. DAVID:  Like, in this corner we've got renaming everything with intentional names and making functions out of everything. In this corner, we've got efficient code that doesn't call a stack frame. Let's get ready to rumble! MICHAEL:  I can think of two cases immediately. There are probably a couple of others. But there are a couple of cases. Thankfully, these happened over email so it was a bit… well, I don't know if that's thankful actually. I wonder if these had been done in public, if they would have gone differently. But they weren't bad. It's just the amount of work that was being done relative to progress being made was terrible. And for me it was fascinating because in both cases what happened here is that we had two people who were definitely experts in what they did, like definitely. They were well-known in their communities. And we thought it would be a great idea to get these two experts and have them review each other's work. And this happened… we did this simultaneously with four or five different groups of folks. And a couple of them, we did not realize that they were axiomatically at odds with each other's style, from the ground up. There was just a huge amount of difference between everything that these people valued in their own programming practice and in their own work. And they were also at this stage in their career where I felt like there was a certain amount of artistry and pride to the work they were doing. And so, it's not the kind of person who's going to readily back down and say, “Oh no, I submit to your idea. I think it's possible” So, watching these exchanges was endlessly fascinating for me. And I [go] back and read them once in a while because I learn a lot every time I go back and see. Like, “Wow, I didn't even think about this as an argument. That is so cool.” But they weren't very productive in getting things moving forward. So, in the most extreme cases, what I would have to do is say stuff like, “At the end of the day, this doesn't seem to be…” like a polite way of saying, “This doesn't seem to be getting anywhere.” But it was very valuable feedback on either side and it gives us a lot of things to think about. There was always the invariable thing like we had some reviewers who would say something like, “Based on these reasons I don't think the chapter should be included in the book.” And that was where I felt like we were going a little bit too far and saying, “Maybe we don't make that decision yet,” because I can't see many examples that could be so atrociously bad that there's nothing to learn from there, or even that there's not much to be learned from them. So, in those cases what we'd end up doing is I would often stop the review and say, 'Thanks. I know we didn't come to firm conclusions but we definitely generated a ton of stuff to think about.” And then I would get all that feedback and go work with the author on it personally. And we would try to say, “Okay, let's try to figure out what our audience would think of this.” And so, that's the last [major] lesson that I think might be interesting to discuss in the context of this conversation, was that one of the big, big things I picked up while working on this book was the concept of audience and thinking about your audience. And that's what I used to try to bring up in some of the more difficult code reviews was to say, “Hey, we're not reviewing this on the grounds of whatever we arbitrarily think is good. What kinds of programmers do you think would be working on this kind of code in their day-to-day life? And what kinds of things do you think junior engineers might have a harder time understanding if they were to pick up this chapter? And can we focus on that?” And that tended to refocus the conversation a bit. And so, that's something I've actually done a lot at work, which is to say the chapter, the audiences that we picked for the AOSA books are actually kind of terrible in the sense that if your audience is any junior engineer who might have any sort of experience who we want them to learn something, that's a super hard audience to write for, in my opinion. Whereas when you're forming your own team or your own set of teams you probably know, “Here's the domain we're going to be working in for this foreseeable future. Here are the sorts of people that we think are going to be interested in this kind of work. And maybe these are the kinds of abstractions or design decisions we think they would be least surprised by. Maybe we should stick with those.” Like, I work in the payments space now. And so, there are certain attitudes and sets of expertise that we see in people that come in that are interested in that space. And I feel like that's a lot easier than an audience to look at, because we know more about them. That may lead to us making assumptions about them that are wrong but at least we have some context. And that's something that we really pushed early on in the book's life. A lot of the authors who were not familiar with writing a chapter or not familiar with writing technical material for a big audience, we held an open Skype call for them to come and ask questions. And Greg ran a little session with them that he's done in the past which is basically stop worrying about being technically accurate and start worrying about telling a really good story. Because people are going to learn more from a good story than something that's very dry but perfect, you know? And so, that got me thinking about extending this idea of audience further. So, one of the… there's some mention of picks and I don't know if I'm jumping the gun here a bit, but you guys, you folks asked me to maybe look ahead and pick two or three resources that might be interesting to share in the context of this podcast. And somebody in a previous podcast recently mentioned Brandon Sanderson who's a fantasy author. And I actually hate his writing, like a lot. [Laughter] DAVID:  [I'll tell him] you said that. MICHAEL:  Yeah. But I love his podcast. He has a podcast called Writing Excuses. And that is one of the best podcasts I've ever listened to about anything, ever. It's phenomenal. And one of the things I really picked up from that both in my own writing and in working on this book was the different ways of thinking about your audience and the importance to your own craft of considering who they are and how you're writing for them. So, I feel like a lot of times in the context of code writing or work that we're doing we can use that as an overriding technique or concern in what we're building to say if we're thinking about readability maybe let's not use the 10 or 12 things that we've read in our own history about readability that we think are important just because they came to us early in our career. Let's maybe think about what we've seen in our team and the kinds of things that they react to and the kinds of things they understand. And let's make it readable in that sense rather than in the sense of, I think everything should be two tabs or something, or two spaces to a tab or something like that, right? So, these are all the things that are nebulous in my brain right now. And I have to write an introduction to the book. So, I'm hoping to [inaudible] lock some of them down before I do that. But the thing that came up when I first tried to give a talk for 500 Lines was I have one topic I can talk about in a 10-minute talk, it's going to be audience. And I think there's a lot there to be considered as well. DAVID:  Would you say then that the most difficult interactions that you had… and by the way, email is one of the least empathic modes of communication. You said you wondered if it would be different if they were in the same room together. And not knowing the people involved or the topic of the conversation, I'm confident that I'm right when I would say, “Oh, yes,” because email is a time and a place where you can just write… it's all about you. You can make these very eloquent arguments and da-da-da-da-da, but yeah. If you've got an axiomatic disconnect with somebody which is you've got a fundamental core belief or something in your wheelhouse that is based on something completely orthogonal and unrelated to what is the core fundamental that somebody else uses, you're going to have a hard time seeing eye to eye and you have to get those people in the same room so that they start treating each other like people rather than opposing positions. The interesting thing that I'm hearing you saying is that yes it's hard to write for junior audiences. It's hard to write for people who are new. But it sounds like it's even harder to write for people who have obtained expertise in one area but they're being written for in an area that they are very inexperienced and in a way quite junior. And because they have this expertise elsewhere, especially if that expertise applies to the domain, is that when you feel like you run into the most trouble getting people to cooperate? MICHAEL:  I wonder there if there are a couple of cases. I think one might be a case where yes, you're very learned in a particular domain. And maybe I hadn't realized yet that some of these lessons that I've learned are actually domain-specific and some of them maybe are more general. I feel like another situation where that might happen is for people who have been instrumental in creating new ideas or creating new techniques that are very popular. Like how often does this happen? But I think within even specific organizations like, Dan Luu was on recently and he talked about the normalization of deviation and how certain things get a little bit wacky in certain organizations when they're rewarded early on and consistently. Oftentimes I imagine in certain organizations there are people who feel probably rightfully so that they've contributed new ideas or worked within the context of that company that was very revolutionary or different and had a lot of success. And maybe that's the case where they feel like they may not… sorry, maybe that person isn't disambiguating the things that worked for them in their domain or their level of expertise with this problem that they may not be recognizing is new or different. So, in both cases maybe there's a lack of empathy or consideration there about what actually is the target audience for what I'm doing right now? And am I dictating things because I think they are axiomatically right or am I dictating things because they will be comprehensible to others? And is there somewhere in the middle that is a good balance? And I don't know. Maybe there's some sort of upfront… I don't know of an empathy checklist but effectiveness checklist, like you can just read before you do a code review to put you into the right frame of mind. Because I feel like that's partially what some of the early design sessions that I was mentioning before, before we even get to code review. Let's make sure that we're not going to be surprised when we get there. Some of these things may be doable at the code review stage, just you have to remind yourself that these are the things that I'm going to do and not do when I do this code review. DAVID:  Yeah. CHUCK:  Alright. Well, I hate to derail us but we need to get to picks. MICHAEL:  Cool. CHUCK:  So yeah, Dave do you want to start us off with picks? DAVID:  Sure. And [chuckles] I'm going to be real quick because it turns out these have already been picked. But 'The Fallacy of ReUse' is something I mentioned early in the show. There's a good blog article on that by, I'm going to pronounce his name wrong, Udi Dahan, Udi Dahan, that it's really short and to the point. And it's fantastic. The fundamental point of it is that reuse creates dependencies and dependencies are our hobgoblins. And yes, DRY-ing things up actually creates dependencies. And so, you have to find a trade-off there. The other two things that I want to pick are things [chuckles]… I was actually going to pick the 'Normalization of Deviance' by Dan Luu. I was out sick for six weeks early in the year. And yeah, it turns out you guys had him on the show. So, I'm going to go back and listen to that episode [chuckles] and I'm absolutely going to pick his blog post where he wrote about that. Because if you are normalizing deviance in your organization and you do not actively violently, vehemently hunt it down and root it out, the only way your organization is going to learn is if you get hacked. Or if you have a breach or if you screw up in some catastrophic way. And at that point, you have to hope that your organization survived it. And so, 'Normalization of Deviance' by Dan Luu. I can't recommend his blog post highly enough. So, those are my picks. CHUCK:  Awesome. Avdi, what are your picks? AVDI:  Just one pick today. As I do so often I'm going to pick the last audio book that I finished, which was 'A Mind of Its Own' by Cordelia Fine. This is a book on cognitive biases and things that your brain gets wrong. The subtitle is 'How Your Brain Distorts and Deceives'. This is very much the same subject matter as another pick of mine, I think something that was picked by several people, which is 'Thinking Fast and Slow' by Daniel Kahneman. There's a lot of overlap here but there's also a lot of stuff that she covers that Kahneman doesn't cover and vice versa. If you're looking for a book to start out with in this field, this one might be a better one. 'A Mind of Its Own' might be a better one because it's a relatively short book and it's very entertainingly written.  Kahneman is also quite readable but it's a bit longer, a bit drier. So yeah, if you're interested in the field of cognitive biases, and you should be because we can't really understand what we're seeing without realizing how we bias what we're seeing, I recommend this book. And that's it for me. CHUCK:  Alright. I've got a couple of picks. So, the last two weeks I've been out at conferences. And so, I have some picks related to that. The first conference that I went to was Build Conference which may surprise some people. It's the big Microsoft developer conference. It was out in San Francisco which was a lot of fun, actually. So, some of the cool things that we got to do there, I think one of the just really awesome things was that they had a HoloLens demo. And the HoloLens is their virtual reality headset. It's virtual reality, augmented reality. I'm not sure exactly where the line is on that. So, you have a visor in front of your face and it projects things right in front of you. But the demo they had, they teamed up with NASAs JPL and it was Mars encounters. And so, they had video, images basically that had been collected by the Curiosity rover. And so, you had the experience of walking up. And they had Buzz Aldrin as your guide or the host of the experience. And then you got to stand there and you could see Mars and you could see the satellites that orbit Mars. And they pointed out features on Mars' surface while you're looking at the planet. And you could walk up to the planet. You could walk through the orbits of the satellites and it told you the rotational velocity of all that stuff. And then it took you to Mars' surface and you could actually get on your hands and knees and look at the dirt. And you could look around you and look at the landscape. And they had the Curiosity rover so you could walk up to the rover and have a good look at it and things like that. DAVID:  Cool. CHUCK:  They explain how it works and what it does and it was really, really fascinating. I don't know if this is something you can duplicate but the HoloLens was really cool. Of course, I was on Mars with Earth gravity. But you can't have it all. And of course, it's all visual and audio. So, you don't feel the environment but you get to see it. And it was really cool. There were some other really interesting announcements there. And we actually did about five episodes of JavaScript Jabber while we were there about some of that stuff. So, I would invite you to go check those out. The other conference I went to was MicroConf. And if you haven't been and you're in a small business you should definitely go to MicroConf so I'm going to pick that as well. Interestingly enough, you pay for access to the sessions which are great. The sessions are worth the price of admission but the real money is in the… they have evening parties, receptions. They keep the music turned down to the point where you can actually have a conversation which is usually what drives me away from most conference parties is that the music's too loud. There are way too many people drinking way too much and I just, it makes it really hard to have a conversation especially in the press of people around the bar or whatever. So, I really enjoyed that. And then I've also been playing around with, and I'll find a link to this, but I found information about building your own Echo on a Raspberry Pi. It's an Amazon Echo. And I really want to try it. DAVID:  [Chuckles] CHUCK:  So, I'm going to pick it. I'll put a link to that in the show notes and yeah, we'll see how that goes. But anyway, super cool stuff. I had a great couple of weeks. I'm also going to pick just putting it out there, but just getting away and having a change of pace was really good for me. I was getting pretty burned out. I think I'm still on the burnout scale. Jamis Buck actually gave a really interesting talk about burnout at MountainWest Ruby Conference. Anyway, and we're trying to get him on the show to talk about it. But I definitely feel better than I did. So, just getting that change of pace is also a really important and nice thing. I have more stuff I want to pick but I think I'm just going to stop there and save it for next week. Mike, what are your picks? MICHAEL:  So, I have three. Two of them were pretty instrumental to the AOSA book series I think throughout. And then the third is something that we picked up along the way. So, the first is a book called 'How Buildings Learn'. So, it's a book from architecture. I'm not going to say too much about it other than read it and see how it applies to your everyday life. They examine a bunch of buildings and how they were architected the first time. And then how they adapted to their surroundings and different projects that were done on them over time. So, I'm sure you can see the high-level analogies. But there's stuff there that I found pretty interesting. The second is 'How Learning Works'. It's research-based principles, something, something, something. So, we'll put it in the links section. It's got a huge title. But I don't feel like many of us have time to go out and spend two years learning how to be good teachers and learning about the state of the art in education right now. But every day we're helping people learn how to become better engineers and how to become better people, ourselves included. And this is sort of a really well-explained distillation of actual research-based practices that have been done in education over the last little while. And that was a recommendation from Greg early on. And I learned a lot from it. I use it to help frame a lot of the conversations I have at work day to day. And then the third one is the Writing Excuses podcast by Brandon Sanderson and company. When we're thinking about ideas of audience and stuff like that there's a lot of fantasy trope talk in that podcast, but again I've [read] a few things on how to consider your audience and how to communicate with an audience and I still feel like that's one of the best ones. Probably because they do a lot with a very short amount of time. I think each podcast is 15 to 20 minutes. And I love their work there. CHUCK:  I know David has met most of the folks on that show. DAVID:  Yep. CHUCK:  In fact, I need to strong-arm Dave into taking me and introducing me to all those folks on that show. DAVID:  [Chuckles] MICHAEL:  It's awesome. DAVID:  So, shout-out to my peep. I think episode one of Ruby Rogues, it's in the first three episodes, my pick was Schlock Mercenary. MICHAEL:  [Laughs] DAVID:  Which is a cartoon drawn by Howard Tayler who is on the Writing Excuses podcast. He's a two, oh he's going to kill me, three-time Hugo Award winner. And I got my start… I've been programming since I was 13 and growing up in a small town working at the Radio Shack there. They guy there that owned it said, “Yeah, you can sit in the back and write,” building software for my paging business and that. So, I got to put on my resume that from age 15 I was programming professionally and that sort of thing. But when I came up to 'the big city' in Utah… CHUCK:  [Laughs] DAVID:  That's a town with a hundred thousand people in it [chuckles]. CHUCK:  Bigger now. DAVID:  And coming from a town of four thousand, but anyway I needed to get a foot in the territory up here. I needed the money to live up here but to live up here I needed a job. In order to have a job I needed to live up here. And long story short, I had met Howard Tayler. This was before he was doing Schlock Mercenary. I had met him and his wife Sandra and they just called me out of the blue when I was down in my hometown and said, “We just want to hang out with you more. Is there anything we can do to help you out?” And I'm like, “Actually yeah. Can I come live in your basement indefinitely?” [Chuckles] And he was like, “Yeah, sure. Come on up.” And so, I actually lived in his basement for almost two years and got my start in technical career. I got my NetWare CNE. This story is way too long. Anyway, Howard is freaking awesome. He's a fantastic human being. And through him yes, I did get to meet Brandon Sanderson once. So, that's that story. CHUCK:  Alright. And on that note, I guess we'll go ahead and wrap up. Thanks for coming, Michael. AVDI:  Yeah. Thanks a lot. MICHAEL:  My pleasure. [Inaudible] for everything. CHUCK:  Alright. Well, if people want to follow up, know more about what you're working on these days, where do they go? MICHAEL:  AOSAbook.org is the best place to go. We'll have everything linked from there. CHUCK:  Alright. We'll go ahead and wrap this up and we'll catch you all next week.[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]**[Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit C-A-C-H-E-F-L-Y dot com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.