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

svnからgitへ移行したんですが、「gitの使い方よくわからない」って言って今までのsvnのリポジトリのまま作業してる人が居て…。gitチュートリアルやった日にそいつ休んでたの気づかなかった。

人間の品質管理をするとしたら、品質の低い人間はどうするの？
デスノート？？？

ロースキルプログラマー「難しくて分からない」（スキル不足で理解が追い付いてない）
ハイスキルプログラマー「難しくて分からない」（てめえが作った仕様書意味わかんねえよ）

2分どころか、言語仕様とプログラムの仕様を完全に理解していれば、バグの内容を見た瞬間に「このバグなら絶対にここでしか発生しない」と推測できる場合もある

帰り遅いので、輪読会のための事前読込＋資料作成はほぼ進んでないに等しいんですが、明日は休みで時間取れるので明日から進めていきます。

上の人が言う「仕様書を細かいレベルまでちゃんと書いたから、あとはただコーティングしてくだけ」は信用しないことにした

上の人が作った仕様書がグダグダなのは、まず最初に懸念点、不備を最初に洗い出してからやったほうがいい気がした。
今回、それができてなくて時間食った気がする。

#redmine

Redmineのチケット運用。
みんなでプランニングして、後輩にエクセルに予定工数書き込ませて、チケットのCSVインポートをさせてる

参考資料
RedmineでチケットのCSVインポート - Qiita https://qiita.com/momosetkn/items/e482f693459d3608fc61

【後輩に教えたデバッグのテクニック】

バグってるシステムには、正常なデータが入る入口(input)と間違ったデータが出てくる出口(output)がある。
入口と出口の距離が短ければ短いほどバグの原因に近づける。
まずは、中間地点のデータを覗いてみて「入口」と「出口」の距離を短くしよう。

パーセンテージでの進捗報告は内部的な問題点よりも、「いつ終わるか？」という結論重視な報告で、顧客向けの報告だと思う。
内部向けの報告には問題点が分かるようにタスク分解してサブタスク毎に報告するといいと思う。

#IT業界あるある

なぜか、進捗0%を50%にする実績工数よりも、50%を100%にする実績工数のほうがはるかに大きい。

ばななぱんださんのTPD(Toots Per Day)、高い！
これ、ブーストもカウントされてる？

話遮る行為は、「相手の説明してるその時間が無駄だ、俺に喋らせろ」というメッセージと捉えます。

こっちが丁寧に説明しようとしてるのに、いちいちすぐに遮ってくるし、それでもってこっちの言うこと全く理解してないしで、こんなんでよくITエンジニアやってるなって思った。
話遮ってはいけないです。相手を尊重して話を聞ましょう。

担当しているシステムのファイルアップロードの上限サイズを即答できたり、他の人が悩んでるバグの原因を即答できたり、
「こんなのアジャイルじゃない」とか言って朝会を仕切りだしたりしてるので、
常駐先の人にいい意味でヤバい奴と思われてそう…。

JavaScriptのイベント関連でヘルプ！されたので、見に行った。
イベントがどこに貼られているのか、わかってない感じだったので、Visual Eventを実行して可視化して説明してあげた。

JavaScript初心者への説明にはこれいいツールかもしれない。

仕事って大変だな～。
色んなタイプの人ともうまくやらないといけないんだから。

そういう面では、ぼく協調性無いんだと思います。

コミュニケーションに難があるタイプの人（こっちのターン与えてくれなくてずっと喋る系）に出会った。
今までそういう人種の人とあまり接したことないんで、ずっと言いなりになってしまう…どうすればいいのやら。

偉い人が中間に入ってくれるとめっちゃ楽なんだけど…。ｳｰﾝ。

Momose.Tくん: "徳丸本輪読会第２回目の日程調整・参加申し込みを行います。 場所は東京都内を予定しております。 詳し…" - Qiitadon https://qiitadon.com/@momosetkn/100458667836706505

こちらですが、参加申し込み・調整の入力期限は8/4までとします！

社内のインフラ系エンジニアと呼ばれてる人が「きいたって何？」って聞いてきた。
開発しないエンジニアにはあまり知られていないのかな。