>私たちは「べき」ではなく「有用」であることを追求し続けるべきです。

>sugimoto_kei 郷に入れば郷に従え。その時々に与えられた場でベストの仕事をする。事業企画が大事なら事業企画をする。コードにひきつけない。平たいコードを書くべき場なら平たいコードを書く。OOPにひきつけない。OOPが力を発揮する場なら、思いっきりそれをする。僕にとって仕事とはそういうものだ。

>sugimoto_kei 何をするかより、その仕事は何を達成しようとしているのか、それは、自分の側で多少の妥協をしても達成する価値があることなのか、と問う。Yesならば、それを達成するためになんでもやる。自分の経験値が少ないことならその場で学ぶ。

>sugimoto_kei 僕が見てきた仕事のできないひとは、コンテキストに関係なく自分が得意なことに話を持っていこうとする。それで、周りが理解してくれない認めてくれないと言い出す。理解してくれない認めてくれないという認知の問題ではなく、言っていることが状況に合わず、単に役立たずなんだとわからなければ。

>hrjn これすごく重要だなーと思う。

> 平たいコードをみて発狂した強強エンジニア()がOOP的なコードを混ぜてしまった結果読解不能に陥ったコードを何度か見たことがある。

>

> 一度構造が崩れると割れ窓みたいなものでいろんな流儀が混ぜこぜになり、つよつよ天下一武道会みたいになって誰もメンテできなくなる

>nishio 僕が20歳の時に平たい関数群で記述されたベクトル計算ライブラリを見て、ベクトルクラスを作って演算子オーバーライドしていい見た目で記述できるように書き換えて、性能が出なくて捨てざるを得なくなるって体験をしたのはいい勉強になったのだなぁと思い出した

>nishio 当時の僕はadd_v3(v1, scale_v3(s, v2))みたいなコードがv1 + v2 * sと書ける「べきだ」と考えていたわけだが、実際にやってみて「書ける『とよい』」に過ぎず、たくさんある価値観軸の一本に過ぎなくて、「速い『とよい』」の方が強かったと知った。「べき」「正しい」ではなく「有用」への相対化

>nishio 置き換えるにしても、性能上の問題が起きる可能性を予見して、まず主要なところだけ実装して性能比較のテストをするべきだった。しかし当時の僕は考えが足りなかったから、ベクトル計算ライブラリの全書き換えをして、既存のものと差し替えて、そこで性能問題に直面した。