「型」とか言いつつ結局は過去の障害でボコられた経験値の差なんだよな。若手はこれ読んで震えろ
あたりをつける。
この辺の勘と経験、今ならAIでどこまで肉薄できるんだろう
全部やってる。どうやればこうなるのか逆算する。最近は素直にチャッピーに質問を投げて発想を変えてもらってる。エラーメッセージ貼ると、解決してくれるから堪らん。答えがわかっていても質問すると勉強になるね。
う～ん、多分全然違う。常日頃からこういう機能を開発するとこの手のバグが起き易いみたいな事を考えてる。初手からほぼ限定できる。パフォーマンスは要求次第。改善できる場合は初手の開発が不味い時がほとんど。
仮想DOMみたいなもんで、システム構造は頭の中で作っておくのは普通のことじゃないの?まさか表面に出てきたところを最初からなぞってるわけじゃあるまい。そんなの時間がかかりすぎるだろうに。
妄想力。過去の被害を未来の糧にするためには妄想力だ
"4. 計測してから動く 「遅そう」「怪しそう」で修正しない" ここ大事、若い頃は仮説だけで動いて時間を無駄にしがちだった
AIに代替されるタイプのしらみ潰し型シニアエンジニア仕草っぽさある
AI原因きり分けで対処できるんだけど、ちゃんとたどり着けないケースあるんだよね。 直近だと、キーボードのファームウェアバージョンアップで直った入力不備と、vpn利用時にwslからsslログインできない時のwtu設定。
仮想DOMみたいな構造を脳内イメージに常備できていれば端折れるけど、引き継いだシステムとかだとそうもいかないので汎用化された手順が必要となる。あと計測できるケースとできないケースがどうしてもある…。
チャッピーと開発出来る時代は良いなぁ。エラーコードでググるくらいしか無かった時代はしんどかった。英語のサイト引っかかって、Accessのバグだったとかさ。
年を取ると二分検索的に原因を特定するのが楽しくなる
勘ですよ、勘
“1. まず全体を見る”の前に「0. 勘で何個かの仮説を立てる」があるよ。と書いたら「2」にそれっぽいのがあった。ただ「仮説なしに掘り始めると、異常を見逃しやすい」はどうだろ。仮説を立てると逆に思考に縛られる
git bisectでバグの出るコミットとでないコミットを詰めてコミット特定したけどメモリエラーだったので全然違うところのバグだった経験を思い出した。バグの特性と対応する特定手順は引き出し本当大事。
７にあたるが、「ITエンジニアに二度同じ障害は通用しない」の気構えで、しっかり障害の記録を取っておくの大事。ノウハウの積み重ねが大きな財産になる。ピンチはチャンス。
「まず全体を見る」と全体を見るのが最初化のように言ってるのに「見る前に予測する」なんて言っていてどっちが先のつもりで書いてるのか。全体的に雰囲気で物を言ってる。
あんま事前に予測を立てない方がいい気がするんだよなぁ、〜はないだろうとか思想の範囲を狭めるのは危険に思う
大体やってた。ただし予測はピンポイントで勘が働いてるときだけだな。
「なんか変なこと起きたから調べてくれ」というエンジニア未満は不要
この機能でこんな障害おこってるけど可能性調査してってaiにいう時代だよ ClaudeとかCodex使えない職場は…
仮説は立てるけどあんまりそれに寄りかかって調査すると原因見つけられないこと多いよ。エラーメッセージで仮説以外のメッセージフィルタリングして根本原因見逃してる例を何回も見てきた。
二分探索みたいな感じだよ。慣れると染み付いてライン探るムーブだらけになる
言語化してて偉い
最初のほうがふんわりしてるけど全体的に良い内容では
調査中は常に「今、自分は何を確かめようとしているのか？」という問いに答えられる状態を保つ。答えられなくなったら、それは迷子になっているサイン
言語化されてるのを眺めると、「あの時にあの先輩に言われてこうやるようになったな」「あの障害調査で手間どって以来この作法を守るようになったな」など思い起こされて感慨深い
更に立場や技術的・経歴的に偉い人が言っている事も疑うってのがある
ソフトウェアエンジニアの経歴に「ミュンヘン国立バレエ団」という文字が現れることはなかなかないと思う
シニアエンジニアが呼吸するようにやっている「調査 / 切り分けの思考の型」
「型」とか言いつつ結局は過去の障害でボコられた経験値の差なんだよな。若手はこれ読んで震えろ
あたりをつける。
この辺の勘と経験、今ならAIでどこまで肉薄できるんだろう
全部やってる。どうやればこうなるのか逆算する。最近は素直にチャッピーに質問を投げて発想を変えてもらってる。エラーメッセージ貼ると、解決してくれるから堪らん。答えがわかっていても質問すると勉強になるね。
う～ん、多分全然違う。常日頃からこういう機能を開発するとこの手のバグが起き易いみたいな事を考えてる。初手からほぼ限定できる。パフォーマンスは要求次第。改善できる場合は初手の開発が不味い時がほとんど。
仮想DOMみたいなもんで、システム構造は頭の中で作っておくのは普通のことじゃないの?まさか表面に出てきたところを最初からなぞってるわけじゃあるまい。そんなの時間がかかりすぎるだろうに。
妄想力。過去の被害を未来の糧にするためには妄想力だ
"4. 計測してから動く 「遅そう」「怪しそう」で修正しない" ここ大事、若い頃は仮説だけで動いて時間を無駄にしがちだった
AIに代替されるタイプのしらみ潰し型シニアエンジニア仕草っぽさある
AI原因きり分けで対処できるんだけど、ちゃんとたどり着けないケースあるんだよね。 直近だと、キーボードのファームウェアバージョンアップで直った入力不備と、vpn利用時にwslからsslログインできない時のwtu設定。
仮想DOMみたいな構造を脳内イメージに常備できていれば端折れるけど、引き継いだシステムとかだとそうもいかないので汎用化された手順が必要となる。あと計測できるケースとできないケースがどうしてもある…。
チャッピーと開発出来る時代は良いなぁ。エラーコードでググるくらいしか無かった時代はしんどかった。英語のサイト引っかかって、Accessのバグだったとかさ。
年を取ると二分検索的に原因を特定するのが楽しくなる
勘ですよ、勘
“1. まず全体を見る”の前に「0. 勘で何個かの仮説を立てる」があるよ。と書いたら「2」にそれっぽいのがあった。ただ「仮説なしに掘り始めると、異常を見逃しやすい」はどうだろ。仮説を立てると逆に思考に縛られる
git bisectでバグの出るコミットとでないコミットを詰めてコミット特定したけどメモリエラーだったので全然違うところのバグだった経験を思い出した。バグの特性と対応する特定手順は引き出し本当大事。
７にあたるが、「ITエンジニアに二度同じ障害は通用しない」の気構えで、しっかり障害の記録を取っておくの大事。ノウハウの積み重ねが大きな財産になる。ピンチはチャンス。
「まず全体を見る」と全体を見るのが最初化のように言ってるのに「見る前に予測する」なんて言っていてどっちが先のつもりで書いてるのか。全体的に雰囲気で物を言ってる。
あんま事前に予測を立てない方がいい気がするんだよなぁ、〜はないだろうとか思想の範囲を狭めるのは危険に思う
大体やってた。ただし予測はピンポイントで勘が働いてるときだけだな。
「なんか変なこと起きたから調べてくれ」というエンジニア未満は不要
この機能でこんな障害おこってるけど可能性調査してってaiにいう時代だよ ClaudeとかCodex使えない職場は…
仮説は立てるけどあんまりそれに寄りかかって調査すると原因見つけられないこと多いよ。エラーメッセージで仮説以外のメッセージフィルタリングして根本原因見逃してる例を何回も見てきた。
二分探索みたいな感じだよ。慣れると染み付いてライン探るムーブだらけになる
言語化してて偉い
最初のほうがふんわりしてるけど全体的に良い内容では
調査中は常に「今、自分は何を確かめようとしているのか？」という問いに答えられる状態を保つ。答えられなくなったら、それは迷子になっているサイン
言語化されてるのを眺めると、「あの時にあの先輩に言われてこうやるようになったな」「あの障害調査で手間どって以来この作法を守るようになったな」など思い起こされて感慨深い
更に立場や技術的・経歴的に偉い人が言っている事も疑うってのがある
ソフトウェアエンジニアの経歴に「ミュンヘン国立バレエ団」という文字が現れることはなかなかないと思う