プログラミングは「損得勘定」で考える
1年以上前の記事だが，たまたま見かけたので。
いや，何が凄いって，ここまで「新人」に付き合えることが本当に凄い。 以前書いた記事でも思ったが，こればっかりは真似できない。
既にあちこちで書いているのでご存じの方もいるかもしれないが，私は親に「冷血漢」の称号を頂くほどに薄情な人間なので，こういう「新人」を見ると「向いてない」とはっきり言ってしまう。 私がこの歳でまだプログラマなんかやってるのは「自分で書いたほうが早い」と思ってしまうからだ。 私みたいな人間が「人を教える」なんてのはまったくもって彼岸の話である。
この際なのではっきり言うが
数学の問題を解くのに公式の暗記から始める人はプログラマには向いてないので諦めた方がいい
最初に挙げた記事でも
しかし、これはコピペを多用している人にありがちな考え方のようで、コピペしても動かないのはなにか間違ったことをしていて、正確にコピペできていないところがないかを探すというプログラミングサイクルが習慣化していることが背景にはあるのではないかと感じられた。
そのため、一度書き終わったコードは記号の羅列のように見えてしまい、そこに何か間違いがないか目で探すのだ。自分で書いたものもコピペで始まっているため、それは記号の羅列であって、理解していないものになってしまう。
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習より
とあって，気の毒としか言いようがない。 そんなことに時間を取られるくらいなら，とっとと別の職業に転職（class change）するほうがマシだと思ってしまう。
プログラム言語が他の（日本語や英語などの）自然言語と決定的に異なるのは，「ゼロ知識」で記述することができる点である。 プログラム言語は与えられたルールだけで対象を記述することができ，記述することによって知識が（あと付で）積み上がっていく。
たとえば日本語や英語を修得する際に文法から習う人はいない（日本の学校教育は違うかもだけど）。 まずはみんなが話している会話から「文脈」を類推し，そこから言葉自体を理解していく。 「文脈」を類推するためには（他者と共有可能な）大量の知識が必要で，これは「語彙（vocabulary）」と呼ばれるものだ。
プログラミング言語は（原理的には）語彙を知らなくても文法（ルール）の組み合わせで記述でき，記述そのものを語彙として再利用できる。 これを面白いと思えず，他人の書いた語彙をひたすら写経のごとく書き写すのではしんどいばかりで，後には何も残らない。
私はそれを「センス」の問題だと思ってるけど，上述のリンク先の記事では「習慣」の問題だとしている。 しかし，たとえばチャイムと餌で条件付けされた犬に対し「チャイムを聞いて涎が出てしまうのは習慣の問題」とか言ってもどうしようもない。 いや，もしかしたら物凄く頑張れば克服できるのかもしれないけど，そのためにかかるコストは果たして意味があるものなのか疑問である。
趣味でやってる人は別だが，それを「仕事」にしているなら「損得勘定」で考えなければダメである。 ここで言う「損得勘定」は（顧客とか上司とか会社とかではなく）自分にとっての損得である。
たとえば Test First とか Test Driven とか言われているやつ。 これって要するに先にテストを書くことによってコーディングにかかるコスト（金銭的・時間的コスト）を実質ゼロにする考え方だ。 何故なら，先にテストコードを書くことによって「いきなりデバッグ」から始めることが出来るから（テストを書く行為は設計することと同等）。 1行もビジネスロジックを書いてないのにデバッグから始められるとか，なんてクールなんだろう。
良いひとも悪い人も，大人も子供も，貧乏人も金持ちも，誰しも有限のリソースしか持ち得ない。 その有限のリソースを最適化して最大限の効果を得るのが「損得勘定」の基本的な考え方だ。 人の直感は目先のものや心理的なバイアスに大きく左右される。 直感をコントロールして正しい「損得」を見積もれるようになるには訓練が必要である。
とういうわけで，楽しくお仕事しましょう。