My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
I was first introduced to the concept that choice could be a bad thing back in 2007 at NFJS in Austin, during Scott Davis's keynote.

It might have been obvious to me before then, had I paid attention to my own thoughts and actions. Instead, it took a little prodding and the knowledge that others experienced the same things I did to get me thinking about it.

I was reintroduced to the concept while listening to an episode of my favorite podcast what might be the best radio show on the planet, titled "Choice." Taking it in while traveling nowhere on my elliptical machine, I realized I had to share the podcast and its lessons with the rest of you.

The theme weaved by the lessons is that choice is not all it's cracked up to be. For programmers, I think this is especially so.


The more you have to remember, the worse decisions you make
In the episode, hosts Jad Abumrad and Robert Krulwich relate a story from Baba Shiv at the Stanford School of Business, whose research has to do with the brain and tricking people.

In one experiment, Shiv has subjects memorize a number (taking as much time as they want), then go to another room and recite the number.

Some people only have to memorize a two-digit number, while the others are supposed to remember a seven-digit one. The trickery comes in when the researchers interrupt the subjects on the way to the second room: "Excuse me? Sorry to interrupt you, but would you like a snack?"

The research subjects are then asked to choose between chocolate cake or fruit salad for their snack. The results show those who only need to remember two digits almost always choose the fruit, while the seven-digit club nearly always choose the cake.

The pair also discuss Barry Schwartz's book, The Paradox of Choice, that Scott Davis spoke about in this aforementioned keynote, and about which I wrote in 2007:

Cover of The Paradox of Choice Book

He [Scott Davis] told a story (I believe to be from the book) that succinctly showed what happens when consumers are presented with too many choices: Given 3-5 options for tasting Jellies/Jams, customers ended up buying more of it. However, increasing that to two-dozen left sales at levels lower than having no sampling at all.

We simply become overwhelmed by the number of options available, turn off, and refuse to make a choice at all. That leads us to the Maximizer/Satisficer concept, where the Maximizers are especially prone to analysis because they try to be more prepared when making decisions and never stop analyzing, even after making the choice. On the other hand, satisficers try to narrow their decision-making points down to a reasonable few.
When my to-do list is unordered and contains too many items, I often revert to the infamous analysis paralysis; the too-many-things-to-remember causes the poor decision of making no decision. (I am working on some software to relieve me of this feeling, but more on that some other time).

In pursuit of this goal of making better decisions when we have less to remember, we see ideas arise like convention over configuration and Paul Graham's belief that great hackers make use of shorter programs, having less to remember:
More powerful programming languages make programs shorter. And programmers seem to think of programs at least partially in the language they're using to write them. The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.

Choosing quickly versus Deliberating
In the same Radiolab episode, the hosts visit Berkeley Bowl and encounter the "too many choices" dilemma. In choosing an apple each, Jad deliberated as Robert just chose on his first gut instinct.

The problem behind the kind of choice we make when we have too many things to choose from is that it short-circuits our prefrontal cortex - the rational, deliberative system in our brains. We can only hold so much data at a given moment, and when we encounter encephaloverlow, the emotional, unconscious, automatic part of our brain takes over.

The brain, with prefrontal cortex highlighted.

Trying to make that choice brings us back to the maximizers vs. satisficers bisection mentioned above: in deliberating all of the options behind a series of choices, the maximizer is often less satisfied with his choice. In general, I'm that guy; and I can say without a doubt that the decisions I'm most happy with are the ones I make in an instant.

When I have to decide which version of Windows to go with, I'm either feeling like I paid too much for crap I didn't need or didn't get what I needed at the right price. I'd much rather simply decide how many licenses I need and get the whole package than try to weigh my options playing the "how much can you afford to pay?" market segmentation game Microsoft hoists us into.

Kathy Sierra hits on this idea that people are happier with fewer options when she talks about happy users and featuritis. It's not just her - there's an entire school of thought based around the idea that simple, focused programs are preferable to monstrosities that do it all.

Some programmers might be drawn to think about cohesion and coupling. Less is more, after all.


Complete rationality leaves you nowhere. Feelings are what makes decisions work.
In the Radiolab episode that inspired this post, Antoine Bechara, a psychology professor at USC tells the story of Elliot, a man who became completely rational after having a tumor removed from his brain. He had no mental impairment that anyone could detect, but he had an impossible time deciding between the simple things in life: whether to use a blue pen or a black one; or which cereal to eat in the mornings.

Neither feelings nor emotion seemed to play any part in Eliott's decision-making, and he could never decide on anything. He ended up divorced, losing his job, and losing his life savings. After he became entirely rational, his life fell apart.

This segment shows us that gut feelings are shorthand averages of past wisdom, a theme Andy Hunt discusses in Pragmatic Thinking and Learning: L-mode is the analytical, rational process in our brain, but
We want to use R-mode more than we have because the R-mode provides intuition, and that's something we desperately need in order to become experts. We cannot be expert without it. The Dreyfus model emphasizes the expert's reliance on tacit knowledge; that's over here in the R-mode as well. Experts rely on seeing and discriminating patterns; pattern matching is here too.
Cover of Pragmatic Thinking and Learning book


Justifying choices makes you choose pop culture.
The implication here is that pop culture is bad in some respect. That's not necessarily the case, but when, as Malcolm Gladwell explains about the "perils of introspection," you have one group overwhelmingly choosing this poster

Hang in there, Baby! Cat Poster

over this one,

A painting from the Impressionist, Manet

you might have a problem of the high-cultural taste variety.

It turns out, those who had to justify their choice were the ones choosing the precursor to the LOLcat. (And as Gladwell points out, the scary part is that we ask our focus groups to explain their choices, and what we have left to purchase is what they favored.)

In that vein, I try not to think too hard about my programming. I don't mean to minimalize it - after all, programmers are wizards who
use the keyboard to type our incantations out to produce stuff from nothing but thought. We can think things, and make them happen without so much as a thought toward physical materials aside from our keyboards and displays.
But at the same time, I believe there are no best practices - only better practices in particular contexts. And those "best practices" are often the stuff of pop culture programming legend. You know - those message board posts that tell you "don't do that" instead of answering your question? Yeah, I know you know them. I love those almost as much as the ones that tell me "that can't happen" after I've been trying to find out why the hell it just did.

Even though having too many choices can cause you to make bad decisions - and the wide-open-world of programming has infinitely many choices - you need to find and focus-in on the decisions worth making. It's quite alright to have shortcuts that help you narrow down the options to choose from. Given the evidence, it seems like a good idea.

But let the R-mode part of your brain and your expertise be the guiding factor in your choice in eliminating extraneous options, not a reliance on pop culture. If you have to stop to justify your decision, it's likely you're reverting to the pop-culture decisions that have you appreciating charlatans over masters of their craft.

How have you noticed choice impairing you as a programmer? How has it enabled you?

Some links in this post are affiliate links!

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

I feel like I can relate to the fellow with the removed tumor: ever since I got seriously into programming, my L-mode has gotten a bit out of control. For example, coming down to a choice about triangle-based vs plane-based collision for cubes took days of deliberation just to get it down to those two choices. Plenty of folks had to yell in my face just to "make a decision already!"

I feel like it's hard because not only do I not have a lot of experience, but I'm typically left without enough concrete information. And when you're the type of person who typically double-checks and second-guesses himself a lot, actual work slows to a crawl. Having a bad memory doesn't exactly help either (especially when you're trying to recall paradigms), so sometimes I just have to guess. And making an educated guess when you have little creative energy is barely a guess at all.

When those guesses go awry, you start to doubt yourself a lot (hence more double-checks and asking other people questions). R-mode sometimes feels like a crapshoot!

Anyway, I think I need to take a hint from you and not think *too hard* about it. I imagine that takes practice, though.

Posted by Steve on May 12, 2010 at 03:09 PM UTC - 5 hrs

I think programmers are faced with the these dilemmas every day. And it spans various orders of magnitude from architectural decisions, language decisions to things as detailed as should I use a recursive solution or an iterative one and whether a variable should be an integer or long or a double.
IMO this <a href="http://technikhil.wordpress.com/2010/04/07/jugglin...">mental juggling is a part of programming</a> and what makes programming so challenging and when you get it right - so rewarding.

Posted by Technikhil on May 12, 2010 at 10:23 PM UTC - 5 hrs

@sammy, i think this can cover a lot more areas in life than just programming. i believe i handle things differently in programming (or even business in my case), than i do in everyday life (specifically with spending my own money). since your post is directed more at programming, i would add the caveats of confidence and goal.

i would suggest that someone who is confident in their abilities and decisions will not have any issue regardless of how many decisions/flavors are placed in front of them. i would agree that at some point, there will be some dissemination, in order to determine if their chosen path is better than this new path presented. in the end, i believe their confidence will lead to the direction chosen, and quickly. i would chalk this up to leadership. some are leaders in some areas, others in other areas, while some are not leaders at all. if you are a leader in that area, generally speaking decisions will come easy.

another caveat is goal. if the goal is to get it done, then you are going to choose the path of least resistance and most comfortable, but if the goal is to make a process faster, then a different path may be chosen. if lines of code, or cost are the goal, then other choices may be made. many times the goal will dictate decisions.

one other thought... policy... many times policy removes the decisions as well.

Posted by shag on May 13, 2010 at 05:34 PM UTC - 5 hrs

My best defense against "analysis paralysis" was taught in a class on Engineering Decision Making long ago. The class taught many estimation and preference-expression techniques, but the best lesson it taught the batch of young academics in the room was that outside the world of a textbook, information is NOT free. With so many books and blogs and discussion boards to do cheap research that cost may seem low at first but if we consider the time needed, the cost is clearer.

Cost awareness has a way of sharpening focus, with oneself or when dealing with clients/colleagues/bosses.

Posted by Chris on May 13, 2010 at 05:54 PM UTC - 5 hrs

Alas, the Baba Shiv experiment holds unsettling implications for anyone looking for a society based upon reason. It suggests reason can occur, but it cannot prevail. As a WSJ reporter commented, the surprising thing is not that emotion sometimes wins over reason, it's how easily it wins.

Posted by tom sheepandgoats on Nov 20, 2010 at 08:01 AM UTC - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner