この本が翻訳に値する理由
私は、「情熱的なプログラマー」という本についてのhabrasocietyと私の意見を共有したいと思います。 この本は2009年に出版されましたが、ロシアのプログラマーの間ではあまり広く知られていませんが、それにもかかわらず、多くの人がそれを非常に価値があると考えています。 Chad Fowler（本の著者）は、豊かな経験を読者に伝えるために最善を尽くしました（彼は現在CTO 6Wunderkinderであり、20年以上の開発経験があり、彼の広範な経験と興味のために、RubyおよびITカンファレンスの歓迎ゲストです） 。 はい、この本をどのように見つけたか覚えていませんが、Kent Beck（テスト駆動開発とエクストリームプログラミングのイデオロギー的インスピレーション）からの導入が、この本を読む理由となったことを覚えています。
この本は特定の技術、アルゴリズムなどについては説明していませんが、開発者が時々遭遇することに関するヒントがたくさんあります。やる気の欠如、優先順位の選択、プログラミング心理学、経営陣や同僚との関係。 概して、プログラマーとして輝かしいキャリアを積む方法について多くの指示が与えられています。 もちろん、経験豊富な開発者は彼のアイデアのいくつかを非常に明白に感じるかもしれませんが、キャリアのごく初期段階にある人にとって、この本を読むことは間違いなく時間の良い投資になるでしょう。 大きなプラスは、本が非常に読みやすく、英語に堪能であれば、実際に数日で読むことができるということです。 出版社がまだロシア語に翻訳していないのはなぜだろうか？
この本を読んだ後、私はチャドに興味を持ちました。 ネットで彼のブログを見つけました。 判明したように、彼は彼の本から彼の章をレイアウトし始めました（現在、53の内2つの章が出版されています）。 私はHabrの翻訳の許可を求めましたが、彼はそれは良いアイデアだと答えましたが、最初に私が彼に私が翻訳したいものを正確に書いた手紙を送る必要があります。 返信後、1週間沈黙があったので、2番目の手紙を送りました。再び返事はありませんでした。 その後、彼からWunderlist（彼が現在担当しているサービス）への招待状を受け取りました。 一般に、明示的な禁止がなく、これらの章がすでにパブリックドメインにあり、彼が私を完全に忘れていない場合、翻訳を行うことができると感じました。 一般的に、翻訳がコミュニティに役立つ場合、他の章の翻訳を続けます。 テキストに誤りがある可能性があるため（校正を数回行いましたが、突然）、事前に謝罪し、プライベートメッセージですべての問題をお知らせください。
パニックにならないで
私はコンピューターゲームが大好きだったので、プログラマーとしてのキャリアを始めました。 Commodore 64のカセットからゲームが開始された日から、私は彼らのインタラクティブ性と、プレイヤーが自分の世界にどれだけ深く没入できるかということに単に魅了されました。 私はこの事実を認めることに恥ずかしかったが、時間が経つにつれて、それには何の問題もないことに気づいた。 それはともかく、コンピューターゲームは、モニター画面の画像を、私にとってより快適で、私を喜ばせる何かに変えてくれました。
好きなゲームはid SoftwareのDoomでした。 私は特に他のプレイヤーに対するネットワーク上のゲームモードが好きでした-デスマッチ。 自分の中でプレーしたい人は、電話回線を介してモデムを介して、または通常のシリアル接続を介して互いに接続し、狭い場所で戦うことができます。 私はデスマッチがとても上手でした。 私はこれが私の職業になる可能性があると冗談を言いました-私はそれがとても上手でした。 驚くべきことに、実際には単純な目標を持つ他のプレイヤーとの決闘は非常に複雑です。 チェスと早送りの非常識な組み合わせとして、ゲームの優れた技術的スキルと心理学の両方を使用する必要があります。
分野のスキルをアップグレードする最良の方法は、マスターの動作を観察することです。 私の趣味の運命の当時、皮肉なニックネーム「ノースキル」 （「狂気」-翻訳者のコメントのしゃれ）で知られているそのようなマスターがいました。 NoskillはDoomの現チャンピオンでした。 北米中の人々は、彼と一緒に遊ぶ運を試すために高価な電話代を支払うことができました。 戦いは、内蔵のDoom記録機能を使用して保存されました。 それらのそれぞれを確認しました。
私にとって、Noskillの職人技の秘密はそれほど時間はかかりませんでした。 もちろん、彼はゲーム自体は非常に得意でしたが、彼の成功への明らかな鍵もありました-パニックに陥ることはありませんでした。 Doomは、ラウンドが開始してから数秒で終了するようなゲームでした。 本当に速かった。 私は最初のデスマッチを覚えています：登場死、出現死、出現死 長い目で見れば、数秒以上生き続けることができたとき、私は自分が今いる場所をほとんど理解できず、廊下をあてもなく走っていることに気付きました。
しかし、Noskillはそれをしませんでした。 これらのメモでは、状況がどれほど困難であっても、彼は常にリラックスしており、次に何をすべきかを常に知っていたことがはっきりと見えました。 そして、彼は常に現在のコンテキストが試合の全体像にどのように適合するかを知っていたようです。
今、他のゲーム、特にスポーツを思い出すと、すべての最高のプレーヤーがこの品質を共有していることがわかります。 実際、私たちが賞賛する本や映画のキャラクターでさえ、この品質を共有しています。 ヒーローはパニックに陥ることはありません。 彼らは望むものは何でも手に入れることができます。都市や飛行機のcrash落を狙った核爆弾ですが、いつでも助けを見つけたり、生存者を助けたり、敵を裏切ったり、少なくとも涙が出ることはありません。
また、実際の生活に外挿されています。 すべての計画努力にもかかわらず、私の職業生活は一連の緊急事態と災害でした。 プロジェクトは非常に遅れて完了しました。 私のプログラムは落ちていましたが、それは私の雇用者に本当のお金と私への信頼の損失をもたらしました。 悪い副大統領に悪いことを言って、政治的な敵を育てました。 通常、このようなものはすべて一緒に波に巻き込まれ、順番に来ることはありません。
最悪の瞬間、私はパニックに陥りました。 私は自分自身を閉じ、各イベントを個別に考慮して戦術を開発することができました。
しかし、発生したすべての災害を振り返ってみると、どれも私のキャリアに持続的で顕著な影響を与えていないことが明らかです。 どんなにパニックに陥り、動揺したとしても、どんなにうつ病を経験したとしても、本質的にそうではないこれらの表面的に危険な状況すべてに対処できました。
この警官は私に何をくれましたか？ なし。 これらの状況のそれぞれに対する否定的な反応には利点がありましたか？ いや パニックが本当に貢献したのは、私が本当に最高であることが本当に必要だったときに最高になることができないことでした。
はい、ストレスの多い状況でパニックを解消するように単にアドバイスすることは、実際にこのアドバイスを実践するよりも簡単であることを認めなければなりません。 それは誰かに「ただ幸せになれ」と言うようなものです。 もちろん、これは良いアドバイスですが、その方法は？ すべてが崩壊したように見えるとき、どうすればパニック状態を回避できますか？ この質問に答えるには、なぜパニックに陥っているのかを少し考える必要があります。
視点を失うとパニックに陥ります。 何かがうまくいかないとき、それに注意を向けないことは難しい。 これが悪いと言っているのではなく、ある程度まで問題を解決する良い方法です。 しかし、残念ながら、このアプローチは別の問題の原因になります。主要な問題がどれほど小さくても、それだけが重要であるように思われ始めます。 問題はどんどん増えており、ストレスのレベルは増加しており、その結果、私たちの脳は単純に消えています。
あなたが知っている最悪のコンピューターユーザーは誰ですか？ 私にとって、これはほとんどの場合、私の両親または私の配偶者の両親のいずれかです（私はそれが誰であるかは知っていますが、ここに彼らの名前を書かないほど賢いです）。 この人がコンピューターの前に座って、何をしようとしてもエラーメッセージが表示され始めたときに作業プロジェクトを完了しようとしているとします。 私たちのほとんどは、同様の状況を目撃しています。 経験の浅いコンピューターユーザーはすぐに動揺し、さまざまな奇妙なことを始めます。 何度も何度も表示される潜在的に有用なエラーテキストを無視して、ウィンドウを熱心にクリックしてドラッグし始めます。 最終的に、彼らは非常に興奮して、もちろん、電話する前に1つまたは2つの付随するシステムで完全な混乱を起こした後、助けを求めます。
私がgloめているとは思わないでください。おそらくあなたが知っているような主人公でこの状況を説明したいと思います。私はあなたに心から笑ってほしいです。 この動作はばかげています。 そう？
面白いのは、問題に遭遇してパニックになり始めたときに、人が快適ゾーンの外で働くという現実のシナリオを示したことです。 これは、私の開発が期限に間に合わなかった、予期せずにシステムを台無しにした、または単にクライアントを失望させた瞬間に私が反応した方法とあまり変わりません。 それはすべて異なる状況で起こりました。
まあ、それは私が実際にパニックにならないことを学んだ方法です。 何か悪いことが起こり、不安になり、パニックを引き起こそうとしていると感じ始めると、私はそのイライラしたユーザーと自分自身を比較し始め、自分自身を笑います。 私は、親relativeがその荒れ狂うワードプロセッサに対処するのを助けるかのように、第三者の観点から状況を分析します。 突然、複雑に思えた問題が簡単になります。 そして、この悪い状況、それは実際にはそれほど悪くなってきていません。 多くの問題の解決策は非常に単純であり、文字通り私の顔に叫ぶという事実に出くわすことがよくあります。それは、次に何をすべきかを伝えるエラーのダイアログと同じです。 あなたの心が逃げず、エラーメッセージを読むことができれば、問題は解決できます。
行動する！
1.パニックログを開始します。 一番下の行は、発生する前にパニックをインターセプトすることです。 これは、新たな感覚や感情に対する「リアルタイム」の認識を養う場合に可能です。 事後の反応や状況を分析することでこれを行うことを学びました。 バックグラウンドでフローを開始して新たな思考を分析するほどクールではありませんが、オフラインで分析を実践すれば、リアルタイム分析を行うことでどんどん良くなることがわかりました。
反応を分析することで自分の仕事をより良くすると言うことと、実際にそれを行うことは、2つの異なることです。 ロギングはプロセスの構造化に役立ちます。 毎日特定の時間に（リマインダー付きのカレンダーを使用してください！）、テキストファイルを開いて、パニックを引き起こした状況を記録します。 週に一度、コンパイルされたリストを見て、パニックを引き起こした各状況の長期的な結果を評価します。 パニックを起こす価値は本当にあったのでしょうか？ この状況に対する最も合理的な対応は何でしょうか？ 主人公は警戒心ではなくあなたの人生についての映画で何をしますか？
いくつかの練習の後、パニックが忍び寄る間に分析が行われることがわかります。 リアルタイムでパニックの原因を合理的に調査することにより、パニックが後退し、最終的には消失することがわかります。
PS 2009年のハブで、この本の翻訳プロジェクトが始まりました。
プログラミングへの情熱
プログラミングへの情熱。 第2章謝辞
プログラミングへの情熱。 第3章はじめに
プログラミングへの情熱。 パート1（市場の選択）。 開始する
プログラミングへの情熱。 パート1.アドバイス2.需要と供給
プログラミングへの情熱。 パート1.ヒント3.コーディングがすべてではない