トラブルはきわめて論理的なものです。繰り返しますが『必ずどこかに原因がある』のです。ヒューズが飛んだということは、ヒューズが飛ぶように作ったということであり、音が出ないということは音が出ないように作ったと考えるのがトラブル解決の近道です。何故、ヒューズが飛んだかではなく、どうしたらヒューズを飛ぶアンプを作れるか、どうしたら各部の電圧が正常なのに音が出ないようにできるか、と考えるわけです。この発想ができないとトラブルを効率的に発見できません。
引用元：私のアンプ設計マニュアル / トラブル・シューティング編
あたしはこの考え方に自力で到達することができないうんこだったが故に、無軌道なトライアンドエラーを繰り返してデバッグするうんこプログラマーなのであるという自覚を得ました。割と最近のお話。
で、この考え方そのものはアンプもプログラムもパンもぜーんぶに敷衍することができるものであって、つまり、バグってうんこになってるプログラムや何かで失敗して酷い出来になってるパンも、
「この状態にするためにはどんな要素が必要であるか」
という観点が必要なのであると。
そういった意味であたしが、このあたしが、普段とりもしないメモでもってパンの勝敗記録をつけ続けているのは、それがすなわち、後のあたしの素晴らしいコッペパン焼成の日に至る道のりの道標や地図になると信じて疑わないからであります。
一方、なんでそういう思考ができるにも関わらず仕事ではこれを適用しないクズであり続けようとしてしまうのか、について、よく考える必要があるわけです。
そんなことやっても無駄だと思っているのか、眼前のトラブルを根拠なくナメる傾向があるのか、時間がないとかいうヒネリのない言い訳を思いついてしまうからなのか。
よく考える必要があります。ありますよこれは。