プログラマが知るべき９７のことを読んで学びがあったと思ったこと「その５」です。
今回のポイント
プログラミングをテーマにしたエッセイ集です。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
97ではなく、107個のエッセイがあります。
スキルの高い方々が書いたエッセイですから勉強になります。
今回は、自分が学んだこと「その５」として
間違えると痛い人に見られそうなポイント
のキーワードで引用しながら書こうと思います。
例外を握りつぶして一目にふれさせない
予兆になるべき例外を握りつぶし続けて、データを壊すレベルの大トラブルになって初めて問題が発覚する・・。
そんなケースの対応は、かなりイラつきます。
プログラム修正以外に、データリカバリまで必要になり、対応工数が爆発的に増えて、ユーザにもボロクソに叩かれますから。
まさに。
try-catchブロックをコードベースに大量に入れれば、「例外が発生しても絶対に止まらない」というアプリケーションを作ることが可能なはずです
。ただ、これは、もう死んでいる人の体を釘か何かで固定し、無理矢理立った状態にしているようなものですが・・・・・・。
これです。
だから、エッセイを読んだとき
彼は「例外に関する情報をユーザの目に触れさせてはならない(NEVER LET THE USER SEE ANE XCEPTION REPORT)」それがUIデザイナーのおきてだ、と言ってきました。
すべてを大文字で打ったところから見て、これさえ言えば話は終わるだろうと思ったようでした。
銀行のATMなどで突然ブルースクリーンが出ることがまれに起きますが、そういうATMのコードを書いているのは彼のような人間なんじゃないか、と思ってしまいました。
こういうヤツが開発したのか・・と苦い記憶を思いだし、うんざりします。
やっぱり「例外」とは「発生してはいけないこと」です。
だからこそ。
- 例外が発生したら、情報を残して止まる・・のが正解。
- 例外が発生しないように、エラーチェックされたプログラムを作る。
- 例外が発生しないように、テストを十分に行う。
これは大事だと思います。
これを崩すと、自分のプログラムを見ながら「痛い野郎だ」などと毒づかれたりするんだろうな・・と想像してしまったりします。
常に長時間オフィスにいるような働き方
長時間労働を、やらざるをえない状況というのはあります。
でも、常にするものではない。
自分はそう思っています。
だから。
長時間オフィスにいれば、プロジェクトに多大な貢献をしているような錯覚に陥ることもあゐし、同僚たちもそう思ってくれることがあります。
しかし事実はまったく逆で、自分の働く時間や労力を減らせば減らすほど、プロジェクトへの貢献は大きくなると言えるのです。
ときには、頑張って働くよりも、働かずに済む努力をした方が、はるかに大きな貢献ができることもあります。
この意見に賛成です。
さらに。
ソフトウェア開発や、プログラミング技術全般についてもずっと勉強を続ける必要があります。
勉強の手段は様々です。
本を読むのもいいでしょうし、カンファレンスへの参加や、他のプログラマとの情報交換なども役立ちます。
新たな実装テクニックを試したり、作業の効率化に役立ちそうなツールを探したり、使い方を調べるといったことも大事でしょう。
脳外科医や航空機のパイロットと同じく、プロのプログラマなら、知識と技術の研鑽を怠ってはならないのです。
それには主に、帰宅後や休日などの時間を利用することになります。
会社の仕事で夜遅くまで、残っていたり、休日出勤をしたりしていたりすると、それができなくなります。
この意見に対しても、まったくその通りだと思います。
ここ20年ほどの間の技術の進歩はすさまじいものがありました。
自分も、それまでの経験・知識・スキルがゼロリセットされて、何の役にもたたなくなるくらいの変化を何度も経験しました。
そのたびに、変化に追随できずに辞めていく人も何人も見てた経験を踏まえると。
結局、変化についていけたのは、コンピュータが好きで、新しい技術の勉強を「楽しい遊び」としてやれていた人間だけだったなと思います。
だから。
状況にかかわらず、常に長時間オフィスにいて「頑張っているアピール」をしている人が、そういう「遊び」の時間をとれていると思えないので、「今だけを見ていて、技術の進歩に取り残された痛い人」にならなければいいけど・・と心配にはなります。
優秀な人の仕事を評価できない経営者
他人のしていることが簡単に見えるのは本当です。
エッセイの中にもこう書かれてます。
他人のする仕事というのは、どういうものであれ、遠くから見ているとどうしても実際より簡単に思えてしまうものです。
自身が開発を経験していないマネージャは、プログラマの仕事を簡単だと思ってしまいますし、逆にマネージメントの経験のないプログラマは、マネージャの仕事を簡単だと思い込んでしまいがちです。
いや・・まったく・・その通りだと思います。
スポーツとかで顕著なんですが。
一流の選手はすごく難しいことを簡単そうにやります。
それだけ見ていると誰でもできそうに思えます。
でも、ほかの人にはできません。
こういうことは、仕事でも同じで、ニコニコと何も苦労していない風に結果を出していた人の凄さがわかるのは、その人がいなくなった後だったりします。
まんまの例が、エッセイにありました。
何もかもが常に順調に進む部署がありました。
納期には絶対に遅れず、深夜までデバッグに追われるということも、顧客から緊急でバグ修正を求められるということもありませんでした。
あまりにスムーズなので、会社の上層部は、物事がまるで自動的に回っているかのように思い込んでしまいました。
そして「プロジェクトマネージャなど不要なのでは?」と考えるようになったのです。
プロシェクトマネージャがいなくなった後、その部署の仕事ぶりは他と何ら変わらないものになってしまいました。
納期には遅れ、バグは大量で、リリース後も絶えずパッチをあてているという有様になってしまいました。
まさに、これ！！。
この会社の上層部は「能力のある人を評価できない凡人であることを自覚できていない」究極の痛い人です。
でも、明日は我が身かもしれません。
事実として。
優秀な人を評価できるのは、その人と同等以上に優秀な人だけです。
でも、優秀かどうかは相対評価的なところがあるので、ある日、自分が評価できないくらい優秀な人間が部下になる可能性は常にあるわけです。
うまく使えれば「超ラッキー」。
でも、上記会社の上層部みたいに「痛い上司」の仲間入りリスクもある。
そんなとき、心がけるべきは。
- 自分が相手より凡人であることを自覚する。
- 目に見える頑張りよりも、結果を客観的に評価する
- 自分がわからないことを、簡単だと思い込まないようにする
みたいなことなんだろうか・・などと、エッセイを読みながら思ってしまいます。
今回はこんなところで。
ではでは。