「戦いとは、いつも二手三手先を考えて行うものだ」これは、シャア・アズナブルのあまりにも有名な名言です。しかし、二手三手先というのは不確実なもので、いくら大局眼に優れたシャアとはいえ、杞憂・無駄に終わるということも少なくないはず。 先に準備したほうがコストが少なくて済む、または、無駄になってもほとんどコストがないという、前提条件があったうえで成り立つ名言です。 例えば、勉強といったたぐいのものに関しては全く当てはまらない言葉になります。必要に迫られたほうが吸収しやすいのはもちろん、勉強して結局使わなかったものはただ忘れてしまうのみでしょう。 泥縄と対になる言葉がないっていうのは困ったもんですね。時によっては必要になるのに。 「将来の自分の成長のために、小さな試合にはこだわらないという考え方もあるだろう。でも俺はそういうヤツを信用できない。なぜならそいつは、大事な試合でも同じ理由を持ち出して、勝負を保留すると思うからだ。」テニスではこう言ってる人もいましたねえ。
まずですが、
相対性理論の中身については書くつもりないのでご安心くださいｗ
相対性理論には、特殊な状況でのみ成り立つ特殊相対性理論と、いつでも成り立つ一般相対性理論の2種類ががあります。
アインシュタインは、まず特殊～を考え出し、そのあとそれを一般化して一般～を考え出しました。名前的には特殊～のほうが難しそうですが、実際は逆です。「(特殊な状況)風がない時のボールの動き」のほうが、「(一般化)ボールの動き」より話として簡単ですよね、そんな感じです。
ここで重要なのが、学ぶ順番。
特殊→一般という順番で学ばないといけない。
テニスの例なら、
無風でボールがどう動くか分からない人が、
強風の中でボールを予測するのは無理ですよね？
なのに、適用できる範囲が広いからといって、
一般～から学び始めてしまうことってすごく多いと思います。
というのも、教える側が一般～を理解していると、
良かれと思って一般～を教えちゃうんです。
一般～が理解できれば特殊～はその一部なんだから当然理解できる。
確かにそりゃそうなんだけど、代わりにハードルはグンと上がる。
本だったり、インタビューだったり、
ターゲットが広くなればなるほど、
一般～寄りになっていく。
遠くの偉人より、近くの凡人のアドバイスのほうが、
よっぽど役に立つってことです。
「高校数学でわかるマクスウェル方程式」に続いて、
難しそうな物理の話をわかりやすく説明している本。
まだ半分くらいしか読んでないけど、
抜群におもしろい。
信じられないだろ・・・500円なんだぜ、これ・・・
やるおで学ぶフェルマーの最終定理
http://
これもおススメ。
この二つがおもしろい理由の一つは、
『歴史を語っている』
ところなんだよね。
当然、たくさんの人が出てきて、
議論を戦わせて、
ストーリーが進んでいく。
相対性理論、フェルマーの最終定理、
それぞれがプロジェクトXなんです。
もちろん、この二つは特別スケールの大きい話。
どこにでもあるような題材じゃないだろう。
でも、興味を持つきっかけとするには十分だと思う。
その好奇心で、未来をつくろう！！
とまでは言わないけど、
やっぱおもしろいことは勉強したくなるんだなあと。
あ、インテルのCMっていつもおもしろいですよね。
おもしろいと思ったCM募集。
先輩にコードレビューをしてもらった。55点といわれた。一番問題なのは、55点をとるために時間をかけすぎていることだ。 この55点を80点にすることにもとても価値があるが、今興味があるのはどちらかというと、半分の時間で55点を取ることだ さて、どうすればスピードが上がるかだが・・・時間を4つに分ける。実装してる時間、考えたり調べたりしてる時間、テストしてる時間、何もしてない時間(すいません) 何もしていない時間を減らす方法はここでは割愛。一番減らしやすいのは、考えたり調べたりしている時間だと思う。ざっくりした言い方をすると、「ハマらなければすぐ終わる」実際これはかなり大きくて、しかも差が出る部分。 考えたり調べたりしている時間をさらに分ける。案件固有の、どうしようもない部分、当然、調べても載ってない。アーキテクチャに依存する部分。HTTPに依存する部分。 HTTPに依存する部分は、一番汎用的かつ、一番クリティカル。つまり、基礎。じゃあ簡単かというとそうじゃない。つけた力がそのまま効いてくる、もっとも注力すべき部分。GET？POST？SESSION？タイムアウトは？エラーハンドリングは？ログは？ アーキテクチャに依存する部分は、ちょっとやっかい。というのも、ポリシーを理解することも大事だが、特有の書き方を覚えるか調べるかしなきゃいけない部分がある。同じアーキテクチャを使い続けられれば、かなり抑えられる部分ではある。 最後に一番大事なこととして、基本的に、スピードと品質は相関関係。品質が悪いとスピードも上がらないし、スピードを上げるために前述の部分を鍛えれば品質も上がる。。トレードオフになっているのは、汎用性やパフォーマンスの部分。
プログラマは、人によって生産性に10倍の差が出るという。もしそれは少し言いすぎだとしても、5倍くらいは差があるだろう。この差をチームプレーで取り返すのは至難の業。
身近なラインで、Aさんが3倍のスピードでプログラミングできるなら、ダメなBさんのダメ設計のせいで全部最初から作り直しが生じても、Aさんが完璧に設計して一発でBさんが作るより速い。
コミュニケーションコストによるロスを考えたら、Aさんに勝つには、Bさんが5人いないといけない。
まずは優秀なプログラマ集団によるゴリ押し戦術を第一目標に考えるべきなんじゃないか。
プログラマ視点では、最低でも2-3倍の界王拳は使えないと、自分はチームのコミュニケーションコストを上げているだけ。マネージャ視点では、中途半端な施策を打つよりも、プログラマを成長させるほうが効率がいい。
1+1=3のチームを作るより、2+1=3のチームを作る方がきっと簡単。2倍の速さでプログラミングするのは、2倍の速さで走るよりずっと楽なんだから。