00:16 – Welcome to “99 Bottles of Podcasts!” …we mean, “Greater Than Code!”
01:31 – Collaboration on the Book
— Jessica Kerr (@jessitron) November 21, 2016
14:56 – Audience: Who is this book for?
21:06 – The DRY (Don’t Repeat Yourself) Principle; Duplication and Replication
— Jessica Kerr (@jessitron) November 21, 2016
29:21 – Code Review and Naming Things
32:53 – “The 99 Bottles book seems to document all the trade-offs we’ve been implicitly making. Could this possibly be a first step in automating those decisions? i.e.: Might we take those now-explicit rules and partially automate the process of programming?” – Craig Buchek
34:47 – Llewellyn Falco: “Sparrow Decks”
39:57 – “what non-Ruby technologies are you interested in right now?” – Darin Wilson
— Jessica Kerr (@jessitron) November 21, 2016
“Code is easy; people are hard. If you want to get things done, you have to get good at people.” – @sandimetz
— Greater Than Code (@greaterthancode) November 21, 2016
45:00 – Sandi’s Unique Approach to Teaching
47:53 – Speaking at Conferences
— Jessica Kerr (@jessitron) November 21, 2016
Coraline: Inspiration to return to work on her book about empathy. Also, exploring whether that visual interpretation of code is the shape of code in the abstract or the shape of the code that’s written on-screen.
Sandi: Controversy around the notion that duplication is better than the wrong abstraction.
Katrina: We are humans and we have ideas and sharing those ideas makes us visible to other humans. It is also incredibly important and impactful to speak.
Jessica: Development of relationships and partnerships with someone who will push you.
Sam: Helping people realize things on their own is greater than telling them the answer. Also, practicing better self-control in coding and mentoring.
Please leave us an iTunes Review!
CORALINE: Hello and welcome to Episode 8 of “99 Bottles of Podcasts!” I’m joined today by Sam Livingston-Gray.
SAM: Good morning, Coraline. And “99 Bottle of Podcasts” sounds wonderful but I think I have an even better idea and that is “Greater Than Code!”
JESSICA: Yey! Greater Than Code!
SAM: And I am joined this morning as well by the extremely enthusiastic Jessica Kerr.
JESSICA: I get excited about this podcast game every time we go back to it. However today, we do get to talk about 99 Bottles of Object-Oriented Programming. We have today, Sandi Metz and Katrina Owen.
Sandi is a programmer, teacher, author, and sometime consultant. Her career has spanned over 30 years during which time, she has dealt with long-lived applications that taught her to create practical solutions to produce working software that is easy to change. She’s been a frequent speaker at conferences since 2009.
CORALINE: We also have Katrina Owen. Katrina is a programmer who mostly works on web backends in Go and Ruby. She’s obsessed with automating workflows, and making code readable so that it’s easier to change. She’s a master of refactoring. Katrina created exercism.io, an open source project that helps people improve their programming skills.
Katrina and Sandi, welcome to the podcast.
SANDI: Thank you. It’s a pleasure to be here.
KATRINA: Thank you.
CORALINE: We do want to spend some time today talking about the book which I believe is out in beta form right now.
CORALINE: I think it’s really interesting that two people like you decided to collaborate on a book together. Can you talk a little bit about the origin of the idea?
KATRINA: I have one question: can you elaborate on ‘like you’?
CORALINE: Sure. Very prominent members of the community, each with independent careers and great speaking experience and this high visibility basically is what I meant by ‘people like you’.
SAM: People like two of my favorite people on the planet.
KATRINA: We kind of accidentally ran into each other through — I think I originally reached out to Sandi because of her first book when it was in beta. I was very, very excited about the book and gave her quite a bit of feedback on it. And that ended up starting some conversations and we kept in touch. And then my very first talk got accepted and Sandi gave me feedback on that talk. So these conversations continued.
JESSICA: That first book was Object-Oriented Programming in Ruby?
SANDI: No, Practical.
JESSICA: Practical. The POODR book, right?
JESSICA: Practical Object-Oriented Development in Ruby.
SANDI: Design. Close enough.
JESSICA: Oh, it’s close!
SANDI: Close enough. Google will fill in the gaps. It was very interesting when Katrina asked you, Caroline, to define who ‘people like you’ are. And you mentioned a bunch of things and I wrote some of them down – you said speakers but the impression I got was you were saying ‘people like you who are well-known’ in some narrow definition of that word.
SANDI: It made me laugh because the conversations that we started having that led to this book happened long before we were well-known at all. Right?
KATRINA: I was known amongst about a dozen people in Oslo.
SANDI: I was working on a book that I didn’t want to write that I got browbeat into and that friends of mine who asked me who seemed excited when I told them about it, they asked me to give them a copy of the beta, it would sink without a trace they would never read it. And so, we were people who were not at all known about anything but part of the transition certainly in my life, and I think it’s quite true for Katrina too, that’s happened over the last four or five years is as a result of thinking about and working on the things that led to the production of this book.
Thinking about working on the book is what caused us to have more public ideas. It’s not the inverse. It was not like we were all famous in some narrow part of the world and we decided to work together. We decided to work together and then that led to some more visible presence in the public world.
CORALINE: Obviously, the ideas that you put in your first book, Sandi, really resonated with a lot of people.
SANDI: Wasn’t that a surprise?
SAM: I remember reading the pre-release version of the book on a plane coming back from DC with pneumonia and thinking it was absolutely amazing.
CORALINE: To be clear, did the plane have pneumonia or did you?
SAM: Oh yes, sorry. Thank you for the associativity thing. I had the pneumonia, the plane was fine. [Chuckles]
KATRINA: And you said you read the beta of the book. Was this POODR or was it 99 Bottles?
SAM: Oh, I’m sorry. This was POODR. Yeah, I had paid for the pre-print PDF and I was reading it on the way back and I thought, “This is wonderful. I should read it again when I’m not sick.”
SANDI: You know I never quite know how to respond to that. It’s really wonderful. Imagine you’re me. I struggled in basic anonymity to really explain things to my former self. When [inaudible] right, you have an audience in mind and the audience I had in mind was the younger me. And so, I wrote that down with no expectation about what the future held. And so, the fact that it was well received came not only as a surprise, but it was deeply pleasing. You should all write books. That’s really the lesson here.
CORALINE: Working on it.
JESSICA: Do you see the audience for your current book?
KATRINA: I think the audience for the current book is much more like me than like Sandi. And what I mean by that is someone who has less experience, certainly. I have a bit over 10 years of experience, not 30.
One of the reasons that Sandi and I started talking about many of these ideas is that Sandi has a view of the world which encompasses big ideas and a deep insight that comes from that understanding that is built on this instinct that we build over years and years and years, and that is unexplainable. It’s this thing where you just know. You know the answer. You know why it works or why it doesn’t work or why it should be this way. And Sandi has that too in enormous degree and I don’t. I’m on the other end, completely at the other end of the spectrum.
You know that ‘can’t see the forest for the trees’? Sandi jokes that I can’t even see the trees because I’m in the weeds.
KATRINA: And we know because it’s true.
SANDI: Now, I wouldn’t say it that way, Katrina. I mean, it’s true. Here’s what I would say. It came very clear to me early on in our collaborations that you need to assemble a whole from a series of parts. And if I looked at a problem and saw the whole, I mean I don’t want to describe myself as handwavy but I can be a little hand. I have a lot of confidence that the parts are going to be findable if I understand the whole. I find the parts less interesting. Once I understand the whole, it’s like the other parts that are there will work.
But you really challenged me to be very definite about what the parts were. And mostly, that kind of challenge is interesting because mostly it turns out I was right that the parts would work out the way I imagined they would. But it’s not always true. And so having someone that will say, “Tell me the details,” basically like, “I need the proof of this idea,” by building it up from the parts. I mean, that’s the strength of our collaboration, I think, that we’re just enormously different in that way.
CORALINE: Katrina, you talked before the show about language hunters and fluency versus proficiency. Do you feel like that was a factor in the relationship you developed with Sandi over the course of writing the book? Like, was there a delta between fluency and proficiency that you both had and how did that play out?
KATRINA: I don’t actually know that this came into play in the collaboration on the book. We both have a very high degree of fluency in very different skills. And so, the skills that I have are this ability to go and build up a big picture from the very, very fine grain details whereas Sandi’s skill fluency lies much more in the ability to see a big picture and understand how it fits together, if that makes sense. So, the work that we did was in one way figuring out how to use my detail-oriented approach to arrive at her big picture understanding.
JESSICA: When you’re communicating with people, it can be easier to convey a small part and let other people build it up than to start from a whole that they can’t see yet.
SANDI: Oh yeah, exactly. The book came out of a course that originally Katrina and I talked together where I wrote this book, people started calling me and want me to teach OO. My primary teaching technique at that point was — because my primary explanations consisted of some form of ‘can’t you just see’ which is not very helpful. And then I had Katrina who was sort of the perfect guinea pig because Katrina was really great at refactoring. And so, we went on a path — so I would say, “Look, here’s the entry. Can’t you see?” And Katrina would say, “Well, no. How did you know?” And I would say, “Well,” I will just repeat myself and repeat it a little louder, “Can’t you just see?!”
SAM: Damn it!
SANDI: Exactly. So we have lengthy conversations that led us to do a bunch of refactorings. And I was like, “Like everybody about refactoring?” I was like, “I thought I knew how to refactor but I didn’t actually.” And Katrina who had actually read Martin Fowler’s book and done all the exercises was actually quite good at refactoring but didn’t have the overall guiding principles that it would let her make choices of directions of refactoring. Did that seem correct Katrina?
KATRINA: Yeah. There’s this thing, people who like me call me disciplined and meticulous. And people who don’t, call me anal and pedantic. But it’s really the same thing.
KATRINA: I have a process. I follow these very, very low level granular rules about how to refactor and I know how to get places. I just don’t always know where I’m going.
SANDI: So we would have these discussions where we would make up set of rules and then Katrina would go do the refactoring and I would watch her. I would say, “No, no, that won’t work. That’s not right. It’s got to be like this.” And she’d be like, “No, it breaks the rule.”
SANDI: “I don’t care if it breaks the rule, it’s right!” One of the most powerful things that happened to me for sure — and again, I don’t want to speak for Katrina but I hope it also happened to her is that a deep rededication to the idea of how much value there is in working with people that are not like you.
KATRINA: It was amazing.
SANDI: Yeah. It was amazing. It was amazing for me too.
KATRINA: Over and over again, we would have this disagreement. Exactly what Sandi said, “This is wrong,” and I’m like, “It can’t be wrong because the rule says it’s right.” And we’d arrive at an understanding of a better rule.
KATRINA: A lot of times, we would disagree and disagree and disagree until we found the way of viewing it where we both actually agreed. And it wasn’t like one person was wrong or the other person was right. We were both right and we have to find the [inaudible].
SANDI: And if there are rules — so here’s what we wanted, right? Wouldn’t it be great if you could take someone who didn’t know a lot about OO and give them a series of rules? And if they just follow those rules, that would teach them how find objects? It would teach them the things that I feel like I know after many years of experience. And that was the set of rules we were looking for and it meant that there was no place where I could say, “Draw that cloud,” there’s a joke where I could draw a cloud on whiteboard and it says ‘a miracle occurs here’.
SANDI: If you follow the rules, they have to work all the way down. And so, my challenge was to learn to articulate things that I was doing just on feeling. And Katrina’s challenge was to continue to insist to me that we were not going to stop until we had the rule.
KATRINA: Also, once the rules became correct or right or useful, I want to say useful more than correct, I was able to relinquish some of my dependents on them. Like once we were able to trust them, I could take bigger steps, I could feel comfortable with a variation on it or not necessarily following all of the details of it. I don’t know if that makes sense.
SANDI: You relax.
KATRINA: Yeah, a little bit.
JESSICA: This is really fascinating. Sandi, I totally understand that feeling of, “I get it! What’s your problem?” And if you don’t remember how you learn something, it’s really hard to figure out how to teach it which is important because that means that right after you learn something, it is the best time to write that tutorial or that blog post or that book. When you’re an expert in it is not the best time.
CORALINE: I hear that a lot from people that I encourage to give talks. They’re like, “Oh, but I’m not an expert on subject X.” I’m like, “No, talk about the process of learning subject X because that will resonate with people.”
JESSICA: Yeah, perfect!
SAM: Oh yeah, and if I can add to that too. I’ve given a couple of talks on things where I feel like I could almost pass for an expert on things but I exhausted those topics very quickly. And now, I’m like, “Well, I could give a talk but I don’t really know about what,” because in our process it’s been I’m only going to talk about something that I could rant about for three hours. So yeah, people who are doing talks earlier on in their proficiency, it’s great. They can bring people along.
JESSICA: You also said that Sandi is good at knowing where you’re going and Katrina is good at the details of how to get there.
SANDI: I think now, they’re accurate enough. Yeah.
SAM: What’s missing?
JESSICA: Yeah, what’s missing there?
KATRINA: Okay. So, having written this book, Sandi knows how to get like the details of the process is absolutely completely exposed and available. Sandi will no longer look at me refactoring and say, “What are you doing?”
SANDI: That’s annoying. That’s more like what I’d say. That’s annoying. Oh my God, don’t make me do that.
KATRINA: We’ve both arrived at this understanding of what the process actually looks like.
JESSICA: That’s such a beautiful description of pairing as I like it because I often find that remembering why I’m doing something and what the real objective is, is totally opposed to the details of the code like your brain space, and I find it really helpful to have one part of the pair focused on each of those levels. And then yeah, ideally you come together. That’s beautiful.
SANDI: Certainly our collaboration has changed how I write code.
KATRINA: Yeah, same here.
SAM: That sounds like that was worth everything, at least I would think it was.
SANDI: Boy, I would hate to go back.
CORALINE: Never go back.
KATRINA: Yeah. And I wouldn’t want to have not done it.
SAM: In reading your book, I was reflecting back on my own sort of professional development over the years. I had, at one point maybe four or five years ago, reached the point where my refactoring skills were decent enough that I had learned to trust that a series of small cleanups would remove enough of the obfuscating details, that I could see a little bit further and that I would eventually, if I did a bunch of little sort of cleanup things, that it would let me see a larger skill design that I could eventually get to. But at that point, I already had years of exposure to both refactoring skills and some basic OO design concepts.
And this book, I felt like in some ways, it came a little bit late for me. But in other ways, it was like, “Oh wow! That’s really amazing,” because it took all of that stuff that I had kind of halfway understood and made it very explicit which I thought was really great. It seems to me that where I was proficient at some level N where N is probably two or three minus where Sandi is, but this book seems like it’s good for people who are at like level one or two in their fluency. And it seems like it’s a really good way to bring people up faster. And so it’s another one of those things that I really wish that I had had earlier in my career. Is that kind of what you’re hoping for when you wrote this?
SANDI: It’s interesting that you would say one or two fluency because when I teach on my hands-on people who are going to this comp tent, what I find is that more advanced people that have difficulty with it, not the less advanced people. The kids…
SANDI: Oh yeah, the kids just do it because they don’t know anything. And so, they have no prior learning that gets in the way.
JESSICA: They’re not held back by their previous successes.
SANDI: They are not. They don’t think they know anything. What happens is the people who have the most experience, I actually let them argue with me in the course about what a bad idea, they hate it all. They absolutely hate it.
SANDI: They’re like, “Why are you making me do this step-by-step refactorings that are intended to expose the bones of the abstractions? Why are you making me do that teasing when I can just look at the problem and I can just go write it down?” But they have no idea the solutions that those people write.
One of the things the book does is at the very beginning it says, “Please go do the 99 Bottles of Beer Exercise before you start.” They write the most horrifically overcomplicated solutions. It’s astonishing how terrible they are. And we didn’t use to make them do it before we taught them but we started doing that because they don’t believe how bad their stuff is.
We have, as a business, as a set of programmers, we have gotten to the point where there’s a kind of over complex solution that we somehow have placed a lot of value on. If we use that complexity to — I hate to say this — there are ways in which we make ourselves feel better and defend our jobs by writing overly complex solutions.
SAM: [Laughs] Yeah.
SANDI: And we are very attached to the way it makes us feel – to be smart and clever and write things that are complex. And so, the people who invested in complexity have a very difficult time with these techniques because they are absolutely simple.
CORALINE: The first chapter you present the problem of the 99 Bottles of Beer song and you worked through four different implementations of it and I have to confess that my own implementation when I did you exercise was somewhere between the third and the fourth. When I saw the fourth, I was like, “Yeah, of course, you do it that way.” But what I’m curious about is how easy was it to write the bad code for the first example?
KATRINA: Oh, it was so much fun.
SAM: Fun? Fun, how?
KATRINA: Because we had seen all of these directions, all of these ways in which people write code. The first example is you do everything inline so I just took what I had already seen and went to the absolute extreme and wrote that. I knew exactly where I was going so it’s pretty easy to do it.
In the second version, I had also seen people do this, building this baroque-like as many indirections as you can that actually don’t help you go anywhere so that too was pretty fun.
Then the third example, this is the classic. You see this type of code everywhere in Ruby especially, if people do not have a lot of experience with design and have been following rules that the community has set out for them, without really understanding what those rules might get you.
JESSICA: Could you describe that example?
KATRINA: Yeah. You have a bunch of tiny methods and each method contains a fragment of an idea. Each method is named very, very, very explicitly to kind of describe this fragment and nothing coheres into an actual solid concept. So it’s impossible, even though, the code looks like it’s got small methods, it seems like it’s simple, it’s small, it’s pretty short. Even though it seems like it should be good code, it’s impossible to understand. Of course, in addition to this, there are some state that mutates but it makes us query in command.
SANDI: You know, if you think of OO as a place where you give names to abstractions, where an abstract concept has more than one implementation, you create objects that you polymorphically send messages to. There’s a way in which that describes all of the OO. You give names of abstractions and having abstractions let you compose problems of different implementations of the same abstraction. Then the solution — the solution number three looks like OO code but it violates all those rules. They don’t really identify the abstractions. They don’t really give them good names and there’s nothing polymorphic about it.
So despite the fact that it might score well on some metric tools and you look at it and it looks like it should be object-oriented, but it’s really not. It’s just uses an OO language to express a problem in a way that’s very confusing.
SAM: The way that you framed that just now, Sandi, had an interesting implication, which was that it sounds like you might be saying that until you have more than one implementation, you shouldn’t bother with the abstraction?
SANDI: Well, the short answer is yes. I think the hubris that we have as humans is we look at problems and we believe that we see the abstractions. Certainly, I did that before I met Katrina. Can’t you just see? I know it’s in there. But the truth is far greater minds than me — I’ll quote Martin Fowler — they’re saying that you should tolerate a little duplication until your occurrences of duplication start revealing the things that really truly are the same.
We learned that DRY rule early on in our programming careers and it’s because people teaches DRY because we can’t recognize anything but duplication. We don’t know anything. And so that pressure that we put on kids to DRY things out too soon, what does it mean when you DRY something out? You take two identical copies of code, you give them a name, you put it somewhere, and you call that name from the place where the duplication used to be. That is doing what I said a minute ago. It’s declaring an abstraction and giving it a name. But if you’re wrong because you don’t have enough information to know what’s going on, then you end up in a situation where the code doesn’t really tell the story of the domain.
CORALINE: I think it’s a major problem that people apply DRY (Don’t Repeat Yourself) and also, YAGNI (You Ain’t Gonna Need It), way too early in the process.
SANDI: It’s because when I teach classes and I ask people — in chapter one, the fourth example is an example we call Shameless Green and it’s just a case statement that returns the [inaudible] and there’s tons of duplication.
One of the things that happens is when we show people that solution, they all have the same reaction and I forget who said it a while ago, who said, “Oh, this is so simple. I should have written this.” When I asked people, we show them that and I say, “Is this good enough?” They’re like, “Oh, this is great. Oh, I loved it. It’s such a relief to see that code.” It’s so obvious. Then I say, “What happens if you submit it to code review?” They’re like, “Oh, you get hammered.”
So now we have the situation where I’ve got 30 people in a room and they all agree, “This simple code is better than all the complicated solutions.” Then I ask them that if their team’s at work, we’ll allow them to check it in and walk away and they all just laugh.
JESSICA: That’s terrible.
JESSICA: People want to activate DRY when they see duplicate code, but just because the code is the same doesn’t mean the idea is the same.
KATRINA: Yeah. I have thoughts about this on my [inaudible] and feelings, so many feelings. One of the problems that we see when people try to tackle duplication is that they do it in a way that is exactly the opposite of what design says that you should do. In every single book that I’ve ever read about design, they talk about encapsulating the part that varies.
But when people see duplication, they’ll look at two things that are pretty similar and a lot of those little pieces are exactly alike and then there are pieces that are not alike. What they end up doing is they encapsulate the piece that is identical, but it’s not an entire idea. Instead of taking a look at the two things that have similar ideas in them and then encapsulating the part that varies.
SANDI: Can I put that in a different way?
KATRINA: Please do.
SANDI: Sameness is interesting but different is more interesting. If you have an abstraction that represents itself in two different ways, let’s use the 99 Bottles of Beer song. Sometimes, you say the word ‘bottles’ and sometimes, you say the word ‘bottle’ — “2 bottles of beer on the wall, 2 bottles of beer, take one down and pass it around, 1 bottle of beer on the wall.” That’s the first unique verse as you’re counting down from 99, is push us with a new rule.
So in all the verses, they all say of ‘beer’ and ‘on the wall’. You see that repeated over and over and over again and it’s really easy to look at it and feel as if you want to take that duplication out: hide it behind a method, give it a name, send a message.
However, the ‘of beer’ and the ‘on the wall’ part are really boring. They’re sameness. The difference, though, between ‘bottles’ and ‘bottle’ means something and giving that a name is a more useful abstraction. The name of the difference is more interesting than the name of the sameness. Often, it’s really easy. We create abstractions. If I can put words in Katrina’s mouth, I think what she was saying is that we look at things and we create abstractions for the sameness and that’s easy and we leave out the difference and the difference is really the thing that matters most.
KATRINA: Yes. And it’s actually really hard to name that piece that’s the same. What do you mean ‘on the wall’? It’s not an idea. It’s not a concept so it gets really, really, really hard to find a name that actually encompasses what that is because it’s not really even a thing.
JESSICA: Yeah, that’s something I would put in a constant and I would name the constant ‘on the wall’ in all caps.
SANDI: Exactly. Then when you change the value ‘on the wall’, the constant would still be named ‘on the wall’, you have this huge problem about whether you’re going to… right? Like I work someplace once that had a method called blue box that returned a grey box.
JESSICA: Oh, perfect. Yeah.
SAM: Very nice.
JESSICA: I’ve totally seen that kind of thing and I love that phrase that it doesn’t represent a complete idea so don’t abstract it. If I need to change every place that says ‘on the wall’, I have command Shift-R.
SANDI: There you go.
SAM: I was thinking about this actually just yesterday, I remembered that somebody that I worked with had once written on the white board. Instead of DRY, they had written, whatever it takes to spell out ‘what’. It got me thinking again about the ways in which I’ve seen the DRY principle be horribly misapplied and I’ve done this many times myself. It seems to me that the fundamental problem with DRY is that it doesn’t tell you what kind of repetition is important. As new developers, the thing that we can see most easily is structural duplication.
This piece of code has the same shape as that piece of code so they must be abstracted out, whereas, I feel like the more important part of repetition is conceptual duplication. That’s where it kind of almost refer once and only once because it has that emphasis on once, this idea that you should have an idea that is in your code represented in a place. I don’t know. Am I off base with that?
SANDI: No, I totally agree. Like if you think of don’t repeat yourself as don’t repeat the idea rather than don’t repeat the exact keystrokes that got typed on the keyboard, like the key ‘Shift’ could be incidental duplications or they could represent some kind of duplication that could be a kind of duplication of a partial abstraction that you don’t understand yet. What we don’t want to do is duplicate ideas all over because when the ideas change, that’s when we get screwed, especially if the implementations of those ideas represent different characters. You can’t find them if you do that but ‘on the wall’, I have a text editor that can fix that. The duplication is not very costly and the problem is not very interesting. Yet we spend most of our effort working on that problem rather than the real problem, which is naming the abstractions.
SAM: Right. Also, the classic example that I think of as a date range where maybe in your application you’re passing around something that in some places the parameters are named ‘from’ and ‘to’, another place is they’re named ‘start date’ and ‘end date’ but really the underlying concept is that you have a range of time in which you’re interested in something happening.
JESSICA: Like interval?
SAM: Sure, yeah.
SANDI: I mean the DataClump/CodeSmell, right? Is it that name of that Code Smell? This is a situation where our names mislead us. We introduce difference in those argument names, the parameter names, and they make it appear as if things are not the same. When the underlying idea really is the same but we can’t find it because of the extraneous differences we’ve imposed upon the code.
KATRINA: Because the keystrokes weren’t the same.
JESSICA: I have a question. You mentioned that people love the simple code but they don’t think it would pass code review. Is your book, 99 Bottles of OOP, a new set of rules that we can apply to code review?
SANDI: Well, maybe.
JESSICA: Martin Fowler’s refactoring became the standard for code review at the place that I worked. Maybe you can help with that.
SANDI: There’s this thing that happened if you give stuff a name like the SOLID acronym, for instance. You know, all those principles of object-oriented design are pretty well-known because they gave it a good name. Katrina and I took it. Also, Martin Fowler, he named the Code Smells and then named the refactorings. The Gang Of Four book, they gave names to patterns.
There’s something really powerful about naming things. Katrina and I kind of took that to heart and we tried to give things names, like we name the simple solution that doesn’t create abstractions first. We name it Shameless Green and we create a definition for Shameless Green — it’s to write a solution that optimizes for understandability without regard to changeability. It may be, I don’t know, that these kinds of things will start showing up in code reviews. It would be wonderful if they did.
JESSICA: We had a guest question from Benjamin Fleischer. He asked, “In what ways is 99 Bottles of a richer kata than fizz buzz?”
KATRINA: I would like to try to tackle that. ’99 Bottles’ has two interesting things. One is that there is enormous amount of duplications and fizz buzz does not have that. The other thing is that it has just enough algorithmic complexity to potentially lead you astray. If you change the requirements on fizz buzz, it really just changes what numbers you put in the modulo or whatever.
SAM: Isn’t there sort of a meta version of the fizz buzz, or if I’m remembering it correctly, it might even have been the original formulation of fizz buzz. But I thought that there was another version of it that was to write something that you could give modulos and numbers and it would automatically give you a program that would output the right thing. But even that, you’re right, it’s not nearly as complicated and interesting as 99 Bottles.
SANDI: The goal of 99 Bottles of OOP book is not to write a great solution to the 99 Bottles of Beer song problem.
CORALINE: Is there a problem at all that face us in real lives? Come on.
SANDI: Like somebody’s fizz buzz is an exercise that they give you when you’re trying to be interviewed to see whether you can write a good solution to fizz buzz. The 99 Bottles book is about how to do OO, and the 99 Bottles problem is a convenient problem that brings up many, many, many issues in OO that give us a chance to talk about mutability. It gives us a chance to talk about inheritance. It gives us a chance to talk about simplicity. It gives us a chance to talk about how to deal with conditionals.
Just because that’s a convenient problem, it’s not fizz buzz. It is true that your only job is to write a solution and be done, if that was the point of the code, then I don’t know, it’s more complicated that fizz buzz, arguably but maybe the same kind of thing except on a bigger dimension. But that’s not the point at all. The point is to teach people how to think about objects and to deal with change. Given a problem domain, that is more interesting than [inaudible].
CORALINE: That kind of ties into one of our other guest questions that came from Craig Buchek, “Is the 99 Bottles book seems to document the trade-offs we’ve been implicitly making?” And he wondered if this could possibly be a first step in automating some of those decisions? Can we take now-explicit rules and partially automate the process of programming?
KATRINA: I think one of the keywords in his question is decisions. A lot of these things are trade-offs that you make based on your understanding. I don’t think you can automate understanding.
SANDI: Yeah. It’s interesting, the refactorings are mechanical. No doubt about it. Many languages have refactoring browsers or you can just say I want to an inline in this step or do an extra class on this stuff. Certainly, once you choose a refactoring, the steps are pretty well-known but at every decision point there are many, many, many, many choices that you could make. That’s what people want us to teach them. They do need us to teach in refactoring because it turns out most of us don’t really know that. But it’s not so much that but how to decide what refactoring to do. There’s a lot of judgment and experience involved in that and we’re trying to give people a leg-up down that experience path.
SAM: That was one of the things that I loved about the book was that rule of find the smallest difference and make it the same. That was really illuminating for me, I think.
SANDI: Yeah, it came out of the whole issue about as programmers, we’re really attracted to the hard problems and we tend to skip over the easy ones. What we found doing those refactorings and trying to figure out what the rules were, was that if we solve the simple problems first, the hard things got simple. But if we skipped the simple things, we left them as artifacts in the code, and worked on the hardest things first, very often the hardest things were unsolvable. That was a really powerful experience.
CORALINE: I want to go meta for a second and ask. Katrina, I was really fascinated about the conversation we had last week. I’ve never heard of Sparrow cards before. Would it be worthwhile to talk about Sparrow cards and talk about a process for building that intuition that is impossible to teach?
KATRINA: I would love to talk about it. Llewellyn Falco created something which he calls Sparrow Decks because he used PowerPoint side decks to show people pictures of different types of sparrows in order to teach them to recognize the difference between different species of sparrows. This was inspired by some of the work that Kathy Sierra has done around learning and creating passionate users and developing instincts, developing skill which has her insights came from among other things, the skill that people who are able to determine the gender of a day-old chick have.
In the poultry industry, if you’re trying to optimize for laying eggs, it’s really important to give all of the good feed to the girl chickens and not the boy chickens because the boy chickens, in the egg laying varieties of chickens, are not going to be economically viable. However, it’s really hard to tell the difference between a female and male chick when they’re a day old. It usually takes several weeks before they’re obviously one or the other. There are experts who are able to see this at a glance. They can sex up to 1200 baby chickens per hour and they just know. It’s impossible to explain how they know.
This has inspired a lot of research into how does the brain develop an intuition that is correct because they have a 97% accuracy rate on guessing the gender of the day-old chick. It’s clearly based on experience. The brain is clearly recognizing something even though it’s not able to say what it is. So Llewellyn Falco used this in order to create these PowerPoint decks to experiment with this idea of can you speed up people’s acquisition of intuition.
There’s actually been a lot of scientific research in the past 25 years on this idea of speeding up the acquisition of intuition. It’s called perceptual learning. If you want to go look at some of the research, the name to look for is Philip Kellman. He has done a lot of fascinating research with very, very systematically building learning modules that help people acquire very, very complex skills, like pattern matching in algebra, or in teaching middle schoolers to solve fractions. Not even to solve fractions but to recognize the type of problem that they’re dealing with. Are you doing with the ‘find the part’ or ‘find the whole’ because if you can’t tell the difference, then you’re going to have a hard time solving the problem. Visual navigations for airline pilots. So, he’s delved into very, very complex skills and he’s found that you can deliberately speed up the acquisition of this instinct to the point where people are spending a few hours, instead of months and years acquiring a skill.
JESSICA: Do your classes work like that?
SANDI: It would be an interesting thing. Katrina thought about using that for exercism, right?
KATRINA: I have thought of doing not directly exercism but as a separate project that builds various modules to help people recognize. For example, with CodeNewbie, one of the things that people lose a lot of time on is recognizing syntax errors. They’ll be like debugging their code for three days before they really realize that it’s just a missing brace or quote or whatever. I think that it would be fairly straightforward to build something that would help train people to recognize syntax errors.
CORALINE: Train them to read error messages.
KATRINA: Oh, that too.
SAM: Which is hard.
KATRINA: One of the things that’s hard about error messages is that we know exactly where in this big, old stack trace to look. We look for specific keywords or we kind of recognize the patterns of things that lead us to the right things but we don’t really necessarily know how we know or what we’re looking for. We just kind of know. I think it would be useful to find ways of helping people learn that.
JESSICA: Such as compilers that actually output polite, sweet error messages.
KATRINA: For example? That’s impossible.
JESSICA: Yeah, Elm does that.
KATRINA: No, I just think that there are so many ways in which we use this intuition, this pattern matching ability when we’re programming from the very, very simple things like syntax errors to the very, very complex things like Code Smells, abstractions, design patterns, debugging, and troubleshooting. I think we could do a lot to help people learn these things.
SAM: It’s time to thank another one of our $10-level patrons — Jer Lance. Jer is a software developer, teacher, and a self-professed opinionated jerk from Livonia, Michigan and is @jer_ on Twitter. Thank you, Jer and thank you to all of our awesome contributors. If you would like to support us, please visit Patreon.com/GreaterThanCode and that link will also be in the show notes for your clicking convenience.
CORALINE: We have another guest question from Darin Wilson who asked Avdi the same question and he’s interested in your answer, “What non-Ruby technologies are you interested in right now?”
SANDI: But it just seems like I would have to understand some. Are you telling me that my goal of making both these things happen at once by learning Elm is I’m not going be able combine them?
SANDI: But I was thinking more about solving the problem — taking a problem and solving it with both variants.
JESSICA: Like separately?
JESSICA: Yeah, that would be fascinating. Actually, I would suggest you do it in the opposite order.
SANDI: Oh, really?
CORALINE: That’s so cool.
SANDI: It’s a whole world of people who, I think, would find this stuff useful.
JESSICA: I wrote some TypeScript last night for the first time and I think I might be able to bear it.
SANDI: Really? No. Don’t make me. Don’t make me.
JESSICA: And I desperately need those.
SANDI: You know, I’m a dynamic typist from way back.
SAM: You know, I am too but I’m starting to get really impatient with Ruby.
SANDI: Yeah, but it never breaks for me. I don’t get type errors in Ruby. Write a trustworthy code and trust it. It’s easy.
JESSICA: But Sandi, aren’t we writing code for other people to modify because I’m working in a Legacy Ruby right now. It tells me it’s not friendly.
SANDI: I know. You know, I recognize that I’m a little bit of an outlier on that and what works for me doesn’t always work for everyone else. If you own your own code base and if you write it and you maintain it, then you can really lean on the dynamism in a way that makes you feel confident and safe but I totally understand. I’m not making fun of the statically-typed people. I’m not.
JESSICA: I can cope with my weaknesses but with the help of a compiler.
CORALINE: What about you, Katrina, what are you interested in right now?
KATRINA: I have been running a fair amount of Go and I’ve been participating in a lot of Go events and Go things and I really enjoy the language. But I have to admit that at the moment, I have more interest in things like people interactions, strategy, and things that are not directly technical but that getting better at them would help me do my work more efficiently and be more impactful, both in terms of work and open source.
CORALINE: Are you saying there’s value in being something more than an emotionless robot that produces code? Is that what you’re trying to say?
KATRINA: It pains me to me say this but yes.
JESSICA: That you might, in fact, be greater than code?
KATRINA: Yeah. That’s why I’ve been trying to become a better person lately.
JESSICA: There’s leverage in that that what makes our work as knowledge workers so valuable is that we have an incredible amount of leverage by teaching the computer how to do things a thousand million times. When we learn about working with other developers, we increase our leverage further.
CORALINE: Especially when we think about communities that arise around code. Not every GitHub project is going to have a community around it. But there are some that do. Understanding the human dynamics and human interactions goes a long way toward making sure that a community is welcoming, friendly, productive, and non-toxic.
KATRINA: Once the project starts growing. The more people are involved but the user base and the contributor base for project is and the less important the code becomes, the more important the interactions and the mentoring in the community, the issues, the discussions, and the code reviews become. We’re not very good at measuring those things. Sometimes, it can seem like we don’t value those things.
SANDI: Code is easy. People are hard. If you want to get things done, you got to get good at people.
JESSICA: We got Katrina to talk about some of her approach to teaching. Avdi asked to hear about Sandi’s unique approach to teaching.
SANDI: That’s a plant because Avdi has taught with me.
SAM: Which is why I wanted to make sure we asked it because it sounded like there’s some dirt there.
SANDI: Here’s the deal about teaching. So, think about this. When you’re up in front of the classroom, everyone’s looking at you, they’re all paying attention, and hanging on your every word, it’s so tempting to just natter on and on and on and bore everyone to death.
We know that listening is not how people learn. I have a psychology degree. When I started teaching, I did a bunch of research about how people best learn. It boils down to basically that you learn by doing and the best way to help someone who’s trying to learn by doing is to ask them questions.
So in my course, when we are helping people, we only get to ask them a series of leading questions and there are very carefully curated set of leading questions to get students to think of any idea. You know that feeling when you’re pairing with someone and they keep trying to explain something to you and you just wish they’d shut up and give you a minute to think, like they’re trying to tell you. Then contrast that feeling with the feeling you have when you suddenly get that moment of insight. You know like, “Oh, I see.” Until the whole course is structured around letting people have the moment of insight, rather than telling them things. It takes a lot of work to get the questions right and it takes a lot of self-control not to try to tell people things. But it does seem to work.
JESSICA: I think that’s really hard.
SANDI: It’s really hard. Sometimes, when you are in the class, I’ll have people who know the answers to the questions and they can almost not prevent themselves from telling other people. Maybe there’ll be some topic that someone already gets really well and I have to tell them, “You can help me but you can only ask questions,” and it almost makes them mute. We are very bad at this. Try this next time if you’re trying to help someone with something, don’t tell them. Just ask them things and see if you can get them to have the idea.
JESSICA: Yeah, people are much more likely to run with an idea if they thought of it or if they have the feeling that they thought of it.
SANDI: And they will remember it. They’ll apply it. It’ll fit in their context. The number of ways in which it is good for you to have the idea yourself rather than be told, it’s a long bunch of different dimensions, it’s better. And it’s what we do if we’re interested in having people learn rather than having us be the one to get to teach.
JESSICA: Yeah, because it’s about the audience. It’s not about us if you’re going to effectively transfer information.
SANDI: Yeah. So who cares if I teach? What we care about is whether people learned the things they wanted and needed to learn. That’s the point. It’s about them. It’s not about us.
CORALINE: I have one more question. It comes out of a conversation, Sandi that you and I had back in September at Beyond the Code. You said something really interesting to me and it’s sort of stuck with me. You said you’re looking forward to the day when no one asked you to speak any more. Can you talk about what you meant by that?
SANDI: Sure. I think the community is made stronger, more interesting, and more competent by lots of different points of view. This is code, in some ways, for saying there are no fun in software. You know, I speak at conferences now and by and large, I get invited to speak. That’s a symptom. In some ways, I hope it reflects the effort I put into my talks. But it’s also a symptom of the fact that there is not enough diversity on stage.
I feel strongly that the world will be a better place when it is such that no one ever asked me to speak because it will mean that there are lots of women, there lots of people of color, there are lots of older people. There I fit neatly into a bunch of demographic categories that I can add a lot of adversity to your conference in a bunch of different categories. But when no one invites me, it means that there’s enough diversity so that I don’t matter.
So, I want two things. I want to world where no one asked me to give a talk and I want a world where people who are outside the mainstream can give crappy talks and no one mentions it. Those two things. If those two things were true, the world would be a better place.
JESSICA: Yeah, I’m glad that people invite us to speak. That’s an improvement over than not caring. But at the same time, it’s like, “Yeah, we’re the easy ones for sure to be a hit.”
JESSICA: And we want the average women developer to succeed just as much as the average male developer and people of color and people who didn’t go to MIT.
CORALINE: White women are the easy form of diversity. I’d like to see us be more diverse in other ways.
JESSICA: Yep, level one.
CORALINE: Yeah, exactly.
SANDI: There is a way in which I feel like I often say yes when people ask me to speak. I do it partly because seeing someone on stage that reflects even part of a different demographic, makes the space more welcoming to everyone. It feels important for us to be there because of that but we need more.
JESSICA: Yep, and hopefully by being more than there used to be then we’re pushing our way up the spiral because more people will feel welcome and then more people will submit and then more people get invited and eventually, we’ll have 50/50 or maybe… I don’t know. I’d be happy with 40/60 gender balance and it just won’t matter anymore.
SANDI: Yeah, exactly. Everybody who’s listening to this, if it feels that they’re in an underrepresented category, needs to submit an abstract to give a talk at a conference.
JESSICA: Yeah, because gender is still level one, in my opinion, the least problematic of the demographics that are being left out.
CORALINE: I would also love to see more talks by people of color and women and people from other marginalized populations that don’t have to do with being a part of a marginalized population.
SANDI: Everyone loves a tech talk. Just give to that. It’s the thing that we’re talking about earlier that if you know things now that you didn’t know a year ago, then your past self would be grateful if you would give that talk.
JESSICA: Yes and what you said earlier, Sandi, about your audience is your younger self. So, just speak to the person you are a year ago because there’s a lot of people who are that person.
SANDI: Yeah. And the other thing is people often feel free to give talks because they feel like everybody knows what I know and that I’m going to get criticized somehow. Everyone is smarter than me and they all know this stuff.
Someone once told me a thing that I found greatly comforting. They said people love the story they know and it’s so true. That’s why children watch movies over and over again. Even if you go in a situation where some proportion of the audience does know your topic, they really enjoy seeing a good story well told.
JESSICA: Yeah, especially like at the local user groups.
SANDI: Yep, it’s a great place to start, right? If you’re prepared, they will love you and they will support you and you can feel it. All of us have given talks. How does it feel when you’re on stage? You get up there and do you feel like they hate you?
KATRINA: It’s like everyone there wants you to succeed.
SANDI: Yeah. It feels like they love you. I think people who haven’t given a talk and who are still stuck in it, like pre-talk terror. You have to see that they’re not going to hate you and eat you and that the mean people are going to ask you questions that make you like a fool. That’s what it feels like if you’ve never given a talk. But the reality of giving a talk is very different. They love you. You can feel them rooting for you when you get up there. They’re very generous and sympathetic as long as you’re prepared. If you’re nervous, even if you’re visibly nervous, they just double down on rooting for you.
JESSICA: By prepared, we don’t mean expert in that category. You don’t need to be able to answer all the questions. You need to be able to talk about it for the 45 minutes in some sort of coherent fashion. But if there’s a question you don’t know the answer to, my strategy is always caution, “I don’t know. Does anybody else here know?” And somebody does.
SANDI: I remember doing that to you at a talk once.
JESSICA: And somebody does and then the whole audience is like bonded together and happier. If they don’t, worst case, “Well, that was an interesting question. Give me your email address and I’ll find out and get back to you. Thank you.”
SAM: And if you’re still terrified at the idea of taking questions, don’t take questions. You can get up there and you can say, “I wanted to leave the stage for somebody else but I’m happy to answer questions afterwards. So, come see me.”
JESSICA: Yeah, good point. There’s a trend at conferences toward less taking of questions at the end of talks. I like that trend.
SAM: It helps avoid the thesis statement masquerading as a question, which incidentally I did earlier in this call.
JESSICA: That’s okay, Sam. We’re here because we think you’re interesting.
SANDI: We love you, Sam.
SAM: Awww… thank you.
CORALINE: Love is a strong word but I’m glad you’re here, Sam.
SAM: Hey, I did it today if you could do it to me.
SAM: I want to follow this up with an offer. I am obviously not the world’s most experienced conference speaker but if there are any first time submitters out there who are looking for help on their CFP or reviews on their talks, subject to my availability, I am happy to help you out.
JESSICA: Thanks, Sam. Now is the time in the show when we get to reflect upon what we have learned and provide our takeaway or maybe an action item that the audience could take away from this podcast. Who wants to go first?
CORALINE: I’ll go first.
JESSICA: Coraline will go first.
CORALINE: For one thing, the talk about the process of writing a book in which you learned about each other and learned about yourselves is giving me some inspiration to return to work on my book which is about empathy in software development. A lot of trouble writing the book because I’m still learning empathy and still practicing empathy. But I think I’m inspired to start writing it and to write it, I think, now for myself 10 years ago who really needed it more than I would like to admit.
The other thing that I got out this conversation, when we’re talking about DRY and code duplication, how it’s easy to spot structural duplication and harder to spot the duplication of ideas. I’m a very visual person and I think about software in very visual terms. I want to spend some time exploring whether that visual interpretation of code is the shape of code in the abstract or the shape of the code that’s written on screen and I want to do some reflection on that.
SANDI: I’m going to follow up on that since you just mentioned DRY. It was very interesting to me how there’s a little bit of a controversy around the notion that duplication is better than the wrong abstraction. I’ve been sort of espousing that and thinking about that hard for the last year or so. There’s some confusion in the world about what’s good, what’s bad. It was very interesting for me to hear the group of you have the discussion that we had about duplication versus what is duplication and how was abstraction. It makes me feel more confident even than that idea and more able to resist calls to DRY things out prematurely.
KATRINA: I want to take this in a completely different direction. There’s something very interesting about being reminded that people think of you in a different way than you yourself do or I myself think about myself. I’m often shocked to realize that someone is nervous to talk to me because they have seen me on Twitter or have seen a talk that I’ve done.
This idea that I am famous and therefore, I do talks, I think it’s really important to go back to this idea that we are humans and we have ideas and sharing those ideas makes us visible to other humans. That can have various consequences but it’s this process of sharing that’s way more interesting, which takes us back to the speaking and how incredibly important and impactful speaking can be for your career. I know certainly, for my career, it’s been incredibly important.
I have opportunities that I did not have. I meet people that I would not have met because I, at some point, chose to get up on stage and talk about refactoring in front of people who most certainly knew more about it than I do.
SANDI: Even though I have already gone, can I go again?
SANDI: Yes, what she said.
SANDI: Right? I wrote a book but it started with a talk and it changed my life in ways that I could never have imagined. Maybe you don’t want these changes in your life but I love my life now. I have a lot more control. The pressure is a little bit higher but the ways in which I can manage my own affairs and do what I want to do, spend my time the way I want to spend it, started out by getting on stage. You just don’t know where that’s going to lead.
JESSICA: Talks in particular are interesting because you’re sharing an idea with a live audience and you usually get some opportunity to interact with them afterward. That gives you feedback about what was important in those ideas and then you can go on to share them in books and things.
SAM: Since most of you are dog-piling on Katrina’s reflections, I would like to get in on this too and say that, Katrina, your decision to speak in your speaking career has also been impactful on my career because I wouldn’t have met you or Sandi and I certainly wouldn’t have given my refactoring talk if you hadn’t started off with yours. So, thank you.
KATRINA: Thank you. I have no idea. Cool.
JESSICA: Way back in the beginning of this podcast — this was my surprise takeaway — you all talked about how you gave each other feedback. Katrina gave Sandi feedback on a book, on POODR, and then you gave each other feedback on talks and things. Eventually, that led to this collaboration. That kind of development of a friendship, of a working relationship with someone who will push you, who is also working on the same path that you’re on to some degree but also on their own and you can level each other up a bit, that is super essential to our learning and growing as a community and as a team. That’s something to look for in a job or in a user group or wherever you can find it because people really grow by bouncing off of each other.
In particular, we also talked about how Sandi said that she loves working with people and that’s something else to look for. I want to work with people who are not like me but whom I like. I also think that liking people is mostly a choice so that’s almost everybody. I’m really glad that I get the opportunity to do that in programming and in speaking and in this podcast.
SAM: Yay! I had at least two reflections. The first of which was that it was really good to hear that helping others realize things on their own is so much greater than just telling them the answer. It was a really good reminder to me.
About the second reflection that I have, which is that I really need to keep practicing better self-control, both in my own coding and also in my mentoring, especially with regard to that first thing about letting people figure things out for themselves instead of trying to nudge them in the right direction. So I’m going to try and work on both of those. Thank you.
CORALINE: This is been an absolutely wonderful conversation. Thank you, Sandi and thank you, Katrina for joining us on Episode 8 of Greater Than Code.
JESSICA: Yes and thank you to all of our listeners, especially the ones who support us on Patreon and come into our Slack channel and ask guest questions.
CORALINE: Yes, and if you want to be one of those supporters and get access to our Slack community, go to Patreon.com/GreaterThanCode. We are at this point, 100% listener funded and we want to continue that tradition. But we do need some more help to achieve our target goal. So if you can help out, please do. Thank you and we’ll talk to you next week.
This episode was brought to you by the panelists and Patrons of >Code. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode. Managed and produced by @therubyrep of DevReps, LLC.