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

COGNITIVE SHORTCUTS:
MODELS, VISUALIZATIONS,
METAPHORS, AND OTHER LIES
Friday, April 25, 14
[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 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.

“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 ...”
-GlennVanderburg, Ruby Rogues #77
Now, I normally prefer the kind of talk where the speaker just launches
right 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’re
all just as fried as I am. So, some background.
I got the idea for this talk when I was listening to the Ruby Rogues
podcast episode with Glenn Vanderburg. This is lightly edited for
length, 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 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 makes
perfect sense that you would wanna 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."
When I heard this, I started thinking about the times that I’ve stumbled
across some technique like this and been really excited to find some way
of translating some programming problem into a form that my brain could
really get a handle on, and I started thinking, “yeah! YEAH! Brains are
awesome, 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 if
we 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 rope
the physical and sensory parts of your brain—as well as some
other parts I’ll talk about—into helping you deal with abstractions.
Part 2: Brains are horrible, and they lie to us all the time. But
if 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 you
just might be able to come up with.

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.
So, over the years, I’ve built up a small collection of shortcuts that
engage some specialized structures in my brain to help me reason
about programming problems.

VISUAL/SPATIAL REASONING
BOXES & ARROWS
There's an entire category of visual tools that let us leverage
our spatial reasoning skills to discover relationships between
different parts of a model, or to stay oriented while we’re
trying to reason through a complex problem.
I’m just going to list a few examples quickly, 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.

http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
ENTITY-RELATIONSHIP DIAGRAM
There are Entity-Relationship diagrams, which help us
understand 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 like
linked 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 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.
There are three things I like about boxes and arrows:
First, they lend themselves really well to standing up in front of
a whiteboard, possibly with some colleagues, and just moving
around a bit helps wake your brain up a little bit.
Second, diagrams let us offload some of the work of keeping track
of different concepts by attaching those concepts to objects in a
two-dimensional space—and our brains have a lot of hardware
support for keeping track of where things are in space.
Third, our brains are really good at pattern recognition, so visualizing
our designs can give us a chance to spot certain kinds of problems just
by looking at their shapes before we ever start typing code in an editor.

VISUAL/SPATIAL REASONING
THE SQUINT TEST
Here’s another technique that makes use of our spatial
perception skills: it’s called the squint test.
It’s very straightforward: you open up some code and either
squint your eyes at it, or decrease the font size. The point is
to 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
end
end
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 on
high-risk areas of code, or just to get oriented in a new codebase.
Here are a few speciﬁc 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 ﬁle mostly regular, but with a big gnarly mess in one section?
Incidentally, I’ve only ever met one blind programmer, and we didn’t
talk about this stuff. If any of you have found that a physical or cognitive
disability has helped give you a different perspective on understanding
code, please come talk to me; I would love to hear your story and geek
out about this stuff with you.

LINGUISTIC REASONING
I also have a couple of techniques that involve the clever use of language.
The ﬁrst 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 away
with using the souvenir edition.
What you do is, you keep a rubber duck on your desk. When
you 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 process
of putting your problem into words, you’ll realize that you’ve
been making an incorrect assumption, or you’ll think of another
potential solution.
I’ve also heard of people using teddy bears or other stuffed
animals. One of my coworkers said she learned this as the
“pet rock” technique, and also said that she ﬁnds it useful to
compose 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, “Practical
Object-Oriented Design in Ruby”—POODR for short—she describes a
technique she uses to ﬁgure out what object a method should belong to.
I tried paraphrasing this, but honestly, Sandi did a much better job
describing 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 Metz
Practical Object-Oriented Design in Ruby
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.

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
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.
This is a great way to evaluate objects in light of
the Single Responsibility Principle, and I’ll come
back to this idea later. But ﬁrst...

•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
feel right. Both of them force us to put our questions into
words... 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 behaviors
for getting our needs met as part of a community. So while these
techniques do involve the language centers of our brain, I think
they 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 problem
into words forces you to organize your understanding of the
problem in such a way that you can verbally lead another mind
through it.
And "Please, Mr. Gear..." lets us anthropomorphize an object
and talk to it to discover whether it conforms to the Single
Responsibility 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 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, and gives us an opportunity to notice that a particular
question doesn’t ﬁt with any of our existing objects, and ask if we should
create a new object instead.
Personally, I would've considered POODR to have been worthwhile
if “Please, Mr. Gear...” was the only thing I learned from it. But Sandi
also 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 object
should be responsible for a particular method, a sequence
diagram can help you analyze the runtime interaction between
several objects.
At ﬁrst glance, this looks like something in the “boxes and arrows”
category of visual/spatial tools, but to me, this feels more like it's
tapping into that social understanding again: this can be a good
way to get a sense for when an object is bossy, or for when performing
a 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 go
buy Sandi’s book. If for whatever reason you can’t afford it, come
talk 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 some
point, but most of the rendering systems I've used are based on a
Cartesian coordinate system. This metaphor encourages the
programmer to imagine themselves as the turtle and use that
understanding to ﬁgure out what to do next. One of the original
creators of Logo called this [ADVANCE] "body syntonic reasoning"...

http://commons.wikimedia.org/wiki/File:TurtleGraphics1.png
BODY SYNTONIC REASONING
...and speciﬁcally developed it to help children solve problems.
But the turtle metaphor works for everyone, not just kids.
Cartesian grids are great for drawing boxes.

CSS
is
awesome
http://www.codeproject.com/Articles/117957/Turtle-Graphics-and-L-systems-with-F-and-WPF
http://docs.python.org/3/library/turtle.html
http://smackerelofopinion.blogspot.com/2013/12/infinite-snowflake.html
http://programmingpraxis.com/2012/01/03/turtle-graphics/
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.

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 what
he 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 sends
messages to other objects—where information ﬂows east—is easier
to extend and maintain than code that looks at data and decides
what to do with it—where information ﬂows 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.
In fact, there are plenty of ways we can use our background-level
awareness to analyze our code.

http://www.ﬂickr.com/photos/sherwood411/9052151857/
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... 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 social
awareness, to give a name to a pattern of dysfunction, and—by
naming the problem—to suggest a possible solution.

COGNITIVE SHORTCUTS
•Boxes & Arrows
•SquintTest
•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 for
some 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 justiﬁed.
Evolution does one thing, and one thing only: it selects for
traits that help an organism stay alive long enough to reproduce.
It 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.

HUMAN VISION
As an example, let’s take a minute to talk about
how 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. These
play little or no role in color perception and are mostly
used 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 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.

http://www.cambridgeincolour.com/tutorials/cameras-vs-human-eye.htm
As a result, our vision is extremely directional. We have a
very small area of high detail and high color, and the rest
of our ﬁeld 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 on
the right, our brains are doing a lot of work that we’re
mostly unaware of.

http://www.leahstahl.com/connected.html
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 ﬁfth of a second.
What I ﬁnd 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.”

“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
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 reﬂection 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.
...aaand now I have to wait a moment while everyone ﬁnishes glancing
around the room, or you’ll all miss the next part. :)
When I was preparing this talk, I found an absolutely wonderful 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 hides the evidence that anything
has been hidden."

“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
"HIDES THE EVIDENCE THAT ANYTHING HAS BEEN HIDDEN."
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, you got distracted by all the pretty
colors. 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 ﬁfth of a second.
I wanted to talk about this partly because it’s a really fun
subject, but also to show just one way that our brains are
doing a massive amount of work to process information
from our environment and present us with an abstraction.

http://www.cambridgeincolour.com/tutorials/cameras-vs-human-eye.htm
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?

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.

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
Google effect
Group attribution error
Halo effect
Hard-easy effect
Hindsight bias
Hostile media effect
Hot-hand fallacy
Humor effect
Hyperbolic discounting
Identifiable victim effect
Cognitive bias is a term for systematic errors in thinking: 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”
and—I kid you not—the “IKEA 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.”

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]
“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.”
...sound like anyone you know?

{{
Screenshot image of tweet by DHH: “TIL about the
Dunning-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.

HERE IS A PICTURE OF MR. SPOCK.
YOUR ARGUMENT IS INVALID.
https://ﬂickr.com/photos/39039799@N04/3589716749/in/gallery-48528847@N04-72157628424835507/
In our ﬁeld, we like to think of ourselves as more rational than the
average person, and it just isn’t true.
Yes, we have a valuable, marketable skill that depends on our ability
to reason mathematically. But we do ourselves and others a disservice
if we allow ourselves to believe that being good at programming means
anything more than “we’re good at programming.”
As humans, we’re all biased. It’s built into us. Pretending that we
aren’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, but
an obvious and necessary ﬁrst step is just to ask the question:
“how is this biased?”
Beyond that, I suggest that you learn about as many speciﬁc
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.
I think everyone should understand their own biases, because
only by knowing how you're biased can you then decide how to
correct for that bias in the decisions that you make.
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.

3. AMAZING HACK
For part 3 of my talk, I have an example of a solution that is
simple, elegant, and just about the last thing I ever would have
thought 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 first
gray hair, Pac-Man was a video game released in the fall of 1980
that let people maneuver around a maze eating dots while 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.

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 the
player, so that code is basically responding to hardware events. [HIDE]
The maze is there so that the player has some chance at avoiding the
ghosts. [HIDE]
But the ghost AI is what’s going to make the game interesting enough
that 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 we
program 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 the
ghost will get stuck in corners or behind walls, and again, it'll be too
easy for the player.
[REVEAL]
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 ﬁne 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.
[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 be

BIAS?
I don’t have a statistically valid sample, but my guess is that
when asked to design an AI for the ghosts, a lot of programmers
would go through more or less the thought process I just walked
through.
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 you
through a very different solution...

OBJECT-ORIENTED PROGRAMMING
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.

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

http://youtu.be/RaDAROMGiYA
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]
So we’ve got the Pac-Man, and we’ve got the ﬂoor 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, which
chops 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 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 changes the shape of the diffusion contour. Now, instead of
a smooth hill that always slopes down away from the Pac Man, there
are cliffs where the hill drops immediately to zero. In effect, we turn
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 needing to be
aware of each other.
Halfway through the conference session where I saw this, I was just...

{{ Image: Jackie Chan captioned “MIND = BLOWN” }}
At ﬁrst, I was just really surprised by this approach,
but as I sat there, I became absolutely stunned by how
surprised I was.
I hope that looking at the second solution makes it easier to see
[ADVANCE] the bias in the ﬁrst 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 challenge
to 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 in
this case, it’s a trap—because it leads us to solve the pursuit
problem by making the pursuer “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.
In other words, 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.

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. 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. But it only works after you’ve
given at least one of those objects a name.
Names have gravity. Metaphors can be tar pits. It’s very likely
that the new objects you discover will acquire names that are
related 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 “inﬁnity.” 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 ﬁnd a novel application of a seemingly unrelated
technique.

DENOUEMENT
It can be exhilarating and empowering to ﬁnd 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.
Let’s go back to that quote that got me thinking about this
in the ﬁrst place.

“... But the work we do as programmers is all abstract. And
it makes perfect sense that you would want to ﬁnd 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 paraphrase
Glenn, we should teach people that this is a thing
you can and should do.
And...
I think we should teach people that looking critically at
the answers these techniques give you is also a thing that
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 an opportunity
by asking: “how is this biased?”

<3
Ada Developers Academy,
inaugural cohort of
Avdi Grimm
Chris Morris
David Brady
David Woodall
GlennVanderburg
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 paying
for my trip.

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (9)

En vedette

En vedette (20)

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

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

Dernier

Dernier (20)

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