第一章「実用的な哲学に焦点を当て、」ノート - この記事では、「小さな仕事から専門家への実用的なプログラマー」を読んでいます。あなたはキャリアプランニングを行っている場合は、より気持ちになり、この本を読んだ後、いくつかの開発経験を持っている、本の最初の章では、プログラマの最も基本的な要件のいくつかについて話しました、そしてこの本は良い参考意義です。今、私は最初の章の内容について話を自分の経験を兼ね備えています。
責任
責任は小さく、大きな人生計画として、あなたのコードの前提を取得するために全力を尽くすことです、私はこれが最初の段落の最初の章として、それの原因だと思います。責任はあなたが、もちろん、前提とするためのイニシアチブを取る、それはあなたのコントロールを超えた場合、あなたはそれのために右の責任を負いません持っているものです。そうでなければ、プロセスは言い訳、過ちを認めることに正直でないべきである場合でも、責任を取る必要があります。私はほとんどのプログラマが自分のコードのための強い責任感を持っているだろうと思い、結局、それは子供のようなものだ、当然のことながら、責任感があまりにも頻繁にミスを認めるに消極つながります。実際には、職場での指導者たちは、従業員がミスを認めるためのイニシアチブを取ることができることを、誰もがミスをしないように保証することはできません好むが、ミスはそれをスタッフであっても、任意の拒否ポットを隠す、リーダーシップは、より多くの重要なタスクを実現するために彼を信頼していないかもしれ。
エントロピーソフトウェア
エントロピーは、物理学の概念であり、システム、ソフトウェアのスプロールが、我々はそれを呼び出すには、「障害」の合計量を意味する「ソフトウェアの腐敗。」ソフトウェアの腐敗につながる何のためとして、著者はつまり、私たちはしばしばを聞く、「壊れた窓」の例を挙げて「割れ窓理論」。簡単に言えば、長い時間のための未修復のままに壊れた窓は、廃棄物の感覚を生じさせます。だから、彼らは人々がポイ捨て、落書きを始め、窓を壊し、家の最終的な構造は激しく損傷、および感覚を放棄し、修理の所有者が、現実になるものを超えていました。壊れた窓理論インスピレーションを得た警察署は厳密にも、いくつかのマイナーな例であり、大規模な事例の発生を防止することができます。
ソフトウェア開発、貧しいデザイン、不正なコードや低品質の文書では、「壊れた窓」が、修理を参照してくださいする必要があり、障害のこの状態を聞かせて、より深刻な、ソフトウェアの腐敗につながることができません。もちろん、我々はすべての「壊れた窓を」クリーンアップするための時間とエネルギーを持っていない可能性があり、我々はいくつかのTODOを追加したり、特に特別な契約を引っ張って、文書化に焦点を当てることができます。だから、何の良いプログラマ、唯一の悪い設計、コードやドキュメントがありません。
茹でカエル石のスープ
当社の開発プロセス、と他のチームの必要性は、多くの場合、我々が遅れるように見えるんどのような他のチームを無視することは容易です。この時は良い習慣では、我々は最初の版を自分のアイデアが上陸して入れ、設計、開発する必要があり、あなたと共有するいくつかの肯定的な成果があります。他の人がこのことは、成功に向かって移動され表示されたら、他の人が私たちを助けて喜んで、そして最終的にプロジェクトを完了するために協力する、もちろん、結果はみんなと共有する必要があります。この問題を説明するために、著者らは、物語を伝える3人の飢えた兵士が原因戦争の年に、村を通過し、そこにある、村人の食べ物が不足しています。その後、兵士たちは、いくつかの石を入れた水のポットを、沸騰ます。兵士たちは、それは「石のスープ、」あなたは少しニンジンがより美味しくなります置けば、村人はニンジンをピックアップして逃げたと言った驚い村人に語りました。兵士はそれがより良いいくつかのジャガイモを入れ、他の村人たちはジャガイモを取得するために戻ったことになると述べました。その後、食事を楽しむために一緒に、より多くのボリュームたっぷりのスープ、究極の兵士と村人が、物事をより多くの食品になってきました。これは、「石のスープ」の場合です。もちろん、仕事はほんの一部の村人は、物事の自分の所有物を出すことを望んでいないと同じように、適合しないいくつかのチームに実行されます。これは、方法はありません、多分他の人が行うにはより重要なものを持っています。この場合、少なくともそれは私たちに、このような問題を解決するための新たな視点を提供します。
村人の観点から、この場合も、それは我々が積極的に大きな画像に注意を払って、中に参加すべき価値のあるものであれば、他の人が何に注意を払うように、ビジョンの狭すぎるフィールドではないと、私たちに警告しました。1は、ぬるま湯でカエルをしないことを自分自身のコンテンツについて頑なにのみ責任を負うないでください。だから、石のスープとゆでカエル一見二つの別々の場合、いくつかの接続があります。
ユーザーの関与
通常、我々は他の人のためのソフトウェアを書いているので、完璧なソフトウェアは、ユーザの関与を必要とします。機能ソフトウェアの要件だけでなく、納期、ソフトウェアの品質要件、ユーザーのニーズを無視して、新機能のブラインドを追求懸念に加えて、実際のプロフェッショナリズムのコードがごまかしていません。私の実際のお客様の事業、製品であるビッグデータワーク、に従事して、彼らはデータのニーズを無視した場合、盲目的に、製品の分析をいくつかのクールな指標を追加し、助けないかもしれないが、これは明らかに間違っていますA。また、納期のため、練習も望ましいのプロジェクト機能要件の品質を無視して。だから、私たちはしばしば、ユーザーのニーズと技術的手法間の完全なトレードオフを満たす必要があります。
知識資産
私たちはしばしば、プログラマの若い人は、その知識資産が時間に敏感であることを聞きます。私たちの知識、私たちの会社や顧客のより低い値では、私たちの価値観は低いです。そのようなことが起こるのを防止するために、我々は我々の知識資産を扱うなどの金融資産を処理する必要があります。著書に、各四半期を読んで、毎年新しいプログラミング言語を学ぶ（定期的に自分自身を投資）。以下のような他の技術スタック、とのより多くの接触を学ぶ：アルゴリズムデータ（分散投資）の大きなバックエンド技術の先端を理解し、理解してください。我々は人々の大半を（低買って高く売る）リードしている人気のあるときに流行が、勉強する時間がかかります前に、新しい技術、新しい技術に焦点を当てています。常にあなたが風邪持っている場合は、（定期的に資産を再評価）の新しい方向に必要な経験を与えることを決定し、市場での技術の彼らの把握を評価します。私たちはしばしば、彼らの価値を確保するためにのみ、金融資産としてその外国人の知識資産を見つけるために、このセクションを読んで、食べて、プログラマ若いご飯に反論するために外国人を取ります。
為替
プログラマが、生活は非常におしゃべりではなく、仕事で頻繁に通信、小さなインターフェースプロトコル、大規模な建築デザインの多くを必要とします。一方では、彼らの視点の出力に一方で自分の仕事の交流を促進するために、自分の影響力を確立することです。、あなたの聴衆を知っている通信の時間を選択し、コミュニケーションスタイルの選択、ドキュメントがクリアされているかどうかを、通信の前に彼のアイデアに注意を払う、交換は、他人の意見に耳を傾ける聴衆が参加しましょう、通信をまとめる必要があります。同時に交換プロセスは、次のような、いくつかの詳細に注意が必要です、他人を返信。
概要
各のこの部分を要約すると、一見複数の独立したが、実際には特定のリンクがあります。最初の責任は、後続ので、コンテンツのための前提条件です。第二に、私たちは自分の仕事をしたいプログラマーとして、「エントロピーソフトウェア」で独自のソフトウェア解決するために、私たち自身の仕事に基づくことを教えてくれる「壊れた窓を。」私たちは、自分のことを行うとき、私たちは、それがの内容である我々が協力する方法を必要とする大規模な共同の体からなる、ソフトウェアに参加する他の人々を必要とする「ゆでカエル石のスープ。」私たちは、ソフトウェアを開発し、最終的には顧客のために価値を創造し、ユーザーのニーズを解決するために、そのプロセスがなければなりません「ユーザの関与。」私たちは製品の顧客満足度を開発してきたが、プロセスの知識は、我々は時間に敏感使用していますが、「知識資産」このセクションでは、以下の場合には、自分自身が貴重せていることを教えてくれる。最後に述べた「コミュニケーション」たちの上に彼らの影響力を確立するため、出力することができるすべての努力をすることです。
国民の関心番号へようこそ「ヤードを越え、」私はもっと良い本を共有します
