orange @[email protected]

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

よくわかんないけど(＞＜；)、オレンジがやってたのって再発明だけどなんかちゃんとしたそういうやつもそんな感じっぽい＞＜
やっぱ下流から上流にツリー状にたどって問題解決( 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

低レベル側からを原則にして本当に実践してるプログラマって実際にいるのかわからないけど、もしそういう人がいたら、他人が書いたプログラムで問題が起きた時にその問題の解決の為にはエントリーポイントから細かく動作を追っていくみたいな読み方をする事になると思う＞＜
ごくごく小規模なソフトウェアやライブラリならそれでも日が暮れないだろうけど、ある程度大きなアプリなんかでバグをなおすんだったら、問題が表面化した箇所をIDEやgithubなんかの検索機能で探して、高レベル側から処理の流れとは逆に読んでいくようにソースを読むのが普通だと思うんだけど＞＜

蛇口から水が出ないって場面でたとえて、低レベル側から探索を原則にしてしまうと、「水道料金払ったか？」とかその辺をやったあとに、さっき書いた通り水源の川の源流を求める冒険に出発しちゃう事になっちゃうので、低レベル側からを原則にするのはおかしいかも＞＜

そのたとえで思ったけど、土台から探索って経験則からの問題特定になりがちで、お約束のトラブル、水道なら水道料金、家電なら「ほんとに電源繋いだ？」みたいなお約束パターンをまず検討するって面では便利かも＞＜
なので、お約束パターンは最初に検討すべきかも＞＜
一方で経験則で気づけない範囲であれば当然経験則に頼れないので、高レベル側からになると思う＞＜

問題の切り分けの為に
『正常に動いてる最小セットから、問題が発生する高レベル側に順に結合して問題発生箇所を探る』のと『高レベル側から低レベル側に向かって問題が含まれなくなるまで探索する』ってやり方、
低レベル側から高レベルへの試行錯誤は、『何らかを作っていく場面(設計も含む)』では有用で、
高レベルから低レベルへの探索は、『既に動いているものの問題解決』に有用かもたぶん＞＜

蛇口から水が出ない時に原因を探る時には、浄水場や水源の川の源流から辿っていくと迷子になるので、蛇口から浄水場の方に辿って行く方がいいかも＞＜

ピラミッドでたとえると、一番下の石を見ていくと膨大な上に、載っかる石との関係を見いだせないまま探索して見落としが発生しやすいと思うけど、問題が表面化した箇所の石がどの石に載ってるかって方向で、その石を支えてる石を支えてる石を支えてる石を・・・ってツリー状探索する方が見落としが発生しづらいと思うかも＞＜

オレンジと読み方違うかもしれない＞＜
オレンジはデバッグする時には、問題発生箇所を高レベル側から低レベル側に向かって探索してくけど、この記事だと土台全部見るみたいな感じに読めたけど、低レベル(土台)から探索すると関係する範囲の見落としが発生すると思う＞＜