フレキシブルな思考:経験から学んだ"有用性"の追求
gpt.icon皆さんこんにちは、nishioです。
20歳の時、私はあるライブラリのコードを見て、自分がより「美しい」と思う方法で書き直すことに挑戦しました。結果としてそのアプローチが性能の低下を招き、そのライブラリを捨てざるを得ませんでした。
この経験から学んだのは、「美しさ」だけでなく、「有用性」を追求することの重要性です。私がその時考えていたのは、コードが短くて読みやすい方が「良い」というものでした。しかし、私が試みた改善が結果的には性能を悪化させ、それが「有用」でないことを痛感させられました。 また、私は一気に全体を書き換えてしまいましたが、小さな実験を行なってその結果に基づいて判断することを怠ったので、結果として無駄になる作業にたくさん時間を使ってしまいました。
自己成長と共に、私たちは「べき」ではなく「有用」であることを追求し続けるべきです。自分の技術や知識を日々向上させ、常に最適な解決策を見つけ出す柔軟性を持つことで、より良い成果を生み出せるようになることでしょう。
これからも学び続け、日々の仕事に活かしていきます。皆さんにも、自身の経験を通じて「有用性」を追求する視点を持つことをお勧めします。
感想
私たちは「べき」ではなく「有用」であることを追求し続けるべきです。
元ネタ
sugimoto_kei 郷に入れば郷に従え。その時々に与えられた場でベストの仕事をする。事業企画が大事なら事業企画をする。コードにひきつけない。平たいコードを書くべき場なら平たいコードを書く。OOPにひきつけない。OOPが力を発揮する場なら、思いっきりそれをする。僕にとって仕事とはそういうものだ。 sugimoto_kei 何をするかより、その仕事は何を達成しようとしているのか、それは、自分の側で多少の妥協をしても達成する価値があることなのか、と問う。Yesならば、それを達成するためになんでもやる。自分の経験値が少ないことならその場で学ぶ。 sugimoto_kei 僕が見てきた仕事のできないひとは、コンテキストに関係なく自分が得意なことに話を持っていこうとする。それで、周りが理解してくれない認めてくれないと言い出す。理解してくれない認めてくれないという認知の問題ではなく、言っていることが状況に合わず、単に役立たずなんだとわからなければ。 平たいコードをみて発狂した強強エンジニア()がOOP的なコードを混ぜてしまった結果読解不能に陥ったコードを何度か見たことがある。
一度構造が崩れると割れ窓みたいなものでいろんな流儀が混ぜこぜになり、つよつよ天下一武道会みたいになって誰もメンテできなくなる
nishio 僕が20歳の時に平たい関数群で記述されたベクトル計算ライブラリを見て、ベクトルクラスを作って演算子オーバーライドしていい見た目で記述できるように書き換えて、性能が出なくて捨てざるを得なくなるって体験をしたのはいい勉強になったのだなぁと思い出した nishio 当時の僕はadd_v3(v1, scale_v3(s, v2))みたいなコードがv1 + v2 * sと書ける「べきだ」と考えていたわけだが、実際にやってみて「書ける『とよい』」に過ぎず、たくさんある価値観軸の一本に過ぎなくて、「速い『とよい』」の方が強かったと知った。「べき」「正しい」ではなく「有用」への相対化 nishio 置き換えるにしても、性能上の問題が起きる可能性を予見して、まず主要なところだけ実装して性能比較のテストをするべきだった。しかし当時の僕は考えが足りなかったから、ベクトル計算ライブラリの全書き換えをして、既存のものと差し替えて、そこで性能問題に直面した。