達人プログラマを読んだので要約(1章)
はじめに
新装版達人プログラマ― を読みました。自分の中の要約的な何かを今回は一章分まとめておきます。
1章
前書き
パンピーと達人の差は問題に対するアプローチや、解決手段のアプローチ、問題を抽象化することでより大きな問題を解決しようとする姿勢が違う。
背景を理解することが知的な解決や、見識ある決定を出すことができる
以後の章ではそれらについて解説する。らしい
1. 猫がソースコードを食べちゃった：行うことすべてに責任を持つ
2. ソフトウェアのエントロピー：プロジェクト開始時点での整合性を維持するための方法を解説
3. 石のスープと蛙の煮物：変革を呼ぶための戦術
4. 十分によいソフトウェア：トレードオフ
5. あなたの知識とポートフォリオ：幅広い知識と経験を衰えさせない
6. 伝達しよう！：他人とのやり取りに時間の多くを割いている
1：猫がソースコードを食べちゃった
責任を持つこと：これは常にソフトウェアが完璧に動作することを求めているわけではない。制御外のことまで管理する必要があるわけではない。
むしろ、責任を負わない選択をする必要がある。負うなら、責任を取ることが求められる。過ちや、判断ミスをした場合、そのことを正直に認めて取り得る選択肢の提案を試みる。非を言い訳してはいけない。言い訳よりも対策を用意しろとのこと。
もし問題が起きて説明するときに、その説明は論理的かどうかを心に説いてみようぜってことらしい
2:ソフトウェアのエントロピー
エントロピー：無秩序さを表す指標
ソフトウェアもまた宇宙と同様に無秩序さになっていく。
割れた窓理論：割れた窓が一枚でもあると、住人に投げやりな気持ちが生まれてしまう。そしてそこから破壊が始まってしまう。
ソフトウェアでも同じことが起きうる。割れた窓＝悪い設計、間違った意思決定、質の悪いコードをそのままにしてはいけない。
汚い設計によるコードや貧弱な意思決定などは崩壊の始まりである
3:石のスープと蛙の煮物
石のスープを触媒にして活動する必要がある。
みんなが自分のリソースを守ろうと活動する。そうすることによって「疲労の開始」と呼ばれる現象である。
ここで石＝触媒＝道理にかなった要求を出す。そして要求をうまく引き出せるようそれなりのものを出す＝未来をちょっと見せる。
人はちょっとうまくいきそうなことには参加したくなる。
「変化の触媒たれ」
触媒による変化を受けた人間側にとっては一杯食われされないようにしないといけない。徐々な変化には気が付かないものである
4:十分によいソフトウェア
十分によいをチェックするためのプロセスにユーザーを参加させることをお勧めする。
全くの新規プロジェクトだといろいろ制約あるよね？ユーザーの要求があるにも関わらず、プログラムに新機能をつっこんだりコードを磨き上げてお茶を濁すのは得策ではない。
作るものは品質要求とか適応範囲はシステムに組み込まれている必要がある。このトレードオフ、今日の粗いソフトか明日の完璧なソフトだったら今日の粗いソフトが好まれる。
辞め時を知る：プログラムはまっしろなキャンバスに絵をかくようなものである。芸術家は辞め時を知らないと危険であることを知っている。 プログラムも同じで完璧を追及して台無しにしてはいけない
5:あなたの知識のポートフォリオ
金融ポートフォリオ
- まじめな投資家は習慣的に定期的な投資を行う
- 分散投資は長期的な成功に対する鍵です
- 頭の切れる投資家は有価証券を堅実、ハイリスク・ハイリターンといった観点で分けバランスよく投資している
- 投資家は利益を最大にするべく、安く買い、高く売ろうとする
- 有価証券は定期的に見直して再分配するべきです
エンジニアポートフォリオの作り方
- 定期的に投資を行う
それぞれが小さいものでも継続することで大きなものになる - 多角化
作業している特定の技術におけるすべての詳細を知る必要がある。多くの技術に親しむうちによりうまく変化に適応できるようになる - リスク管理
技術はハイリスク・ハイリターンやローリスクローリターンのものまで多岐にわたる。技術的には両方のものを学ぶ必要がある - 安く買い、高く売る
今後クローズアップされる技術を一般的になる前に学んでおく、高騰する前の株を探すくらい難しいが、先にやればその分野をトップとれる。 - 見直しと再分配
先月投資を始めたばかりの技術が今日には冷たいものになっていることもある
最も重要な要素として定期的に投資を行うことである。
ゴール
ポートフォリオを充実させる知的資源獲得に向けての方法をみていくことにする
1. 毎年少なくとも一つの言語を習得する必要がある
言語が異なると同じ問題でも別のアプローチがある。それを学ぶことで選択肢が広がる。
2. 四半期ごとに技術書籍を読む
月に一冊程度本を読む習慣をつけましょう。
3. 技術書籍以外の書籍を読む
要はエンジニア以外にソフトウェアを使っている。つまり彼らのことを本を通じて理解する必要がある。（これは小説とか自己啓発系の本を読むに通じる？）
4. 講習を受講する
5. ローカルユーザーグループに参加する
足を運ぶだけでなく、活発に参加する。経歴に孤独は禁物
6. 異なった環境に慣れ親しんでみる
OSを変えるなど。家ではUNIXを使うなど
7. 最先端にとどまり続ける
業界紙やその他の雑誌を読もうね
8. インターネットを使う
いろんなことを学べば思考に幅ができる。
学習の機会
批判的な考え方
6:伝達しよう
言いたいことを知る
最も難しいことの一つに言いたいことを明確にする作業である。概略から練ることを満足になるまで続ける必要がある。 何種類か戦略を練ってみよう
聞き手のことを知る
うまく伝えるためには聞き手のニーズ、興味、乗る欲を理解しておく必要がある。聞き手のイメージを WISDOM を理解しておく必要がある
* 何:W（What) 聞き手に何を知ってほしいのか
* 興味:I(Interest) 言いたいことの中にある彼らの興味とは何か
* 洗礼:(Sophisticate) それらはどれくらい洗礼されているか
* 詳細:(Detail) 彼らはどのくらい詳細を知ってもらいか
* 誰の情報(Own) 誰にその情報を知ってもらいたいか
* 動機付け(Motivate) 話を聞いてもらうにはどうするのか
タイミングを選ぶ
情報を伝えるにはそれらに合ったタイミングを選ぶ必要がある
スタイルを選ぶ
聞き手が好むスタイルで伝える必要がある
見栄えをよくする
見栄えをよくする。アイディアの中身は重要だけどそれに付随する外見がよくないと駄目であることを理解する必要がある
聞き手を巻き込む
ドキュメント作成時から読者を巻き込もう。フィードバックを受けることでよりよくすることができる
よい聞き手になる
いい聞き手になってもらうのであれいいい聞き手であるべきである
聞き手の立場になる
質問や連絡が来た場合何かしらのアクションをしないと無礼に当たる。状況を知らせることは大事なことである
