プログラム作ってる途中であまり動かさない

OJT で最初に課題プログラムを書いた時、
「エスケープシーケンスを使って、 more の劣化版みたいなページャーを作れ」
という課題だった。MS-DOS で作った。

課長に
「コンパイルはしてもいいけど、動かしちゃいけない」
と言われたので、コーディングしてコンパイルができたところで持っていった。
一応、自分なりにはわかる範囲で動くように作ってるわけだけど、新人が一発で動くわけない。最初の最初のほうでエラーになって動かない。
直して、コンパイルして持っていって動かない・・・その後、どの程度までやったかは忘れたけど、まあ、何か動くくらいのところまではやったんだと思う。
確か、最初に more ができたら、違うキーを押したらページアップとか、機能が追加されていった記憶はあるので。

とにかく「動かしちゃいけないとは意地悪だなぁ」と思った。

しかし、今になってみるとあれが良かった。今につながっていると思う。
あのとき、自分のコードを（動かさないで）よく読んで考えるようになった。
動かして動作を確認するよりも、立ち止まってソースを読んで挙動を追ったほうが、トータルの時間はずっと短いと言うことを知った。
（ごちゃごちゃで動かしてみないとわからないコードっていうのが、あるにはあるが）

HP-UX 9.0 くらいの頃に、CAD のアドオンアプリで三角関数の計算を再帰で大量にやる処理を書いたのだが、開発途中で猛烈なバグがあった。
ユーザーランドのプログラムなのに、実行すると OSが再起動して fsck が走るものだから、どこかおかしいところを探すのに１ターン15分かかった。
ちょっと直して再実行が１時間に４回しかできないのだ。
しかも、どこに不具合があるのかまったくわからない。
あの時、
「GUI でステップ実行できるデバッガーがないとデバッグできません」
とかじゃなくて本当に良かった。

デバッガーが進化しても、（Webプログラムが主流になったっていうのもあるけど）ソースコードを読んで考えるほうが、気軽に動かして、ちょっと直して、また動かすよりも早く完成することには変わりないと思う。