2017-07-07

IT】開発スピードは全力で落とすべきである

頑張って一度速くやると、アホなマネージャー勘違いする

勘違いしたアホなマネージャーは、次もそのスピードを求めるし、他者にもそれを求める

マネージャーだけではない、別領域のアホなエンジニア勘違いする

「何とか間に合わせてほしい」に応じる必要もない

応じた結果品質が少しでも落ちたらこちらの責任にされる、説明無駄である

 

遅いチームはとても楽しそうである

全力でガバガバスケジュールを引いて、入念にコードをチェックして、楽しそうに議論を交わす

コードが正しいかどうか、高尚かどうかが最も大事ことなのだ

事業の都合とか考えなくていい

どうせ今取り組んでいる作業は売上につながらないのだから

リファクタリング設計は開発スピードを上げるために行うのではない

楽しいから、あるいはそれが絶対的に正しいからやるのだ

正しいかどうかは、チームの一番えらいような気がするエンジニアが行う

 

私のように大量の仕事をしてはいけない

何か問題があればコードを書いたもの自分責任になるのだ

極力既存状態を保持し、影響のないように書くべきである

でないと「元のコードが悪い」なんて言えなくなる

いか責任回避するかがこの仕事本質である

 

もし同僚が頑張っていたら可哀想から仕事を遅くしてあげよう

簡単だ、ルールをいっぱい作ると良い

トラックバック - https://anond.hatelabo.jp/20170707112540
  • https://anond.hatelabo.jp/20170707112540

    ウサインボルトが100m9秒58で走れるからって1000mを同じペースで計画するなっていう内容をツイランドで見た

    • https://anond.hatelabo.jp/20170707113429

      分かりやすいな   1人だと分かりやすいんだけど、「陸上選手」みたいに集団になると難しいよな 「ウサイン・ボルトはあんなに速く走れるんだから、お前らも頑張ればできるだろう」...

記事への反応(ブックマークコメント)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん