orange @[email protected]

小さいパターンなんてあったっけ？＞＜　って思ったけどやっぱ無いっぽい？ので、でかいに遭遇した次の回に偶然見つけづらいのを引いて小さいのと勘違いした可能性？＞＜
(つまり、でかいパターンに遭遇したんでは？＞＜)

こんにゃくとちくわぶが・・・＞＜

13-10-2023
California signs with Stadler for America’s first hydrogen trains | RailTech.com https://www.railtech.com/rolling-stock/2023/10/13/california-signs-with-stadler-for-americas-first-hydrogen-trains/

[B! 車] 廃業に追い込まれる業者も…訪日観光客のレンタカー事故多発「止まれ」標識が原因に？（テレビ朝日系（ANN）） - Yahoo!ニュース https://b.hatena.ne.jp/entry/s/news.yahoo.co.jp/articles/efa89d22a03892bbd602f54daedf281869d4747a

道路標識、アメリカの道路標識の方がわかりやすいのでアメリカにあわせてほしい＞＜
でも、アメリカの道路標識がわかりやすいのってもしかしたら英語だからで日本語だとごちゃっとして読みづらくなるとかもある可能性？＞＜；

つまりオレンジが「ピラミッドの問題が表面化した箇所の石が、どの石に乗っかってるのか辿って行くように問題発生箇所を探る」みたいに説明した(オレンジは自分で当たり前の事だと思って再発明してたもの)やつは、
ちゃんとした用語(？)では、「ロジックツリー」って言うっぽい＞＜

よくわかんないけど(＞＜；)、オレンジがやってたのって再発明だけどなんかちゃんとしたそういうやつもそんな感じっぽい＞＜
やっぱ下流から上流にツリー状にたどって問題解決( https://mstdn.nere9.help/@orange_in_space/111514075956359263 )って考え方おかしくないんじゃん＞＜
なんでオレンジがおかしいみたいな空気になったのか＞＜

MECEとロジックツリー | ロジック図解・情報整理術実践講座 https://ideacraft.jp/logic/basics/mece_logictree/

サイトの名前はちょっと胡散臭いけど、オレンジが言ってる事とほぼ同じ事が書いてあるページ見つけた＞＜

原因の分析 | ロジカルシンキング研修.com https://www.ltkensyu.com/logicalthinking/1-4/4-4/

ていうかむしろ、場面によって低レベル側から探索すべき場面か高レベル側から探索すべき場面かをある程度適切に判断できない人も、プログラミングを授業かなんかで習っても出来ないタイプの一例なんでは感＞＜

こんな長文を書くまでもなく、デバッグする時は問題が表面化した箇所から処理とは逆順に辿って問題発生箇所を探るのは当たり前に誰もがやってる事だと思ってたので、「そりゃそうだ」って人がそんなに現れないのがマジでわけがわからない＞＜

何年か前にオレンジのおうちのFTTHが突然切れて、NTTの人を呼んで直して貰った時、どこで断線してるのかを探るのにオレンジのおうち側から探索してって、途中で「なんkm辿ったけどまた問題箇所が見つからなかったので、もっと局舎(？)側らしいのでもうちょっと時間かりそうですごめんなさい」的な連絡があったし、これも蛇口から水源に向かってトラブルシューティングする例のひとつかも＞＜

オレンジが言いたいのはつまり、『蛇口から水が出ない時に水源の川の源流に冒険に行っちゃうやつ』に "問題を切り分ける力" なんてあるとは言わないだろうし、プログラミングであっても『低レベルから』を原則にしてしまう( "...一番土台のところからチェックを始める..." )のは源流に冒険に行くやつと同じだし、"可能性をひとつずつつ" ってその可能性の範囲を見極めたり探索する優先度をつける作業こそが "問題を切り分ける力" じゃないの？＞＜
って事＞＜

たまに「マストドンのこの挙動ってバグじゃね？」的な話題になった時に、ソースコードを読みにいった人って、マストドンのコードを低レベル側から読むような読み方してたの？＞＜
オレンジはその問題の箇所を起点にどこを呼んでるか、どこでその値をセットしてるのかみたいに探る方向で読んでたけど＞＜

たとえばオープンソースなオフィススイートを使ってて、「なんかここの表示が壊れてるかも！ ちょっとしたバグだから自分で直しちゃお」って思った時に、そのオフィススイートの膨大なソースコードをエントリーポイントから辿って読むプログラマなんているの？＞＜；
開発に参加しようってなら、時間が許す範囲で目を通しておこうとなるかもだけど、ちょっとなおすのにまずエントリーポイントから読んでくなんて事する？＞＜；
その表示をしてる箇所をまず読んでそこから原因を探ってく読み方の方が一般的というかほぼ全てのプログラマがそうしてるんでは？＞＜

元記事の微妙に微妙な感じでオレンジがひっかかってる点ってつまり
"可能性をひとつずつつぶしていくと..."
って『その可能性の範囲を見いだす能力』こそがタイトル通りにあるといい "問題を切り分ける力" であって、「経験則を多く知ってる」って発想ではしっかりしらみつぶしにって発想とは逆になるし、「低レベル側から漏れなく」では、結局効率のよい問題切り分けとかけ離れて日が暮れるし、切り分けが出来てるとは言いがたい感＞＜

エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba https://bufferings.hatenablog.com/entry/2019/03/31/005750