私はこうしてプログラミングを覚えた

うっ，自分語りのエントリが続くな。 まぁいいや。

「ぼくはこうしてプログラミングを覚えた」を読んで「はて，自分の時はどうだっただろう」と思ったので，思い出しながら記事を書いてみる。 先に予防線を張っておくが，「ぼくはこうしてプログラミングを覚えた」は元 Facebook のエンジニアの方で（実はよく知らないが）ハッカーと呼ばれる方だろうが，私はハッカーではない。 ただの場末の職業エンジニアなのでマジに受け取らないように（笑）

手短かに言えば

私はプログラミングが好きでも嫌いでもない。 私にとってプログラミングは手段であり道具であるに過ぎない。 私から見れば「プログラミングが好き」とかいうのは「鉋や鋸が好き」と言ってるのと大差ない。 私にはその手の倒錯趣味はない。 私にとって「プログラミングを覚える」というのは，趣味や仕事の上で必要だから，ということに過ぎない。

もっと詳しく言えば

うちの両親は若いころ貧乏かつ非常に苦労した人達で，そのとばっちりを食らった私も子供時代は貧乏な環境に育った（もっとも子供時代の私は「ものを欲しがらない子」だったそうで，私自身じぶんちが貧乏だと意識したことはなかった。貧乏でも親がしっかりしてれば子供はのびのび育つと言う好例ですなw）。 いわゆるマイコンは中学高校あたりから登場し始めていたが，そんな高価なものを買ってもらえるはずもなく，しかも同じ高価なものなら天体望遠鏡が欲しいと思う子供だった。

そのマイコンを触れるようになったのは大学に入ってから。 入学祝で買ってもらった旧式の PASOPIA とバイトで買った CASIO のポケコンとサークル（天文研）の備品の PC-8001 が私の遊び道具になった。

当時ハマっていたのは「日経サイエンス」で連載していた「コンピューターレクリエーション」で，この連載記事の内容をマイコンで試して遊んでいた。 もちろんマシン語なんか知ってるわけもないので BASIC で組んでいた。 最初に組んだマンデルブロ集合の描画プログラムはモニタ画面全体（640×400）を描画し終えるまで1週間マイコンを立ち上げっぱなしにしなければならなかった（しかも画面を保存する機能はない。砂絵かっちうのw）。 あと進化シミュレーション（この記事は後に「遊びの展開」に収録された。この雑誌は今読んでも面白いので探してみて）とかも試して遊んでいた。

ポケコンには（カンニング用途（笑）以外には）北極星の時角を計算するプログラム（もちろん BASIC）をぶち込んで使っていた。 平均恒星時を使って1秒程度の誤差があったが，まあまあ使える代物であった。

大学では FORTRAN の講義を受けたが，最初の課題でお金を使い果たしたので放棄した（でも何故か単位はもらえた）。

本格的にプログラミングを学んだのは，あるシステムハウスに入社してから。 実は当時「プログラミングがお金になる」ことを知らなかったのだ。 BASIC と FORTRAN をちょっとかじっただけの小僧が，ただただ「週休二日，固定給，社会保険完備」という文言につられて入ったのである（入れる会社も会社だけどね。当時のボスは何で私を入れたのか謎だと言っていたw）。 入った会社では3ヶ月間みっちりとプログラミングを仕込まれた。 そのうちの1ヶ月間はアセンブラを使った研修だった。 そこで私は（生まれて25年目にして）はじめてコンピュータがどういう仕組みで動いているのか知ったのである（笑うところだよ）。 あの3ヶ月は本当の意味で私の実になった。 期間は3ヶ月だが，そっち系の専門学校の2年分のカリキュラムを優に超える内容だった思っている。 （ちうわけで私は「学校で習ったプログラミング」なるものを全く評価していない。当時（バブル期）の新卒採用でも専門学校でB,C判定しか取れないようなのは問答無用で切ってたし）

ちなみに研修期間中 C 言語の基本部分は3日で覚えた。 プログラミングの基本ができてれば，どの言語を選ぶかなんてことは比較的どうでもいいことである。 今でも私は（仕様レベルなら）たいていの言語は3日以内で覚えれる自信がある（ただし各言語の癖のようなものは実際にコードを組んでいろいろ試してみないと分からないけど）。

プログラミングを覚える助けとなるのは「他人のコードを読む」ことである。 それも大量に。

そしてもうひとつ助けになるのは「コードを書く」ことである。 それも大量に。

思うのだが，「○○をしてはいけない」と言われて本当にそれをしない人というのはプログラマには向かないと思う。 「○○をしてはいけない」と言われたら，まず○○を試してみるのがプログラマとして正しい態度である。 なぜならプログラム・コードの大半は異常系，つまり「してはいけない」ことに関する記述だからだ。 今まで何度も書いているが，優れたシステムとは失敗しないシステムではなく上手に失敗するシステムである。 上手に失敗するためには「○○をしてはいけない」ことの意味を正しく理解する必要があり，正しく理解するためには「してはいけない」ことを試してみるしかないのである。

だから大量にコードを書くことをお勧めする。 良いコードも悪いコードも書いてみなければ理解できない。 また「「してはいけない」ことを試してみる」というアプローチをとれるのはソフトウェア・エンジニアリングの優れた特性であり，その行為に（罪悪感ではなく）享楽を感じないようならプログラマとか止めたほうがいい。 そしてそのことさえ押えておけば，どんな言語にも適応できる。 ソフトウェアなんて簡単なのである。

3ヶ月の研修のあと，当時のボスから「君はハードウェアには向かない」と言われたのだが，今ならその意味するところがはっきり分かる。 私のような人間がハードの設計なんかやったらコストが3倍でも済まなくなるだろう（笑）