from エンジニアの知的生産術 反響まとめ
試行錯誤の重要性と共有のすすめ
エンジニアが試行錯誤の過程を共有し、透明性を持って行動する重要性についてのツイートのまとめ。特に、この過程を公開することや新しい技術の取り組みにおいて初期の「試行錯誤フェーズ」を設けることが強調されている。
- https://twitter.com/satoru_takeuchi/status/1034487329065295872
- 「エンジニアの知的生産術」の「試行錯誤は見えにくい」という表現、完全に同意
- 人に物を教えるときも、答えや解決方法は教えやすいけど、それを見つけるまでの試行錯誤は伝えるのが難しい
- 答えだけ言うより何倍も長くなる
- 慣れてると自分はいろいろ省略できてしまいますけど教える対象の人にとってはそうでない
- 試行錯誤した結果とか経緯とかを、例えばcommitメッセージなどに残していかないといけないな
- https://twitter.com/mhiramat/status/1034577487110397952
- これがあるので、OSS上で（最終的にコミットを目指して）試行錯誤するときは、一人でやるのではなく、先にMLなりissueなりで問題を提起して、見えるところで試行錯誤するといいんだよね。
- あと、試行錯誤だけじゃなく、品質向上も同じように目に見えない。やはりオープンな場所でやるのが吉。
- git logでは見えない部分ですね
- issue#がついていれば逆引きはできるんですけどね。lkmlだと最近はURLが付けられているからhttp://lkml.org から逆引きできますが、カバーメールに以前のシリーズへのリンクを付けないと辿れなくなる罠が。
- git logでは見えない部分ですね
- https://twitter.com/yoosee/status/1034951720617426944
- 自分に裁量があるプロジェクトで特に新しいフレームワーク・ミドルウェア・パッケージソフトを使う場合は最初の方に「試行錯誤フェーズ」を作るようにしてる
- その期間に試しに作ったものは原則捨てる。
- お作法覚えるまでは写経や試行錯誤が必要
- 実際には自分に裁量が無いプロジェクトも少なくないので常にはやれてないけど、明な試行錯誤なしに新しいことをやると最初に何かを勘違いして作った設計なり実装なりが後々にすごく大きな負債になる
- 人に物を教えるときも、答えや解決方法は教えやすいけど、それを見つけるまでの試行錯誤は伝えるのが難しい
- 「エンジニアの知的生産術」の「試行錯誤は見えにくい」という表現、完全に同意