March 18, 2010

読書: 情熱プログラマー – Chad Fowler

情熱プログラマー」読みました。オーム社の森田さんから献本していただきました。ありがとうございます!いつも思うんですけど、どの本も装丁が奇麗ですね!

さて、この本ですが、まだ自分のなかで内容を消化しきれてないというか、身につまされないといけないはずなんだけどまだ実感がわかないというか、なんかそんな感じです。あいまいな表現で申し訳ありません。読み終わった後に「さて、じゃあ僕は今何をすべきだろうか」と、ちょっと(いや、かなり)考えてしました。で、いまだにあれこれ考えてます。

本書の後半にさしかかってくるとだんだん自分が説教されてるんじゃないかとかいう変な思いにかられてしまったりしました。あと、「ファウラー氏に比べたら、俺しょぼい仕事しかしてねー」とか思ってしまいました。(いや、しょぼい仕事なんて言ってすみません。。仕事があるっていうのはほんとありがたいことです。)

ていうかチャド・ファウラー氏すごすぎなんですよ!なんかこう、追いつきたいという思いを通り越して畏怖してしまうような、そんな感じっす。ていうか日本人って外人を無条件にすごいと思ってしまうところありますよね、ね。

そんな中、僕が面白いと感じたのはファウラー氏の若かりしころの話。読むと「ファウラーさんも人間なんだなぁ」(あたりまえだけど)とか思えます。

すごい人に少しでも近づくには、すごい人が何を考えているのか・どういう考え方をしているのかを知る必要があって、そのためにこういう本があるんじゃないかな、と思いました。あと、「こういう時、チャド・ファウラー氏ならこうするはずだ!」という指針にもなりますね。

僕もサックスが吹けるようになりたいです。

GitHub 誕生のコラムはかなり読んでいて熱いものが込み上げてくる感じがありました。やっぱああいうのにあこがれますねぇ。人生、冒険ですねぇ。

あと興味深かったのは、 Patrick Collison という人の「失敗と模倣」というコラム。とにかく自分の手でいろんなプログラムを作って失敗してみるべき、というようなことを言っていて、すごく共感できました。すごいものを作り上げた人って、実際にはそれ以外にもいろんなものを作っているはずで、それらのほとんどは失敗作だったりするんだと思うんですよね。何度も何度も失敗してたまに良いできのものができる、という感じなんだと思うんです。実際に作ることを通してしか得られないものがあると思うのです

そんなわけで、明日もがんばるぞー。

January 21, 2009

転職しました

転職しました!
株式会社万葉に。

きっかけとしては、ogijun さんの日記で会社の存在を知って、あとは Rails 勉強会で万葉入社予定の人とたまたま知り合いになって、で、で、Find Job でたまたま求人広告を見つけて応募して面接して入社することになりました。

社長の旦那さんがたまたま Termtter のコミッターになったりもしてます。

というわけで、Termtter をよろしくお願いいたします。

November 17, 2008

モチベーションという名の悪魔

タイトルのみ。

megane3.png

October 21, 2008

読書: ソフトウェア開発者採用ガイド

ソフトウェア開発者採用ガイド ソフトウェア開発者採用ガイド
青木 靖

翔泳社 2008-03-20
売り上げランキング : 12836

Amazonで詳しく見る by G-Tools

これ読んだ。
いやー、Joel の文章はどれもいい。
書いてある内容もそうだけど、とにかく文章がいい。
例えるなら、めちゃくちゃいい絵を描く漫画家みたいな感じ。
こんなふうに書けたら(描けたら)いいなぁと思わせる。

印象に残ったところをいくつか引用。

この6年の間、友人のマイケルと私でソフトウェア会社を率いてきた。私たちは最初の最初から第一に優先することは優れた人を採用することだと考えていた。どんなソフトウェアを作るか考える前からだ。そうしてその年月の間、優れた人たちが私たちのところで働きたいと思うようにすることに注力し続けた −− まだ誰かを雇えるようになる前からだ。私たちはいくつか間違いをし、そこから多くを学んだ。今では優れた人を得るというのは Fog Creek にとって唯一問題を感じないことと思えるほどになった。

逆にいうと、すごいアイデアがあったとしても優秀な人間がいないと実現に至らないんだよなぁ。
金で技術は買えるかもしれないけど、見極める力がなくて間違った技術を買っちゃったらどうするの?、とかも思う。
A ランクの人は自分よりも能力のある人を雇い、B ランクの人は自分よりも能力が劣る人を雇う、みたいな話があったな。

ソフトウェア会社を作るのは、それまで解けなかった何かの問題を解決する巧妙なアイデアを見つけて実現し、それによって富を得るのが目的なのだ、と一般には信じられている。これを「より良いねずみ取り作りの信条」と呼ぶことにしよう。しかしソフトウェア会社の本当の目的は、資本を役立つソフトウェアへと変えることであるべきなのだ。

Joel が言いたかったことからは若干ずれるかもしれないけど、最近僕はこんなふうに考えてる。
「誰でもすごいアイデアを思いつけるわけじゃない」
というか、人間の発想なんてたかが知れてる。
すごいアイデアで何かを成し遂げたい!って思うのは、そうすることがすごく魅力的に見えるからだと思う。
なぜそれが魅力的に見えるかというと、すごいアイデアで何かを成し遂げるということができていない今の自分が全然魅力的に見えないからなんだよね。
状況を変える何かが欲しいんだよね。
とにかく努力あるのみ。
中途半端な努力で思いつくようなアイデアなんて誰もが思いつくようなものばかりだと思う。

開発者が現在の作業のために最適でないプログラミング言語を、それがボスの好みだからという理由で使うように言われることほど、彼らを憤慨させることはない。人々が厳格に能力によって昇進するのではなく、コネによって昇進することほど、彼らを怒らせることはない。組織で自分より上にいるか、より強いコネをもった人間が要求しているために、技術的に劣った方法でやらなければならないということほど、彼らをムカつかせることはない。

まあ、これはその通りですね。
プログラマじゃなくてもこういう事態になったら普通怒ると思うけど。
ただ、ちゃんとした根拠もなく最新の技術を使いたいとかお気に入りのフレームワークを使いたいとか言うのはちょっと違う。
あくまでその状況において最適な技術・ツールは何か、ということをちゃんと考える必要がある。

私たちの信条は長期的視点で採用するということだ。現在たまたま知っているどんな技術も、来年には古くなっている可能性がある。しかもそれらの技術の中にはいとも簡単に学べるものもある。 [略] 基本的に優れたソフトウェア開発者には、別なプログラミング言語を学ぶというのはまったくたいしたことではないのだ。彼らは2週間で非常に生産的になっていることだろう。2年後には、まだ発明されていないプログラミング言語でまったく違ったことをやってもらっているかもしれない。

これもその通り。
Joel の話からはちょっとそれるけど、僕が前から思っているのは「PHP しか知らない人は PHP すらも知らない」ということ。
他の言語を理解するということは、その言語の理解も深めることにもなる。
そもそもプログラミングを学ぶというのはそういうことだと思うんだけどなぁ。
あ、Lisp 勉強しないと。

問題のある開発者の多くは、単純に優れた開発者になるための素養を欠いているものだ。頭は良いがポインタや再帰を決して理解できない人がいるというのは私が強く思っていることだ。

そうかもしれない。

October 14, 2008

漠然とした不安

当面の自分の課題は英語のレベルを上げること、というふうに決めたのでアマゾンで本を選別するときもそれを意識してる。
なんでもかんでも手当たり次第に知識を詰め込もうとしても効率悪い気がしてきたので、テーマを1、2個に絞って継続的かつ長期的に取り組んでいくことにした、最近。

プログラマーになるって決めた後はただひたすらプログラミングの勉強をすればよかった。
手当たり次第に本を読んだり、ネットの情報を漁ったりした。
バイト先では、仕事をさっさと片付けてこっそり勉強したりした。
どんな方面の情報であってもその当時の僕にとっては何らかの役には立った。
ある分野に取り組む際には、とにかくその分野に関係がありそうな本なりを手当たり次第に読んでいくのがいい。
というか、そうするしかない。
右も左もわからないのでとにかく右にも左にも行ってみる必要がある。

で、まあ今はプログラマとしてそこそこの経験も積めてある程度は気楽に日々の仕事をこなしてるわけなんだけど、ふと気づくと目の前にでかい壁が立ちはだかってるような気がしてくる。
またいつかのようにがむしゃらにやらないと次のステージに行けないんじゃないか、というような漠然とした不安をすごく感じる。
というか、いつでもがむしゃらになる準備はできてるんだけど、バチッと方向性を決められていないのが現状。
昔は今よりは目標が単純だったから良かった、という話。
目標をうまくコントロールできないとダメだなぁ、と思った次第。

July 31, 2008

IT 業界をどう生き延びていくか

IT 業界をどう生き延びていくか、とか最近よく考えるんですよ。
ま、いろいろな道があります。
いろいろあるんですけど、先のことを見越して何をやるべきか、とか考え出すと正直ちょっと悩みます。

結局は、IT 業界に限らず仕事って問題解決の連続なんですよねー(僕の中の定義では)。
いかに上手く問題を解決するか。
問題を解決するためにはいろんなスキルセットが必要で、だから日々情報収集したり勉強したりしてるわけですよね。

あと、問題を解決するのも重要ですけどその前に、問題をちゃんと見極めるということも重要ですよね。
自分自身が問題の種になってたりすることもあるかもしれません。

もっと広い視点から語ると、重要なのは、あるべき状態にどういうふうにもっていくか、ということなんだと思います。
現状をどうしたいのか、ひいては自分の人生をどういう方向に持っていきたいのかとか。
そのためには何が必要で、現状はどうなのかとかいろいろ考えるわけです。

要は、問題を見抜くスキル・問題を解決するスキルをたくさん身につけるために日々努力し続ける必要があるってことですね。
まあ、幸いそういったことは嫌いではないというかむしろ好きなので、良かったなぁというか。
なんていうんですかねぇ、普遍的なスキルっていうんですかねぇ(そういうのがあるとして)。

ま、とにかく勉強します。

July 2, 2008

読書: ラクをしないと成果は出ない

ラクをしないと成果は出ない ラクをしないと成果は出ない
日垣 隆

大和書房 2008-05-23
売り上げランキング : 252

Amazonで詳しく見る by G-Tools

まあそんな感動するほどではないにしても、そこそこ面白かったと思います。

いろんなことが書かれていたのでもうほとんど内容忘れた。
なので、今パラパラ読み返してる。

誰かに勧められたら、すぐさま取り入れないと何も教えてもらえなくなり、人とのネットワークも脆いものに変わってしまうものです。

うん、そうですね。
例えば、他人から勧められた本はすぐに読まないといけないと思う。
すぐ読む気がないんだったら「すぐ読む気がない」と相手に言うべき。
相手のアウトプットをこちら側でちゃんとインプットしてこそ、こちらのアウトプットを相手にちゃんとインプットしてもらえるんだと思います。

生活すべてにおいて冷静かつ正確な視点を得るためには、確率を考える習慣が必要です。

確率で物事を考えられない人が宝くじとか毎年買うんですね。
当たらないのに。
もし当たってもろくなことにしか使わないのに。

いかなる目標だろうと、数値化しないと達成できません。

これはよく言われること。
僕は全然数値化できてないんですけどね。

「ラクをしないと成果は出ない」というのはその通りだと思います。
プログラマだったら特にそう。
いかにラクをして成果を上げるか、とうことを常に考えるべきです。
いかにラクをするかを考えることそれ自体が仕事としてのプログラミングの楽しみでもあると、僕は考えています。
いかに怠けるか、ということに僕は日々真剣に取り組んでいるわけです。
偉いですね。