Trusting a black box

Steven Johnson wrote in Everything Bad Is Good For You about how in video games we have to figure out the rules of the built world. We are not just exploring a virtual space but build a mental map of cause and effect.

The humor of memes about video games having prepared one when finding something random that looks like a glitch in the real world reflects this mental map concept.

Anything built without our controlling the rules works this way. Say I have a car that estimates the range. It says I have 11 miles before it runs out of gas and the fans are on full, so I see the miles dropping faster than they should. I come to doubt really have 11 miles and the gas station I can get $.40 off is 7 miles away. I might get there and I might not. So, I put a gallon in it. The range doesn’t budge.

Do I still have 11 miles? Surely I have more, but how do I know that I do? Can I trust it?

Opaque rules impair causation. See, the whole point of the tool is to allow me to predict when to take action. More gasoline SHOULD cause more actual range which should cause the gauge to show more range. Filling up the tank soon after did show the max range like it should. This event eroded my trust, which makes me worry about whether I can trust the gauge even when it does show there is plenty of gas.

P.S. the gas gauge did not move either.

Conditional Thinking

XKCDTech Support Flowchart

My mind made a leap past something blocking it for a while now.

This post, If This, Then That (ifttt): Teaching Conditional Thinking laid the groundwork I needed. The post describes a new simpler version of Yahoo Pipes called ifttt. The idea of both is to take data generated at one or many places and output that data in new interesting ways. An example for how I have used it is creating a single Bbworld feed taking the hashtags in Twitter, a couple dozen blogs, and Flickr tagged photos to produce a single RSS feed to follow. Sooo easier to give out this one than list all the feeds to coworkers or peers at other work places. It then describes this as a useful way to teach conditional thinking.

We have been discussing learning, specifically teaching the skills involved in problem solving: understand the problem, make a guess how to solve, try it, check the efficacy, decide whether solved or keep trying or give up. One idea thrown out was that there was a culture us-vs-them and that our culture made problem solving possible where as another culture did not. Another idea was that in order to problem solve one has to be able to find causes. A third was that someone taught us how to problem solve so someone needs to teach them.

This made me realize problem solving is similar to process flows in that have conditional logic.

  • Case: make a guess how to solve.
  • Exec: try it.
  • Test: check the efficacy.
  • Loop: decide whether solved or keep trying or give up.

The key piece really is someone who writes code reaches a point where letters, numbers, and symbols mean anticipated behavior. They know what it should do to solve the problem. Then when the code does not do it, they use problem-solving to fix it so it will.

So… To solve a problem, I may write code with conditional logic similar to problem-solving with problem solving to make it work. Even when I am writing this blog post, I am thinking about problems with it, how I can improve it, trying different ways to express it, and deciding whether it is okay. Think that seals it: Problem solving is a culture in which we are completely mired. Those trying to participate without thinking this way will have a hard time being relevant. Er… Useful. Er… Helpful.