■http://anond.hatelabo.jp/20130524071640

元ブログ見たけど酷いな。俺なりの解決案を書いてみる。アホなこと書いてるかもしれないが、少なくとも仕事はうまくいってる。

1) 仕様があいまいな場合の適当なコーディング

誰か話が出来そうな人に聞いて決める。納期や現場の人間関係が問題？そんなクソ環境とか知るか。

エラーメッセージは後でトラブルが起きたときに使うんだろ？トラブル解決に必要な情報くらい分かるだろ。

2) 進捗報告

数字でなく、抱えている問題を報告させる。

90％終わってるけれど大きい問題を抱えてていつ終わるか分からないのと、30%しか終わってないけれど後は単調作業で先が読める場合、前者の方が問題だろ。

量じゃなくて質。量は適当。間に合いそうかそうでないかだけでいい。

3) 面倒な繰り返し作業やテスト

自動化は当然として、単調作業だけ一ヶ月はスケジュール組む方がアホ。適度に単調でない作業を混ぜろ。

4) 他人の担当箇所だからいいや

気づいたら報告しろ。嫌いな奴、知らない奴だから報告できない？お前のそのコミュ障をまず何とかしろ。

5) 後から気づく

元増田と同じ。リーダーに報告しろ。

6) 誰も知らないかもしれない仕様

UT作るなり適当にログ入れたら分かるだろ。分かったことからコメント入れていけ。ログ入れたら動かなくなった？そんな言語捨てろ。

番外) 極端に有能なプログラマー

時間が余ったら元増田の言うように仕事の精度を上げるようにしてる。優先度は低いかもしれないけれど、コードだけが成果物じゃないから。

俺ですらこうなんだから、有能なプログラマーならもっといろいろ思いつくだろう。

そもそもの問題点

バレずに、そのまま自分が別の案件や現場に移動するまで逃げ切れれば

万事解決なのである。

俺は一つのシステムを開発から保守までやってるから、逃げようにも逃げられないし、サボったらそれだけ自分が後で苦しむ。逆に頑張れば頑張るほど仕事が楽になっていくからやりがいもある。まず完成したら終わりというクソ環境から逃げることを考えたら？

こんなクソ記事がホットエントリってお前らどんだけクソ環境で働いてるんだ？

Permalink | 記事への反応(1) | 10:11

ツイートシェア