プログラマは意外とプログラミングをさせてもらえない現実
http://tech.a-listers.jp/2011/05/12/programmer-does-not-write-code/
現実：多くのプログラマは下記の事に多くの時間を費やしている。（順不同）
- 外部のプログラマーのMLへのメールやテックでない人へのメールを用心深く書く
- ミーティングに参加、モックアップやDBスキーマの作成、要求された機能へのパフォーマンスの心配
- バグレポートを書く、過去のバグを検索
- 複雑なシステムの障害の原因を何ギガもあるログを探索して調べる
- ダウンタイムについてユーザーや上司への説明
- 他人の問題の解決へ協力
- ドキュメント、本、ブログ、リリースノート、脆弱性アナウンスを読む
- 必要な既存の名前の分からないようなコードを探す
- 見つかったコードが自分の環境に互換性がありライセンスに問題がなくコミュニティが生き残っているかを検証する
- ソフトウェアをインストール、設定、テストまでしてみたがけっきょく自分の環境では動かない
- エラーメッセージをググる
- 公開されているコードを調べて「あるOSSがどう動いてるかを調べる」
- ソース管理ツールやbash、GNUツール、Linuxのファイル権限について学習
- IDEやVM、サーバー、データベースの設定
- 共存できないように設計されたコードをなんとかひとつにまとめる方法を考える
- おわりなくやってくるタスクに優先度をつける
こんな恵まれてる環境ならいいんだけどね
- 名も知れぬ前任者が遺した負の遺産，スパゲッティプログラムの解読にひたすら時間を費やす．工数の９５％くらいが解読作業のことも．
- ミーティングに参加．プログラミングのプの字も知らない開発責任者に何度も説明を繰り返す．（けど，やっぱりわからんと言われて振り出しに戻る）
- OSSを使えばすぐ済む作業なのに，自社の独自仕様ガラパゴスライブラリを解読してなんとか動くようにする．しかしドキュメントもなく開発者もおらず，バグだらけのコードであるため，トラブルが再発するのは時間の問題．*1
- 藁にもすがる思いでエラーメッセージや関数名をぐぐる．が，独自仕様なので答はもちろん見つからない．
- 「仕様書を全部読んでその通りに作れ」と厳命される．苦労して全部読んでみたら中身はスカスカ．これでいったい何をどーしろと？
- コードを修正していて仕様の詳細について不明な点が出てきたので，担当社に確認したら「そのくらい自分で考えろ」と逆ギレされる．
- ドキュメント、本（の一部）、ブログ、リリースノート、脆弱性アナウンスを，社内の英語の分からないプログラマや管理職向けに翻訳する．
- バグを修正しろと言われて，とりあえず過去の類似のバグでも調べる‥‥調べようと思ったら，バグの内容は口伝でのみ伝わっていた．しかも一番詳しい人は既に退社していた．
- 数々の困難を乗り越えて修正が完了した．．．．と思ったら仕様変更が入って必殺ちゃぶ台返し．
日本だとこういうことって良くあるよね？
http://b.hatena.ne.jp/entry?mode=more&url=http%3A%2F%2Ftech.a-listers.jp%2F2011%2F05%2F12%2Fprogrammer-does-not-write-code%2F
- id:ryoasai でも、日本のSI業界にいるとこのような技術系の仕事に集中できるとはなんと恵まれた環境なのだと思ってしまう。
- id:steel-plate 誰も見ることのない設計書の作成が抜けてる
泣きたいほど同意．
- id:harumomo2006 昔は5%もなかった。仕様書の作成時間が一番で、動作確認などの検証時間が二番目に長いかな。段ボール箱10箱くらいの書類の運搬、レビュー報告書、バグのお詫びレポートの作成も多い。
- id:steel-plate 誰も見ることのない設計書の作成が抜けてる
- id:rightgo09 消防士が火ばっかり消してないようなものじゃないの？
一方で，凄腕プログラマは火消しばかりやらされていた．
- id:hiroomi 「ドキっとしますよね。」ギック。
十中ハックそうでしょう．
「プログラマーの情熱を奪わない開発プロセスとは？ 」
http://slashdot.jp/developers/article.pl?sid=11/05/13/180240
ついでにメモ
