Having an audience watch over my shoulder while I bang the keyboard looking for a solution to a tricky problem can be an unpleasant feeling. The unpleasantness ranges from a niggling feeling of self doubt after I make a silly typo to a hot itchy feeling when it becomes apparent that the peanut gallery knows a more elegant command prompt shortcut than the one I just used.
But back seat programming is so effective that is something I think we just have to learn to deal with. The reason it is effective, I believe, has something to do with our minds inability to operate on more than one scale at a time.
Stay with me here… the poor monkey at the keyboard is working on a fine grained scale, that is concentrating on syntax, pointers and file paths. While he is handling these details his audience is free to ponder in a more coarse grained manner on such things as system architecture. Combine the two scales and you have direction and implementation happening in real time.
I suspect that anyone who has worked solo on a project with an undercooked specification will know all too well how the code can spiral into unnecessary complexity. I believe this is a result of only working on the fine grained scale, and could be prevented with a regular back seat programmer.
I should qualify all of this by saying that it is imperative to have the right sort of back seat programmer. It needs to be someone whose technical ability you respect, someone who gives you a moment to see your own syntax errors before saying something and someone who keeps their damned fingers off the screen!
No comments:
Post a Comment