「あるプログラマ」といっても,自身のことです.ついでに,この出だしは,ある教育者のマイルストーンと同じです.
学科の学生を,授業とは別に短期間で,私に近いレベルまで引き上げるにはどうすればいいか,妄想してみました.そうしたところ,個々の知識や技術よりも,日常の心がけのほうが大事なのかなと思うようになりまして,以下,書くことにします.
- 読む
- 記録をつける
- 目標を決めてプログラムを書く
- 過去・現在・未来を司る
- ときどき一新する
- 問題をつくる
- 議論する
1. 読む
本を読みます.Webページを読みます.
本を読むのは主に,行き帰りの電車やバスの中です.電車なんかで移動のときには,1冊か2冊,持って行きます.行楽の途中で買って,帰るときには読み終えているということもあります.
Webの情報については,読むだけでなく,後で読み直すようにしています.具体的にはこんな感じ.
読みながら,書き手と自分のギャップを探ります.たいていは,自分に足りないところがあるもので,そこを埋めるのが,「ひとつ賢くなった」ということです.
書き手に足りないところがあるなあと感じたとき,コメント欄(あれば)に書くか,メールを送るか,何日か後の日記に書いてトラックバックを送る/送らないか,自分の心にしまうか,妻への馬鹿話に使うかは,その時々によって異なります.
2. 記録をつける
何かしたいなと思ったときは,記録をつけます.紙に書きます.NTEmacsで,ファイルに書きます.ものによっては,Word/Excel/PowerPoint/Inkscape/GIMPで作ります.
後で必要になるかもしれないコマンド実行は,一つ一つ記録します…だと大変なので,一連の実行を終えたところで,historyコマンドで直近に実行したコマンドを出力させ,取捨選択します.最近,研究室内で,自分を含む数人が使うLinuxマシンのためのメーリングリストを作りまして,何かインストールしたらそこに送るようにもしています.
アナログとデジタルの連携も,不可欠です.手段として,いったん紙に書いたものを,エディタなどを使ってファイル化するか,スキャナで電子化するか,ケータイデジカメで撮って自分宛にメールを送るかは,状況で決めます.
ブックマークと同じで,思いついて書いたことは一つのディレクトリに入れ,たまに見直して整理します.
3. 目標を決めてプログラムを書く
授業用のサンプルプログラムにせよ,研究を支援するためのちょっとしたコードにせよ,趣味のプログラミングにせよ,「何をするプログラムなのか」は常に点検します.
それと別に,「プログラムが完成したら,その活動から何を学ぶか」を考えます.これがなければ,退屈な機械的作業なのです.
「何をするプログラムなのか」に属する典型的な質問は「プログラムが動くようになれば,どれだけ省力化できるか?」であり*2,一方「何を学ぶか」については,最初に「言語やライブラリなどが提供する,どんな機能を使ってみたいのか?」を検討することになります.
4. 過去・現在・未来を司る
「司る」と,いかめしく書きましたが,要は「コントロールする」です.
コントロールの対象は,計算機内のファイルのほか,自分と,周囲の人になります.
計算機内のファイルは,他の人と共有していない限り,完全に自分のものです.自分自身は,自分自身のものと言いたいところですが,いろいろしがらみがあるのも事実です.周囲の人「をコントロールする」のは傲慢であり,「に働きかける」のほうが正確でしょう.
それぞれに対して,過去・現在・未来があるわけです.ファイルの過去・現在・未来をコントロールするには,Subversionを使ったバージョン管理が一番です*3.とはいえ,バージョン管理だけあればいいというものでもありません.例えば多数の小さなサイズのデータだと,データベースで管理すべきかもしれません.逆に,大きなサイズのファイルについては,もう書き換えないとなった時点で,バックアップして残しておくことにします.
自分の過去・現在・未来をコントロールするため,スケジュールをつけて毎日何度も見直すこと,周囲の人とは,頻繁にコミュニケーションをとることを,心がけています.
ある科目で学んだ用語ですが,「可観測」「可制御」という言葉を思い出すことがあります.問題解決に役立つキーワードだと思っています.
5. ときどき一新する
使い慣れているものを,ときどきリニューアルして,新鮮な気持ちで活動しています.
リニューアルできる対象には,ハードウェア,OS,アプリケーション,部屋があります.アプリケーションのリニューアルというのは,バージョンアップのことです.
部屋の掃除をしていると,前になくして,記憶からもほぼなくなっていたものが,見つかることがよくあります.
ハードウェア,OS,アプリケーションも,同様です.
6. 問題をつくる
問題をつくる,といっても,トラブルメーカーになれと言っているのではありません.
もやもやしているときは,問題を明確にしようという意識です.そこでも基本は,紙やファイルに書き出すことです.
そうして問題を目に見える形にすることで,解くのに何が必要かが見えやすくなります.計算機(プログラミング*4,あるいはコマンド)かもしれませんし,本を読めば書いてあるのかもしれませんし,周囲の人の手助けかもしれませんし,お金かもしれませんし時間かもしれません.
問題を明確にした上で,今すぐ解決できないから今後に回すといった行動も,少なくありません.
7. 議論する
「口角泡を飛ばす」なんて言葉もありますが,そういった激しい議論は,不要です.
身近な人と,ふだんから,情報交換をしていればいいのです.
理想としては,知性・技術に関して自分と近いレベルで,考え方の違う人がいいのですが,難しいものです.現実のところ,さまざまな知性・技術・バックグラウンドの人と,真摯に情報のgive and takeをすることで,私もハッピーあなたもハッピーな日々を送ることができます.
「考え方の違う人」って誰? そこは,逆転の発想です.自分自身が,周囲の誰とも違い,だけど一貫性をもって行動するよう,努めます.はじめは窮屈に感じるのですが,その活動で得たルール,すなわち心がけを持っているだけで,迷わず行動ができることがあります.心が軽くなった瞬間です.
*1:ブックマーク内でフォルダを作ってそこに入れています.ブラウザ間のブックマーク共有にはGMarksを使用しています.
*2:授業のサンプルプログラムだって,ある技法を学べば,そこから,コード量が減るだとか,保守性に優れたコードを書きやすいだとかいった形で,省力化に役立てられるわけです.
*3:Gitを日常のファイルの履歴管理に使えるか,少しだけ試しましたが,Subversionに戻しました.1回コミットで1増える,通し番号があるので!
*4:ある人々は,「プログラムを書いて問題解決する」ことを,簡潔に「コードを書け」と表現します.