修正してください

仕様が変更になった上での変更であれば、修正ではない。
ので、「変更した理由」と「変更して欲しい意図」を説明する。
その前に一言、「修正」とかチケットで「修正」とつけてはいけない。

その人は「変更前の仕様」を充足した形で実装していたのだから。

バグを出した後の言葉かけ

僕は率直に、見つかってよかったと思うし、そう表現するのだけど、
人によって追い詰める言葉を発してしまう。
追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。
そうなると品質が下がる。意味が無い。

話を自己の経験100%で話してしまう

自分が得られた知見は重要なんだけど
働いてきた場所は10も無いだろう。というので
50%ぐらいに抑えて、後は他社の事例とか、
なんか優れたようなドキュメントとか開発の歴史事例とか
それを示すだけで終える。

経験のみで語るのは、危険すぎる。
変化が早い業界なのに(最近収穫加速の法則でもっと早くなってる気がするよ)。

まず否定から入る

まだ作ったもののないものを作るのに、否定から入るのはダメだ。
発言ができなくなる。「後からフォローすればいいじゃん」は無理。
人間最初の印象が大事で、最初の印象が「否定」だと発言はしなくなる。
それか、出来る場所でするけど否定が初回な場所・人だと発言しなくなる。

多様を認めない

Scala以外は認めないとか、そういうの。
多分、開発経験が少ない。
まず、先に理由があり、適切だったのがPHPだったとか
そういう流れになるようになるべく、
いろいろなものに手をつけて学ばなければ。

そうじゃない場合で、未熟だとわかっていて
適切なものはGoだ！となっているなら、
実例を示すために超簡単なプロトタイプ、実物を作ってしまおう。
作れないなら、空論。