ここで自分の食事を少し試し、「古」の食事に切り替えることを考えています。 しかし、これは私にとって非常に誇らしいことなので、基本的には、食物に対する私の態度を変えることです。 今日、この分野で十分に実験する余裕があるのは非常に裕福な人々だけです。
人は、低次のニーズが満たされるまで、高次のメリットを大事にすることはありません。 以下は、ニーズのマズローピラミッドの例です。
最近、私は顧客と話をしました。そこでは、1人の優秀な人がコードスタイルにほとんど夢中になっています。中括弧の場所、インターフェイス設計での実証済みのソリューション（「ベストプラクティス」）の使用、重要だがほとんど重要ではない一連のことです。 同時に、ユニットテストは組織で実施されず、「展開」は手動で実行され、アセンブリの検証は不十分でした（「検証可能なビルド」）。
言い換えれば、彼は「私は十分なビタミンAを持っていますか？」という問題に焦点を合わせ、「夕食のために料理するものはありますか？」という問題を見失っています。
私が考えたのは、マスロウのニーズのピラミッドを対象分野であるソフトウェア開発に投影するとしたらどうでしょうか？ カットの下で私がしたことの例があります（「ブレインストーミング」に参加してくれたPhil Haack 、 John Galloway 、 Jonathan Vanagel 、 Paul Stovelに感謝します）。
美しいコード
ポールは、このことについて何よりも自分自身を表現しました。コード：「クラス！ それがスコットのしたことですよね？」
実際、あなたは「ソフトウェアを書いている」のですか、それとも「開発している」（「作成する」）のですか？
これは非常に高貴で間違いなく魅力的な目標です。 しかし、私の意見では、より差し迫ったニーズが満たされた後にのみ努力するべきです。
再構築された（「リファクタリング可能な」）コード
コードのリファクタリングはどれくらい簡単ですか？ あなたはそのような仕事の単なる考えに落胆していませんか？ このプログラミング言語に採用されている規則に準拠していますか？ 典型的なタスクに適した設計、実装、ソリューションテンプレートを使用して、選択したPLの「精神」に従いますか？ 仕事でテスト自動化を使用していますか？
サポートされているコード
次の質問に答えてください：コードを変更することは本当に可能ですか？ 涙のないバグを修正しますか？ はいの場合、編集後に何かが壊れているかどうかを確認する方法はありますか？ 単体テストはどうですか？
ビルドとデプロイの自動化
バージョンを作成するのと同じくらい簡単にシステムを展開できますか？ 継続的インテグレーション（「継続的インテグレーション」）は、間違いなく、ソフトウェア開発の現代世界の標準です。 ただし、より重要なものがあります-継続的な展開（「継続的な展開」）...前のバージョンにロールバックする機能があります。
変更管理
バージョン管理システムを使用していますか？ あなたが受け入れた変更を伴う作業の基準は明らかであり、チームの全員が理解できますか？ コードに加えられた変更を簡単にロールバックし、コードの現在の作業バージョンをマークできますか？ 分岐とマージはどうですか？ なに？ すべてをアーカイブに保管していますか？ 友だち、そうしないでください。クラス管理についてabout音を立てたり、バージョン管理システムが立ち上がるまでUMLダイアグラムを思い浮かべるのを止めないでください。
エピローグの代わりに：リーダーシップの重要性
上記の点は、チームに強力で健全なリーダーを置くことの重要性を強調しています。 もちろん、創造性は優れていますが、プロジェクトの完成までの次のステップに必要なのは、常にそうではありません。 技術的リーダーは、創造的な衝動が適切である時期と、基本的な開発プロセスに真剣に投資する時期を区別する必要があります。
言い換えると、「私たちのチームの食事には十分な緑がありますか？ うーん...全体として夕食会を開催することから始めましょう。