The Changelog: Software Development, Open Source - 99 Practical Bottles of OOP (Interview)

Episode Date: October 28, 2016

Sandi Metz joined the show to talk about her beginnings on a mainframe, her 30+ years of programming experience, the ins and outs of OOP, her book Practical Object-Oriented Design in Ruby (aka POODR), as well as her latest book 99 Bottles of OOP which she co-authored with Katrina Owen. We also covered a few listener submitted questions at the end.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. I'm Sandy Metz, and you're listening to The Changelog. Welcome back, everyone. This is The Changelog, and I'm your host, Adam Stachowiak. This is episode 225, and today we're joined by Sandy Metz, author of Pooter, practical object-oriented design in Ruby. She also recently released her latest book 99 Bottles of OOP with co-author Katrina Owen. We talked to Sandy about her beginnings on the mainframe, 30 plus years of programming experience, the ins and outs of OOP, and we also covered some listener submitted questions at the end of the show

we have three sponsors Heap, Rollbar, and CodeSchool our first sponsor of the show today is our friends at Heap Heap is a new sponsor of ours check out heapanalytics.com slash changelog Heap automatically tracks everything your users do

every click, every page view every tap, swipe, or gesture a user does on your website or your mobile app that's tracked by Heap. And I talked to Alan DeSouza, the director of product analytics for LendingClub, and he shared some insights on how his team relies upon web analytics, but more importantly, why Heap was the right choice for them. Take a bit. And very quickly, we realized that we were not good at anticipating every single question that would come up. We could get questions from, you know, different departments about, well, how many people are looking at this agreement on this page? Or how many people clicked on this particular link in a seven day period. And 99% of the time, that link actually has no value until that discrete question comes up. And those moments are tough, right?

So we really wanted something that addressed that. You know, it seems to me for analytics, you want a silver bullet. You want something that kind of predicts what you want, the clicks, the events, all these different things. And most tools out there, you have to kind of granularly go through each one and select the things you want. That's different with Geek. Can you talk about that? When I looked into other possible web analytics tools, a lot of them, what's nice about them is you're able to go to their site and sign up for an account.

And they give you the snippet and you can kind of get on your way. So I got the tags, went ahead and implemented all three of them in kind of a local environment of our site on my machine. And what I noticed was 10 minutes later, heaps getting all this data while the other two were silent and that's just a factor of how the tool works. But that's exactly what we needed. Our engineering team kind of reduced the burden on them,

make this as effortless as possible, yet track really rich data. And Heap just worked. And it kind of lived up to all the messaging on their site. Okay, so here you are. You've got Heap installed, very low burden on your engineering team to get in place. You don't have to go through and individually track events or taps or predict the future, basically. But you've got all this data in heap. And obviously, we're all data driven.

Talk to me about how you get value from all this data being in heap. Data is really hot. Everyone's talking about it. People are creating tons and tons of data. Every tool lets you export raw data and do this and do that. People have a ton of data, but that doesn't necessarily mean that you're getting anything valuable out of it or you're able to answer questions or inform your decision-making process using data and incorporate it into day-to-day things.

And that's not valuable. What is valuable is the tool that might have large amounts of data in the background, makes it seamless for you to phrase a question and get an answer to that question in real time. What you really need is a tool that is able to work with you and create value out of all this data that might be there in the back end, right? And Heap is the only tool that I've encountered that lets everyone instantly answer business questions. Very cool.

Thanks, Ellen, for speaking with me. For the listeners out there who want to check out Heap, go to heapanalytics.com slash changelog. Don't Google it. Use our special URL. Again, heapanalytics.com slash changelog. And now on to the show. All right, we're back.

Jared, fun show today. I mean, this is a show, I think, how long? Sandy Metz, right? Like, we've wanted to have Sandy Metz on this show for years. And finally, finally. For always and ever, and also our listeners have pounded us relentlessly, get Sandy on, get Sandy on. Yes, and we did. Sandy, thanks so much for joining us. You guys are just making all that up. No, complete truth. 100% truth. thanks so much for joining us you guys are just making all that up no complete truth 100 i'm so happy to be here okay so here i'll stop i'm happy to be here thanks so much for asking me i wish i could have come sooner let me say that well we've uh we've been fans of yours

uh read books of yours uh observed you teaching before and you're just uh a wonderful person and an energetic teacher too. And you give us hope in the people that are out there doing what you do. Well, you should have hope, right? It's like the world is a much more positive place than sometimes we think. And so, yeah, I applaud you for having hope. Keep on doing that. You give us the hope. That's the thing. Keep on doing that. You give us the hope. That's the thing.

Help us, Andy Metz. You're our only hope. Yes. Yeah, okay. So here's what I would say, right? I'm just a schmuck. And if I'm giving you hope, it means we can all give hope to each other. That's right.

That is a very hopeful thing. Well, let's give listeners some hope. And let's tell your backstory because that's always a fun place to start when someone like you comes on the show like this and gets to tell your story and talk about your book and how you teach and all the fun things you're involved in. But kind of take us back to where you began because you're just like anyone else, right? Are you special or are you not special? I am not special. No. Well, I'm a woman of a certain age.

I wrote code every day for 35 years and then I wrote a book. We'll come back to that in a second. I got into programming because I was a music student at Florida State University. And it turned out that I was not going to be able to graduate with a music degree because you had to perform at a certain level. And I just wasn't enough so i was looking for a job i was trying to figure out how to get a job i went to votex school in okay i'll say it 1978 and learned to write cobalt and fortran got a job at a state agency and wrote code on mainframes i when p PCs came out in the 80s, I can remember, I distinctly remember feeling quite disdainful of those

devices because I had a mainframe. And so I've spent, seriously. You were offended. Well, they just seemed like such toys, such a waste of time. And I eventually got a little bit of a clue. I mean, I can remember building 8086 from parts

that some friend of mine in order some friend of mine and i like figured out what like you need a motherboard and a power supply and a case to put it in right and a keyboard and some kind of a hard drive tiny little hard drive tiny little memory and so I have my life as a programmer has spanned a lot of generations of technology. Somehow I've managed to make the transitions partly through. I mean, I'll take a little bit of credit. I'm insanely curious. And so I have enjoyed learning the new thing, but also I've just been lucky. I've been in the right. I've been a DBA. I wrote many, many, many years of small talk. I got into Ruby and Ruby on Rails before the 1.0 release. So I have this breadth of experience, which means many problems fit somewhere in the slot in my, you know, I have a middle framework of computer programming that many problems fit into somewhere. Even if I don't know the, like things don't intimidate me like they once did just because I have so much

context. Yeah. Let's talk about that because like you said, you wrote a book. This was, I believe, 2012. Practical object oriented design in Ruby. Yes. Say it. Codename Pooter. Pooter. There it is. It's not a bad word. I have a friend who was four years old at the time who would say Pooter when he wanted the computer. Think of it that way.

I like that. The pooter. Just imagine you're a small child. There you go. That's how I'm going to think about it when I say pooter. So you wrote pooter. It took off like gangbusters. This was, like you said,

after 35 plus years of practical programming experience, writing production applications of all shapes and sizes, I'm sure. Yep. And, you know, so it's one of these overnight successes that took, you know, it was probably 40 years in the making or whatnot. You know, this is so different than what we have in many cases today. I think, you know, a programmer gets started. The first thing she does is write some blogging software so she can start blogging about the programming. And, you know, I even encourage such things. So I'm not saying it's a terrible thing to go out there and share novice knowledge. But, you know, now you go about

speaking and teaching and consulting and writing books and you had 35 years of doing it before you, you know, got started there it before you, you know, got started thereabouts. At least book wise, right? Yeah. Is that the key to like all of your wisdom is, is that you were in it for so long and, and,

and, you know, should more people of your experience level be writing than less people of my experience level be writing? Okay. Well, first of all, I would not recommend the path I took really.

Okay. Um, because, because I think the advice that you give, if I understood you correctly, the advice that you just said you give to tell people early on to start writing, writing and sharing the things they learn, that's probably the best thing to do. I didn't mean to write a book. I didn't want to write a book. The story about how that book got written is maybe longer than we want to go into here. I mean, the short version is, you know, there are people, there are people with big publishing houses whose job it is to find authors. And so I got overheard doing a rant in the hall at a ruby conference somewhere rails conference maybe after a talk that i thought

um explained some piece i don't even know what it was some part of object-oriented programming in an overly complicated way and so i I was in a hallway going, man, why do people do that? It just makes everybody feel stupid. It's so simple. If you just think of it this way, and someone heard me, who was one of those people on the lookout for folks to write books. And so, and she started, the woman who is now my publisher, my editor, started this campaign to get me to write a book. And so I'd go to a conference.

It took her four or five years to make – to get me to agree. So I'd go to a conference. Her name is Deb. I would go to a conference. I would see Deb. Deb would buy me a really expensive meal and say, so, have you thought more about writing a book? Oh, I was so – I felt so guilty because every time i went someplace i would get like really nice food at really nice restaurants um and so eventually i i agreed to write it but it was partly actually one of the things that

like she would trot out reasons why i should do it so every time i would see her you know twice a year there would be a new reason she would give me why I should do the book. And I'd be like, no, I'm not going to write a book. What do I know about writing a book? I'm not going to write a book. I write email and documentation code. I'm not going to write a book. And so finally she told me you use open source software and you don't get

back. Oh, yeah. Dang. That's below the Oh, yeah. Dang. That's below the belt right there. Totally. Don't you like this? That person? Totally.

And so, you know, that was so. So then that made me think really hard. It was all the guilt card, right? Guilt about the meals, guilt about the software. And so finally, I did agree to try to write things down, but I was woefully unprepared because I had not blogged. I didn't really have any experience. I mean, I had a lot of experience drawing on whiteboards at my business place. I was always that guy, right? The person who, like all the whiteboards in every office, every whiteboard

had long, complicated explanations of things, pictures that I had drawn in many colors. Like it was a running joke at Duke university when I worked there. Um, so it wasn't that I wasn't, was unused to being the explainer. I I'm, you know, I'm certainly not the smartest guy in the room, but when I understand things, finally, they seem simple. So if I get it, I can, I can explain to anybody once I get it, that if I have one strength,

it's that. Yeah. All right. And so, I don't know. So I, you know, I wasn't,

I didn't have any experience writing and I, I don't know. So I caved like, like, like it really was it like, if there's value in Puder, it is, we are, we should thank those New York publishing houses because I would never have done it left to my own devices. Never. That book would not exist, except they made me, they just would not take no for an answer.

Well, let's set the book aside for a second and just talk about your conference talks and your trainings and these other things. You have a lot to say and you have a lot to give. And people take the things that you say, the explanations that you give, and it helps them write better software today and tomorrow and moving forward.

And I'm wondering if it's like, not to take away any credit from you at all, but it's like, well, maybe it's because she spent 35 years doing this stuff and she's speaking out of 35 plus years of experience. And like, it makes me think maybe us quote unquote youngsters should kind of like keep our mouths shut and just pay attention to people with, with all the experience for a little while.

Does that resonate with you or not not at all okay why not well i mean i would say well well first of all you can't assume that just because someone's been writing code for you know there's that joke about yeah you either have 10 years experience or one year experience 10 times right so you have to be a little like I would I my instinctive reaction to what you said was the sense of caution about assuming that people who've been doing this a long time are the people who have the best experience. Well said. Right. I don't want to make a blanket rule about that. But it's also true. I mean, here's what I tell people. Like, I get a lot of questions from people where they tell me, I'm always, I'm always trying to get people to give talks. And the, it's very common that I'll have a conversation with someone who seems thoughtful and curious and bright and energetic. And I'll say, have you ever given a conference talk that it will change your life? If you want, you know, if you, if you want to move your sort of programming life, your visibility to the next level for whatever reason, to have more opportunity to whatever.

Right. For whatever reason, you might want to do that. The first step. You can you can have a blog or you can get on stage. And people usually tell me, oh, I don't have anything to say. And I ask them, I ask them, I'll ask you guys, do you know anything now that you didn't know a year ago? That's not a rhetorical question. Yeah, definitely. Okay.

Sure. Like if you could go back in time and talk to younger Adam, younger Jared now, is there anything you can imagine telling them that would have saved you some pain in this last year because of something you've learned? Every day. I think about that every day. Yeah. And there's a song about that from Bob Seger. How's it go? Dallas. I don't know.

It's like a rock. I think it's 20 years, not where they've gone, that kind of thing. Good one. So if you have that, younger Adam, younger Jared would be so grateful if you would get on stage and tell them that. And that's the talk you need to give. That's who your audience is. Your audience isn't scary people that you imagine are all brilliant. Your audience is the people who are desperate to know the things you know now.

Yeah. And your emotional connection to those people is very generous, right? Like, how do you feel about younger Adam, younger Jared? Do you think they're idiots? Fools. Just fools. Handsome. Well, okay. We all think a little bit about that of our past selves but in general are they well-meaning fools or are they slacker fools well-meaning yeah well-meaning depends on the

yeah and so you like do you feel sympathetic do you feel sympathetic to them do you think they're idiots that don't deserve your help oh they deserve our help for sure yeah and so that think about that so now you're giving a talk full of useful information to an audience to whom you feel very sympathetic changes things it changes everything and it's a talk you can give it's a topic you know and it's an audience that you feel you feel confident about so on that note then this is just trying to play one other side of this do you ever get um does twitter ever put you down so to speak like the the critics and they seem to they seem to be on other platforms too but in our neck of the woods the programming software development open

source world seems that camp out on twitter does the critics ever put you down is there do they ever get you down because that's what to me there's a lot of critics on twitter it's true okay i mean i love our audience but there's a lot of critics out there that can really inhibit you from doing what you're saying i i kind of have two i have two sort of completely different responses that one of them is that so again this is going to turn into questions again um let me just apologize in advance so does it mean you're a good person if people say nice things about you on twitter certainly Certainly helps my ego a little bit. Yeah, I'm not asking whether it feels good or not.

What I'm asking is, does it mean that you are good if they say nice things about you? No. It's probably an indicator. I'm going to say yeah. Well, let me ask you this then. Does it mean that you are bad if they say mean things about you because you can't have it you can't have one without see jared that's part of her knowing the answer to her question right we talked about that earlier

and the pre-call prepping for this um yeah i don't know i guess i guess it shouldn't reflect actually who i am because i am who i am regardless of the critics, but it's hard. It certainly puts the wall there. Well, see, I'm older. That helps. Being older helps. And so fame came to me. This is like fame in a very known niche, absolutely. Right.

But kind of fame that never, a kind of notoriety that would never have occurred to me that I would ever have, came to me when I was a mature adult. And it was very, very clear to me from day one that I couldn't get too attached to the nice things that people said about me. Like if I gave that meaning, then the bad things have to have meaning too. If my identity came from what people were saying about me online. So I pretty much just ignore it it that's the thing about critics

i pay no attention i don't much read my press in either direction but the so so there's that right you can ignore it the other thing is and this again is part of being older and frankly part of being female i think like there's a way in which i'm everybody's i don't want to be your mom but i could be your like cool aunt and people want to talk to me and i um someone asked me very early on when my life took this abrupt change they they suggested that i had currency and they challenged me about how i was going to spend it and that isn't that an interesting idea that's very close to the other one that was pivotal for you which was you do so much with open source but don't give back exactly yeah it's a like an ironic version of that a variation of that uh-huh i mean now yeah first i was a consumer and then suddenly i got like deposits made in this mysterious virtual virtual

bank account where I have cred somehow and so like I may I have a okay I I refer to myself there's two Sandy's there's me and there's quote internet Sandy right and internet Sandy is the virtual image that people who don't know real Sandy have of me. And so there's a way in which we're the same person, but there's also there are ways in which we're not quite the same. Like Internet Sandy is nicer than real Sandy. And it's because I want us to be nice. I want to have a wonderfully enthusiastic conversation about differences of opinion online. Right. And so I because I want to have that conversation, but I want the discourse to be civil.

I want people who might not ordinarily engage in a in a boisterous difference of opinion to feel safe and comfortable doing it because i think we are all made better like if our if everyone's intentions are good and we have differences of opinion it means if we understood one another we would all be better and so i because people want to engage with internet sandy and internet sandy will not talk to you unless you are nice about it then what happens is I tend to the people who want to have negative discussions with me tend to fall fall away quickly because I don't engage with them and the people who really want to have discussions with me online adopt a matching tone.

I'm very careful to be nice and people match that tone. And so I don't have much problem with criticism online because of those two things. Yeah. So your generalized advice then would be that you do have something like to the younger person or to the inexperienced or whomever you're giving advice to is that you do have something to give. And that conference talks is a great way of doing that for the reasons that you stated.

And secondly, ignore the haters. Yeah. Ignore the haters. Don't engage with the haters. Yeah. When you say don't engage, you just mean ignore completely? Very often I say, like if someone writes a comment on one of my blog posts that seems critical, I'll look through it and try to like put your ego aside, look through it and see what they're saying. And then I'll do that echoey thing where I'll write back. I'll respond to their comment and say, as far as I understand, your concerns are in these two categories.

I'll ignore everything that sounds personal and critical and try to, you know, unearth the technical parts and turn the conversation back to technical and never say anything personally critical about them on the way back. And then if they, like, it's so easy to miscommunicate in writing on Twitter, especially on Twitter, but certainly even on a comment on a blog. So I try to act as if they're well-intentioned and I respond to act as if they're well-intentioned and I respond to them as if they were well-intentioned. And then if they come back again and they seem snarky, then I don't respond. Like you don't get two tries with me. I'm like, I'll assume you're good intentions once,

but then I don't know, maybe we should just not be talking. That's one of the reasons why I love the audio format so much. And just generally speaking, it seems like in text, and I feel like maybe I said this on a recent show, Adam, or maybe it was a recall, but in text, you know, people tend to take away the benefit of the doubt. Like they take it and as an audio, they give it back because there's more humanity to the format. You know, they get the voice inflection, the there's just humanity to the format. You know, the voice inflection, there's just more grace given, I believe, when you speak and are heard than when you write,

when you have to be incredibly clear and precise with words in text. But in audio, there's more benefit of the doubt. Yeah, I mean, if we had a miscommunication between the three of us right here, we could recognize that it had happened in real time and fix it very quickly. And that's much harder to do going back and forth in text. Well, we're coming up on our first break here soon, Sandy.

But before we go into that break, I want to ask you this question. I think this is something we want to hear from you, particularly considering your experience and the overnight success that you are, of course, someone like you back in the day when you said COBOL and, and Fortran, what was it that got you, you know,

when you said you were, I forget what you said you were going to school for that didn't work out was music, right? And it wasn't working out. And so something wasn't happening there, but then, you know,

you got kind of tapped into programming. I'm not even sure how. That'd be an interesting story to hear. But I'm curious, like, what was it about programming that got you? I went, OK, it was back in the day, right, where there wasn't like nobody had PC. So no, you the normal human being had no experience with programming, had never written a computer program. It wasn't possible. Like hardware didn't exist for us to mess around with. The normal human being had no experience with programming, had never written a computer program. It wasn't possible. Like, hardware didn't exist for us to mess around with. I went to Votek school the very first day.

We had an IBM 370. We punched cards. I wrote, I think, a 10-line Fortran program, and I was hooked forever. I remember. I don't remember what that program did, but I remember the feeling of taking the deck in to the computer operator and having him run it and getting back output on that 11 by 14 green, you know, green, white barred paper. And it seemed like a miracle. It was so amazingly cool. I was a little, there was something a little magical about it.

You know, that whole thing about technology that you don't completely understand is indistinguishable from magic. I was, I was bothered by the magical, the apparent magic of it because I couldn't see how it worked because it's all electrical somewhere. Right. because it's all electrical somewhere, right? And I eventually got over the magic, but being able to write a program and have it run was fascinating to me. And I have written code from that day till now. And I actually enjoyed it as much today as I did then. I write too little code now, and it's a disappointment to me. Writing books is not nearly as much fun as writing code.

We do a lot of teaching too, right? You have a traveling class you do? Yep. Yeah, I teach probably on average of maybe once a month. And teaching is really, teaching is exhausting. It's hugely fun. You can imagine. Yeah.

I mean, imagine, right? You guys have seen the course. I don't know if the listeners know that you were we we met in person at a course i was teaching you saw in there like students you know it's not like going and teaching a class where the students want to ignore you it's very interactive i mean like you were part of the class so to speak like you were leading it but you were very much like entrenched in it you weren't by any means talking at a podium and people were just listening well it's that whole thing about like are you what is your goal is it to stand up there and talk or is it to make it so

that people can learn yeah and there's something so fun about doing you know i have a psychology background so i did a bunch of research about teaching and i feel like i that for that course it almost totally works to help people learn and it is such a blast i think what's interesting too is to reflect back on deb uh challenging you with the whole giving back and look where that question from her got not only you but all the people you've influenced yeah it's kind of that's amazing i don't know yeah that's a big level up right there you know it's that whole thing about like i can't read my press i'm grateful i'm it is well the one thing i will say is that at this stage in my career, it is such a pleasure to find that the things that have come to me sort of laboriously over time are things that I can pass on and that people

are finding them useful. I am deeply pleased to feel as if that is true in my life right now. What a wonderful thing at this point in my life to be able to pass all this knowledge on. Well, let's take that first break. On the other side, we are going to tap into some of that knowledge. Sandy, we have some OOP-based questions and lots of interesting things, which will lead us into a conversation around your new book, 99 Bottles, which you are co-authoring with Katrina Owen, friend of the show. So we'll break here and we'll be back with a lot more goodies after this break. Hey everyone, Adam Stachowiak here, editor-in-chief of ChangeLog. And I'm talking to a Rollbar customer. Rollbar puts errors in their place.

Rollbar.com slash ChangeLog. Check them out. Get 90 days of the bootstrap plan totally for free. I had a conversation with Paul Bigger, the founder of CircleCI, and he talked deeply about how they use Rollbar and how important that tool is to their developers. Take a listen.

CircleCI is a continuous integration and continuous delivery platform. Our customers are the developers in an organization. Developers rely on us heavily as part of their deployment workflow. So clearly, you know, you're like a part of the machine that should not break, could not, should not break, right? If you break, you're one, losing trust, you're losing value, and ultimately you're not delivering your brand promise. Let's talk about the obvious question here, which is, you know, how do you use Rollbar?

So not just how do you use Rollbar, but why use Rollbar? So I was talking about doing continuous delivery there. And one of the key parts about doing continuous delivery, you don't just have to test your software, but you have to constantly keep track of it. You're going to be doing deploys 10 times a day or 20 times a day. And you have to know that each deploy works. And the way to do that is to have really good monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make sure that every time you deploy, you're going to get an alert if something goes wrong. And that's exactly what Rollbar does for ServiceCI for our infrastructure.

So let's assume anyone listening to this is someone who needs to use Rollbar. Someone needs to know about this tool, needs to know about this product, needs to know how it's changed how you do business because of it. I'd like them to know how important this tool is to you. And a better question might even be, could you have done what you're doing with CircleCI without Rollbar's help? We operate at serious scale. And literally the first thing we do when we create a new service is we install Robor in it. We need to have that visibility. And without that visibility, it would be impossible to run at the scale we do.

And certainly with the number of people that we have. We're a relatively small team operating a major service, and without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. If there's people out there who ship code without Rollbar, I can only imagine the pain that they're going through. Oh, that's awesome. Thanks, Paul. I appreciate your time.

So listeners, we have a special offer for you. Go to rollbar.com slash changelog. Sign up. Get the bootstrap plan for free for 90 days. That's 300,000 errors tracked totally for free. Give Rollbar a try today. Head over to rollbar.com slash changelog. All right.

We are back with Sandy Metz, and we're talking about object-oriented programming, her experience programming, teaching, and consulting. And Sandy, you've made your recent living and much of your time spent teaching other people how to do object-oriented programming correctly or better, or I don't know what word you put on it, but you're kind of an OOP guru at this point. And so I have a lot of questions about object-oriented programming. And I thought we'd just start off with this one,

which is what are the best things, in your opinion, that OOP has to offer? It's, hmm, so it's a style of programming that lets you model a problem in a virtual world. And so there's a way in which we're creating, like human beings seem hardwired to tell stories about things. And in some ways, an object-oriented application

is a story about a problem domain. It's not a bunch of unrelated functions. It's a living, breathing entity that has characters and actors and players and things happen. And so there's a way in which I think the impedance mismatch between, it has a smaller impedance mismatch between how our brains work and what we have to write down in order to make computer programs run and in order to solve a problem in the computer.

It's a better match than many styles of programming. Yeah. Just the ability to think about the nouns and the verbs that you're trying to program with by using them. Like we're talking about, you know, it's a bicycling thing. So it's bicycles and riders and and these ways that I would naturally think about it is a way that I can I can code it. And not only that, like it's it's it's so it's a natural fit for all the noun-y things yeah but the one of the huge powers of o is that i can create things that only exist as thoughts or ideas in the physical world this world here i'll i'm gonna make a noise right the world of my desk like the world it's easy to model the world of things, but you can also create a world in which ideas are as real as things. Does that make any sense?

I can, I can, you know, the, okay, this is just, this is an example that comes right out of the new book and it's in my mind cause I've been working on this chapter. Sure. You know, in a ticket app where you had buyers and tickets, you might also have refunds and purchases. And a refund isn't, the refund is an idea, but you can make an object for a refund. And that refund object is just as real as the buyer object in an object-oriented application, even though out in the real world, it's not.

And so being able to model, to create a world where ideas are as real as things is enormously powerful. So, yeah, you're taking a thing that's abstract in your real world scenario and you're making it more real in the programming scenario. When you think about object orientation, is that what you think about? I know it's become inheritance and polymorphism and encapsulation and these other things right that these things around it that i mean these are ways yeah go you go i'll just say like if you're going to be taught that you're gonna be taught oop uh in a traditional uh university or

something like these are the things that they teach you, these pieces of it, but is that the essence? I think that misses the point. I mean, certainly the people who created the OO languages defined what it means to be an object-oriented language, and originally those definitions would say it would have these characteristics.

It wouldn't be a language if it didn't have inheritance, for example. I think of inheritance as just a way to share behavior between objects or to... Actually, that's probably the wrong way to put it. Inheritance is a way to create a specialization of an object. It's really not best to share behavior, but it's a technique and there's a bunch of techniques. And the thing about techniques is you can just learn them, right? Knowing the techniques is really different from understanding how to combine them in such a way as to make a virtual world of objects that is easily understood, easily

changed, and does the job you want it to do. I find, I'm surprised when I go to teach at how my vision of what it means to think in an object-oriented way doesn't seem that widely shared. Right. I feel like I, when I go talk to people, they're my idea about what it means to write.

Oh, it, it, it seems like a surprise to people when I explain it to them. And that surprises me. Are these seasoned programmers or are they new programmers that surprises me are these seasoned programmers or are they new programmers very often they're seasoned programmers

I mean it runs a gamut this does not seem to map in any way to the amount of experience people have right do you think it's the way you think about it is different or just profound I think part of it is just that I have've done i've made so many mistakes over

so many years writing oh that some things could not help but become more clear to me you become a master at the maze maybe like again it's like a thing i i think i said a while ago while we were on here uh now it kind of seems simple to me what it means to really be an object. Like an object is a thing that tries not to know very much and communicates with other things by sending messages. And there's a bunch of techniques that we can use to create objects. Like I can use inheritance. I can use composition. I can follow design patterns.

I can assemble objects in certain ways. But there's this fundamental deep, deep, deep bias I have. I recently taught in London with a guy named Tom Stewart. He's the guy that wrote, the Tom Stewart who wrote Understanding Computation. And, you know, I was speaking American English and they were speaking British English. So we had some miscommunications in the class. And there was a point where he interrupted me because he's a Brit. He interrupted me in front of the class and he told the students,

the thing you have to understand about Sandy is she feels entitled to send a message. Huh. That's a weird way of putting it. Yeah, it made me laugh because that feeling of entitlement is so deeply embedded in me that I don't even realize I have it. Just explain what you meant by that. You feel entitled to send a message. I was having this rant because I was showing him some code. And it was code where we were interacting. Object A was interacting with Object B, and it was looking at Object B

and had if statements that looked at qualities on Object B, and then the branches of the if statement supplied behavior because of the result of conditionals where it checked things against Object B. And I was having this whole rant about that. It's like, this is insane, right? Somebody gave you object B, like, why are they giving you an object that you have to look at and then know things about

and then supply behavior for a bunch of different behavior for that's conditional based on some things. This is crazy. Like, don't give me an idiot object. Just give me something that I can send a message to. And there's a huge, like I know that may sound incomprehensible, and it definitely can be tough to talk about these things without code. Yeah. And so I don't want to get too deep down that rabbit hole. But there's a way in which, like I go out in the world and I look at other people's code and I think, wow, you're a genius because I could never have made this work. Like dependency-laden, conditional bound, like huge, tightly coupled messes of code.

Like you have to admire the people who are charged with keeping long-lived, constantly maintained applications running that are using object-oriented languages but don't use, that have let a lot of procedural programming techniques creep in over the years. Because those apps are really hard.

Oh my gosh, no wonder people hate them yeah it's just a nightmare and and so i uh i really firmly believe that apps can be way simpler than many of the apps i've seen and i uh find that it's a surprise to people like i think people get me to come in because they think, oh, I have this terrible, ugly app, and Sandy's going to teach us to understand complexity. I think that's what they think they're buying. And I look at their apps and I'm like, whoa, this is way too complicated. Let's make this simpler. And it comes as a great relief to people, I think, to see that OO is actually easy and hard

anyway sorry i had a whole rant there but you can tell i kind of goes back to kent beck's that kent beck's statement uh first make the change easy this may be hard and then make then make the easy change exactly i think it's that's a brilliant way of distilling that that kind of easy to say hard to do although they're in statement, there's a disclaimer, this will be hard to do. And so that leads me to just the thought of like, and I've been doing object-oriented programming for 10 years or so. And so I've been on the good and the bad of it.

And I've written stuff I can't maintain and stuff that seems to be more maintainable and in the gamut. And I've seen a lot of really bad object-oriented code out there and it's procedural and falls into many of the traps that were kind of just taught these different techniques and tools and it's like you just go out and you start i'll try this here and then you're like oh you don't find out until maybe a couple years later that was a really bad idea

um and so in many ways i like adam's metaphor of kind of the master of the maze because there's a lot of traps like there's a lot of bad ways of doing it. There's a lot of ways of getting it wrong or maze and you've been thinking this way so long, even a way that some of us haven't even got the right way of thinking about it, is like maybe the whole paradigm is too hard. Like, is there a better, you know, maybe is functional programming the answer? Have you thought about like maybe OO?

I think the functional people would tell you that functional is the solution to the problems of OO. Yeah. But do you, okay, really? tell you that functional is the solution to the problems of ooo yeah but but okay really do you do you think that it's not do you think it is important it's certainly true i absolutely uh accede in that there are some problems that you cannot create for yourself in functional programming absolutely just like there are some problems that you cannot create for yourself in functional programming. Absolutely. Just like there are some problems that you cannot create for yourself in statically typed OO languages.

But do you think, if I ask you, is it possible to make a mess in a functional programming language? Would you answer yes or no? Is it possible to make a mess? I'm sure I could find a way. Yeah.

I'd figure out how, yeah. I mean, I think the think it feels like certain languages are good at certain problems. And then it behooves us as stewards of our customers' money to pick languages that are good fits for the problems they're asking us to solve. And that once we do that, then it is, once we pick a language that's suitable, it is our job to write code that makes sense in that language. And if the question is, are some programming paradigms so naturally difficult that people shouldn't use them at all? I mean, maybe that's true. I feel like, I feel as if we as a technical community have done a terrible job of teaching programmers of

all styles of languages how best to write code. And that I don't really know what the fix for that is so so on one hand i approach this problem from two ends right on one side we've done a terrible job explaining things how like how many technical books do you have on your bookshelves have you read every technical book that you've bought no no me neither i mean most of them i've read now since i finally wrote a book people think i've read everything and so i it forced me to go back and get at least a passing of familiarity with many books that people would think. Right. And so, so it's like we, we, and when I talk, I see people, I get people in my classes who have computer science degrees who certainly don't know very much about object-oriented programming and when i ask them what kind of training they had in college they say well not you know like we learned java and we learned inheritance right um and so so we've so there's a failure of teaching that's one thing, the other thing is this thing about cargo holding new ideas. I distinctly

remember when I read the design patterns book back in the day, right not long after it came out, and how I felt like I'd been saved. It was such a relief to see the clarity that they had around categories of problems that occurred over and over again. And I just used those design patterns everywhere. I used them all over my code

in inappropriate places. Same thing with TED came out. When I decided I was going to get on the testing bandwagon, People who seem smarter than me were saying it was a good idea. And I went from being a pretty useful, competent programmer who get a lot done to being able to accomplish almost nothing from one day to the next. Because I was so bad at writing tests and my tests were, I was bad at writing, I was slow

and I was bad at writing tests. And so my desire to use this new thing that seemed like a good idea caused me harm instead of doing good. And does this mean that testing is bad or that design patterns are bad? No. Does it mean that I was terrible at them when I started doing them? Yes. But how else could I learn? Like, what is the alternative? And so one of the egg as knowing all the answers you're just gonna learn from writing code and so i think there's a lot of o-o code out there where people didn't get the chance to stick with it so that they could learn stuff they came from procedural or they went they have a cs degree where they didn't really learn to understand OO. And then they wrote a bunch of apps that people maintained over a bunch of

years. And those apps are big and messy and hard to understand. But I'm not convinced that any other programming language under any, under the similar circumstance would not be equally imperfect. Yeah. Over a few years. I'll say one more thing about this and then i'm going to shut up like i see a buy i i realize that i have a bias and it is because when people call me like people don't call me when things are perfect and so it is true that maybe I skew a little bit toward the big, large, unmaintainable OO app. Right.

However, right, that could be. I'm aware that I need to be careful about that. But I believe that despite that, despite that qualification, I believe this statement is true. Any business that's been, anybody that's been in business for 10 years, anybody who won has apps that are a mess. And there's pretty apps that you see here from those startups that disappear. Right? Like when, it is a, it should be considered a triumph, a triumph of persistence and an ability to survive in the marketplace, to have big computer applications that are

imperfect. Because they all are they all are that's the world we live in that there's a big mess and our job is to figure out how to deal with it yeah absolutely i think you know you talked about the what o is you know you're modeling the real world or you're modeling thoughts in code and you know the real world is messy and it's full of edge cases and corner cases and except if this happens and like those kind of things like yeah exactly and like that's it almost seems inevitable that a piece of software that maps to the world long enough to watch the world first of all be messy when it was but also change over time is uh if that's going to be a you know pristine kind of a holy temple is probably it

seems like it's impossible to to maintain that over time well you said it right there jared like if you're if you're writing software modeled after the world we can all look at the world and know it's messy the world changes there's variables there's brokenness there's a constant stream of change in our world so we can only expect any software we write to model the world we live in to be and have similar attributes. And so our job as programmers isn't to make perfection, it's to deal with imperfection. It's to figure out a way to keep on adding new features, improving old features, meeting our customers' needs in the face of success, which is probably ugly and messy. And there's a way in which adult, I mean, in my classes,

I tell them that the most fun part of our job, the most challenging part for adult programmers, experienced programmers, is transitioning from one big mess into a new design. And you want to have some fun writing code like go do that that's a real problem those are the problems that like you know make you get up in the morning and sort of drink two cups of coffee yeah get on right and and and if we believe like if we if we judge ourselves by the perfection of our large apps uh by the by the perfection instead of just by the mere longevity and existence like that that's a bad it's just it's just a bad like you are not

your code and yeah feeling like big apps have to be perfect it's a way just to make yourself feel terrible because they're they're just not gonna. They aren't. They never are. And like I said, I'm a little skewed because of what I see, but I believe it's true even for people who don't call me. Let's talk a little bit about what you've seen out there as a teacher and a consultant, you know, coming into these large companies that are successful and have, you know, OO based applications that are in different states of disrepair or perhaps still working, but hard to change. What's one mistake or give us a couple that most programmers make with regards to production code

that you just see it time and time again and we're all making the same mistakes? If we had a couple of those, what would they be? I would say two things. One is that everybody's tests are killing them. They're absolutely killing them. And it's because we haven't, you know, we cargo called the idea of testing. I think testing is right. I think TDD is right and testing is right and it will save time and money. But it feels like as a community, the vast majority of our community hasn't yet tipped over to the point where they're good enough at testing so that tests save them money all the time instead of costing them money.

Tests run too long. They're too tough. They interfere with change. Well, they interfere with change and they run too long. They make it hard to write new code. And so if we could just get better at testing, it would save a lot of pain. The other thing is it's been a thing I've been all over for the last couple years. I see a lot of huge conditionals in code.

What happens is that people in big OO applications, for the ideas that are at the core ideas in in the business are often embodied in huge classes and uh the uh ideas around the edge but often applications have lots and lots and lots of beautifully uh elegant single responsibly small classes and then there'll be one huge five or ten thousand line class that is at the center of their domain user if you're a rails app very often but but anything whatever the core ideas in the domain is it and what has happened is that we get in the situation where the easy things were easy to do but the hard thing got out of control and then all the code just got put in one class. And then what you have is just a bunch of procedural code in a very large file. Right. And so that finding a way to commit to writing small objects, even though and I don't tell people like you're going to go fix all the fat ones, huge ones you have now.

But as things change, you should make new small objects instead of making big things bigger. And so that one thing, having that one huge class that has a bunch of conditionals in it, where all the important parts of your business somehow are in there, makes it really hard to move forward. Earlier on, you said we should try to teach what is a good way to write programs

despite the language or kind of at a higher level than paradigms or languages and uh i guess the question would be like if you had to pick what that way is would you say like makes things small would that be like your guiding concept or would you would you have others i maybe very often we're not okay this is this is just a personal story about me when very often i write when i try to write some code it'll start out simple and then it'll get ugly and complicated and then sometimes if i'm if i have enough insight into the problem i can make it simple again. And so, and then, so I end up with this, I start out with small things and then I get this bloat, confusing, intermixing of ideas, period. And then sometimes on the other side of that, I, I'm back to small things, a bunch of small things,

all of which represent a small idea. It feels like we don't, it's almost as if we don't have the correct appreciation for the difficulty of simplicity and that we don't once we reach it's almost like we we think complex code like we love complicated code we love looking at complicated code we love writing complicated code and there's a way in which we value complication and we think highly of people who can produce complicated code but but the truth is simplicity is harder than complexity very often and if we valued simplicity more i think we would reward those who achieved it and we would strive harder to achieve it, and we'd all be better off. And so we do this thing where we overvalue complexity when it's just a way to intimidate people very often. To me, when I write complex code, I believe I have failed in some way to communicate the idea.

It only ought to be as complex as it needs to be. Right. Very often less complex than I've made it. You leave a comment right above kind of explaining why, how you're going to come back and make this less complex later. That comment that says, I'm really sorry. The one that starts that way. Apologizing for this.

Yeah, exactly. Apologizing for my go exactly i wrote that comment recently okay one last question before our next break uh you know you spent all these years you know basically as a nine-to-five software developer um recently that's changed you're now as we've said you're a writer you're a speaker you're teacher, you're all these other things. Do you ever fear that you might lose your edge if you're not able to write production code on a regular basis? Totally, totally. Absolutely. I write way too little code now. It's interesting. I feel like I have not yet lost it. And there's some reason which I understand code better now than I did when I was writing code eight hours a day. Because I have the leisure to think about code.

And so that balances out somewhat, I hope, whatever skill loss I'm having from not writing code eight hours a day. But I think that's a great question. And I think it's a thing that I am definitely paying attention to. Has being a teacher helped ingrain anything that was loose for you that is now way solid because you've taught it so many times? Oh, yeah. I mean, I feel like here's the thing, right? Every learner sees the world a different way. And so every idea that seems obvious to me is not at all. If you're just like me, it's easy for me to explain things to you

because you think just like I do. But if you think in a different way, then I have to find some way to reach you with ideas. And so the challenge of communicating with people who are different than me has made forced me to look at things I thought I understood and understand them in different ways. So I feel like I have a much broader understanding of really what truth is about programming and what truth is about these ideas. And it's been enormously helpful to me. That has improved my code a lot. Like I can now, it's easier for me now to look at big messy blobs of code and say, oh, it has this problem.

This is the core thing that's wrong with it. And in a way that I can see it and I, and I can explain it and that what that's a result of teaching. As Jared said, we are getting close to our next break. When we come back, we're going to talk about 99 bottles and kind of go deeper into this rabbit hole, so to speak, that you've opened up for us. Jared mentioned earlier, we haven't read the book, but we've experienced firsthand your teaching. And we kind of extract a lot of the questions we have around that. So we'll take

this break and we'll come back talking about that. If you want to learn something new, a proven method is to learn by doing, and that's exactly the way CodeSchool works. You learn to program by doing with hands-on courses. Their courses are organized into paths based on technologies like HTML, CSS, JavaScript, with hot topics like React and Angular, Ruby, Python,.NET, iOS, Git, databases, and even electives that take you off the beaten path. Say you want to learn React. You can start level one of CodeSchool's React course, which begins with a quick video on React components. After the video, you get hands-on practice building with components using their in-browser

coding challenges. There's no hassle, no setup, just learning. And the best part is when you use our special URL, codeschool.com slash changelog, you save an extra $10 per month. Instead of paying $29, you pay $19 because you're a listener of this show. Again, use our special URL, codeschool.com slash changelog. Don't Google it. That's the only way to get our special deal. Once again, codeschool.com slash changelog and learn by doing. All right, we're back with Sandy and Matt. Talking about 99 bottles of OOP. What an awesome title. A practical guide to writing cost-effective maintainable and pleasing object-oriented code who came up with that was that you all alone that tagline the tagline i don't know probably i'm i am

the the writer of taglines so it probably was me though it's hard to say at this point the origin of the all the best phrases well there's been so much collaboration with katrina owen who's also writing with me on that book that it's sometimes like most of the final writing is done by me but i can't i don't feel like i can claim any single idea is my own right it's a shared thing population yeah going on i mean it's it's inviting right a practical guide everybody's welcome to this like it's it's good for anybody writing cost effective that's, that speaks to CTOs and anybody who's trying to save money with their development team.

Maintainable, who doesn't want that? And pleasing. Pleasing object-oriented code. But why this book? Why now? Why this book? Why now? Okay, I'm teaching the course. This book is a programming exercise that I do in the classes in my practical object-oriented design course.

The course I am now booking next summer. I'm booked into the summer of 2017. I don't want to raise prices anymore because I have a blue- background. I find everything that we pay in tech seems enormously high to me. I am unwilling to raise prices anymore on my course, but it means I'm filtering now by time. And even so, much of the content that I'm teaching is unavailable to most people. There's no matter how many talks I do and no matter how many private and public classes I teach, the classes are reaching numbers probably in the four digits by now, in the thousands. The talks reach a much broader audience, but even so, there's this huge body of knowledge that is an outgrowth of the course

that is completely inaccessible to most people. And I felt, I feel a lot of sympathy toward programmers who are like me, who have my background, who are essentially untrained, who learned on the job, who were reliant on other people to take the time to write things down or tell us or give talks. And so Katrina and I agreed that we would take what's effectively the first two days of the course and write it all down and so that we could sell it to individuals. And so that's where the book came from. We meant to make it for, I don't know, pricing is always an issue, but for a reasonable, reachable amount of money available to anybody who wanted to read it.

And so that's where it came from. A lot of people who write books like this, or they would think potentially to add some videos to it or have tiers where you have not only your $49 version, you have maybe an even less, even more affordable version of it and even less affordable version of it where it's like you've done some videos and there's some extra goodies or some sample code or something like that. Why have you chosen just one pricing point for that? Okay, pricing is so hard. Right, it is what what is fair what is

right and so we started off we started off being like ten dollars ten dollars is the right price um and then the years went by we've been working on this book for two and a half years we we finally decided in the end that we're going to price it with all the other books in its category. Avdi Grim's book, Jim Gay's book, the people we know who are self-publishing are pricing at this price point. The tier thing, so then that left us with a moral dilemma. Okay, if our purported goal is to make this available, this content available to people who can't afford to come to a course, what about people who don't have $49? And so we stole an idea from Avdi Grim, which is the postcard plan. If you send me a postcard, we will email you the book for free.

And so there are really two prices for the book. There's $49 and there's a postcard and the postcard is not like uh it is not a piece of a cut up section of a box with a first class stamp on it what's the yeah what's the point of it right like the point is to make people go to a little trouble and well the there's a couple points one first off for us to get the coolest postcards on the planet. But the next thing is to make a barrier, enough of a barrier, so that it's clear that money is in short enough supply that you would be willing to trade a little bit of time for it. I like that. Because what we want is a real postcard with a postcard stamp. And then you have to write a little thing on it that says how you will do good in the world,

how, how having this book for free will help you accomplish some good thing in the world. That's what we want. Right. And we've gone, I don't know how many yet, cause the postcards don't come to me,

but it's, it's been hundreds. It did say, um, don't come to me, but it's been hundreds. It did say maybe 10% of the copies of the book have gone for free to people. We just had a long email thing from some guy actually, because he sent a postcard from somewhere in Eastern Europe and he wanted to know if it had arrived because we hadn't mailed him a book yet and he sent email and it was this long narration of the path that his postcard would have had to have traveled geographically like it went overland from my house to here and then it got on a boat across

the baltic sea right and so he was trying to explain how it might be that his postcard might not have actually arrived but in to assure us that he sent when he took a picture he showed us a email that emailed a picture of himself holding the postcard that he mailed us and we're like just send me a book you've worked hard enough yeah yeah and so like we i've been working on it for two and a half years and i am just so delighted to give it to people who can't afford it. But it does seem like not too much to ask that they would go to a little bit of effort. And so it was really great. Right. That, you know, another thing that happened that has happened a lot since I self-published that book is that we get there are so many countries in the world where the exchange rate is bad relative to the u.s and some authors have a policy to sell books at half price to say brazil but i just it

feels like perilous waters to navigate like does every different country have a different price based on their exchange rate relative to the dollar? So I don't know. So in the end, we're like free or $49. You can give us money, give us money or send us a postcard. Like finally, some people really do want to pay something. And so we on the website where you can buy the book, there's, you can buy karma. So there's like a $10 karma and a $25 karma, and you can buy them any combination.

And so when we send people free copies of the book, we tell them your copy is free, feel no obligation. But if you're one of those people who wanted a discount that we wouldn't give you, we made you send a postcard and get a free book instead. If you wanted a discount, you can buy, you can, there's a way for people to give us a part of the price of the book, but they get to decide. I don't decide for them. Let's talk about the content of the book.

Yeah. Chapter five is coming out this week. It's currently at, according to your website, 45,000 words, which to me sounds like a lot. This is all about a single programming problem, which is the name of the book, 99 Bottles. This is a single problem that you give as part of your course. Describe to us the problem and why this makes for a good kind of example case for applying all these different object-oriented ideas to it.

So the problem is in 99 Bottles, the beer song, the exact same one you sang on the bus as a child coming home from school trips. The task is to write code to produce the lyrics to that song. That seems incredibly simple until you try to do it, at which point you discover that there are hidden complexity. Well, give us an example of, oh, you probably were just going to. Okay, so we're going to have to sing a little bit then, right? So, the first verse, the verse that starts with nine bottles and the verse that starts with 98

bottles, they're almost identical. It's just the numbers change, right? You get all the way down to three, uh, three bottles of beer on the wall, three bottles of beer.

Sounds good. Take one and pass it around. Two bottles of beer on the wall. Okay. So that's still the same, but listen to the next verse. Two bottles of beer on the wall, two bottles of beer.

Take one down and pass it around. One bottle of beer on the wall two bottles of beer take one down and pass it around one bottle of beer on the wall so one bottle is singular right that's not so bad right the next verse the one verse uh has a similar problem but instead of take one down it says one bottle of beer on the wall one one bottle of beer. Take one down, pass it around. Right. So and then the zero verse in the zero verse, instead of taking one or it down and passing it around, you go to the store and buy some more. And the zero verse, if you've sung it on the bus, you may recall. Once you get to no bottles of beer on the wall, no bottles of beer, take them down, pass it around. 99 bottles of beer on the wall.

And so we all think we know that song. We think it's simple. But if you're not careful, you can write a bunch of if statements. That's the way that I would do it first. It's just like, well, there's like seven ifs and I'm done. Yeah. And so it's interesting to. So it turns out that the problem has a couple of really great characteristics.

One, it's kind of fun. We can all sing in class when we work on it. Two, it's a problem domain that everybody knows. We don't have to teach you about bank loans in order to have a class exercise. Three, it seems simple, but actually it's sneakily complicated. And those three qualities combine to make it a really useful programming exercise. In the book, you know, there are a number of ways to do it. I wouldn't say that I have the perfect solution to it at all. But the nice thing about the problem is the kinds of difficulties that you get into trying to write code for it, provide a scaffolding

to talk about big ideas in object-oriented programming. So it's really easy to talk about the Liskov substitution principle because there are sort of natural Liskov violations in that song. There comes a time when it's really easy to talk about inheritance versus composition because we end up in situations where we have to choose what we're going to do. It's easy to talk about mutability. There's a place in the song where having immutable objects is possible, but you could mutate them instead. And what does it mean to do that? We're an object-oriented language, but immutability is a big idea that we should, you know, freely steal from the

functional people. And so it isn't, you know, the goal of the book isn't to write the perfect solution to the 99 bottles of beer problem. The goal of the book is to take a problem that everybody knows that you don't have to bend any extra brain power to understand the domain and use that problem to explain ideas in OO. And it's pretty perfect for that. Very cool. We'll take the last 10 minutes or so and just we're going to give you some rapid fire questions, listener questions, some listeners, some are ours.

If you're cool with that. The first one is actually related to the book. So I want to ask that one first. And somebody would like to hear from you about the overall experience of writing the book. You can get some insight there. I find writing torturous. And yet I'm weirdly compelled to do it.

Like, I'm really happy when it's done, but I hate doing it. I mostly what we do is we write all the coding samples. Like we do all the code, all the code examples. Then I pseudo write around it. And then I go back and laboriously write. I'm a little dyslexic. So very often I'll write paragraphs and then read them out loud until I like the way they sound. To do a chapter that way takes me about, if I work on nothing else, if I'm not traveling or teaching or working on a conference talk, that's about a two-month process.

Then I have a professional editor. Chapter 5 is going to come out this week. I'm just finishing the third round of professional editing for it. And so writing is hard. Other people are faster. I'm keenly aware that other people write faster than i do but i've just given up trying to be faster i'm what i am it hurts was this one of these books that was like uh was it a open beta type of a book where you were writing it in public or did you

keep it behind the fence and release it how'd that go we didn't um i talked to a number of people i was getting a lot it took a while to write it and people knew we were writing it so we kept getting bugged and bugged and bugged finally I talked to a bunch of people about when can I release a beta when is it ethical to release a beta because releasing a beta means taking people's money like selling the beta and so it was pointed someone gave me a great criteria they said it has to be

what you give people has to be enough so if you got hit by a truck and never gave them another word, it would be, you would feel that it was worth it. And so that made it pretty obvious that the book would have to go through chapter four. Chapters one through four would have to be done, which is that, whatever it is, 45,000 words. I mean, it's 150, I don't know, 80 page, 8.5 by 11 PDF right now. It's big. It's almost as big as Pooter in the beta. And so, we did it.

There was a way in which I slightly regret it. I'm always over-optimistic about how much writing I can get done in a period of time. And I, as soon as, well, it's just so surprised me that people bought it. So we made this and a bunch of people bought it like that day. And so then I felt this enormous pressure to get the rest of the writing done. But I am such a slow writer that feeling that pressure did not speed up my writing at all. It just made me feel pressure while I was writing.

That actually leads us directly into the next question, which is, is there a lot of pressure to be, quote, Sandy Metz? I, well, again, there's Internet Sandy and there's real Sandy. I feel some, I wouldn't say pressure. As Internet Sandy, I feel some obligation to model the behavior I pressure I feel is I want to, you know, there's a certain, like I would love to see more diversity in our community. And part of having a broad range of different kinds of people, ages, genders, races, ethnic backgrounds, right? Part of that means having the community be, have lots of representation in it, partly means when you, if you come to our community and you're

not well represented, you're not part of a well represented group, it can be easy to feel like like there's no place for you. And so I am, that mission is near and dear to my heart. And so part of the reason I go out is because I represent a little bit of a neuro demographic in our community. I'm older, I'm female, I'm certainly white, right? So I'm Caucasian. So that puts me right in the middle of a big, broad demographic group. But so I find that I feel an obligation to respond maybe to requests, to go out and be Internet Sandy for people. And I – that – it's always a challenge to know when – how much can I stay home and rest? How much should I go do those things even if I feel like I don't – I'd rather stay home and play with a dog, right? And so pressure – like pressure – I could whine a little bit about the pressure that travel gets wearing and all that, but I love my life. I love. If you're me and you've come at the end of your long life, you can feel the

sort of kind regard of the people in our community. It's a wonderful thing. I feel like I feel obligation to live up to it, but I wouldn't really call it pressure. Okay. Next one. I'll just quote this one because i like the way he wrote it i'd be keen to know if a person like sandy ever gets wowed by development trends or falls victim to nerd hype well yeah i think that's a whole cargo call anything right we follow up with stuff we're like whoa that's so cool i'm gonna do that they must be right and then you know two weeks later you're like what a mess why did i do this i hate myself if we had perfect foresight we would write perfect code but it's a matter of you know you just do the best you can what you

have and you like don't be attached to your code as long as i can walk away from mistakes and acknowledge i made them then things are pretty painless if i it's only when I hold on to a bad idea that I regret. What's a good example of nerd hype, Jared? Well, I mean, there's lots of different examples. What would be a good example of nerd hype? Perhaps some of the, you know, in the JavaScript world, you'd have a new framework or animation type of a thing. And now you're going to follow that rabbit hole for a little while and then

come back. I don't know. What do you think, Adam? What's a good nerd hype example? I'd probably say the same, like something that's, I mean,

open source moves so fast, it's difficult to keep up. And I would think that the next new thing could be not so much nerd hype, but it could be easy to always want to be on the train, you know, because it's exciting. Well, one thing that we know Sandy is interested by, at least, is Elm, because she has, Sandy, you told us you have a tab open

on a browser that you haven't quite got to yet, which is kind of a learn Elm tutorial. So whether it's hype or a trend, or if it's, you know, something that's going to last, at least that has caught your attention. Totally. I mean, I know that JavaScript people often feel like they don't get enough respect from, say, Elixir or Go, right? There's some pecking order of programming languages and JavaScript is not at the top. And that seems completely wrong to me, right? JavaScript might take over

the world. We might all regret not being really good at JavaScript and learning. I've been on my list for a while to get better at JavaScript, but, you know, Elm is not. And then I get to combine my desire to learn something about functional programming with a desire to do a little, get a little more of the JavaScript space. So what's not to like about that combination? It's a play toy project for me, but I could easily imagine using that, having that move more into, you know, big time apps. Just want to thank Brian Douglas for that one.

He's a changelog member. I think he wouldn't mind us mentioning him by name. So Brian, thanks for that question. Next one for you. We got two more questions and we're getting close to time. So here it is. Is 99 bottles your swan song? Are you ready to ride off into the sunset or do you have more to give to the software community?

I don't know. Oh my goodness. Swan song. That's hilarious. I mean, here's the thing. Everything you know seems simple and obvious. And the content that I create that I tell other people is an outgrowth of having conversations with people where they're like, wow, you're genius. And about things that, you know, are are comfortably sort of already in my brain and so figuring out what it is that things that i've learned in my

long life that just seem that are second nature to me now that other people are interested in hearing about that that's what triggers these things right that's what triggered teaching it seemed it seemed obvious to me but clearly it was useful to other people so who knows what's gonna i cannot even predict what's going to happen next. So your plan is not for this to be your swan song, but... I'm not done. You're not done. How can we be done?

How can we be done? We're not done. There's tons of code left to write. That's right. So we mentioned earlier, I think it was the pre-call, but you've been named as the hero of many people who have been on this show before. I'm going to get you a list.

But we like to ask anybody who comes on the show, you know, especially someone like you. You've had to have some influencers throughout your life. Who is influencers, programming heroes, whatever you want to call them. Who is that person or persons to you? Who's your hero? Okay, I'm going to mention the name of someone that no one listening could possibly know. And he was, okay, I worked for Sperry Univac back in the day. I was a young pup.

And there was a grizzled senior system guy who was, oh, probably 30 years old. I don't know. He was way older than me. And he was such a great teacher. He kind of scared me to death. But he was incredibly gentle with me in a gruff sort of way. And he made me feel as if I had a place in this community. And so his name is Rich Workentine.

Like I said, he's probably, I don't even know, there's no way he'll ever hear this. But it's not the people now. There's tons of people now who are wonderful people who I could mention. But the difference that was made in my life was made when I was a young programmer. And, you know, we all have that obligation to treat kindly the tender youths, right? So that's a lesson. That's a lesson for you guys and for everyone who's listening, right? The kids are who needs us, not the grownups. So your hero is someone who has, who influenced you young on and helped shape your career. Right.

Influenced a lot of people, right? And so those are, and there's a lot of heroes like that. What I want is everyone to be that kind of hero. We all aspire to be, that's for sure. And it's nice What I want is everyone to be that kind of hero. I think we all aspire to be, that's for sure. And it's nice when we get a chance to be. And I think if you do get

a chance to be, honor that and do it well. But Sandy, we are out of time with you. I know you've got a hard stop. So I want to mention your book URL on the air so people can go

and check this out. SandyMetz.com slash 99 bottles. We'll have it in the show notes, so go check that out. But mets.com slash 99 bottles we'll have in the show notes so go go check that out but any closing thoughts from you whatsoever before letting you go no this has been such a treat thank you both okay well listeners thank you so much for tuning in sandy thank you for your time and all the work uh that you're giving back uh thanks to deb thank you deb thanks for that question and that guilt trip that you put Sandy on because we're riding the ride of

Sandy Metz and it's because of your question and your perseverance. Thank you very much. So that's it for this show. So let's say goodbye. Bye. Bye. Thanks, Sandy.

Yeah. Thank you guys. We'll see you next time. you