Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies (Cascadia Ruby Conf 2014)


Published on

Slides for presentation at Cascadia Ruby Conf 2014

Published in: Software
  • Be the first to comment

  • Be the first to like this

Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies (Cascadia Ruby Conf 2014)

  2. 2. PROGRAMMING IS HARD {{ IMAGE: cat in a box }} ! ...but neither is it falling off a log. ! If I had to pick just one word to explain why programming is hard, that word would be [ADVANCE] "abstract". 5
  3. 3. ABSTRACT Existing in thought or as an idea but not having a physical or concrete existence As software developers, we deal in abstractions. ! I asked Google to "define abstract", and here’s what it said: [REVEAL] "existing in thought or as an idea but not having a physical or concrete existence". ! I usually prefer defining things in terms of what they are, but in this case I find the negative definition extremely telling. Abstract things are hard for us to think about precisely because they don't have a physical or concrete existence. 6
  4. 4. “The best programmers I know all have some good techniques for ... conceptualizing or modeling programs they work with. And it tends to be sort of a spatial/visual model ... but not always. ... our brains are geared towards the physical world and dealing with our senses and integrating ... sensory input ...” ! -GlennVanderburg, Ruby Rogues #77 I got the idea for this talk when I was listening to the Ruby Rogues podcast episode with Glenn Vanderburg. I edited this a little bit, but basically, Glenn said: [REVEAL] ! "the best programmers I know all have some good techniques for conceptualizing or modeling programs they work with. And it tends to be sort of a spatial/visual model but not always. What's going on is that our brains are geared towards the physical world and dealing with our senses and integrating sensory input." 7
  5. 5. “... But the work we do as programmers is all abstract. And 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.” ! -GlennVanderburg, Ruby Rogues #77 "But the work we do as programmers is all abstract. And 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." ! [PAUSE] 8
  6. 6. 1. Brains are awesome!  You can take shortcuts through the hard work of programming with specialized modes of thought. 2. Brains are horrible!  They lie to us all the time! But if you watch out for cognitive biases... 3. just might be able to pull off an amazing hack. When I heard Glenn say this, I got really excited, and I started thinking, [REVEAL] “yeah! YEAH! Brains are awesome, and we should be teaching people that this is a thing they can do!” ! And then I thought... “wait, no! [REVEAL] Brains are horrible, and they lie to us all the time! Teaching this stuff would be completely irresponsible if we didn’t also warn people about cognitive bias!” ! And then [REVEAL] I thought about an amazing hack that we won’t find unless we actively work to counter our biases. 9
  7. 7. 1. BRAINS ARE AWESOME Our brains are extremely well-adapted for dealing with the physical world. Our hindbrains, which regulate respiration, temperature, and balance, have been around for half a billion years or so. ! But when I write software, I’m leaning hard on parts of the brain that are relatively new in evolutionary terms, and I’m using some relatively expensive resources. ! Over the years, I’ve built up a small collection of shortcuts that engage some specialized structures in my brain. 10
  8. 8. VISUAL/SPATIAL REASONING BOXES & ARROWS There are a lot of visual tools that let us leverage our spatial reasoning skills. ! I’ll list a few examples, because I think most developers are likely to encounter these tools, either in school or on the job, and they all have the same basic shape: they’re boxes and arrows. 11
  9. 9. ENTITY-RELATIONSHIP DIAGRAM There are Entity-Relationship diagrams, which help us understand how our data is modeled... 12
  10. 10. DATA STRUCTURE DIAGRAM We often draw diagrams to describe data structures like linked lists, binary trees, and so on... 13
  11. 11. STATE MACHINE DIAGRAM And for state machines of any complexity, diagrams are often the only way to make sense of them. ! I could go on, but like I said, most of us are probably used to using these kinds of tools as at least an occasional part of our jobs. ! Diagrams are great, because they let us analyze systems that are larger than what we can hold in our heads. They let us associate ideas with things in space—and our brains have a lot of hardware support for keeping track of where things are in space. This lets us free up some room in our working memory. ! Also, our brains are really good at pattern recognition. So using diagrams to visualize our designs can give us a chance to spot certain kinds of problems before we ever start typing code in an editor—just by looking at their shapes. 14
  12. 12. VISUAL/SPATIAL REASONING THE SQUINT TEST Here’s another way to use your spatial skills to work with code. This one is called the squint test. You can use this to get oriented in a new codebase, or to zero in on high-risk areas. ! It’s very simple: you open up some code and either squint your eyes at it, or make the font size smaller than you can comfortably read. The idea is to look past the words and notice things about the shape of the code. 15
  13. 13. class InstallationsController < ActionController::Base! def schedule! desired_date = params[:desired_date]! if request.xhr?! begin! if @installation.pending_credit_check?! render :json => {:errors => ["Cannot schedule installation while credit check is pending"]}, :status => 400! return! end! audit_trail_for(current_user) do! if @installation.schedule!(desired_date, :installation_type => params[:installation_type], :city => @city)! if @installation.scheduled_date! date = @installation.scheduled_date.in_time_zone(! render :json => {:errors => nil, :html => schedule_response(@installation, date)}! end! else! render :json => {:errors => [%Q{Could not update installation. #{@installation.errors.full_messages.join(' ')}}] }! end! end! rescue ActiveRecord::RecordInvalid => e! render :json => {:errors => [e.message] }! rescue ArgumentError => e! render :json =>! {:errors => ["Could not schedule installation. Start by making sure the desired date is on a business day."]}! end! else! if @installation.pending_credit_check?! flash[:error] = "Cannot schedule installation while credit check is pending"! redirect_to installations_path(:city_id => @installation.city_id, :view => "calendar") and return! end! begin! audit_trail_for(current_user) do! if @installation.schedule!(desired_date, :installation_type => params[:installation_type], :city => @city)! if @installation.scheduled_date! if @installation.customer_provided_equipment?! flash[:success] = %Q{Installation scheduled}! else! flash[:success] = %Q{Installation scheduled! Don't forget to order the equipment also.}! end! end! else! flash[:error] = %Q{Could not schedule installation, check the phase of the moon}! end! end! rescue => e! flash[:error] = e.message! end! redirect_to(@installation.customer_provided_equipment? ? customer_provided_installations_path : installations_path(:city_id => @installation.city_id, :view => "calendar")! end! end! end Here are a few things you can look for: - Is the left margin ragged, with lots of nesting? - Are there any ridiculously long lines? - Are there areas where code is formatted into vertical columns? - Is the file mostly regular, but with one big gnarly area? Or is it a mess from top to bottom? - What does your syntax highlighting tell you? Do certain colors cluster together, or spread themselves out in a regular pattern? 16
  14. 14. LINGUISTIC REASONING I also have a couple of techniques that involve the clever use of language. ! The first one is very simple, but it does require a prop... 17
  15. 15. LINGUISTIC REASONING: RUBBER DUCK [PROP: BRAIN] ! Here’s how it works: you keep a rubber duck on your desk. When you get stuck, you pick up the rubber duck and put it on top of your keyboard, so that you can’t type. Then you explain your problem, out loud, to the duck. ! It sounds silly, but there's a good chance that, in the process of putting your problem into words, you’ll either realize what’s wrong, or at least think of something else to try. ! One of my coworkers has an interesting variation on this technique, which is to start writing an email describing the problem. I like this one because I think differently when I’m writing than I do when I’m speaking. 18
  16. 16. LINGUISTIC REASONING: “PLEASE, MR. GEAR...” The other linguistic hack I got from Sandi Metz. In her book, “Practical Object-Oriented Design in Ruby”, she describes a technique she uses to figure out what object a method should belong to. ! She says… 19
  17. 17. “How can you determine if the Gear class contains behavior that belongs somewhere else? One way is to pretend that it's sentient and to interrogate it. If you rephrase every one of its methods as a question, asking the question ought to make sense. ...” ! -Sandi Metz Practical Object-Oriented Design in Ruby ! [READ QUOTE] 20
  18. 18. “... For example, "Please Mr. Gear, what is your ratio?" seems perfectly reasonable, while "Please Mr. Gear, what are your gear_inches?" is on shaky ground, and "Please Mr. Gear, what is your tire (size)?" is just downright ridiculous.” ! ! -Sandi Metz Practical Object-Oriented Design in Ruby [FINISH READING] ! This is a great way to evaluate objects in light of the Single Responsibility Principle, and I’ll come back to that in a moment. But first... 21
  19. 19. •Rubber Duck •“Please, Mr. Gear, what is your ratio?” LINGUISTIC REASONING I described the rubber duck and “Please, Mr. Gear...” as techniques to engage linguistic reasoning, but that doesn't really do them justice. Both of these tools force us to put our questions into words... but words themselves are tools. ! We use words to communicate our ideas with other people. ! So while these techniques do involve the language centers of our brains, I think they go beyond language to tap into our [ADVANCE] social reasoning. 22
  20. 20. •Rubber Duck •“Please, Mr. Gear, what is your ratio?” •asking the question ought to make sense LINGUISTIC SOCIAL REASONING The rubber duck technique works because putting your problem into words forces you to organize your understanding of the problem in such a way that you can verbally lead someone else through it who doesn’t have all of your implicit context. ! And by anthropomorphizing an object and talking to it, "Please, Mr. Gear..." lets us discover whether it conforms to the Single Responsibility Principle. ! To me, the key phrase in Sandi's description of this technique is: [REVEAL] "asking the question ought to make sense." ! Most of us have an intuitive understanding that it might not be appropriate to ask Alice about something that is Bob’s responsibility. Interrogating an object as though it were a person helps us use that social knowledge. It gives us an opportunity to notice that answering this question isn’t really the job of any of our existing objects, which in turn prompts us to create a new role and give it its own name. 23
  21. 21. METAPHORS Now for the really handwavy stuff. ! Metaphors can be a very useful tool in software. 24
  22. 22. SPATIAL METAPHOR: TURTLE GRAPHICS The turtle graphics system in Logo is a great metaphor. ! Most of the rendering systems I've used are based on a Cartesian coordinate system, which is all very formal. But Logo encourages the programmer to imagine themselves as the turtle and use that understanding to figure out what to do next. One of the original creators of Logo called this [ADVANCE] "body syntonic reasoning"... 25
  23. 23. BODY SYNTONIC REASONING ...and specifically developed it to help children solve problems. ! But the turtle metaphor works for everyone, not just kids. Cartesian grids are great for drawing boxes. 26
  24. 24. CSS is awesome Well, mostly great. ! But it can take some very careful thinking to figure out how to compute the set of (x, y) pairs you need to draw: ! - A spiral. - Or a star. - Or a snowflake. - Or a tree. ! Choosing a different metaphor can make certain kinds of solutions easy, where before they seemed like too much trouble to be worth bothering with. 27
 -JAMES LADD James Ladd has a couple of interesting blog posts about what he calls “east-oriented code”. ! Imagine a compass overlaid on your code. 28
  26. 26. class Invoice! def total! line_items_total + taxes! end! ! # ...! ! def line_items_total! @line_items.sum(&:amount)! end! ! end class LineItem! ! def name! ! def description! ! def quantity! ! def amount! ! end In this model, messages that an object sends to itself go [REVEAL] south. Any data returned from those calls goes [REVEAL] north. ! Communication between objects [REVEAL] is the same thing, rotated 90 degrees: messages sent to other objects go [REVEAL] east, and return values go [REVEAL] west. ! What James Ladd suggests is that, in general, code that sends messages to other objects—where information flows east—is easier to extend and maintain than code that looks at data and decides what to do with it—where information flows west. ! Really, this is just the design principle “Tell, Don’t Ask”, but the metaphor of the compass recasts it in a way that lets us use our background spatial awareness to keep the principle in mind. 29
  27. 27. METAPHOR: CODE SMELLS Code smells are an entire category of metaphors that we use to talk about our work. In fact, the name “code smell” is itself a metaphor for anything about your code that hints at a design problem. ! I guess that makes it a… [REVEAL] meta-metaphor? 30
  28. 28. META-METAPHOR: CODE SMELLS …okay, maybe not. 31
  29. 29. METAPHOR: CODE SMELLS •Duplicated Code •Long Method •Large Class •Too Many Parameters
 •Feature Envy •Refused Bequest •Primitive Obsession Some code smells have names that are extremely literal: “Duplicated Code”, “Long Method”, and so on. ! But some of them are delightfully suggestive: [REVEAL EACH] “Feature Envy." "Refused Bequest." "Primitive Obsession." ! To me, the names on the right have a lot in common with “Please, Mr. Gear”: they’re chosen to hook into something in our social awareness, to give a name to a pattern of dysfunction, and—by naming the problem—to suggest a possible solution. 32
  30. 30. COGNITIVE SHORTCUTS •Boxes & Arrows •SquintTest •Rubber Duck •"Please, Mr. Gear..." ! •Metaphors: •Turtle Graphics •East-Oriented Code •Code Smells These are some of the shortcuts I’ve accumulated over the years, and I hope that this can be the start of a similar collection for some of you. 33
  31. 31. 2. BRAINS ARE HORRIBLE [PAUSE] ! Evolution has designed our brains to lie to us. ! Brains are expensive. The human brain accounts for about 2% of body weight and about 20% of our caloric intake. That’s a huge energy requirement that has to be justified. ! Evolution does one thing, and one thing only: it selects for traits that help an organism stay alive long enough to reproduce. Evolution doesn’t care about getting the best solution—only one that’s good enough to compete. Evolution will tolerate any hack as long as it meets that one goal. 34
  32. 32. HUMAN VISION To illustrate, let’s talk about how we see the world around us. 35
  33. 33. PHOTORECEPTOR CELLS •~120m rod cells
 (monochrome, low light, peripheral vision) •~6-7m cone cells
 (color, more light, central details) The human eye has two different kinds of photoreceptors. ! [REVEAL] There are about 120 million rod cells in each eye. These play little or no role in color perception and are mostly used for night and peripheral vision. ! [REVEAL] There are also about 6 or 7 million cone cells in each eye. These require a lot more light, and they’re what lets us see in color. ! The vast majority of the cone cells are packed together in a tight little cluster near the center of the retina. This area is what we use to focus on individual details, and it’s smaller than you might think: it’s only about 15 degrees wide. 36
  34. 34. As a result, our vision is extremely directional. We have a small central area of high detail and high color, but outside that, our visual acuity and our color perception drop off very quickly. ! When we look at [REVEAL RIGHT] this… our eyes see something like [REVEAL LEFT] this. ! [PAUSE. REALLY. AT LEAST FIVE SECONDS.] ! In order to turn the image on the left into the image on the right, our brains are doing a lot of work that we’re mostly unaware of. 37
  35. 35. SACCADES We compensate for having such highly directional vision by moving our eyes around a lot. Our brains combine the details from these individual points of interest to construct a persistent mental model of whatever we're looking at. ! These fast point-to-point movements are called [REVEAL] saccades, and they're actually the fastest movements the human body can make: the shorter saccades you make when you’re reading typically last for 20 to 40 milliseconds. Longer ones might take up to 200 milliseconds, or a fifth of a second. ! What I find so fascinating about this is that we don’t perceive saccades. During a saccade, the eye is still sending data to the brain, but what it’s sending is a smeary blur, so the brain just edits that part out. ! This process is called [ADVANCE] “saccadic masking.” 38
  36. 36. “Due to saccadic masking, the eye/brain system not only
 hides the eye movements
 from the individual but also … SACCADIC MASKING You can see this effect for yourself next time you're in front of a mirror: lean in close, and look back and forth from the reflection of one eye to the other. You will not see your eyes move. As far as we can tell, our gaze just jumps instantaneously from one reference point to the next. ! Now, I hope you like conspiracy theories, because I’m about to give you one you’ll have a hard time forgetting. ! When I was preparing this talk, I found this sentence in the Wikipedia entry on saccades: [REVEAL] ! "Due to saccadic masking, the eye/brain system not only hides the eye movements from the individual but also [ADVANCE] hides the evidence that anything has been hidden." 39
  37. 37. “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.” SACCADIC MASKING [PAUSE] Put that in your tinfoil hat and smoke it. ! Our brains lie to us. And then they lie to us about having lied to us. And this happens multiple times a second, every waking hour, every day of your life. ! Of course, there’s a reason for this. Imagine if, every time you shifted your gaze around, [ADVANCE] you got distracted by all the pretty colors. 40
  38. 38. You would be [ADVANCE] eaten by lions. ! 41
  39. 39. #Not All Lions [PAUSE] ! But in selecting for this design, evolution made a tradeoff. The tradeoff is that we’re effectively blind every time we move our eyes—sometimes for up to a fifth of a second. And we might still get eaten by lions because of this, but… [REVEAL] not as often. ! #NotAllLions ! I wanted to talk about this partly because it’s just a really fun subject, but also to illustrate how our brains are doing a massive amount of work to process information from our environment and present us with an abstraction. 42
  40. 40. And as programmers, if we know anything about abstractions, it’s that they’re hard to get right. ! Which leads me to an interesting question: does it make sense to use any of the techniques I talked about earlier to try to corral different parts of our brains into doing our work if we don’t know what kinds of shortcuts they’re going to take? 43
  41. 41. BIAS . According to the Oxford English Dictionary, the word “bias” seems to have entered the English language in the 1520s. It was used as a technical term in the game of lawn bowling, and it referred to a ball that was made in such a way that it would roll in a curved path instead of in a straight line. ! Since then, it’s picked up a few additional meanings, but they all have that same basic connotation of something that’s skewed or off. 44
  42. 42. COGNITIVE BIAS Actor-observer bias Ambiguity effect Anchoring or focalism Attentional bias Availability cascade Availability heuristic Backfire effect Bandwagon effect Base rate fallacy Belief bias Bias blind spot Bizarreness effect Change bias Cheerleader effect Childhood amnesia Choice-supportive bias Clustering illusion Confirmation bias Congruence bias Conjunction fallacy Conservatism (Bayesian) Consistency bias Context effect Contrast effect Cross-race effect Cryptomnesia Curse of knowledge Decoy effect Defensive attribution hypothesis Denomination effect Distinction bias Dunning-Kruger effect Duration neglect Egocentric bias Empathy gap Endowment effect Essentialism Exaggerated expectation Experimenter's or expectation bias Extrinsic incentives bias Fading affect bias False consensus effect Focusing effect Forer effect
 (aka Barnum effect) Framing effect Frequency illusion Functional fixedness Fundamental attribution error Gambler's fallacy Generation effect Cognitive bias is a term for systematic errors in human cognition: patterns of thought that diverge in measurable, predictable ways from the answers that pure rationality would give. ! When you have some free time, go have a look at the Wikipedia page called “List of cognitive biases”. [REVEAL] There are over 150 of them, and they’re fascinating reading. ! This list of cognitive biases has a lot in common with the list of code smells I showed earlier. A lot of the names are very literal, but there are a few that stand out, like “Curse of knowledge” or the “Google effect”. ! The parallel goes deeper than that, though: this list gives names to patterns of dysfunction, and once you have a name for a thing, it’s much easier to recognize it and figure out how to address it. ! I do want to call your attention to one particular item on this list. It’s called [ADVANCE] “the bias blind spot.” 45
  43. 43. BIAS BLIND SPOT The tendency to see oneself as less biased than other people, or to be able to identify
 more cognitive biases in others than in oneself This is [REVEAL, READ ALOUD] ! ...sound like anyone you know? ! There’s a big part of tech and geek culture that glorifies rationality. We often want to see ourselves as beings of pure logic. 46
  44. 44. HERE IS A PICTURE OF MR. SPOCK. YOUR ARGUMENT IS INVALID. [PAUSE] ! I hate to break it to you, but ain’t none of us Mister Spock. Even Spock would bend or break the rules when it suited him and make up some bullshit excuse later. ! As humans, we’re all biased. It’s built into us. Pretending that we aren’t biased only allows our biases to run free. 47
  45. 45. LOOKING FOR BIAS “HOW IS THIS BIASED?” I don’t have a lot of general advice for how to look for bias, but an obvious and necessary first step is just to ask the question: [REVEAL] “how is this biased?” ! That first word is crucial! If you only ask “is this biased?”, it’s way too easy to let yourself say, “eh, seems fine.” There is always a bias. Your job is to figure out what it is. ! Asking the question is a great way to start. Beyond that, I suggest that you learn about as many specific cognitive biases as you can, so that your brain can do what it does, which is to look for patterns and classify and make associations. ! If you’re not checking your work for bias, you can look right past a great solution, and you'll never even know it was there. 48
  46. 46. 3.AMAZING HACK I have an example of a solution that is simple, elegant, and just about the last thing I ever would have thought of. 49
  47. 47. PAC-MAN Let’s talk about Pac-Man. If you’ve never played it, this is a very simple game where you run around a maze trying to avoid four ghosts. ! Now, playing games is fun, but we’re programmers; we want to know how things work. So let’s talk about programming Pac-Man. 50
  48. 48. PROGRAMMING PAC-MAN For the purposes of this discussion, we'll just consider three things: ! [REVEAL EACH] the Pac Man, the ghosts, and the maze. ! - The Pac Man is controlled by the player, so that code is basically hardware events. Boring. [HIDE] - The maze is there so that the player has some chance at avoiding the ghosts. Boring. [HIDE] ! But the ghost AI is what’s going to make or break the game, and that’s where we get to have some fun. 51
  49. 49. GHOST AI To keep things simple, let’s start with one ghost. How do we program its movement? 52
 AT EVERY OBSTACLE We could choose a random direction and follow it until we hit a wall, then choose another random direction. This is fairly easy to implement, but it’s not much of a challenge for the player. 53
  51. 51. GHOST AI MINIMIZE LINEAR DISTANCE We could compute the distance to the Pac Man in the X and Y axes, and pick a direction that makes one of those smaller... but then the ghost will get stuck in corners or behind walls, and again, it'll be too easy for the player. 54
  52. 52. GHOST AI MINIMIZE TOPOLOGICAL DISTANCE So how about, instead of minimizing linear distance, we focus on topological distance? We could compute all possible paths through the maze to the Pac Man, pick the shortest one, and start down it. Then, next tick, do it all again. ! This works fine for one ghost. But if all four ghosts use this algorithm, they'll wind up chasing after the player in a tight little bunch instead of fanning out. 55
  53. 53. GHOST AI MINIMIZE TOPOLOGICAL DISTANCE, PRUNING PATHS THROUGH ALLIES Okay, so each ghost can compute all possible paths to the Pac Man, and reject any path that goes through another ghost. This means our ghosts have to keep track of each other as well as the Pac-Man, but this seems doable… right? ! Quick show of hands: how many people would approach this problem more or less the way I just walked through it? I certainly would. ! So… 56
  54. 54. HOW IS THIS BIASED? …how is this biased? ! Well, the best way I have to explain the bias in this solution is to walk you through a very different solution. 57
 SYSTEMS, LANGUAGES AND APPLICATIONS OOPSLA In 2006, I attended OOPSLA as a student volunteer, and I happened to sit in on a presentation by [ADVANCE] Alexander Repenning of the University of Colorado. 58
  56. 56. ALEXANDER REPENNING UNIVERSITY OF COLORADO COLLABORATIVE DIFFUSION: PROGRAMMING ANTIOBJECTS In his presentation, Professor Repenning walked through the Pac-Man problem, then presented this idea: give the Pac Man a smell, and model the diffusion of that smell throughout the environment. ! In the real world, smells travel through the air, but we don’t need to model each individual air molecule. What we can do is divide the environment up into reasonably-sized logical chunks, and model the average concentration of scent molecules in each chunk. ! Remember when I said the maze was boring? I lied. As it turns out, the tiles of the maze already divide up the environment for us. They’re not really doing anything else, so we can borrow them as a convenient container for this computation. 59
  57. 57. METAPHOR: DIFFUSION •Pac-Man gives floor tile a smell •Each floor tile passes some of that smell to its neighbors Here’s what we do: we say that the Pac-Man gives whatever floor tile it’s standing on [REVEAL] a "Pac-Man smell" value of, say, 1000. The number doesn’t really matter. ! [REVEAL] That tile then passes a smaller value off to each of its neighbors, and they pass an even smaller value off to their neighbors, and so on. ! Iterate a few times, and we get a diffusion contour that we can visualize as a hill with its peak centered on the Pac- Man. 60
  58. 58. DIFFUSION CONTOUR It’s a little hard to see here, but the Pac-Man is at the bottom of that big yellow bar. ! [CLICK TO PLAY; WAIT 7-8 SECONDS] ! So we’ve got the Pac-Man, and we’ve got the floor tiles passing the Pac-Man smell around. But to make it a maze, we need some walls. The wall tiles have a hard-coded “Pac-Man smell" value of zero, which chops the hill up a bit... 61
  59. 59. WALLS BLOCK DIFFUSION [WAIT ~13 seconds] ! And now, all our ghost has to do is climb the hill. 62
  60. 60. GHOST “AI”: HILL CLIMBING •Sample each adjacent floor tile •Move to the one with the strongest smell •Ghosts cancel “Pac-Man smell” •Intelligent cooperation
 without explicit knowledge! We program our ghost to: - [REVEAL] sample each of the floor tiles next to it, - [REVEAL] pick the one with the biggest number, and go that way. ! It barely seems worthy of being called AI! ! But check this out. When we add more ghosts to the maze, we only have to make one change to get them to cooperate. And interestingly, we don't change the ghost's movement behaviors at all. Instead, [REVEAL] we have the ghosts tell the floor tile they’re standing on that its “Pac-Man smell” value is zero. ! This effectively turns the ghosts into moving walls, so that when one ghost cuts off another one, the second ghost will automatically choose a different path. [REVEAL] This lets the ghosts cooperate without even being aware of each other. ! Halfway through the conference session where I saw this, I was just... 63
  61. 61. …what? ! At first, I was just really surprised by the simplicity of the approach. But then what really messed with my head was the realization that… I never would have thought of this. ! I hope that looking at the second solution makes it easier to see [ADVANCE] the bias in the first solution. 64
  62. 62. BIAS? •“Body syntonic” reasoning… •Leads us to make the pursuer “smarter” •Biases us toward “foreground” objects For most of us, our first instinct is to imagine ourselves as the ghost. This is the [REVEAL] “body syntonic” reasoning that’s designed into Logo, and in this case, it’s a trap—because it leads us to solve the pursuit problem by making the pursuer [REVEAL] “smarter”. ! Once we’ve started down that road, it’s unlikely to occur to us to consider a radically different approach, even if— perhaps especially if—it’s a much simpler one. ! Body syntonicity biases us towards modeling [REVEAL] objects in the “foreground” rather than objects in the “background”. ! Does this mean you shouldn’t use body syntonic reasoning? Of course not. It’s a tool. It’s right for some jobs, but not for others. ! Let's take another look at one more technique from Part 1. 65
  63. 63. BIAS:“PLEASE, MR. GEAR...” What's the bias in "Please, Mr. Gear, what is your ratio?" ! Well, it’s androcentric, for one. [ADVANCE] But more interestingly… 66
  64. 64. BIAS:“PLEASE, MR. MS. GEAR...” •“Please, Ms. Pac-Man,
 what is your current position in the maze?” •“Please, Ms. FloorTile,
 how much do you smell like Ms. Pac-Man?” This technique is explicitly designed to give you an opportunity to discover new objects in your model. The trap in this technique is that it requires a name, and names have gravity. Because our brains are associative, the new objects you discover with this technique will probably acquire names that are related to the ones you already have. ! Here’s what I mean: how many steps does it take to get from [REVEAL] "Please, Ms. Pac-Man, what is your current position in the maze?" ! [REVEAL] "Please, Ms. Floor Tile, how much do you smell like Ms. Pac Man?" ! For a lot of people, the answer is probably “infinity.” My guess is that you don’t come up with this technique unless you’ve already done some work modeling diffusion in some other context. ! Which, incidentally, is why I like to work on diverse teams: the more different backgrounds and perspectives we have access to, the more chances we have to find a novel application of a seemingly unrelated technique. ! [PAUSE] 67
  65. 65. DENOUEMENT It can be exhilarating and empowering to find techniques that let us take shortcuts by leveraging specialized structures in our brains. ! But those structures themselves take shortcuts—and if you’re not careful, they can lead you down a primrose path. ! Here’s that quote that got me thinking about all of this in the first place. 68
  66. 66. “... 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.” ! -GlennVanderburg, Ruby Rogues #77 Ultimately, I think we should use techniques like this. I think we should share them. I think, to paraphrase Glenn, we should teach people that this is a thing you can and should do. ! And... 69
  67. 67. HOW IS THIS BIASED? I think we should teach people that: looking critically at the answers these techniques give you is also a thing you can and should do. We might not always be able to come up with a radically different and simpler approach, but the least we can do is give ourselves the opportunity to do so, by asking: “how is this biased?” 70
  68. 68. <3 ADA.cohorts[0] Avdi Grimm Charles Max Wood Chris Morris David Brady David Woodall ! GlennVanderburg James Edward Gray II Katrina Owen Kerri Miller LivingSocial Peter Dore Rodrigo Franco Sandi Metz Sara Flemming SaronYitbarek Sean McHugh Sonia Connolly Steve Jorgensen Tim Linquist Thank you to everyone who helped me with this talk, or with the ideas in it. ! I look forward to hearing your ideas as well. Thank you. 71