コンパイラなどを作り始めると本来自分が作りたかったわけではないものについてもせっせとコードを書かないといけなくなる。とくに標準ライブラリの貧弱なCで書いているからそうなってしまうんだろうけど、文字列とかハッシュテーブルみたいな基本的なものも自分で書かないといけない。仮に、ライブラリが充実していたとしても、コンパイルする言語の文法の細かいポイントなどは個別に作り込んでいかなくてはいけない。そういうのはただ複雑なだけで、別に何か勉強になるとかそういうものではなく、ただ地道にコードを書いていかないといけないだけのものだ。
こういう話はコンパイラに限ったものではない。なにを作るにしても、自分の最初から作りたいと思っていたところのコードは分量にして1割とか2割とかで、残りはただ単にひたすらガシガシと書いていかないといけないだけのものだったりする。本質的なものではないなら書かずになんとかならないかな？ と考えたりするけど、そういう部分は単に自分が書きたいと思ってたコードとは違うというだけで、本質ではないわけではないので、書かずに済ませるというわけにはいかない。
じゃあどうするか。
これは残念ながらどうにもならない。ここでプログラマの生産性の違いがでてくるのだと思う。コードを書くのが遅い人は、腰も重くて、作業に着手する前にあれこれいろいろ考えて時間を無駄にした挙句、コーディングを始めてみてもなかなか進められずに、途中で挫折してしまったりする。コードが書くのが速い人は、それなりに迷いはあっても、そういうのは置いといて作業量に怯むことなくプロダクトを完成することができる。いいとか悪いとかは抜きにしてとにかくプログラミングはそういうところがある。
たしかEric Raymondが、The New Hacker's Dictionaryの中で、マニュアルを全部頭の中にアップロードしている平凡なプログラマは、創造的で賢いプログラマを容易に上回るといったことを書いていたと思う（Hacker's Dictionaryは有名かつ面白いので読んでいない人は読むこと）。生産性の高いプログラマに対する一般的なイメージとして、非常に創造性が高いというものがあると思うけど、その反例として、実際には知っているか知らないかが重要なんだということを彼は主張していた。それは本当の話だと思う。一つ一つマニュアルを調べたりググったりせずにどんどん作業を進めていけるかどうかが、頭の良さとかよりも重要なのだ。
わからないことは必要になった時点で調べればいいから覚える必要はないと思っている人にはプログラミングは向いていないし、最初から覚えられるだけ覚えてやろうという気がないといつまでたってもコードはサクサク書けるようにはなれない。コーディングの速さは量が質に転化するもので、プロダクトを作り上げるには不可欠なスキルなのだ。