Sit Down and Code
At the 2012 Midwest Instruction and Computing Symposium, visualization researcher Daniel Keefe offered a keynote presentation on data-intensive visualization. His work involves the design of novel interfaces to navigate complex data sets.
Visualization researchers always have the best demos.
Mr. Keefe expressed his frustration with programmers: they hear the problem and then they sit down and write code. He contrasted this with designers, who hear a problem and then they sit down and sketch. He said that programmers should sketch more. I think he misunderstands programmers a bit. Writing code is sketching.
A musician needs a melody and heads to a piano to sound it out. If the result sounds terrible, we don’t say going to the piano was a bad idea. Instead, we say the musician is more informed and revises her tune. If a programmer starts coding and gets stuck, then the programmer has achieved the very thing that sketching was supposed to accomplish.
Elsewhere in his talk, Mr. Keefe talked about a design curve that plotted designers’ forward progress in a project. In the research stage, the design curve goes willy-nilly. Designers vacillate and revert and eventually narrow down the solution space. Ultimately, the design process converges to a straight production path. Engineers do not follow the same curve, he said, and there’s sadly not much willy-nilly in the research phase.
I find that in my own development of software I follow exactly the designer’s curve. I sit down and write code, which helps me get a grasp on the problem. I head one way, and realize it’s the wrong way. I head another way, which seems a bit better. I willy-nilly a whole lot at the beginning, and I too converge to a straight production path.
We must not expect to get our software right on the first try. At that stage, we are only sketching.