Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies (RailsConf 2014)

COGNITIVE SHORTCUTS:MODELS, VISUALIZATIONS,

METAPHORS, AND OTHER LIES

Friday, April 25, 14

IF YOU CAN READ THIS,I NEED TO PRESS THE ‘X’ KEY!preflight checklist:

- thumb drive with PDF - designate a helper in the front row- lanyard off- phone in airplane mode- props! - rubber duck - POODR- USB mic(?)- Start ScreenFlow recording

[WHEN READY]

Hello, and welcome to the very last session!

I have a few items of business before I launch into the presentation proper.


I work for LivingSocial. We are hiring. If this fact is intriguing to you,feel free to ask me for more details after the talk.

[PROP: BRAINS!]

Also, by an amazing coincidence, our recruiters brought a ton ofsquishy stress balls in the form of these little orange brains. I have awhole bag of the things up here, so if you’d like an extra brain, orthree, come get some.

ACCESSIBILITYSLIDES: [INSERT URL HERE]

TODO: UPLOAD SLIDES


If you have any trouble seeing my slides, hearing my voice, orfollowing my train of thought—or if you just like spoilers—youcan get a PDF with both my slides and my script at:[TODO: UPLOAD PDF AND MAKE A MEMORABLE TINYURL].

I’ll leave this URL up for a moment.

[IF YOU SAVED TO A THUMB DRIVE]I’ve also got it up here on a thumb drive because conference wifi.I’m going to hand it to [DESIGNATED HELPER]; please come askthem if you need it.

I also want to call your attention to the Opportunity Scholarship program.Opportunity Scholars not only get admission to the conference, they alsoget matched up with a cocky conference veteran who can help them figureout how to get the most out of their time here.

I am a huge fan of this program. I think this is a great way to welcomenew people and new voices into our community. This is the second yearI’ve volunteered as a Guide, and both times I’ve met someone with afascinating story. If you’re a seasoned conference-goer, I strongly encourageyou to apply to participate next year as a Guide.

COGNITIVE SHORTCUTS:MODELS, VISUALIZATIONS,

METAPHORS, AND OTHER LIES


[TAKE A DEEP BREATH!]

Programming is hard. I mean, it’s not [ADVANCE] quantum physics...

http://fathom-the-universe.tumblr.com/post/56500448933/who-is-schrodingers-cat-no-doubt-schrodingers

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".

Existing in thought or as an idea but not having a physical or

concrete existence

ABSTRACT


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 nothaving a physical or concrete existence".

I usually prefer defining things in terms of what they are, but in thiscase I find the negative definition extremely telling. Abstract thingsare hard for us to think about precisely because they don't have aphysical or concrete existence.

“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 that sensory input ...”

-Glenn Vanderburg, Ruby Rogues #77


Now, I normally prefer the kind of talk where the speaker just launchesright into it and forces me to keep up. But this is a complex idea,and this being the last talk of the last day of RailsConf, I’m sure you’reall just as fried as I am. So, some background.

I got the idea for this talk when I was listening to the Ruby Roguespodcast episode with Glenn Vanderburg. This is lightly edited forlength, but basically, Glenn said: [REVEAL]

"the best programmers I know all have some good techniques forconceptualizing or modeling programs they work with. And it tends to besort of a spatial/visual model but not always. What's going on is thatour brains are geared towards the physical world and dealing with oursenses and integrating that sensory input."

“... 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.”



"But the work we do as programmers is all abstract. And it makesperfect sense that you would wanna find techniques to rope thephysical, sensory parts of your brain into this task of dealing withabstractions. But we don’t ever teach anybody how to do that, oreven that they should do that."

When I heard this, I started thinking about the times that I’ve stumbledacross some technique like this and been really excited to find some wayof translating some programming problem into a form that my brain couldreally get a handle on, and I started thinking, “yeah! YEAH! Brains areawesome, and we should be teaching people that this is a thing they can do!”

Some time later, I thought... “wait a minute. No. Brains are horrible,and teaching people these tricks would be horribly irresponsible ifwe didn’t also warn them about cognitive bias!”

1. Brains are awesome! You can take shortcuts through the hard work of programming by engaging specialized regions of your brain.

2. Brains are horrible! They lie to us all the time! But if you watch out for cognitive biases...

3. ...you just might be able to pull off an amazing hack.


This is a talk in three parts:

[REVEAL EACH]

Part 1: Brains are awesome, and as Glenn said, you can ropethe physical and sensory parts of your brain—as well as someother parts I’ll talk about—into helping you deal with abstractions.

Part 2: Brains are horrible, and they lie to us all the time. Butif you’re on the lookout for the kinds of lies your brain tells you...

In part 3, I have an example of the kind of amazing hack that youjust might be able to come up with.

1. BRAINS ARE AWESOME


Our brains are extremely well-adapted for dealing with the physicalworld. Our hindbrains, which regulate respiration, temperature, andbalance, have been around for half a billion years or so.

But when I write software, I’m leaning hard on parts of the brainthat are relatively new in evolutionary terms, and I’m using somerelatively expensive resources.

So, over the years, I’ve built up a small collection of shortcuts thatengage some specialized structures in my brain to help me reasonabout programming problems.

VISUAL/SPATIAL REASONINGBOXES & ARROWS


There's an entire category of visual tools that let us leverageour spatial reasoning skills to discover relationships betweendifferent parts of a model, or to stay oriented while we’retrying to reason through a complex problem.

I’m just going to list a few examples quickly, because I thinkmost developers are likely to encounter these tools, either inschool or on the job, and they all have the same basic shape:they’re boxes and arrows.

http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

ENTITY-RELATIONSHIP DIAGRAM


There are Entity-Relationship diagrams, which help usunderstand how our data is modeled...

http://en.wikipedia.org/wiki/Self-balancing_binary_search_tree

DATA STRUCTURE DIAGRAM


We use diagrams to describe data structures likelinked lists, binary trees, and so on...

http://commons.wikimedia.org/wiki/File:Finite-state-transducer-comments.png

STATE MACHINE DIAGRAM


And for state machines of any complexity, diagrams are oftenthe only way to make sense of them.

I could go on, but like I said, most of us are probably used tousing these kinds of tools as at least an occasional part of our jobs.

There are three things I like about boxes and arrows:

First, they lend themselves really well to standing up in front ofa whiteboard, possibly with some colleagues, and just movingaround a bit helps wake your brain up a little bit.

Second, diagrams let us offload some of the work of keeping trackof different concepts by attaching those concepts to objects in atwo-dimensional space—and our brains have a lot of hardwaresupport for keeping track of where things are in space.

Third, our brains are really good at pattern recognition, so visualizingour designs can give us a chance to spot certain kinds of problems justby looking at their shapes before we ever start typing code in an editor.

VISUAL/SPATIAL REASONINGTHE SQUINT TEST


Here’s another technique that makes use of our spatialperception skills: it’s called the squint test.

It’s very straightforward: you open up some code and eithersquint your eyes at it, or decrease the font size. The point isto look past the words to the shape of the code.

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(@installation.city.timezone).to_date 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 endend


Here’s a pathological example I used in a refactoring talk last year.

You can use this as an aid to navigation, as a way of zeroing in onhigh-risk areas of code, or just to get oriented in a new codebase.

Here are a few specific patterns you can look for:- Is the left margin ragged?- Are there any ridiculously long lines?- What does your syntax highlighting suggest? Are there big areas of strings, or hashes, or a big pile of constant declarations?- Is the file mostly regular, but with a big gnarly mess in one section?

Incidentally, I’ve only ever met one blind programmer, and we didn’ttalk about this stuff. If any of you have found that a physical or cognitivedisability has helped give you a different perspective on understandingcode, please come talk to me; I would love to hear your story and geekout about this stuff with you.

LINGUISTIC REASONING


I also have a couple of techniques that involve the clever use of language.

The first one is deceptively simple, but it does require a prop...

http://en.wikipedia.org/wiki/Rubber_duck

LINGUISTIC REASONING:RUBBER DUCK


[PROP: RUBBER DUCK]

It doesn’t have to be quite that big. You can totally get awaywith using the souvenir edition.

What you do is, you keep a rubber duck on your desk. Whenyou get stuck, you put the rubber duck on top of your keyboard,and you explain your problem, out loud, to the duck.

It sounds absurd, but there's a good chance that, in the processof putting your problem into words, you’ll realize that you’vebeen making an incorrect assumption, or you’ll think of anotherpotential solution.

I’ve also heard of people using teddy bears or other stuffedanimals. One of my coworkers said she learned this as the“pet rock” technique, and also said that she finds it useful tocompose an email describing the problem.

[PAUSE WHILE YOU RETRIEVE PROP: POODR]

http://en.wikipedia.org/wiki/Bicycle_gearing

LINGUISTIC REASONING:“PLEASE, MR. GEAR...”


The other linguistic hack I got from Sandi Metz. In her book, “PracticalObject-Oriented Design in Ruby”—POODR for short—she describes atechnique she uses to figure out what object a method should belong to.

I tried paraphrasing this, but honestly, Sandi did a much better jobdescribing this than I can, so I’m just going to read it...

“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 MetzPractical Object-Oriented Design in Ruby


How can you determine if the Gear class containsbehavior that belongs somewhere else? One wayis 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.

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 MetzPractical Object-Oriented Design in Ruby


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)?" isjust downright ridiculous.

This is a great way to evaluate objects in light ofthe Single Responsibility Principle, and I’ll comeback to this idea later. But first...

•Rubber Duck

•“Please, Mr. Gear, what is your ratio?”

LINGUISTIC REASONING


I described the rubber duck and “Please, Mr. Gear...” astechniques to engage linguistic reasoning, but that doesn'tfeel right. Both of them force us to put our questions intowords... but words themselves are tools.

We use words to communicate our ideas with other people.

As primates, we've evolved a set of social skills and behaviorsfor getting our needs met as part of a community. So while thesetechniques do involve the language centers of our brain, I thinkthey reach beyond that to tap into our [ADVANCE] social reasoning.

•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 probleminto words forces you to organize your understanding of theproblem in such a way that you can verbally lead another mindthrough it.

And "Please, Mr. Gear..." lets us anthropomorphize an objectand talk to it to discover whether it conforms to the SingleResponsibility Principle.

To me, the telltale 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 beappropriate to ask Alice about something that is Bob’s responsibility.Interrogating an object as though it were a person helps us use thatsocial knowledge, and gives us an opportunity to notice that a particularquestion doesn’t fit with any of our existing objects, and ask if we shouldcreate a new object instead.

Personally, I would've considered POODR to have been worthwhileif “Please, Mr. Gear...” was the only thing I learned from it. But Sandialso made what I thought was a very compelling case for [ADVANCE]UML sequence diagrams.

VISUALIZING SOCIAL INTERACTION:UML SEQUENCE DIAGRAMS


Where "Please, Mr. Gear..." is good for discovering which objectshould be responsible for a particular method, a sequencediagram can help you analyze the runtime interaction betweenseveral objects.

At first glance, this looks like something in the “boxes and arrows”category of visual/spatial tools, but to me, this feels more like it'stapping into that social understanding again: this can be a goodway to get a sense for when an object is bossy, or for when performinga task involves a precise sequence of several complex interactions, or if there are just too many different actors to keep track of.

Rather than turn this into a lecture on UML, I’ll just tell you to gobuy Sandi’s book. If for whatever reason you can’t afford it, cometalk to me; we’ll work something out.

METAPHORS


Now for the really handwavy stuff.

Metaphors can be a very useful tool in software.

http://commons.wikimedia.org/wiki/File:TurtleGraphics1.png

SPATIAL METAPHOR:TURTLE GRAPHICS


The turtle graphics system in Logo is a great metaphor.

We've probably all played with drawing stuff on the screen at somepoint, but most of the rendering systems I've used are based on aCartesian coordinate system. This metaphor encourages theprogrammer to imagine themselves as the turtle and use thatunderstanding to figure out what to do next. One of the originalcreators of Logo called this [ADVANCE] "body syntonic reasoning"...

http://commons.wikimedia.org/wiki/File:TurtleGraphics1.png

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.

CSSisawesome

http://www.codeproject.com/Articles/117957/Turtle-Graphics-and-L-systems-with-F-and-WPFhttp://docs.python.org/3/library/turtle.html

http://smackerelofopinion.blogspot.com/2013/12/infinite-snowflake.htmlhttp://programmingpraxis.com/2012/01/03/turtle-graphics/


Well, mostly great.

But it can take some very careful thinking to figure out howto 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 botheringwith.

http://commons.wikimedia.org/wiki/File:Maury_Geography_005A_compass.jpg

METAPHOR:“EAST-ORIENTED CODE” (JAMES LADD)


James Ladd has a couple of interesting blog posts about whathe calls “east-oriented code”.

Imagine a compass overlaid on your code.

class LineItem

def item

def description

def quantity

def amount

end

class Invoice def total line_items_total + taxes end

# ...

def line_items_total @line_items.sum(&:amount) end

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 sendsmessages to other objects—where information flows east—is easierto extend and maintain than code that looks at data and decideswhat to do with it—where information flows west.

Really, this is just the design principle “Tell, Don’t Ask”, but the metaphorof the compass recasts it in a way that lets us use our background spatialawareness to keep the principle in mind.

In fact, there are plenty of ways we can use our background-levelawareness to analyze our code.

http://www.flickr.com/photos/sherwood411/9052151857/

METAPHOR: CODE SMELLS


Code smells are an entire category of metaphors that we use totalk about our work. In fact, the name “code smell” is itself ametaphor for anything about your code that hints at a designproblem.

I guess that makes it a... meta-metaphor?

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 socialawareness, to give a name to a pattern of dysfunction, and—bynaming the problem—to suggest a possible solution.

COGNITIVE SHORTCUTS

•Boxes & Arrows

•Squint Test

•Rubber Duck

•"Please, Mr. Gear..."

•UML Sequence Diagrams

•Metaphors:

•Turtle Graphics

•East-Oriented Code

•Code Smells


These are most of the shortcuts I’ve accumulated over the years,and I hope that this can be the start of a similar collection forsome of you.

2. BRAINS ARE HORRIBLE


And now, the part where I try to put The Fear into you.

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 fortraits that help an organism stay alive long enough to reproduce.It doesn’t care about getting the best solution—only one that’sgood enough to compete. Evolution will tolerate any hack as longas it meets that one goal.

HUMAN VISION


As an example, let’s take a minute to talk abouthow we see the world around us.

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. Theseplay little or no role in color perception and are mostlyused for night-time and peripheral vision.

[REVEAL]There are also about 6 or 7 million cone cells in each eye;these give us color vision and require a lot more light.

The vast majority of the cone cells are packed together ina tight little cluster near the center of the retina. This areais what we use to focus on individual details, and it’s smallerthan you might think: it’s only about 15 degrees wide.

http://www.cambridgeincolour.com/tutorials/cameras-vs-human-eye.htmFriday, April 25, 14

As a result, our vision is extremely directional. We have avery small area of high detail and high color, and the restof our field of vision is mostly monochrome.

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 onthe right, our brains are doing a lot of work that we’remostly unaware of.

http://www.leahstahl.com/connected.html

SACCADES


We compensate for having such highly directional visionby moving our eyes around a lot. Our brains combine thedetails from these individual points of interest to constructa 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 humanbody can make: the shorter saccades you make when you'rereading typically last for 20 to 40 milliseconds. Longer onesmight 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 thebrain, but what it’s sending is a smeary blur, so the brain justedits that part out.

This process is called [ADVANCE] “saccadic masking.”

“Due to saccadic masking, the eye/brain system not onlyhides the eye movements

from the individual but alsohides the evidence that anything

has been hidden.”

SACCADIC MASKING


You can see this effect for yourself next time you're in front of amirror: lean in close, and look back and forth from the reflection ofone eye to the other. You will not see your eyes move. As far as wecan tell, our gaze just jumps instantaneously from one referencepoint to the next.

...aaand now I have to wait a moment while everyone finishes glancingaround the room, or you’ll all miss the next part. :)

When I was preparing this talk, I found an absolutely wonderful sentencein the Wikipedia entry on saccades: [REVEAL]

"Due to saccadic masking, the eye/brain system not only hides the eyemovements from the individual but also hides the evidence that anythinghas been hidden."

“Due to saccadic masking, the eye/brain system not onlyhides the eye movements

from the individual but alsoHIDES THE EVIDENCE THAT ANYTHING HAS

BEEN HIDDEN.”

SACCADIC MASKING


"HIDES THE EVIDENCE THAT ANYTHING HAS BEEN HIDDEN."

Our brains lie to us. And then they lie to us about having lied tous. 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 youshifted your gaze around, you got distracted by all the prettycolors. You would be eaten by lions.

But in selecting for this design, evolution made a tradeoff.And the tradeoff is that we’re effectively blind every time we move our eyes—sometimes for up to a fifth of a second.

I wanted to talk about this partly because it’s a really funsubject, but also to show just one way that our brains aredoing a massive amount of work to process informationfrom our environment and present us with an abstraction.

http://www.cambridgeincolour.com/tutorials/cameras-vs-human-eye.htmFriday, April 25, 14

And as programmers, if we know anything about abstractions, it’sthat they’re hard to get right.

Which leads me to an interesting question: does it make sense touse any of the techniques I talked about earlier to try to corraldifferent parts of our brains into doing our work if we don’t knowwhat kinds of shortcuts they’re going to take?

BIAS


According to the Oxford English Dictionary, the word “bias” seemsto have entered the English language in the 1520s. It was used asa technical term in the game of lawn bowling, and it referred to aball that was made in such a way that it would roll in a curved pathinstead of in a straight line.

Since then, it’s picked up a few additional meanings, but theyall have that same basic connotation of something that’s skewedor off.

COGNITIVE BIAS

Actor-observer biasAmbiguity effectAnchoring or focalismAttentional biasAvailability cascadeAvailability heuristicBackfire effectBandwagon effectBase rate fallacyBelief biasBias blind spotBizarreness effectChange biasCheerleader effectChildhood amnesiaChoice-supportive bias

Clustering illusionConfirmation biasCongruence biasConjunction fallacyConservatism (Bayesian)Consistency biasContext effectContrast effectCross-race effectCryptomnesiaCurse of knowledgeDecoy effectDefensive attribution

hypothesisDenomination effectDistinction bias

Dunning-Kruger effectDuration neglectEgocentric biasEmpathy gapEndowment effectEssentialismExaggerated expectationExperimenter's or

expectation biasExtrinsic incentives biasFading affect biasFalse consensus effectFocusing effectForer effect

(aka Barnum effect)Framing effect

Frequency illusionFunctional fixednessFundamental attribution

errorGambler's fallacyGeneration effectGoogle effectGroup attribution errorHalo effectHard-easy effectHindsight biasHostile media effectHot-hand fallacyHumor effectHyperbolic discountingIdentifiable victim effect


Cognitive bias is a term for systematic errors in thinking: patternsof thought that diverge in measurable, predictable ways from theanswers that pure rationality would give.

When you have some free time, go have a look at the Wikipedia pagecalled “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 codesmells I showed earlier. A lot of the names are very literal, but thereare a few that stand out, like “Curse of knowledge” or the “Google effect”and—I kid you not—the “IKEA effect”.

The parallel goes deeper than that, though: this list gives names topatterns of dysfunction, and once you have a name for a thing, it’smuch 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.”

BIAS BLIND SPOT

The tendency to see oneself as less biased than other people,

or to be able to identifymore cognitive biases in others

than in oneself


This is [REVEAL]

“the tendency to see oneself asless biased than other people,or to be able to identifymore cognitive biases in othersthan in oneself.”

...sound like anyone you know?


{{Screenshot image of tweet by DHH: “TIL about theDunning-Kruger effect, tinyurl.com/yb627mf — this explains a lot.”}}

DUNNING-KRUGER EFFECT

An effect in which incompetent people fail to realize they are

incompetent because they lack the skill to distinguish between

competence and incompetence.



{{Screenshot image of tweet by DHH: “TIL about theDunning-Kruger effect, tinyurl.com/yb627mf — this explains a lot.”}}

HERE IS A PICTURE OF MR. SPOCK.YOUR ARGUMENT IS INVALID.

https://flickr.com/photos/39039799@N04/3589716749/in/gallery-48528847@N04-72157628424835507/Friday, April 25, 14

In our field, we like to think of ourselves as more rational than theaverage person, and it just isn’t true.

Yes, we have a valuable, marketable skill that depends on our abilityto reason mathematically. But we do ourselves and others a disserviceif we allow ourselves to believe that being good at programming meansanything more than “we’re good at programming.”

As humans, we’re all biased. It’s built into us. Pretending that wearen’t biased only allows our biases to run free.

LOOKING FOR BIAS


I don’t have a lot of general advice for how to look for bias, butan obvious and necessary first step is just to ask the question:“how is this biased?”

Beyond that, I suggest that you learn about as many specificcognitive biases as you can, so that your brain can do what it does,which is to look for patterns and classify and make associations.

I think everyone should understand their own biases, becauseonly by knowing how you're biased can you then decide how tocorrect for that bias in the decisions that you make.

If you’re not checking your work for bias, you can look right past agreat solution, and you'll never even know it was there.

3. AMAZING HACK


For part 3 of my talk, I have an example of a solution that issimple, elegant, and just about the last thing I ever would havethought of.

http://www.spriters-resource.com/nes/pacman/sheet/15839

PAC-MAN


For the benefit of those of you who have yet to find your firstgray hair, Pac-Man was a video game released in the fall of 1980that let people maneuver around a maze eating dots while tryingto avoid four ghosts.

Now, playing games is fun, but we’re programmers; we want toknow how things work. So let’s talk about programming Pac-Man.

http://www.spriters-resource.com/nes/pacman/sheet/15839

PROGRAMMING PAC-MAN


For the purposes of this discussion, we'll just focus on three things:

[REVEAL EACH]the Pac Man, the ghosts, and the maze. The Pac Man is controlled by theplayer, so that code is basically responding to hardware events. [HIDE]

The maze is there so that the player has some chance at avoiding theghosts. [HIDE]

But the ghost AI is what’s going to make the game interesting enoughthat people keep dropping quarters into the slot.

GHOST AI

•Choose random direction at every obstacle

•Minimize linear distance

•Minimize topological distance

•Minimize topological distance, eliminating paths through allies


To keep things simple, let’s start with one ghost. How do weprogram its movement?

[REVEAL]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.

[REVEAL]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 theghost will get stuck in corners or behind walls, and again, it'll be tooeasy for the player.

[REVEAL]So how about, instead of minimizing linear distance, we focus ontopological distance? We could compute all possible paths throughthe 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 offanning out.

[REVEAL]Okay, so each ghost can compute all possible paths to the Pac Man,and reject any path that goes through another ghost. Shouldn’t betoo hard, right?

BIAS?


I don’t have a statistically valid sample, but my guess is thatwhen asked to design an AI for the ghosts, a lot of programmerswould go through more or less the thought process I just walkedthrough.

So how is this solution biased?

Well, I don’t have a good name for this concept.

The best way I have to communicate this idea to you is to walk youthrough a very different solution...

OBJECT-ORIENTED PROGRAMMINGSYSTEMS, LANGUAGES AND APPLICATIONS

OOPSLA


In 2006, I attended OOPSLA as a student volunteer, and I happenedto sit in on a presentation by[ADVANCE] Alexander Repenning of the University of Colorado.

ALEXANDER REPENNINGUNIVERSITY OF COLORADO

COLLABORATIVE DIFFUSION:PROGRAMMING ANTIOBJECTS


In his presentation, Professor Repenning walked through the Pac-Manproblem, then presented this idea: give the Pac Man a smell, and modelthe diffusion of that smell throughout the environment.

In the real world, smells travel through the air, but we don’t need tomodel each individual air molecule. What we can do is divide theenvironment up into reasonably-sized logical chunks, and model those.Coincidentally, we do already have an object that does us exactly that:the tiles of the maze itself. They’re not really doing anything else,so we can borrow them as a convenient container for this computation.

We program the game as follows:

METAPHOR: DIFFUSION

•Pac-Man gives floor tile a smell

•Each floor tile passes some of that smell to its neighbors


We say that the Pac-Man gives whatever floor tile it’s standing on[REVEAL] a "Pac-Man smell" value of, say, 1000. The numberdoesn’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 canvisualize as a hill with its peak centered on the Pac-Man.

http://youtu.be/RaDAROMGiYA

DIFFUSION CONTOUR


It’s a little hard to see here, but the Pac-Man is at the bottom ofthat big yellow bar.

[CLICK TO PLAY]

So we’ve got the Pac-Man, and we’ve got the floor tiles.But in order to make it a maze, we also have some walls.We give the walls a "pac-man smell" value of zero, whichchops the hill up a bit...

http://youtu.be/nm2v18eN5kU

WALLS BLOCK DIFFUSION


[WAIT]

And now, all our ghost has to do is climb the hill.

GHOST “AI”: HILL CLIMBING

•Sample each adjacent floor tile

•Move to the one with the strongest smell

•Ghosts cancel “Pac-Man smell”

•Free cooperation!


We program the first 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, does it?

But check this out. When we add more ghosts to the maze, we only haveto make one change to get them to cooperate. And interestingly, wedon'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-Mansmell” value is zero.

This changes the shape of the diffusion contour. Now, instead ofa smooth hill that always slopes down away from the Pac Man, thereare cliffs where the hill drops immediately to zero. In effect, we turnthe ghosts into moving walls, so that when one ghost cuts off anotherone, the second ghost will automatically choose a different path.[REVEAL] This lets the ghosts cooperate, without needing to beaware of each other.

Halfway through the conference session where I saw this, I was just...


{{ Image: Jackie Chan captioned “MIND = BLOWN” }}

At first, I was just really surprised by this approach,but as I sat there, I became absolutely stunned by howsurprised I was.

I hope that looking at the second solution makes it easier to see[ADVANCE] the bias in the first solution.

BIAS?

•“The challenge to find this solution is a psychological, not a technical one.” -Repenning

•“Body syntonic” reasoning...

•Biases us toward “foreground” objects


In his paper, Professor Repenning wrote [REVEAL] “the challengeto find this solution is a psychological, not a technical one.”

Our first instinct, when presented with the Pac-Man problem,is to imagine ourselves as the ghost. This is the [REVEAL]“body syntonic” reasoning that’s designed into Logo, and inthis case, it’s a trap—because it leads us to solve the pursuitproblem by making the pursuer “smarter”.

Once we’ve started down that road, it’s unlikely to occur to usto consider a radically different approach, even if—perhapsespecially if—it’s a much simpler one.

In other words, body syntonicity biases us towards modeling[REVEAL] objects in the “foreground” rather than objects inthe “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 notfor others.

Let's take another look at one more technique from Part 1.

BIAS: “PLEASE, MR. GEAR...”


What's the bias in "Please, Ms. Gear, what is your ratio?"

Aside from the gendered language, which is trivially easy to address...

BIAS: “PLEASE, MR. MS. GEAR...”

•“Please, Ms. Pac-Man,what is your current position in the maze?”

•“Please, Ms. Floor Tile,how much do you smell like Ms. Pac-Man?”


This technique is explicitly designed to give you an opportunity todiscover new objects in your model. But it only works after you’vegiven at least one of those objects a name.

Names have gravity. Metaphors can be tar pits. It’s very likelythat the new objects you discover will acquire names that arerelated to the ones you already have.

How many steps does it take to get from [REVEAL]"Please, Ms. Pac-Man, what is your current position in the maze?"

...to [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 guessis that you don’t come up with this technique unless you’ve alreadydone some work modeling diffusion in some other context.

Which, incidentally, is why I like to work on diverse teams: the moredifferent backgrounds and perspectives we have access to, the morechances we have to find a novel application of a seemingly unrelatedtechnique.

DENOUEMENT


It can be exhilarating and empowering to find techniques that let ustake shortcuts by leveraging specialized structures in our brains.

But those structures themselves take shortcuts—and if you’re notcareful, they can lead you down a primrose path.

Let’s go back to that quote that got me thinking about thisin the first place.

“... 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.”



Ultimately, I think we should use techniques like this.I think we should share them. I think, to paraphraseGlenn, we should teach people that this is a thingyou can and should do.

And...

I think we should teach people that looking critically atthe answers these techniques give you is also a thing thatyou can and should do. We might not always be able tocome up with a radically different and simpler approach,but the least we can do is give ourselves an opportunityby asking: “how is this biased?”

<3Ada Developers Academy,

inaugural cohort of

Avdi Grimm

Chris Morris

David Brady

David Woodall

Glenn Vanderburg

James Edward Gray

Katrina Owen

Kerri Miller

LivingSocial

Peter Dore

Rodrigo Franco

Sandi Metz

Sara Flemming

Sean McHugh

Sonia Connolly

Tim Linquist


Thank you to everyone who helped me with this talk,or with the ideas in it, and to LivingSocial for payingfor my trip.

Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies (RailsConf 2014)

Software

Transcript of Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies (RailsConf 2014)