热度 23
2012-6-29 13:47
2574 次阅读|
0 个评论
Recently, I observed someone typing a lengthy analysis in response to an email. What a sight it was: fingers blazing, keys clicking, and that poor "delete/backspace" key getting an Olympic-class workout. And no, it was not just a case of poor typing skills. It was a case of typing and untyping over and over, like being stuck in a "do...while" loop without any exit. Each word, phrase, sentence, and even paragraph was done and redone and redone—all at high speed, of course, which word processing makes so easy. I estimate that the ratio of entered keystrokes to final ones actually used was about 10:1. Some thinking begins Then I wondered, what would it have been like to do that by hand, or even with that now-obsolete instrument, the typewriter? Of course, if you were doing this by hand or with a typewriter, you wouldn't have the "luxury" of such ease of do, delete, and re-do. Now, it's so easy to jump in and get going, and keep going, that there's little need to stop first and think, or so it seems. After all, you can correct, edit, re-do, and re-arrange almost ad infinitum , if not ad nauseum . It's as if the movie Groundhog Day met the cliché from those old movies about newspaper reporters, where the grizzly veteran editor yells "get me rewrite." The effect doesn't apply just to writing, either. I like to watch a TV show called The Woodwright's Shop , where the host uses only hand tools from about 1850 or earlier, mostly planes, saws, chisels, scrapers, and dividers (but no sandpaper). What always impresses me, besides his sheer skills and apparent ease while doing a project in a 25-minute block straight through, is how much thought he puts into each step before he does it. Mistakes are fairly rare. When you think about this, it makes sense. If you ruin a piece of standard lumber these days, you just run over to the nearby building-supply store and get another, no big deal. But "back in the day", a ruined piece was a major problem, as replacement material had to be sawn, planed, squared and trued, all of which took a lot of time and raw effort. Much better to get it right the first time, if at all possible. (The same consideration applies to writing with quill pens and costly paper or parchment, as all were very precious; you likely even had to make your own ink.) The engineering aspect It's not just personal projects which now have this "do it fast, and do it over (and over)" mode. The relative ease with which we can now write code, then execute it, test it, edit it, and re-execute it can discourage proper planning, despite all the formal coding procedures which software engineers claim they follow. The excellent book Digital Apollo details how the code which the programmers of the moon project created was actually transformed into executable instructions for the processor. I mean this literally: the 1s and 0s of the coded instructions were set by hand into core memory strings, a process which took weeks for each revision. If there was a bug or problem, then the entire lengthy process had to begin again. You can be sure that these programmers didn't just bang out their software; they analyzed it long and hard first, since the debug and edit process was so painful. Today's pressures don't allow for much of the "first, stop and think" or even "first, slow it down" approach. Plus, the tools we have encourage the "do it fast, then fix" approach. It takes real discipline to not be driven by the pressure from management, especially when it aided by the programming tools which are literally at our fingertips. Too much of a good thing? Maybe this pace is actually counterproductive, and we should remember that sometimes it's better to go slow and careful, than go fast but have to do it over and over again—and the appearance of non-stop activity on a project is not the same as actual progress. Have you seen instances where going slower and steadier would have been better and actually resulted in a project finished sooner?