JAMES: Alright. So Chuck, I started the countdown to you forming the Swift Swashbucklers Podcast.
[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]
[Snap is a hosted CI and continuous delivery services that goes far beyond letting you do continuous deployment. Snap’s first class support for deployment pipelines lets you push any healthy build to multiple environments automatically and on demand. This means with Snap, you can deploy your staging environment today. Verify it works and later deploy the exact same build to production. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many, many more. You can also use Snap to push your gems to RubyGems. Best of all, setting up your build is simple and intuitive. Try Snap free for 30 days. Sign up at SnapCI.com/RubyRogues.]
CHUCK: Hey everybody and welcome to episode 160 of the Ruby Rogues Podcast. This week on our panel, we have James Edward Gray.
JAMES: Avdi, will you marry me?
CHUCK: Avdi Grimm.
AVDI: Yes, yes. A thousand times yes.
CHUCK: David Brady.
DAVID: I’ve had so much caffeine and Ritalin that I’m actually calling from the future. And Chuck, I’m sorry I screwed up your intro.
CHUCK: Saron Yitbarek.
SARON: There you go. You said my name right.
CHUCK: I’m Charles Max Wood from DevChat.TV. And this week, we have two guests this week… [Items falling]
DAVID: Oh, crap. Sorry, sorry.
SAM: Once again, David Brady.
CHUCK: Scrooge McDuck. I’m just kidding.
AVDI: David Brady just lost his marbles.
CHUCK: Sam Livingston-Gray.
SAM: Ah yes, it’s a fine morning to be joining you all on the Ruby Brogues.
JAMES: No, it’s not. Are you listening to this intro?
CHUCK: And Glenn Vanderburg.
GLENN: I’m Glenn Vanderburg. And I’m just here to keep an eye on Sam because he works for me.
CHUCK: Ah. I see how it is. [Chuckles]
JAMES: And with that start, this episode’s got a really low bar, okay? [Chuckles]
CHUCK: The pollen is attacking my eyes and my brain.
SAM: It’s okay. We’re…
AVDI: I saw that X-Files episode. [Chuckles]
SAM: With seven panelists, we are going for quantity over quality.
CHUCK: [Chuckles] Something like that.
JAMES: Absolutely. We’re trying to get all the biases we can in one show.
CHUCK: Hey, my Skype only shows six of you. [Chuckles]
SAM: Off-by-one errors.
CHUCK: [Chuckles] Couldn’t help it, sorry.
JAMES: Alright. So, we are gathered here today to discuss Sam.
CHUCK: I don’t have a eulogy prepared.
JAMES: Or more specifically, what Sam has been up to.
DAVID: I thought this was his intervention.
DAVID: We brought you here to confront you. [Laughs]
SAM: Have I been being too awesome again?
JAMES: Too awesome, yes. [Inaudible]
DAVID: Yes. It’s offensive.
CHUCK: That’s exactly what we were thinking. Alright.
JAMES: So Sam, you gave a RailsConf talk.
SAM: Yeah, I did. So yeah, for the second year in a row, I actually submitted a talk to RailsConf that had absolutely nothing to do with Rails. And for the first year in a row they actually took it.
SAM: So yeah, it was this talk about things we can do with our brains. And it was actually inspired by a bit from episode 77 of this very show where Glenn was on and he made a side comment about all of the things that experienced programmers do to wrangle different parts of their brain in to processing the weird abstract things that we work with.
GLENN: Oh yeah, that’s right. That’s why I’m really here.
SAM: Yeah. [Chuckles]
SAM: And so, that bounced around in my brain.
AVDI: It’s a highly recursive episode.
SAM: [Chuckles] Right. I may also refer to the book club with Tom Stuart as well.
JAMES: Dang it. Now, we’ve got to get Tom on the line. [Laughter]
SAM: Hey, it’ll give us a chance to redo the intro. So, it’s not all bad.
CHUCK: He really is calling from the future though, in Great Britain.
JAMES: That’s true. He is in the future.
JAMES: Tom lives in the future. That’s why he’s so much cooler than the rest of us. So, what was Glenn’s comment that led to all of this?
SAM: So, I’m going to quote you at you, Glenn. You said something like the best programmers you know all have some good techniques for conceptualizing or modeling programs that they work with. And it tends to be a spatial visual model but not always. You said what’s happening is that our brains are geared towards the physical world and getting with our senses and integrating that sensory input. But the work we do as programmers is all abstract. And what you said was, “It makes perfect sense that you would want to find techniques to rope the physical sensory parts of your brain into this task of dealing with abstractions. But we don’t ever teach anybody how to do that, or even that they should do that.”
SAM: And that last bit was really what got me thinking about it, because I’d been going up to Ada Academy once or twice to be a guest instructor there. And I was thinking about how to condense the stuff that I’ve learned and pass it onto my younger self or other people who are in that same position.
GLENN: And that was the episode where we were talking about this talk I gave at GoGaRuCo about dealing with complexity. And I threw that in there. And it’s something I’ve been thinking about for a long time. Dave Thomas and I did an embryonic tutorial about it in 2002. And at LoneStar RubyConf five years ago I gave this talk called ‘Programming Intuition’. But it was nice that I made that comment on Ruby Rogues the last time I was on because Sam latched onto it. And it surfaced us to each other as people who’ve been thinking about this weird thing for a long time. And he was able to take it into a direction and I think make it a lot more comprehensible and applicable than anything I’d been able to do in the past ten years. So, I really enjoyed watching Sam’s talk and learning from it.
CHUCK: I just want to jump in here, because when Sam explained this as part of his talk, I felt like I leveled up. Because a lot of times, I’m sitting at my computer and I’m working on some problem, and it does occur to me, “Oh, well I guess I could go model this on the whiteboard or create some kind of mental model that is the spatial model.” And I sit here for a minute and go, “Eh, I don’t need to do that.” But realizing that that could actually help me harness another part of my brain to pull it in on solving the problem, it was like, “Oh, maybe I should do that,” when I get that feeling of, “This would help.”
GLENN: The thing is, it doesn’t have to be something that you go and do with your senses. But I think most of us visualize or have some sort of mental model, whether it’s spatial or not, while we’re thinking about our code, and especially when we’re thinking about the dynamic runtime behavior of a system as opposed to just the static characters in our text editor or whatever.
JAMES: When we’re talking about this, I always think of musicians. I heard once that the higher you go in music, the more you try to involve all of your senses when playing. And I feel like when I’m watching great musicians I can almost see this. They’re swaying to the music. They have their eyes closed like they’re seeing something I don’t see, et cetera. They’re fully engaged in the thing that they’re doing by employing all of the senses and all of their thinking toward that end.
SAM: Yeah, that reminds me actually of a musician, Imogen Heap. She does a lot of interesting electronic music. And she’s been developing for the past few years this wearable electronic rig with these bend/flex sensors in her jacket. And she’s got gloves that can do gesture detection. And she actually makes music by moving her body, which is really cool.
JAMES: That’s interesting.
AVDI: Imogen Heap is amazing.
SAM: Yeah. I want her rig. [Chuckles]
SARON: You know, I really like that quote, especially because you bring it back at the very end Sam, when you say that we should be teaching people how to do this, and even that they should. How do you begin that process? Do you have to do that at the very beginning of learning to code? Is it better to do it once you’re more comfortable? How do you begin to teaching people that they should use physical and sensory parts when dealing with abstraction?
JAMES: That’s a great question.
SAM: That is a really interesting question. I think that it probably… I actually don’t know a good way of starting absolutely from scratch. But it seems to me that some of these things you might not want necessarily to introduce right away, because as a beginner you’re already overwhelmed with a whole bunch of stuff. And it seems like you have to be able to integrate and internalize at least some of these concepts before you can really start grasping for more and figure out how to use them even more efficiently.
SARON: I totally agree with that. When I read POODR, I learned it or I read it after I went to the Flatiron School. And I think that if I had read that from the very beginning, which a lot of people did, it would have meant nothing to me, because I wouldn’t have been able to appreciate those preliminary concepts to even know what designing code even meant. So, I totally agree with that.
SAM: Yeah, well that leads to an interesting point about working memory and this concept of chunking especially. Is everybody familiar with this already? James, I’m guessing you probably know it.
DAVID: Let’s define it just for fun.
SARON: Yeah, I feel like I should know, but [chuckles].
SAM: I’ve been talking a lot. Someone?
JAMES: Go ahead, Sam.
SAM: Okay. So, chunking is this idea of taking a complex thought and condensing it down into a single thing. It’s highly related to working memory, which is the idea that you can have, most people can hold in their heads seven plus or minus two discrete thoughts, which is why phone numbers are usually seven digits long. But chunking is this idea that you can take discrete things and combine them together into a single thing. So, if you ask me to remember the number sequence 8, 5, 3, I’m going to remember it as three separate things. But if you ask me to remember 9, 1, 6, I’m going to remember that as, “Oh that’s the area code where I grew up.” And so, I think that when you’re learning to program, you’re trying to hold all of these separate concepts in your head at once. And it overwhelms your working memory very quickly. But as you become more experienced, your brain builds these structures that mirror the structures in the code. And you’re able, eventually, to look at it and just go, “Oh, okay. So, that’s a class that does these three things. That’s a pattern. That’s one concept and now I can look at a bunch of other stuff and hold more stuff in my head at once.”
SARON: You know so much about biology and psychology. Where does that come from? SAM: Mostly Wikipedia.
JAMES: I was hoping he was going to say a troubled childhood, but you know.
SAM: No, I find it interesting. A couple of years ago, I read this book called ‘The Brain That Changes Itself’ which was mostly about neuroplasticity. But I also honestly learned a bunch of interesting stuff from the episode called ‘How to Learn’ which was probably my favorite Ruby Rogues episode ever.
JAMES: To me, it sounded a little like patterns, that one of the value of patterns is instead of having to think of these as these three separate class that do three separate things, once I know the pattern and the name for it, then I can just refer to them as that name, right? GLENN: Right.
SAM: Yeah, exactly.
JAMES: So, mental shortcut, basically.
GLENN: And Sam mentioned something about that in his talk, about cognitive biases and how it’s useful to understand the names for those things because just knowing the name helps us to think about them and recognize them and be able to talk about them and things like that. In some ways, I guess that’s a manifestation of the same kind of mental mechanism that you’re taking something that’s abstract and vague and giving it something concrete to hang on to.
GLENN: So, I was thinking about the question of how do you teach this or how do you start teaching it? And I made a point of saying in that thing that Sam quoted that part of the goal is that we should just teach that you should, because I think everybody ends up working out their own way of modeling software that fits their brain and the way they think. We can talk about examples and the way we do it, and I think that’d be really useful in general to talk more about how we visualize software. But maybe also, try to get students talking about the way they model other abstract concepts outside of programming. I think a facility with that kind of thing is probably one of the reasons that musicians tend to make good programmers, because they have an experience mapping from an abstract 2D notation on to physical concepts and bodily motion and things like that.
SAM: Mm, yeah.
GLENN: There’s a great line from Fred Brooks in the silver anniversary edition of ‘Mythical Man-Month’ where he’s talking about programming aptitude. And he talks about his favorite interview question. And I would never ask this in an interview because I don’t like cryptic trick interview questions. But nevertheless…
SAM: Thank you.
GLENN: [Chuckles] Nevertheless, it’s a really good way to get people thinking about mental models of abstract concepts. He said he likes to ask people who are candidates for programmer jobs, where is next November?
GLENN: And he said this sort of, people who are good programmers tend to have a vivid and well, very elaborate spatial model of the calendar.
DAVID: That blows me away, because…
DAVID: I lifted my right hand and reached…
GLENN: Yes! [Chuckles]
DAVID: A little bit forward and way out to the right.
GLENN: Yup, and it’s different for everybody.
DAVID: And it’s different for the time of the year.
GLENN: Right, yeah.
DAVID: Way out to the right because it’s about six months away. [Laughs]
GLENN: Yes, exactly.
GLENN: And it’s a good example that most people, probably not everybody, but most people will be able to relate to. And I bet if we stop to think about it, we could think of other things like that. But when we’re teaching this, what we definitely shouldn’t do is start to tie people down into a particular way of mapping this onto the senses. I initially started thinking about this over ten years ago, spurred by one question, which is if a picture is worth a thousand words, why does UML suck so badly?
GLENN: And one of the reasons is that it nails us down into a particular kind of narrow mapping of the domain onto physical ideas that A, may not be natural to us and B, isn’t rich enough to capture a multidimensional complicated piece of software in a lot of cases.
JAMES: Right. What if the one thing you want to map of your current problem…
JAMES: What if there’s no UML symbol for that?
GLENN: Right, yeah.
SAM: Yeah, exactly. So, it seems to me that the basic problem with UML, which is Unified Modeling Language, is that it’s a language. And languages both allow certain kinds of thoughts but they also constrain thoughts in different ways.
DAVID: Yeah. Yeah Glenn, you talked earlier about it’s so important to have names for some of these patterns and some of these things. And there’s a dangerous thing that starts to happen here at two levels. At the high level, we have the lesser Sapir-Whorf hypothesis.
DAVID: Which basically says the structure of languages influences the structure of your thinking. But at a very low level, if I call something, if I say this is the visitor pattern, that’s a fairly neutral term. But if I were to give it a name like wasteful iterator, all of a sudden this name now has baggage associated with it. Or if I call it the benevolent iterator, it has baggage as well. And that tends to deflect us sometimes. The chunking and the tokenization that we do in our mind has a bias to it.
GLENN: Yeah, that’s true. And that’s one thing I liked about Sam’s talk, is pointing out that these are shortcuts that can help us see and understand things. But we always need to check them with more rational thought.
SAM: Right. And that was really what I was getting at with the whole teaching thing, was I started thinking about yeah, I’ve always been really excited about a lot of these different techniques that I’ve discovered or thought that I invented. And I’ve been really excited to find ways to use them and thinking about how to teach other people to use them. I really wanted to make sure to give them a proper sense of caution about, “Here’s where they’re good and here’s where they fall down, so you want to check your work.”
JAMES: I think one of the things that’s valuable in teaching this stuff, Glenn’s talked about how if we tell you this is the one way to think, then it’s just another box. But to me, one of the most valuable things about this kind of thinking is knowing how to break out of the bubble when I’m stuck. And so, just the simplest trick that I always use for this when I’m really stuck is I reverse it. Whatever process I’m trying to do, I do it backwards. And it’s amazing. I know that sounds like the stupidest trick ever, but you wouldn’t believe, because it changes all the rules. And so, it’s like hitting the reset button in your brain and you have to think it all through again and you’ll come at it from different angles because you’re going at it the other way. And for me, that’s enough to jog me out of whatever I’m stuck in, when I can’t think through it and I know there’s a way to do it or whatever. Just by reversing the process or reversing the data or whatever, it’s one trick that helps me get out of that and think about something else.
GLENN: Can you give us an example?
JAMES: Sure. If you want to write a regular expression to put commas in numbers, so for a thousand it would be 1,000. It’s crazy hard to think about that regular expression if you attack it from the front of the string. But if you call .reverse on the string before you do it, it’s [inaudible] super simple.
GLENN: Oh. Oh yeah. Nice.
JAMES: Super simple regex.
SAM: Yeah. So, there’s an interesting thing that you just said, James, about resetting your brain. The name for one of the cognitive biases that I think you’re talking about is anchoring or focalism where your brain locks in on this one aspect of the problem and then simple discards other information even though it might be useful.
SAM: And one of the things I didn’t put in the talk because I didn’t feel I had enough, well enough time or enough experience working with it is this thing called the oblique strategies card deck.
JAMES: Yes, yes, talk about that.
SAM: So, I’ve known of this thing for a while. It was created by Brian Eno and Peter Schmidt apparently. And they’re musicians and they came up with this list of little strategies that they would use to break creative blocks. And they just had a deck of things that were little suggestions like, “Work at a different time scale,” or, “Emphasize every word in the sentence.” And these are just ways of coming at your work differently.
JAMES: Yeah. I actually have been reading the book ‘Drive’ recently which talks about where intrinsic motivation comes from. It recommends, it’s probably about the tenth time I’ve seen it recommended, I think the first place I ran into it was ‘Pragmatic Thinking and Learning’ from Andy Hunt. I think. But yeah, it too tells you when you’re stuck that oblique strategies can be a great way to get you out of the thing. I know there’s a Mac OS X app or a desktop widget or something that you can just click on and get a new one. It’s pretty cool.
SARON: Yeah. ‘Drive’ is a really good book. One question I had is in the talk, you talk about how once you have a name for a pattern or a concept, it’s much easier to know what to do with it. And I’m wondering, what’s a cognitive shortcut that was way easier for you to implement once you knew what it was and you didn’t have a name for it before?
SAM: I would say the first one that comes to mind is rubber ducking which is this idea that when you get stuck, you put the keyboard down and you turn to a rubber duck or a stuffed animal or a squishy brain.
SAM: And you explain your problem out loud. And when I heard about this practice, I realized that I had done this multiple times of going and interrupting a coworker in the middle of their programming task and being like, “Hey, can you help me figure this thing out?” And inevitably halfway through, you’re like, “Oh hey. Hold on,” and you run back to the keyboard and you fix it, right?
JAMES: [Chuckles] Right, yeah.
SARON: Oh, I do this all the time, yup.
SAM: But once I had a name for rubber ducking, then it became a thing that I was more likely to try first before I interrupted somebody else.
SARON: You know what’s funny, is I think that the idea of talking to an inanimate object is just absolutely ridiculous but I have no problems talking to myself just for hours.
SARON: So, I’ll have to move that on to [inaudible].
SAM: So, just make the inanimate object an extension of your ego and you’re fine, right?
SARON: [Chuckles] Your ego. So, I’ll call it Saron. There you go.
DAVID: I have a coworker who frequently signs emails and code commits as ‘Don and Mocha’ and Mocha is his dog.
DAVID: Mocha has two jobs. Job one is to listen to him debug and the other one is to come woof at him every two or three hours and say, “Hey, I need to go outside and go for a walk.” And so, he gives her credit to him thinking and moving and getting stuff done.
JAMES: While we’re talking about rubber ducking, I want to talk about one expansion of it I’ve found super helpful. It’s great to talk to an inanimate object, talk to yourself, talk to the programmer next door. It’s also really great to talk to someone who is none of those things, like your mom or whatever, that has no context. Because when you find yourself in that conversation, you will have to lift yourself up out of the context you’re stuck in and explain things on a higher level. So, you’ll be like, “So, I’m trying to figure out this algorithm which,” and then you have to explain it in terms someone else who doesn’t have your experience would understand. And in doing that, you’re automatically pushing yourself out of that rut.
CHUCK: I find that I’m rude when I do that with my wife, because in the middle of it I’m like, “Hey hon, I’ll be right back.”
JAMES: Yeah, yeah.
JAMES: I’ve totally done that before. [Chuckles]
SARON: I used to do this with my mom all the time. And she’s such a great sport about it, because she has no idea what I’m talking about. But she can tell from my inflection that something or something bad happened.
SARON: So, I’ll explain to her this complex thing and she’s like, “Oh no. Saron, how did that…” and then I’ll say something good and she’s like, “Oh, good for you.” And she has no idea what’s going on but she still plays along. It’s really helpful.
DAVID: Yup. Yeah, Chuck you think it’s rude. But if my wife is any judge, it’s actually a kindness.
DAVID: When you’re like, “Hang on. I figured it out. I got to go,” and she’s like, “Finally.”
GLENN: It’s like free entertainment too, right?
JAMES: The problem for me is my wife has done it for so long that now, she has enough of my context. I need somebody who doesn’t have it anymore.
JAMES: She can figure out what I’m talking about now. [Chuckles]
SARON: She got all caught up.
JAMES: That’s right, yeah.
SAM: That process, the name that I have in my head for what you just described, James, is when somebody asks me a question and I stop. My whole body freezes and I get the thousand-yard stare. I’m building the dependency tree in my head for all the things I need to explain in order to be able to explain something. Or if you’ve played StarCraft, it’s like the tech tree. You need this in order to get that, which gets you the other thing.
JAMES: Yeah. That’s a good point. I never thought of it as a tech tree before. I actually love that analogy. Civ will never be the same for me again.
AVDI: One of the things that relate to that, one of the things that I found most interesting in your talk and it reminded me of one of my favorite sci-fi books, ‘Blindsight’ by Peter Watts.
SAM: Which I did read, thank you.
AVDI: Oh. Did I recommend that? I recommend that to everyone.
SAM: You did, yeah.
AVDI: Yeah. One of the things you mentioned that also gets mentioned there is, I don’t remember how the word is pronounced, saccades or something like that.
SAM: Yeah, that’s it. Saccades.
AVDI: Basically, the fact that your eyes are sampling and they’re sampling slowly, we think about seeing the world as this consistent feed of information through our eyes.
SAM: We think we see in high-def basically.
AVDI: Right, but we don’t. We’re really just…
GLENN: Temporally as well as spatially.
AVDI: We’re stitching together some pretty lousy samples. The thing I found, actually maybe you can describe it. If you could describe what happens when you look around.
DAVID: Oh, saccades?
SAM: Yeah, saccades. So, a saccade is the technical name for the rapid eye movement that your eye makes when it’s moving from one angle to another. And I think at some point, it must have been thought that the eye actually stopped transmitting information to the brain during the saccade but it doesn’t. It just keeps sending data. But like what happens with a camera when you pan too fast is you just get a smeary blur. And so, your brain actually edits that part out. And this is the part that I thought was really interesting that they went into a little bit in ‘Blindsight’ was that your brain actually coordinates with itself. So, before you even start sending the impulses to your eye to move in a different direction, your brain also prepares itself to start filtering out the information that the eye is sending. So, your eye starts to move and your brain says, “Okay. Cut video and we’re just going to maintain the image of the scene as we last saw it. And then when the eye gets there, we’re going to turn video back on again and we’re going to start seeing things again.” So, effectively you’re blind when you’re moving your gaze around.
AVDI: Which just blows me away, because if you can’t actually believe in something as basic as sight, it really throws anything more subjective even more into question.
JAMES: Yeah, right? We always like to think that our reality is just a recording, that our brain is just…
JAMES: A little recorder sitting in our head. And we don’t like to think about the truth, which is that our reality is always constructed.
SAM: Yeah. And that’s one of the things that has me yelling at the television when I’m watching Sherlock, for example, is that there are several plot points that hinge on his ability to recall everything he’s ever seen, which just, our brains don’t do.
JAMES: It doesn’t work very well, yeah.
DAVID: There are peculiar people who have astonishing amounts of accidental recall.
SAM: That’s true, yes.
GLENN: Yeah, eidetic memory.
DAVID: Yeah. And eidetic memory, if you sat down and stared at my desk and saw how messy it was, there’s just not enough RAM in your brain to store everything that’s on my desk. But somebody who’s eidetic would store an astonishing amount of detail compared to me. I’m going to store seven or eight things that I can chunk together and then I’m done.
JAMES: You know what drives me crazy about saccades is when you’re watching a movie and they zoom in on that person’s face and they catch him at just the right angle that you can see their eyes bouncing back and forth. It drives me crazy.
DAVID: I actually, coming from the video game world, I love saccades because if you look at a video game from 2003, Y2K, that type of era, all of the video game characters, their faces are just, it’s just a bitmap. So, their eyes are just painted on a block of wood, basically. And they have dead staring doll eyes. And as games got more complicated and we had more 3D rendering, we started having individual rendering for eyeballs. [Chuckles] Programmers didn’t move the eyeballs. They just told the eyes to look at the target. And so, everyone had this really hyper-intense, you can see this in video games from 2002, 2003, everyone stares really intensely at everything.
SAM: That’s fun.
DAVID: And then you look at a game from 2009, 2010, and they’ve introduced saccades. And they’ve studied them very carefully. There’s an acting trick. This is what’s called the love triangle I think, is what they call it. And it’s from the corners of your mouth up to the bridge of your nose. That forms a triangle. And if you are in love with somebody and you’re gazing into their eyes, you will look at their eyes and then you will look down into that triangle somewhere. You look at their nose. You look at their lips. You look back at their eyes. You look back at their nose. You look at their eyes. You look back down at their lips. And this look down, look up, look down, look up, it’s actually a strong emotional cue. It’s a thing that you can transmit and evoke empathy in observers. And they’re sticking it in video games to trick us. It’s awesome.
JAMES: That’s hilarious.
DAVID: Harking back to saccades, Sam there was a slide in there that absolutely terrified me. We’ve talked about the fact that the brain is hiding the evidence of these saccades.
SAM: [Laughs] Yeah.
DAVID: But you had this slide that goes even more meta than that which is that the brain hides the evidence that evidence has been hidden.
SAM: I loved that quote. That was so, put that in your tinfoil hat and smoke it, right?
SAM: Yeah. The full quote was, so saccadic masking is the process where the brain edits out the smeary blur that happens when you move your gaze around. And the quote reads, “Due to saccadic masking, the eye-brain system not only hides the eye movements from the individual, but also hides the evidence that anything has been hidden.” I love that.
JAMES: [Chuckles] That’s great.
DAVID: That’s awesome.
AVDI: Right. So, it’s not like you get, you think you see a blank space. You think you see a continuous scene.
DAVID: Yeah. You think you’re seeing the room around you as a real thing, as a contiguous full-color three-dimensional… and it’s just…
AVDI: You think that’s air you’re breathing?
DAVID: Yeah, exactly! Exactly. [Laughter]
SAM: Thank you. That settles it. My brain has to go.
GLENN: Which [inaudible] the last time I was on the show.
JAMES: I feel sorry for any listener who actually trusted their brain before listening to this episode.
AVDI: And it’s interesting, because as programmers we’re surrounded by models. That’s one of the most helpful things that we can do for each other as programmers, because a lot of the stuff that we work with, it’s a sort of… Computers, the way they work is an unintuitive pile of mashed potatoes. And what a lot of programming languages do and programming paradigms do is they overlay a model that just doesn’t exist. A successful object-oriented programming language is one that has a very internally self-consistent model of working with software as objects. So, we can build, keep that model of the objects in our heads and we can see them as little black boxes sending messages to each other. And if it’s a good language, it won’t break down. It won’t have things where it’s like, “Oh, the model broke down.”
SAM: Basically, it lets you forget that there’s a Turing machine down there somewhere.
AVDI: Right. But what that says is that a good model, a good language, is just the most effective language at lying to us about what’s really going on, because that’s not how the machine works at all.
JAMES: Right, right.
AVDI: It might be how separate systems communicating with each other work, more or less. Although there are some oversimplifications there as well. But it doesn’t reflect the reality of CPUs at all. And so, it can constrain us.
GLENN: This is partly related to something that Sam talked about. He talked about a kind of cognitive bias, in part three of his talk when he was talking about that nifty hack about modeling Pac-Man in terms of the ghosts zeroing in on Pac-Man’s smell.
JAMES: Spoiler alert.
CHUCK: It was so good though.
GLENN: Oh yeah, it’s great.
JAMES: We are going to talk about this. It’s very important.
SAM: Oh yes.
SARON: It’s great.
GLENN: But at the start of that, he said, “This is something that I never would have thought of because we have a bias against thinking about these kinds of solutions.” And Sam, you said, “I wish I had a name for this bias.”
GLENN: And it seems to me to be related to what Avdi was talking about, that we have a bias towards mechanistic, straight ahead, procedural thinking a la the way the computers actually work under the covers. And we tend to think of heuristics and shortcuts as cheating somehow. And that’s not as good. That’s something you resort to if you can’t figure out how to do the exhaustive, procedural algorithmic solution. Then, “Okay, we’ll try guesswork or things like that.” And I was thinking about that when we were talking about the ways in which our brain lies to us and how we distrust that. And we distrust it because our brain is using heuristics and shortcuts to help us solve a basically intractable problem of perceiving every instant of everything about the world around us.
JAMES: Oh, I love that example you just gave, because you talked about how we distrust the heuristics and stuff that are applied. But as a person who is both a chess nut and a programmer, I was really interested when Kasparov would go head to head with Deep Blue. And the first time, Kasparov beat Deep Blue and that was basically heuristics versus raw algorithm with ridiculous processing power and just using his simple instincts that he’s developed over the years. And he was way smarter than that machine. So, they went back to the drawing board and threw everything they had to get it and then some and leveled it up even more, and then came back. And when it finally beat him, as a chess-loving programmer watching on, I have never been more unimpressed in my entire life. Like, look at what you had to do to beat this guy.
AVDI: Right, yeah.
JAMES: And it was such an unimpressive thing to me.
SAM: Well, that leads into an interesting story that I really wanted to open this talk with but I had to throw it out. But last year at a conference here in Portland called Open Source Bridge, I went to a talk by Markus Roberts. And he had this wonderful analogy. He was talking about computers Just in the last ten years or so have actually started being able to beat humans at the game of Go. And they do so using these basically Monte Carlo techniques. And for the listeners who aren’t familiar with it, Monte Carlo basically means we used a random number generator. And Markus, in his talk, he gave this wonderful analogy of comparing the amount of power that the human brain uses to the amount of power that is consumed by the supercomputers that are able to beat humans at Go. He likened it to building a big cube out of wood and chicken wire 20 meters on a side, filling it with golf balls, and putting some TNT at the bottom. And so, when you want to go play a round of golf, you construct one of these things.
SAM: And you go hide.
SAM: And then push the button. [Chuckles] And when all the smoke clears, and all the golf balls have distributed themselves across the environment, you walk over to the hole…
JAMES: I think one got in the hole. [Chuckles]
SAM: You walk over to the hole and you find the one that went in and you point to it and you go, “Oh, oh that one. That’s my ball.” [Laughter]
CHUCK: As an avid golfer, I’m going to have to try that.
SAM: Send me video.
DAVID: As an avid enthusiast of explosions, I’m with you.
SAM: Send me video.
DAVID: I like that comment that, Avdi, you were talking about looking for language as a way to build a lie over the top of the machine.
DAVID: And I’m having this epiphany of, I’m loving the fact that programming is ultimately an unending quest for a more convenient lie.
JAMES: [Chuckles] Right.
AVDI: Yeah. Yesterday, for some reason, I tried to read some OAuth documentation. I tried to understand OAuth again. And every time I try to do this, I fail. My brain just shuts down instantly. But it occurred to me, as I was thinking about why my brain shuts down when I study this one thing, because I honestly don’t think that OAuth is unnecessarily complex for what it’s doing. There is some complexity, some essential complexity to what it’s doing. The problem is it has no model. I have never seen it stated in a way that fell into place as a model of an interaction that I can see in my head. It just has a bunch of stuff. It just has a bunch of roles. And that was really a problem with it. So, I don’t want to say this building a lie thing is a bad thing. We need these models to understand things. I’m trying to think of a good example of something that does have a model. One thing I can think of is Git. I’ve seen many different explanations of Git. But there are some good ones out there where…
JAMES: The Jim Weirich explanation is my favorite.
GLENN: And Sam’s ‘Think Like (a) Git’.
AVDI: Yeah, exactly.
JAMES: Yeah, yeah, that too.
AVDI: You know, that do give you a mental model to think of. And it’s like, “Oh, okay.” Once I have that model in my head, things start to make more sense. And I don’t have a model for OAuth and nobody’s ever offered me one, at least in any of the material I’ve seen. And so, it’s just this big load of information without a way for me to organize it in my head.
SAM: Do you think that a UML sequence diagram might help?
AVDI: Maybe, maybe not. I’m not sure. I feel like there’s probably a better visualization than that out there. But it probably wouldn’t hurt. [Chuckles]
GLENN: Back in the 80s, when MIT designed the Kerberos authentication system, one of the documents they published was a dialog between two programmers that basically reenacted in dialog form the design process of Kerberos, with one enthusiastic but a bit naïve programmer saying, “I’m going to design an authentication mechanism. Here’s how it will work,” and then this curmudgeonly older guy poking holes in it and telling him how he would attack that thing. And, “Oh, okay. Well, I’ll improve it by adding this, or that, and seal it against that attack.” And I found it very effective for understanding why that protocol was the way it was.
AVDI: That makes a lot of sense. I sarcastically tweeted during this process, this tweet where I said, “OAuth client must present server with a token. Server will return a cookie. Give the cookie to the monkey.” [Chuckles]
AVDI: “The monkey will lead you to a map.”
SAM: Yeah, loved it.
AVDI: Which is, it’s my interpretation of the docs I was reading. But as I was thinking about that more, I realized that if somebody actually wrote a little text adventure game…
AVDI: That stepped me through that process in those anthropomorphic terms, I would probably finally understand OAuth.
JAMES: [Chuckles] That’s awesome.
DAVID: You are in a maze of twisty little SHA codes all alike.
SARON: So Sam, one thing that you talk about near the end of the talk is the importance of bias and how to battle your biases. And I remember you mentioned that one of the ways that helps you with that is having a diverse team that has different experiences and different backgrounds.
SARON: That approach things differently. And I’d love to hear a little bit more about that.
SAM: Yeah. I think just the real value of diversity is not so much for ticking a box so that you can say you’re diverse and people will stop yelling at you. The real reason to have a diverse team is that you have different people with different perspectives. People with different backgrounds have different things that are easy for them that might be hard for others. And so, that lets you both get creative solutions to problems and also to avoid blunders that might have been obvious to somebody who says, “Oh yeah, you don’t have any women in your slides,” for example. I was pairing yesterday with a teammate of mine, Tom Kiefhaber, who’s one of the Hungry Academy graduates. And I was railroading us through this solution. And he stopped and he asked what he may have thought was a really dumb question and I stopped and I was like, “Oh yeah. You’re right. That would be a much simpler way of doing it.”
SAM: And yeah.
GLENN: You know, it’s important to note that before Hungry Academy, Tom was in video production.
SAM: Yeah. And I don’t want to give the impression that Tom is in any way dumb. He’s a phenomenal developer.
GLENN: No, no, no, yeah.
SAM: He’s great to work with.
GLENN: For sure. But when we say diverse team and things like that, people immediately tend to jump to gender and racial diversity, which is great. But it also applies just to general diversity of background. And I like the fact that on our team we have a lot of people who were musicians. And through Hungry Academy we have a lot of people who started in a different career and then have brought that over to programming. And people who can apply experiences from art or other kinds of sciences or medicine or video production or things like that can bring a lot of interesting perspectives to things.
SAM: Yeah. I once worked with somebody who had, at the time he was working I think on a PhD in Quantum Computing and I think he’s got it now, had done some wonderful really complicated chip design stuff at Intel. But when I first met him, he’d never used a relational database. And so, we were able to see things differently and come at things from very different angles. And if nothing else, it helped me to understand a lot of the assumptions that I had been making because I’d internalized them years before. And yeah, it was really fun just to work with the guy who is this really sweet person to work with.
JAMES: I would say that’s some of the value of working with junior programmers.
JAMES: And it’s that sometimes I’ll be doing something in my head and I’ll explain sort of, skipping several layers, and if you’re working with a good junior programmer they’re like, “Hey, wait. Whoa, back up. What did you do at this level? What did you do at this level? How did you skip all the way to that level?” And I find that it usually improves the design when they do that, because I am skipping steps.
GLENN: Yeah, yup, for sure. And Saron, you talked earlier. You asked Sam about, how do you learn so much about brains? And I think all of this is one reason, that as programmers we ought to try to read non-fiction stuff that’s outside of our field of expertise. Because every time I do, I learn stuff about my own field.
JAMES: Great. Alright, we’ve all been good long enough. I want Pac-Man.
JAMES: That’s it.
CHUCK: I want to work with some people who know what Pac-Man smells like.
JAMES: I’ve waited and waited.
JAMES: And we have not talked about Pac-Man.
DAVID: Here’s a quarter, kid. Go buy yourself a video game.
JAMES: Seriously. Am I the only one that noticed this amazing example at the end of the slides that was cool?
GLENN: Oh no.
CHUCK: I actually have a question about that. And if you want the example, I think you probably have to go watch the talk, because I think it illustrates it well. But here’s my question. So, you start out and you give the approach that I totally would have taken by the way.
SAM: Yeah, me too.
CHUCK: And then you said, “Is this solution biased?” and then you said…
SAM: No, Chuck. This is important. I said, “How is this solution biased?”
JAMES: Yeah, yeah, yeah.
CHUCK: There you go.
SAM: That is the most important question in the talk, I think.
CHUCK: Yeah, and I still don’t have a good answer for it. So, I want to hear what yours is.
SAM: For how that particular solution is biased?
JAMES: The initial one?
SAM: Okay. Well, that’s the thing that I said I didn’t have a good name for, right?
CHUCK: Well, maybe you have a good longer answer for, I’m hoping.
SAM: Should I TL;DR the example for the listeners?
AVDI: Please do.
SAM: Okay. So, just very, very, very quickly, the idea is that if you’re programming Pac-Man you have to figure out a way to write the ghost AI in a way that’s going to be challenging and interesting for the human player. And when you ask programmers to make the ghost chase Pac-Man, they put themselves mentally in the place of the ghost and they figure out how they would solve that problem. And they wind up encoding a lot of rules in the ghost itself where the ghost might ask the maze where things are and then it will figure out its way through the maze to get to the Pac-Man. And I went to this presentation at OOPSLA which is a conference of the ACM. And Professor Alex Repenning gave this talk where he described this thing that basically turns that entire problem on its head, which is that you give the Pac-Man a smell and you use a diffusion model to radiate that smell out through the environment. And then the ghosts basically just have to follow their nose.
JAMES: So, to describe it in the just crazy simple terms, if Pac-Man’s standing on a square, we say that square is 100 or whatever, then we mark every square around it 50 and then every square around that 25. Whatever. And then a ghost at any given point can look at the number under his foot and move to the next bigger number. And by doing so, he’s chasing Pac-Man in a crazy hyper-intelligent way such that if there were multiple ghosts, as long as you have ghosts zero out the number underneath them so it doesn’t radiate out, and Pac-Man goes into a tunnel that has two exits, one ghost would go in one and then that would stop the smell pattern. So then, the other ghost would navigate around to the other one. And they will look like they’re intelligently closing him in and attacking Pac-Man. It’s super cool. You got to see it.
SAM: Yeah, where the most complicated each ghost is doing is comparing floor numbers and picking the biggest one, right? At most four numbers.
AVDI: Yes. It’s almost like a first-person bias.
JAMES: Yeah. That’s interesting.
SAM: Probably there are at least half a dozen cognitive biases that play into this. But the two that come to mind immediately, which by the way is called the availability heuristic, actually I might have mislabeled that. Anyway, one that comes to mind is this idea of anchoring, which I mentioned earlier, which is this idea that once you settle in on something, your brain fixates on it. And I had this line in the slide that I said names have gravity and metaphors can be tar pits. And that’s what I was getting at, was this idea that once your brain labels something and chunks it, it doesn’t think about it again. That’s the entire point of chunking. The other one that comes to mind is this other bias that its name is functional fixedness. This is the idea that people sometimes have a hard time using objects in ways other than the way they’re intended. So, if you have a hammer and you need a paperweight, do you think to put the hammer on the paper? And I see that as one of the key insights that I got out of this, seeing this presentation about Pac-Man so many years ago, is just this idea that when we as programmers put ourselves in that model that we’ve constructed, when we imagine ourselves in a maze, we are biased to think of the actors in that scenario. We think of the Pac-Man as moving around and we think of ourselves as moving around. Literally, what we don’t see is the air between us and our target. And that, the environment, can also be modeled and it can be used to shift things around. The computer doesn’t care how you get the job done. But our limited brains don’t necessarily think of that. And that again, I think, is highly related to functional fixedness.
GLENN: I think there might be a couple of other things going on, too. One is that smell is about the weakest of our senses and unlike with dogs, it’s not directional.
GLENN: So, we tend not to think of it that way. But the big one I see is that we have a hard time grasping the idea of emergent behavior from simple rules.
JAMES: Yeah, yeah.
JAMES: We can see it when it happens, but we have a hard time setting it up.
GLENN: Well, and we distrust it even when it does happen.
JAMES: That’s true, yeah.
SAM: Is that perhaps, again, related to our biases, programmers, especially those of us who have a CS educational background, to wanting to solve the entire problem all at once?
GLENN: Yeah, yeah. Yes, very much so. A distrust of heuristics and things that seem like partial solutions that usually work as opposed to the provably complete, entire problem solution. And that’s something that is drilled into us when we’re in computer science classes, right?
GLENN: Is you have to remember to test for all the edge cases and things like that, and solve the problem. So, a heuristic solution tends to be looked down upon.
AVDI: Yeah. So, what Glenn isn’t saying is that he’s done at least one excellent talk on the topic of heuristic solutions.
GLENN: Well, yeah. That’s actually the talk that I was on Ruby Rogues before. [Inaudible].
AVDI: Oh right, yeah. Yeah, you’re absolutely right. There are things I don’t usually think about. Like I’m thinking, “How do I handle this case? How do I handle this case? It only happens once a month. But I need to handle it.” And the thing that doesn’t occur to me is maybe it’s okay to handle most of the cases and then drop a few cases into a queue for a human to solve. GLENN: Absolutely.
AVDI: It shouldn’t be mind-blowing, but it is.
JAMES: We’ve actually used that scenario once in an app I was working on a long time ago. We had, the user authentication system was such that because of the database we didn’t have ACID and stuff. And so, we couldn’t guarantee that you wouldn’t get a duplicate user account, unlike somebody using the same email address or something and signing up for a new account. And you wouldn’t believe how much effort we originally tried to put into that. And it’s a thing that pretty much never happens. People don’t typically maliciously try to enter somebody else’s email address to create an account unless they’re a spammer bot or something obviously. And if they do typo their email address, the odds that they hit another person’s email address that’s in the system is terrible. And so anyway, it was this scenario we put tons of effort into that was stupid. And in the end, it had tons of problems [inaudible] of course. And what we finally did was when we were pulling a user for login, we pulled with limit two instead of limit one. And if we got multiple accounts, then we send an email to an administrator and put up an error message so that they can [inaudible] fix the problem.
SAM: And how often does that happen?
JAMES: Right, yeah. I can’t remember it ever happening.
GLENN: [Laughs] And you told that same story in episode 77.
CHUCK: I was going to say, this all sounds very familiar.
SAM: Yes, that’s because as humans, our memories are associative.
GLENN: Of course.
JAMES: I only know three tricks, guys.
JAMES: If you’ve listened to all these episodes, that’s it. You know everything I know.
DAVID: You can actually partition the Rogues episodes into three groups based on which trick James mentions.
JAMES: Right, right.
DAVID: There’s a joke that I heard years ago that solved this for me. And it was a military joke that my dad told me, basically some GIs in boot camp. And they’re talking about land mines. And one of the privates says, “Sir, what do I do if I step on a land mine?”
SAM: [Chuckles] Yeah.
DAVID: And the drill sergeant says, “Son, the proper procedure is to jump 20 feet in the air and scatter yourself over a five-meter radius.”
GLENN: That’s in a Blackadder episode, I think.
DAVID: Is it? Okay.
DAVID: So, it’s a disturbing joke/metaphor. But I will frequently write bits in the code where I will actually say, “If we reach this state, the proper behavior of this program is to crash violently and take the server down with it.” Sometimes, the correct behavior is to burn down, fall over, and sink into the swamp.
JAMES: For sure.
SAM: James, was there more that you wanted to talk about with Pac-Man?
JAMES: Yeah. I love that solution. And I should totally confess that Sam showed it to me even before the talk and it still blows my mind every time I see it. It was one of those things where emailed me, “You should read this thing,” and I was busy at the time. I’m like, “Yeah, yeah. I’ll get to it.” And then I think several weeks later when I finally got around to it, I’m emailing Sam, “Oh my gosh. How did I not know about this thing?” So, it’s totally amazing to me. But I’m interested in how we get to more of that. I like what, I think it was Glenn who said that we’re biased to think of the actors in the system. Or was it Sam? And not the environment. The logic is basically move to the floor tiles of the Pac-Man game. And we don’t tend to model objects that way. And that’s part of the, maybe part of your object should be real world things, which I think we all know is BS by now.
SAM: Right, and yet we still can’t avoid it.
JAMES: Right. We still have to do it. Right, yeah. I don’t know. It’s weird.
CHUCK: Sam pointed it out at the beginning of his talk. Our brains are hard-wired to that physical spatial world. And so, we want to map objects to real world objects. Our brains just conceptualize it better that way.
JAMES: Yeah, for sure.
DAVID: Sam, I’ve been thinking this entire episode about what the name of that bias you mentioned earlier would be. And I’m tumbling a bunch of ideas around in my head like a rock tumbler. Did I just say that I have a head full of rocks? Anyway.
CHUCK: [Chuckle] And sand.
DAVID: And sand. And it strikes me. DHH mentioned when he was on the show that he doesn’t want to debate and argue stuff. Just show me a before and after. And there’s a deep cognitive bias in that statement that I think is the same bias that you’re talking about. And I would call this refining the existing paradigm, or perhaps failure to abandon the current paradigm. In other words, you’re seeking a local maximum.
DAVID: And you can run into the local maximum trap problem where there’s a greater global maximum but you’ve refined your existing paradigm to the point where you’re trapped in it. And I’ve noticed that there’s…
SAM: And then the bias called loss aversion kicks in.
DAVID: Right, right, because we don’t want to… Yeah, the sunk cost fallacy. Right. I’ve noticed that I tend to think in two modes. And I think we’ve talked in the past about thinking fast, thinking slow, and that sort of thing. Actually, James and Avdi and I had a great conversation yesterday about exploring and playing versus executing and accomplishing. And it seems to me that sometimes when people, they want to debate the various merits of something, they’re not really in exploration mindset. They’re not looking for new solutions. What they’re trying to do is continue to execute the paradigm that they already have. And so, they’re looking to sharpen and refine. And they’re not really looking to open up to a new paradigm. Does that make sense?
SAM: Yeah. It also seems like in those conversations, people are looking to win rather than to learn.
DAVID: Yeah. We’ve talked in the past about how introversions tend to think things through internally and extroverts like to discuss things. And there’s a dirty trick that I see. I’m definitely an introvert. And so, when somebody says, “You want to explore this new paradigm? Show me how it’s going to work.” And I’m like, “I don’t know. I want to go explore.” And it’s frustrating to me because I don’t have proof, because I haven’t gone and explored and obtained that truth yet, or obtained that proof yet. And yeah, that’s not arguing with data. It’s trying to win.
GLENN: So, another bias here, and Sam might know the name of it, my friend Neal Ford calls it the rocks/suck dichotomy, is the notion to think of things as either having to be best or worst along all axes and not thinking in terms of different levels of tradeoffs in different contexts. And so, you look at that new paradigm and you’re measuring it against the costs and benefits that you’re familiar with in the contexts you’ve been working with your existing paradigm. And it seems to fail. But what you’re missing is that it might have benefits that you’ve never thought of before in your context because your existing paradigm has taught you that they’re unimportant.
GLENN: And it may also have costs that you see but you don’t see the benefits. And tradeoffs are really complex and usually contextual. And we are biased towards seeing costs that we understand and ignoring benefits that we’re unfamiliar with or unsure of.
DAVID: There’s a thing that you run into that when you switch paradigms, you often have to not just get a new idea. You can’t just take a new idea and plug it into what you’ve already been doing. Sometimes, you have to go get a whole new collection of ideas. And those ideas have to cooperate and collaborate with each other. And I think a lot of times in computer science, we want to find a deterministic variable, or in statistics they call it the covering variable. And a covering variable is one that, like if you’re alphabetizing names, your last name is a covering variable to your first name. In other words, your first name cannot… My last name is Brady. And I cannot have my first name ever be high enough in the alphabet that my name would come before Bradshaw in an alphabetization. My last name is a covering variable for my first name. It completely covers it.
JAMES: You’re never making it to the A list.
DAVID: I am never making it to the A list.
DAVID: I am on the B team, absolutely. And there’s this big discussion right now going on about TDD. And we want TDD to be a covering variable. And it’s clearly not a covering variable. If you have TDD it is possible to come up with a design that is worse than a design without TDD. So therefore, TDD is not a covering variable for code quality. And we also want it to be monotonically increasing or universally increasing.
GLENN: Mm, right.
DAVID: Which means that if you take any project and add TDD to it, that project will be better. But if you have…
SAM: And how many times does that happen, right?
DAVID: Sometimes it happens. But if you…
SAM: Depends on the practitioners, I’d say. Sorry, go on.
DAVID: It depends on the practitioners and also it depends on just how much legacy code there is.
DAVID: It’s very hard to add unit tests to code that was not built for tests, and especially when it’s a large codebase and that sort of thing. And so, you have all these ideas that have impedance mismatch with TDD. And if you have dialed the three supporting ideas of the TDD paradigm, if you’ve dialed them down to negative ten, then the higher you dial TDD, you can dial it all the way to 11, and all you’re going to do is wreck the project.
DAVID: Because you’ve got a variable that’s completely out of impedance, out of harmony with the other ideas that you’re using.
GLENN: Boy, have you ever set me up with something I wanted to mention.
GLENN: Because it ties right in with the topic of this whole episode. Just a couple of hours ago, JB Rainsberger tweeted something that really caught my notice. He said, “TDD will not lead to better design unless the programmer uses it as a way to internalize the relevant design principles.”
JAMES: Ah, yeah.
GLENN: And all this stuff that we’re talking about, about using cognitive shortcuts and leveraging the sensory, which is to say the unconscious or precognitive parts of our brain…
SAM: Or system one.
GLENN: Yeah. Right, is all about internalizing lessons that we learn about what works well and what doesn’t work well in our code.
JAMES: Yeah. Good point.
SAM: Plus one. Yeah, I saw that tweet that you retweeted this morning. And it reminded me in turn of the idea behind ‘The GOOS Book’, Growing Object-Oriented Software guided by tests.
SAM: And to me, the most important part of that is the last three words, guided by tests. And it’s not really the tests themselves that are guiding you. It’s the tests are concretizing feedback about your code and your design that otherwise you would have to stop and actively reason about using system two, which is slow and expensive.
GLENN: Yeah, exactly. And that delay mutes the feedback.
GLENN: And we don’t learn from it as much.
SAM: And you have to consciously switch into it and you can only do that so many times a day. And yeah, there are all kinds of fun stuff in there.
GLENN: Kevlin Henney likes to talk about sometimes you meet somebody who says they have ten years of experience as a programmer but then you work with them and you realize that it must have been the same year ten times.
GLENN: And everybody recognizes that and you laugh because you’ve all seen that.
SAM: I’ve been that, mister.
JAMES: It might be me. That’s why I laughed.
GLENN: But you don’t see that quite so much, if at all, in a field where people are working with their hands with materials. And I think a large part of that is the lack of immediacy.
GLENN: Our brains, like you said, system one. Our brains are wired to register an instantaneous effect and learn about cause and effects. But delays really get in the way of that thing. And so, I see, other people might disagree with me, I think programmers on average are getting better. And I think one of the big reasons is more interactivity in the way we do it. REPLs, TDD helps shortening the edit, compile, run cycle.
SAM: Pair programming.
GLENN: Pair programming, things like Swift’s playgrounds and the other things that Bret Victor talks about, it tightens that feedback look and helps us to engage system one and get that tacit learning.
DAVID: That’s the point that I was trying to make earlier. You mentioned Swift and that harkened back to it. There are people that are looking at Swift right now and they’re saying, “Why learn Swift if I’m going to have to learn Objective C anyway?” Why learn RubyMotion if I’m just going to have to learn Objective C? Why learn CoffeeScript if I’m just going to… why learn the pretty language if I’m just going to have to learn the ugly language anyway? Why not start with it? And what they are doing is they are simulating, in their mind, they’re not in exploration mode. They’re in execution mode. And when you’re in execution mode, you are rejecting alternatives. That is your implicit goal. And you are explicitly trying to avoid being surprised. And when you’re in exploration mode, you are seeking surprise. And so, you go to these people and you take a leap of faith. I got into TDD and I love TDD. I’m a big fan. It’s not religious for me. If I get on a big legacy project, I don’t use it because I realize it’s not a covering variable. But the reason I got into TDD and why it leads me to actually really good designs, not these design architectural nightmares that the naysayers are saying are inevitable, is because I went into exploration mode and I said, “I’m going to try TDD.” I’m going to embed myself in this heuristic. I’m going to shut off all of my instincts and my alarm bells that are warning me that I’m headed towards an architectural nightmare and I’m just going to go down this tunnel and I’m going to see where I came out. And where I came out was a beautifully factored design that I did not think was possible. In fact, I knew it was impossible to reach that well-factored design. And by knew, what I mean is, I predicted and I cognitively excluded. And that’s what I meant by this execution mode or sharpening the existing paradigm. We are trying to avoid surprise and delight. The danger of this is that you go to somebody and you say, “Try CoffeeScript. It will make you happier. Try RubyMotion. It will make you happier.” They simulate it, they exclude the surprise, they say, “I’m going to have to learn the ugly language. Why not just start there?” And then answer is oh, if you would just take this leap of faith, you would see how much happier the pretty language is going to make you. And yes, in a year you’ll have to learn both languages. But it will be so much more worth it. And the problem is, this simulation and exclusion, its entire purpose is to prevent you from taking the leap of faith. It is such a catch 22. It’s like I’m trying to say, “Take this leap of faith.” The counterargument is based entirely on a desire to avoid leaps of faith and it’s because we’re trying to avoid surprise.
SAM: Something came up for me as you were saying that, David. I would say that one of the things that I like most about TDD is that if you’re doing it well and you’re doing it at small enough steps, it gives you multiple opportunities and a minute sometimes to switch back and forth between exploration and execution mode.
DAVID: Yes. Yeah.
SAM: Because it gives you that interrupt, that stimulus.
SAM: Oh hey, what do I do now?
JAMES: [inaudible] place to look when it actually exists?
DAVID: My favorite… So, when you’re trying to eliminate surprise it’s because you’re trying to avoid nasty surprises. But when you are exploring and playing, it’s because you are seeking out surprise and delight. And surprise and delight is only experienced through integrating thought rather than dissecting thought. I gave a talk about this at MountainWest. I’ll put it in the show notes. I gave a talk on right brain versus left brain, which is a lie. It’s a cognitive lie but it’s a useful lie. And the thing is that you’re looking for these pleasant surprises when you’re in play mode. And my favorite thing, and this is a dirty, I maybe should have mentioned this in confessions, I have been surprised to discover that I am done. When I’m in TDD mode, I’m just grind, grind, I’m just recursing. I’m just this little tiny Turing machine. I’ve only got two bits of stack. And I’ve just got this next test and I make it pass and the next test and I make it pass. And then all of a sudden, my integration test suite runs and the whole program works. And I go, “Holy crap. I’m done.” And I’ve been surprised by that. I’ve not known…
SAM: Me too, all the time.
DAVID: How close I was… yeah, that’s never happened to me with formal waterfall style development. I’ve always known exactly how far I was away from having the wrong product finished.
SAM: A while back, a friend of mine, Shane Warden, tweeted something, a link to something about the waterfall design process that said, “Essentially waterfall amounts to an agreement between all parties not to learn anything at all for the entire duration of the project.”
DAVID: What I find interesting about waterfall and agile is, and this harkens back, pure waterfall is pure execution, right? We take everything we know and we will not learn anything new. Pure agile is pure exploration. We’re going to take all of the information we learn at every step of the way. And who knows? We’re going to lose all track of time.
SAM: But we are going to run it through everything that we know because we have good people whom we trust.
DAVID: Right. And there’s this interesting thing that I’m seeing, things like scrum where we’re going to do agile but we’re going to do it in two-week bursts. And we’re seeing this return to a waterfall, a phased waterfall approach where, like the SDLC, the Software Design Life Cycle, it’s supposed to be just this line. And now people are taking it and saying no, it’s a circle. And actually what it is, is it’s a spiral.
GLENN: Where have I heard this before?
DAVID: Where have you heard this before?
SAM: It was never supposed to be a line. That was a joke that somebody took seriously.
DAVID: Yeah. And what it is, is you are alternating, stop me when somebody in the podcast recognizes they’ve said this just two minutes ago, is you alternate between execute and explore. You go do your scrum sprint and during a sprint, you cannot change requirements. We refuse to learn anything new. And then you have retrospective and then you have planning. And that’s the moment when you go, “Okay, what did we learn from this? Oh, the customer hates this. Okay, we’re building the wrong product. Okay, we got to fix. Okay, let’s plan the next sprint.” And for two weeks, we refuse to learn anything new. And you’re on a spiral now. And you’ve got this hybrid waterfragile, waterfragile? I don’t know.
DAVID: Agilefall. I like it. That’s the downward spiral, but yeah.
GLENN: But the force that leads us to that is that some of our feedback mechanisms are much more expensive than others.
JAMES: That’s a great point.
GLENN: And so, you can’t do them all the time. You can pair program all the time or most of the time. And you can unit test most of the time. You can’t get user feedback about whether you’re building the right project all the time, or at least in most situations you can’t because it’s a costly thing. And so, I wrote a paper years ago about this, about how you can look at Extreme Programming as this nested set of cost-optimized feedback loops where you’re doing, you’re getting feedback about multiple different scales of decisions as rapidly as is cost-effective to do so for that kind of decision.
JAMES: Yeah. Alright, have we beat it to death? I bet we could talk about this all day.
DAVID: We could make this a three-parter and go for another two hours.
JAMES: I know.
SAM: I’m up for it.
DAVID: And you know what? I’m up for it but we probably shouldn’t.
CHUCK: I actually have a call in about 25 minutes.
SAM: Next week on a very special episode of the Ruby Rogues.
DAVID: That’s great. So, the careful listener will notice that Saron was our guest last week. And we just haven’t bothered to kick her off the call for a week.
JAMES: That’s right. She’s been on the whole time.
SARON: The whole time, yup.
AVID: And Saron, you’re actually going to be with us for another, what, three months.
SARON: Yeah. I’m just going to be on the same call for the next three months.
DAVID: Yeah. She’s got headphone fatigue like you wouldn’t believe and we are not going to let up.
GLENN: I hope you have a standing desk.
DAVID: So, I wanted to point that out. The careful listener will notice that Saron is back and she’s going to be a guest Rogue I guess is what we’re terming it. I don’t know what we’re calling it.
SARON: I like that. That works.
CHUCK: A permanent temporary.
DAVID: Permanent temporary? Yeah, guest [inaudible].
SAM: A Rogue contractor.
DAVID: Yeah. [Chuckles]
SARON: Rogue freelancer. That’s what I’m [inaudible].
JAMES: Freelancer, yeah.
CHUCK: There you go. But anyway…
SAM: That’s awesome.
CHUCK: We were very impressed last week so we invited her to come back.
SARON: Thank you so much for having me.
JAMES: Yeah, thanks.
SAM: [inaudible] though, they wouldn’t let you get to where they [inaudible]. [Chuckles]
CHUCK: Maybe. [Laughter]
CHUCK: Alright, let’s do some picks. David, do you want to start us with picks?
DAVID: You bet. So, I just pasted into our channel, this is for the show notes. I gave a talk at MountainWest in 2012 called ‘What’s Wrong with Ruby’s Object Model (And Why That’s a Good Thing)’. And overtly, it’s a talk where I refactor an awful piece of code. But the secret, actually not so secret of the talk is that I spent most of the time talking about the brain and how we tend to be in execution mode versus integration mode. And it is very, very interesting that you cannot experience delight without being in integration mode. So, if you are continuously trying to reject and execute, it’s a recipe for unhappiness because you’ll never be surprised. And if you’re never surprised, you can never be delighted. And it’s a fun, interesting topic that I ended up talking about. I wrote some awful unit tests that we could prove, looking at the test, that it was awful. And then I stepped back and I said, “Ah, but surprise. This test was actually really useful and here’s why. So, surprise.” It gets to stay in the, it’s earned its right to stay in the test suite, that sort of thing. My next two picks are just a couple of YouTube clips that are a lot of fun. The first one is called ‘An Eyeful of Sound’. Sam, you talked a little bit about various ways of internalizing things. And we didn’t get to talk about this on the show. I wanted to talk a little bit about synesthesia and literally using alternative neuronal clusters in the brain. I literally will use my sense of taste and my sense of smell to analyze code. I will ask myself, does this code have a bad flavor? Does it leave a bad taste in my mouth? Does it make my gut wrench up? And we could talk quite a bit about that but I’m not going to. So, I’m just going to direct you all to ‘An Eyeful of Sound’ which is a fun ten-minute video that shows what it’s like to have audio-visual synesthesia where you see colors and smell sounds and that sort of thing. Oh see colors, everybody does that. Where you see sounds and feel colors, and that sort of thing. The second one is ‘can You Trust Your Ears?’ which is audio illusions from AsapSCIENCE. We talk about optical illusions all the time. And Avdi mentioned a strange loop on the show a couple of weeks ago and I didn’t know what one was. And I went and looked it up. And it’s basically, an example of a strange loop is like an M.C. Escher painting. You’ll have the waterfall that falls and falls and falls and falls and falls and falls, or like the Penrose triangle which every corner of it is drawn perfectly to be a good isomorphic 3D projection. But by the time you get back to the beginning of the triangle, it’s an impossible structure. It’s twisted around on itself. And it turns out that you can do these with sound as well as with visual cues. There are strange loops for your ears. There’s a beautiful thing called, it’s the shepherd tone illusion. And it is a sound that continuously rises. It’s like watching a barber pole turn, how the spiral always goes up and never stops going up. But the barber pole doesn’t actually move and the shepherd’s tone illusion goes up or down and never stops. Very, very cool. It is very cool. It is mind-blowing. And my last pick, sorry to make these so long. It’s been a long time since I’ve done a 20-minute David Brady pick.
CHUCK: [Laughs] You were due.
DAVID: You’re due. my last pick is a game called BioShock. Now, most people out there who’ve played this, it came out in 2007. I saw this game come out. I saw it’s underwater, doesn’t interest me. It’s genetic science fiction, moderately interesting. The genetic science fiction lets you shoot fire, shoot electricity. Oh great, it’s a magic system using genetics. I’m not interested. I just gloss over it. And somebody finally told me, you need to go back and play BioShock because you are missing out on some of the best storytelling you’ve ever seen. So, I have to plug this game. I am halfway through BioShock 2 right now. All three, BioShock 1 and 2 and Infinite are out on Steam right now. I bought all three. I have to walk a fine line between spoiler alert and trigger warning here. And I want to just put this out there. If you’re going to play BioShock, the game really should come with a trigger warning. And that is that the game is based on a mad scientist dystopia and your job is to rescue little girls who have been abducted and subjected to genetic experiments. I have heard gamers say that they could play the game before they had children and they could not play the game after they had children. Caveat.
SAM: I can see that. Thank you.
DAVID: Caveat. I do not have kids. And the game’s treatment of the subject of abduction and terrorizing little girls is very mature and very responsible but they take you to a very, very dark place and force you to look that evil right in the eye and see the effects that it has on the families of these little girls and that sort of thing. And that’s all I’m going to say about it, because if I say any more, I’m going to trigger the actual trigger warning. The game does not shy away from that topic. By the time you finish it, you’re ready to kill everybody that ever had a hand in building that underwater city, because of what they do. And the good news is they pay it off at the end. It’s very, very good storytelling. But it definitely needs a trigger warning, for some people. So, those are my picks. And those of you that are listening to this on your commute, I hope you enjoyed the last 15 miles.
CHUCK: Alright. Avdi, what are your picks?
AVDI: Well, I don’t have any technical picks today. But I have some non-technical ones. I switched over recently to listening to audio books when I run rather than podcasts. And I’m really enjoying that, enjoying the depth of that. And I’m also finally being able to just plow through some of my reading list that I hadn’t been able to touch for years. As a result of that, I recently finished ‘Guns, Germs, and Steel’ which is probably one of the most recommended books I’ve ever seen. And I can say that it was totally, it totally lived up to the recommendations. It is a book of anthropology and history. And it deals with the question of why some societies were ascendant over others and tries to talk, the title refers to the proximate causes that everybody knows. Everybody knows that some societies, they had guns, and they had steel, and they had more virulent germs. And they had other things like writing and centralized political organization, which let to them conquering more primitive societies. But this book tries to go back and back and back until it gets to the ultimate reasons for why those societies had those things before other societies. And it gets into some very, very, very interesting stuff about environment and geography and domestication of animals and plants. And a lot of really fascinating stuff, really opened my eyes to a lot of things that I just had not realized before. So, totally recommend it. It’s a long book but it’s worth it. And if you do the audio book thing, you can get it on Audible. And also, speaking of books, I wasn’t going to have another pick but this conversation we’ve had today reminded me of a book that I read about I think halfway through. I haven’t finished yet. It’s called ‘A Mind of its Own’ by Cordelia Fine. And it’s a book that deals with everything you think you know is wrong because your mind is full of biases. And it’s a very, again, a very enjoyable and eye-opening look at all the lies that our minds tell us.
SAM: Sounds great.
CHUCK: Interesting. Alright, James, what are your picks?
JAMES: I had a set of picks when we started this call. And I’ve reshuffled them 400 times based on things we’ve said.
JAMES: And now, I don’t think any of the originals are in here. But whatever, these are my picks now. Two mini picks real quick upfront because they’ve been picked on the show before but I feel compelled to re-mention them. ‘Pragmatic Thinking and Learning’ by Andy Hunt was mentioned in this episode. It is still an amazing book. If you’re just getting into the brain and figuring out how it works and you want to try experimenting on your own, this is the book that got me started doing all that. The second one, ‘Programming Pearls’ was also mentioned by one of our guests a while back. But if you’ve not read this book, it’s full of basically Sam’s Pac-Man examples. For example, one of my favorite problems in that book is how do you read a whole bunch of integers in and write them back out without sorting them but put them out in order. And it’s totally mind-blowing the first time you see it because it’s a different way to think about a problem. So, those are mini picks. And then for some other stuff you might want to look at, we’ve been talking a lot about, in recent episodes, about TDD debate that’s been raging in our community, mainly sparked my DHH’s keynote. And there have been a series of meetings between DHH, Kent Beck, and Martin Fowler, called ‘Is TDD dead?’ And I have not seen the final installment. But the first one was okay. It was a lot about Grunt and stuff. The second one in my opinion is really good. And I will link to the video of that. You might want to watch it. It’s especially impertinent to a lot of stuff. We talked about, here, about what TDD is doing for you and to you and the decisions you’re making while you’re doing it, et cetera. And then a similar brain. Gary Bernhardt has a good post about test isolation, also related to this debate that’s been raging. And why it’s a value to him and how he’s using it as a feedback mechanism, which is super pertinent to everything we’ve been talking about today. So, if that kind of thing interests you, you’d probably enjoy these two links. Okay. That’s it for me.
CHUCK: Alright. Saron, what are your picks?
SARON: Sure. I have two, one programming related and one not. So, I love bead drawing videos. I don’t know if that’s what they’re called but that’s what I call them. And when an artist will have a time lapse of starting from a blank sheet of paper and then finishing with some beautiful creation. And one of my favorite ones is this guy whose name I’m totally going to destroy, Marcello Barenghi, something like that. And he does really, really hyper-photorealistic drawings and uses all kinds of paint and watercolor and markers and pencils. And he draws just regular objects. He has one of a sunny side up egg. He has one of a $50 bill, a Snickers bar. And the way that he starts from this thing that looks like it’s going nowhere and then built it to be, you really cannot tell that it’s not a photo. It’s just absolutely incredible. So, that is my first one. My second one’s kind of related. It’s this thing that I found relatively recently called ‘TheCodePlayer’. It’s described as a video-style walkthrough showing cool stuff being created from scratch. And when I saw it, I was like, “Great. This is like those speed drawing videos, but for code and things that I don’t know how to do.” So, it’s just awesome to see someone start from nothing and then end up with this beautiful app or whatever it is that they’re building. And that’s what I got.
GLENN: Well, I have four. I’ll indulge myself. So, the first, I want to present as an example of how to teach in a way that helps you engage the spatial parts of your brain. It’s a series of screencasts that Dave Thomas did called The Ruby Object Model and Metaprogramming.
JAMES: Those are so good.
GLENN: Yeah, they’re so good. And he develops this consistent visual language about objects and classes and the way they fit together and uses that with this, builds this mantra of you always think about method dispatch as one to the right and then up. And he does that throughout the whole thing. And it’s really helpful to me. And I now visualize the Ruby object model that way.
CHUCK: Isn’t that where Dave said November was, up in the right? [Laughter] GLENN: Maybe.
DAVID: Out and forward.
SAM: Back and to the left.
GLENN: There’s a book by a guy, I’m going to mispronounce his name for sure, Gerd Gigerenzer, a book called ‘Gut Feelings’. That’s about how intuition works and how intuition among people who are experienced, experienced their internalized expertise as intuition. It’s a great book. Another book called ‘Cognition in the Wild’ by a guy named Edward Hutchins that is about situated learning and the way context and culture shape our cognitive tasks. And most research into cognitive mechanisms deals with one person sitting in a lab. And this book is about how groups of people solve problems together. And given that programming is a social group task for the most part, I’ve learned a lot from that. And finally, an essay by Dick Gabriel called ‘Lessons from the Science of Nothing At All’, which is just about the challenges of working with abstractions all day long. CHUCK: Cool. It sounds really interesting. Sam, what are your picks?
SAM: You are all killing me with these picks. I’m going to have to go lock myself in a room for a year with a stack of books now.
SAM: [Chuckles] Thank you. That was awesome. So, I do have one quick plug, which is this cognitive shortcuts presentation that we started out talking about. I found out the other day that I’m going to be giving that talk again at Cascadia Ruby Conf. It’s here in Portland, August 11th and 12th. I’ve been three out of the four years that they’ve had, or two out of the three, something like that. And it’s been a really fun conference. I like it. And if you want to come to Portland, August is a great time. Okay, so that wasn’t a pick. It was a plug. Now for my picks. First, I’m going to pick something that I know for a fact has been picked before because I picked it the last time I came on the show. For the listeners who don’t know, ADA Developers Academy, ADA is a code school in Seattle with a really interesting model. They’re non-profit. They offer free tuition and even a very small scholarship to their students. And their program is six months in the classroom followed by a six-month internship. And it’s for women. And yes, they are trans-friendly. There’s language on their website about that. Anyway, since I was last on the show, I’ve been up to Seattle twice and I spent four or five days in the classroom helping the first cohort there learn TDD. And it was just an amazing group of women to work with. It’s a fun environment. Everybody was very sharp. They had a lot of diverse and interesting backgrounds. And they ask some really excellent questions. And so, the first cohort, they’re now on their internships and they’re all doing amazing things. And the school is now accepting applications for their second cohort. I think that’s open through June 16th. So, if you’re listening to this and you know anybody who’s thinking of applying, I encourage you to encourage her to go for it, because it’s a fantastic program. But do it fast, because by the time this episode comes out, you’ll probably have a week left. Okay, so next one. If you’re uncomfortable with the idea of a code school that’s only for women, my next pick is for you. This is a blog post by Kronda Adair. That’s spelled K-R-O-N-D-A. It’s pronounced ‘karonda’. And it’s called ‘Five Stages of Unlearning Racism’. I’ll put a link in the show notes. It’s written about racism but it applies equally well to any form of institutional –ism. And it’s a pretty quick read, but I really liked it because it very succinctly named a lot of the mistakes that I’ve made and that I continue to make while I’m learning about oppression and trying to be a better ally. And my third and final pick is also actually from Kronda. Earlier this week, she tweeted a link to this great blog post called ‘A Better Way to Say Sorry’. Avdi, I know this is something you have some experience with as well. You had a great link, a great gist that I’ve been linking people to for a while now. But this post is a teacher’s story about how she taught the kids in her class to apologize and the really transformative effects that it had on their behavior. It’s worth reading the whole thing. But the TL;DR is that it’s a template for apologizing with four parts. And those parts are: I’m sorry for, this is wrong because, in the future I will, and the last part is will you forgive me? And it’s a really interesting and powerful thing. And all four parts are important. And I kind of almost can’t wait to screw something up really badly so I can try it.
DAVID: I’m going to use it twice today.
SAM: Right. So, that’s it for me.
CHUCK: Terrific. Well, before we wrap up the show I want to remind everybody that we are doing our book club book. It is ‘Refactoring: Ruby Edition’. And for bonus, we’re also going to be doing the refactoring Ruby spaghetti book. It has spaghetti on the cover.
JAMES: [Chuckles] The spaghetti book.
JAMES: I don’t think that’s the title.
CHUCK: Yeah, I don’t remember what the title is.
SAM: It’s like the dragon book, right?
JAMES: Yeah. It’s like the dragon book, right.
CHUCK: So yeah, so we’re going to be doing that. And I just want to thank our guests, Glenn and Sam, for coming on the show.
SAM: Thanks. This was great fun.
AVDI: Yeah, thanks a lot.
SARON: Thank you.
CHUCK: Well we’ll wrap up. We’ll catch you all next week.
[This episode is sponsored by Codeship. Codeship is a hosted continuous deployment service that just works. Set up continuous integration in a few steps and automatically deploy when all your tests have passed. Codeship has great support for a lot of languages and test frameworks. It integrates with GitHub and Bitbucket and lets you deploy cloud services like Heroku, AWS, Nodejitsu, Google App Engine, or your own servers. Start with their free plan. Setup only takes three minutes. Codeship, continuous deployment made simple.]
[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]