ビデオスピーチ
ケイトは優れたプログラマーであり、優れたスピーカーです。 レポート自体は、C ++プログラミングとプログラミング全般に関する多くの興味深いことを提起しています（一見の価値あり）。 しかし、何よりも、私は彼女が表現した1つ（文字通り）の考えに夢中になりました。 ケイトは非常に簡単に、この場合プログラマーの動機を特定することができました。 彼女は次のように聞こえた：「プログラマは、働きながら、彼の幸せを最大化しようとする。」 それは角質に聞こえますが、本当にそうです。
私たちはプロジェクト、顧客、会社、人類、そして世界の平和を支援していると言えます（そしてこれは真実かもしれません）。 しかし、正直に言ってください。 私たちは人間であり、すべての人々と同様に、私たちの幸福を最大化するために努力します-私たちの幸せを最大化するために努力しています-私たちの人生全体、戦略的にキャリア、現在のプロジェクトで戦術的に はい、私たちはこれを行っていますが、何が私たちを幸せにし、何が私たちを減らすのかを理解するのは良いことです。 これにより、同僚、部下、および自分自身をよりよく理解できます。
報酬、労働条件、上司、スタッフなどの問題をすぐにまとめたいと思います。 あなたが働いている場所で働いているなら、これはすべておおよそあなたに合っています。 コードに直接取り組むとき、私たちを幸せにし不幸にするものに焦点を当てましょう。
テスト
テストを含むすべてのプロジェクトは同様に満足しています。テストを行わない各プロジェクトはそれ自体が不幸です。 一般的にテストのないプロジェクトに比べて、テスト範囲の良いプロジェクトのプログラマーは平均して幸せだと自信を持って言えます。 上司が本格的なテストの作成に同意しなかったプログラマーが、密かに（場合によっては時間外でも）それらを書いた方法を見ました。 なぜこれが起こったのですか？ 書かれたテストは、プログラマをより幸せにします。 まさにその存在は、プロジェクト内の少なくとも何かが業界のベストプラクティスに従って行われていることの兆候です（残りの部分がそうでなくても）。 テストが正常に終了すると、美しい緑色のチェックマークが表示され、プログラマを称賛します（そして、結局のところ、誰も彼を賞賛しないでしょう）。 100％のテストが正常に完了すると、既に何かを信じることができる場合に、足元に何らかの安定した基盤が提供されます。これにより、今日と明日の自信が増し、幸せになります。 そして、失敗したテストでさえその仕事をします-正当な理由でそれを書いたことを知らせ、先見性を称賛します。 プログラマーをもっと幸せにしたいのなら、彼にテストを書かせてください（または強制的に強制することもできます）（もちろん、すべてが節度に優れています）。
バグ修正と新機能の開発
「オデッサ全体についてはお話ししません」が、私の人生で出会ったプログラマのほとんどは、バグ修正レガックコードよりも新しい機能を書くことを好みました。 なんで？ しかし、バグに触れることは他の誰かの不幸に触れることだからです。 誰かのために何かがうまくいかなかったので、彼は彼の悲しみを開発者に伝えるのが面倒ではないほど重要でした。 彼の位置に移動する必要があり、再現してみてください。 そして、結局のところ、それは再現に成功します-そして、認められたバグのために誇りに打撃があります、またはそれは機能しません、そしてあなたは問題を発見したより多くの情報を取得しようとする生きている人と接触する必要があります これはすべて楽しいとは言えません。
同時に、新しい機能を書くことは、潜在的な幸福感です。 私たちはまだ何も壊しておらず、何の罪もない。 新しい問題を解決するために新しいコードを書いています。 おそらく成功するでしょう。 おそらく、私たちは当然の賞賛（ボーナス、プロモーション）を受け取るでしょう。 Maslowによると 、これはすでに人間のニーズのピラミッドの上位レベルに近い。
結論は何ですか？ プログラマの作業はバランスが取れていなければならず、バグを修正する必要はありません。 各プログラマーは、時々新しい機能の開発を委託する必要があります。 はい、バグ修正から逃れることはできませんが、少なくともこの問題で幸福と不幸の「ほぼゼロ」のバランスを達成しようとすることができます。
リファクタリング
良いコードで作業するのはいいことです。 残念ながら、良いコードは空から落ちません。 最初にそれを取って書くことさえ不可能です。 悪いことから良いコードを作成する必要があります。 ここでは、プログラマーが選択を行います。毎日、仕事に来るとき、彼らは苦しみ続け、悪いコードで仕事をするか、それでも良いコードを取り出してそれを試みます。 2番目のケースでは、新機能が製品に追加されず、古いバグも修正されなかった場合、これらのN時間を何に費やすことができるかを理解していないリーダーシップと戦う必要があります。 はい、あなたは戦わなければなりません。 幸いなことに、この戦争には、簡潔で美しいコードのエラーが少なく、そのサポートにかかる時間が短く（コストも安く）、新しいビジネス要件が発生したときに変更に適しているなどの議論があります。 さらに、この戦争は原則として長くはありません。「いいえ、リファクタリングのために月を与えませんが、金曜日に週に2時間割り当てましょう」のような何らかの妥協で終わります。 さて、それは良いことです。 私たちは自分自身に幸福を手に入れました。 はい、まだ自分の手で構築する必要がありますが、これはすでに可能になっています。
最新のライブラリとツールを使用する
多くの人は、何年も前に何らかの理由でコンパイラー（フレームワーク、ライブラリー）でスタックしているプロジェクトで作業しなければならないことの苦痛を知っています。 そのような理由で、ここで新しいバージョンにアップグレードすることは不可能であると説明しますが、いつかは、おそらくそれがうまくいけば...何ができますか？ まあ、最初に、私たちは状況が私たちに有利ではなく、状況が私たちができる以上に不幸にすることを自分自身に認めなければなりません。 第二に、同じ考えが当局（または顧客）によって表明される可能性があります。 誰もがこれについて議論することはまずありません。 そしてこの瞬間、あなたは自分で交渉しようとすることができます：例えば、まさにテスト、新しい機能、リファクタリングの時間です。 （給与を増やすことはできますが、記事の冒頭で私はそれを写真から除外することを約束しました）。
ちなみに、このような便利なタスクに費やした時間は、実際にここで少し幸せになるだけでなく、新しいツールの使用に切り替えることが不可能だった非常に「怖い」理由を排除することもできます。 私の人生の本当の状況：
-新しいライブラリへの移行が新しい問題をもたらさないかどうかはわかりません...2週間後-運用中の新しいライブラリ。
-ここで、このライブラリを使用してコードのテストを200回作成しました。合格してみて、それらを起動します。
-うーん
おそらく他の側面を探求し続けることができます。 しかし、一般的な考え方は同じです。プログラマーを幸せにするタスクと状況もあれば、幸せでないプログラマーもいます。 1つ目よりも2つ目が多い場合-プログラマーの気分と生産性が低下し、遅かれ早かれプロジェクトの問題やチームからの離脱につながります。 したがって、プログラマーとそのマネージャーの両方が、プロジェクト、会社、またはユーザーの「グローバルグッド」だけでなく、開発者に比較的満足し続ける方法についても考える必要があります。 それ以外の場合、ポイントは何ですか？