Programming your own mind
Here's some required reading for you...
I have geekdom in areas other than computers and music. During my brief stint in college, I studied economics, and it's stuck with me for all the years that have followed. And one of the great things about the modern internet is how many source of world-class econ lectures I can find on a daily basis.
One of my favorite sites is Overcoming Bias, which is only tangentially about economics (but features several contributors with econ backgrounds,) but has excellent daily articles about how to get cognitive biases out of our analyses. In the business world, biases are better known as "the box." We say someone is "thinking outside the box" when they let go of their assumption biases, and look at a topic with untainted eyes.
Biases are rampant in the computer industry. Whether it's vendor bias (I like IBM, I like Microsoft. I like Apple. etc) or workload bias (that's not my fault, that's the network guys' screwup) or interface bias (every Notes app looks like mail, or "users don't like apps that don't look like Microsoft" claims) or planning bias (if we don't have a fully documented spec before writing a single line of code the project will fail!!!) -- we've all experienced bias and chalked it up to stupidity or emotion or politics, when it's really just a set of assumptions in someone else's thinking.
The great Robin Hanson talks about an interesting bias today called the "Inside View." Basically, when you're looking at a problem from inside it, you tend to become overconfident in your own performance and shift problems to the outside container.
I recall a similar experience when I was learning to program. I would carefully check my program and find no errors, and then when my program wouldn't run I was tempted to suspect compiler or hardware errors. Of course the problem was almost always my fault.
I can't count the number of times I've heard this from otherwise competent people. They write 5 lines of code, run it, and it doesn't work, and immediately it's "this must be a bug in Notes." I also can't count the number of times I've sat down in front of their keyboard and put quotes around a parameter and it suddenly works.
I also can't count the number of times this has been done to me.
The first step in overcoming your own biases is to identify them. Then you can learn to recognize the patterns of behavior. Then you can learn to change them.
A few I know of myself...
1) I have a strong vendor bias. The name "Microsoft" sets off warning bells in my head everytime.
2) I have an aesthetic bias. I will gripe about a well-designed application simply because I don't like it's font or color choices.
3) I have an elegance bias. I want to refactor functioning code simply because it isn't well-written OO with understandable variable names.
4) I have a speed bias. I hate plans that stretch more than 6 months, even if doing the thing really does take more than six months by any rational plan. I always want to find a way to do it faster. Usually this happens by redefining the goal to something that can be done in less than 6 months, and switching my focus again at that point.
What are your biases? How do they affect your work, both in terms of output and social interaction? How can you overcome them?
PS: Oh yeah, my worst bias is my challenge bias. Once I've come up with a solution to a problem I can manage to implement that solution maybe once or twice. After that, boredom sets in, and I can't finish it again. At that point, if I can't turn over the implementation, the thing remains incomplete. An interesting converse to this bias is that I'm quite capable of finishing someone ELSE'S thing, just not my own.
Comments
1) I have a bureaucracy bias. If I know something is going to be difficult to get done, I have a tendency to avoid trying to do it. This is not a statement about my employment/employer :)
2) Clearly, I have a vendor bias. Unfortunately, most of you will only learn much about my feelings for Microsoft truly after I write my book and/or leave IBM.
3) I have a "me first" bias, but am not always an early adopter. I'm getting a new iPod tomorrow, whoopee! Don't think it's even worth blogging at this point, since it's a "me, too". But I also have a strong instinct to want to be first person in queue at the airport, first person to discover some really cool restaurant, stuff like that.
Posted by Ed Brill At 05:35:41 PM On 07/25/2007 |
2) Every problem is nothing more than an action item system; who does what, when, and why. Forget UI, after a while lots of apps start to run the same under the covers and I keep thinking if I can just come up with a totally generic action item system, I'm done coding.
3) People - not all people, just some. I'll give them a couple of chances then shut them out if I've decided they don't measure up. This is problematic in that everybody has good ideas even if they tend to state them in ways that annoy me.
Lots more but those three tend to be the ones I need to watch when doing app dev.
Posted by Doug Finner At 12:41:29 PM On 07/30/2007 |