Notices by いつも魚とトマトを買いに来る客 (momosetkn@qiitadon.com), page 125

「転職するとモニタが一枚になるぞ」「ネットに繋ぐと怒られるぞ」「メモリなんて4GBだぞ」「i3だぞ」という国連調査待ったなしの非人道的恐喝

> 当たり前だけど、バグはテストしてないところでバグる。

全くその通りで、逆にテストしたところでバグる場合は、必ず理由がある

ちゃんとテストをしていれば、プロとして「これは分からないよ」と言ってはいけないんだけど、まあこれは事象を素直に説明すればギリギリお客様に許して貰えるかな、と思うバグしか出なかった

逆に、テストに限らず何か気を抜けば、メールの応答が漏れたりとか、誰でもわかるレベルのありえないバグが起きたりとかする
精神論じゃないんだけど、バグを出さないと思ってやっていると、やっぱり単純なケースだけじゃなくて２手先３手先を読みながらバグりやすいところを狙ってテストするようになるし、明らかに手を抜いたバグは無くなる
本当は技術のはずなんだけど、そういう隅々までできるかどうかは、能力以上に執念かなあと思う事が多い

#OKGoogle実話

姪っ子「おっけーグーグル、寝るお話」
:google: 「むかしむかし、三びきの子豚が狼１匹をやっつけました。めでたし、めでたし。」

伯父「えっ？えぇぇ？www」

よほど実力差が無い限りは、Aさんが聞くことというのは、ほとんどの場合Bさんが同じ作業をしていても聞くことになりえる
そういうのを拾った時、チームとしてBさんが"車輪の再開発"をしないようにするのが大事
その機能をAさんが持つのか、Aさんから報告を受けるXさんが持つのかはわからないけど、チームとしては誰かがその機能を持たないといけない

例えばサッカーでも、アシストする機能を持つ人が誰かはわからないけど、誰かアシストする人が居なければ超絶天才が居ないと勝てない

もっと面倒なケースだと、Aさんが聞くことをBさんが漏らしていて聞かないケースで、これは一見Bさんは進捗があるように見えて、実は正しい方向に進んでいなかったりする
これを、AさんがBさんの気持ちになって拾うのは結構難しいので、Xさん（報告を受ける人）からのアプローチが自然かなあと思う

聞ける人が居る前提で、だいたい人に聞いた方が早いと思う
というのは、そもそも解決策が的外れだったり、標準がすでにあったりする場合が多かったりするし、人に聞くことでそういう躓きポイントがあるという共有にもなる
聞くことのメリットは、チーム作業としては本当は聞かれる側にもある
じつは、聞かれた事をどれだけエスカレーションできるかも問われている

もやしっ子を沢山育てるぞ（錯乱）

* コンテキストが業務よりのやつ
* ローカルルール
* 自分が全然詳しくないやつ（標準APIのドキュメントがどこにあるかわからんレベルとか）

あたりは人間に聞いた方が確実に早い

3番目は場合によりそう

音声回答かー、、
mastodonって音声あげられないのかな

【教訓】
・仮想環境でやってダメだった事は、実環境でやってもダメ。
・リハーサルした事だけがうまくいく。リハーサルしていない事は悉くトラブルに見舞われる。
・午後3時には帰路についているはず→午後9時頃には帰れる。
・簡単にできる。→ 失敗して切り戻し。

まあ少なくとも、「お客さんと話すのは苦手、ひたすらプログラミングだけしたい」という人は、フリーランスには全く向いていないのでやめたほうがいいね、というのはあるな…