プログラマーは何を恐れていますか？

プログラマーは、すべての人々と同様、恐怖症を持っています。 誰かがマニアックを恐れ、誰かが人を追いかけるアヒルであり、誰かが通常の日課を破るとパニックに陥り、誰かがスマートフォンで突然失われた接続からピン止めを始めます。

私がそう言うなら、これはすべて、世代、国、大陸全体に固有の普遍的な人間恐怖症です。 しかし、他の職業の代表者が理解しそうにない純粋な職業恐怖症があります。

恐怖症は、人生と仕事の両方で悪です。 なぜなら、恐怖の対象は偽造されており、恐怖そのものが現実だからです。 そして、恐怖の結果は現実です。

この記事では、本当のプログラマーと彼らの喜びのために彼らが生きて働けるのを妨げた彼らの専門的な恐怖症の物語があります。 実在の人物、架空の名前。

コンスタンチン

コスティアは自信に問題があります。 彼は最近プログラマーになり、以前はシステム管理者でしたが、高度な工学教育を受けていました。

コスティアは幸運だったのかどうかはわかりませんが、彼はすぐに弟子や部下になりました。彼は天才の経験豊富で自信を持っていました。 。

アルゴリズム、フレームワーク、リクエスト、アーキテクチャ、ユーザーとのコミュニケーション、開発アプローチなど、すべてを一度に教えました。 すべてうまくいきますが、非常に権威主義的です。 メンターは、問題に対する唯一の真の解決策は彼自身であると信じていました。

コスティアが独自の選択肢を持っているなら、コスティアは彼にふさわしいものを手に入れた。 彼は経験も慢も彼の意見を守る能力も持っていなかったので、彼はいつも寒さの中にいた。 メンターは彼を説得するだけでなく、彼を地面に踏みつけました。 これがコンスタンティンの主な恐怖症になりました。 その状況では、その上司は恐怖症でさえありませんでしたが、不十分さに対する完全に普通の自然な反応でした。 狂犬のように。

それからコスティアは別の仕事に出かけ、恐怖症は彼と共に去った。

ここでは上司は非常に適切でしたが、彼はKostyaに何か問題があるとすぐには考えませんでした。 ある種の特殊性だと思った-Kostyaは問題を解決する最善の方法を考えるのに時間を費やしすぎた。

このトピックには標準はないようですが、問題を解決するための3つのよく知られた方法のどれを考えてから1時間で決定するかは8時間ほどです。 そして、これは、Costeの3つのバリアントすべてが既知であり、理解可能であり、3つのソリューションすべての最適性がほぼ等しいという事実にもかかわらずです。

Kostyaが特定のオプションを実装するための直接的な指示を「伝える」のに役立ちました。 しかし、上司はこのアプローチを好まなかった-彼はプログラマーの乳母になりたくなかった。

また、「何かを解決してやろう」など、コスティアに圧力をかけることは意味がないことを実験的に発見することができました。

ボスは同僚のように、コスティアは退屈で、憂鬱で、退屈なオタクであり、首に追い込まれなければならないと判断しました。

しかし、彼らは彼にもう一度チャンスを与えることにしました。 むしろ、コスタを整理する機会を与えてください。 彼らは彼が展開し始めた適切な雰囲気を作り出し、最終的に彼の最初のメンターの物語を語った。 しかし、コスティアは彼女を目立ったものとは考えていませんでした。

コスティアの話の後、ボスは恐怖症をつかみ、行動を変えようとしました。 Kostyaが長い間ソリューションを選択していた理由を理解しました-慣性によって、潜在意識レベルで、「間違った」オプションを選択した場合、彼は再び地面に踏みつけられることを恐れました。

しかし、実際には、これらの8時間の間に選択の余地はありません。Kostyaは、警戒のセキュリティの幻想に長くとどまるために、最大期間の避けられない事態を単に延期します。

上司がとった措置は簡単でした。

まず、彼はコスティアと長く詳細な議論をしました。 彼は、最初のメンターに話すことを気にしないと説明しました。

彼は平凡な算術演算をもたらしました-3つのソリューションはすべて、8時間何もせずに3時間で完了します。 はい、たった1つのオプションだけが生き残りますが、Kostyaは筋肉を刺激します。経験とプログラミングスキルは彼にとって余計なものではありませんでした。

第二に、しばらくの間、定期的に、タスクの重要性を減らしました-ほとんどの場合、世界とクライアントの運命は彼らのソリューションに依存しません。

第三に、個人的にも、トラッカーで解決されたタスクを通じても、骨を毎日観察し始めました。 彼が再び恐怖症に陥った瞬間をつかむために。

その結果、1〜2か月で恐怖症は去り、コスティアはチームの本格的なメンバーになりました。 そしてしばらくして-チームで最高。

ジェナディ

Gennadyはインテリジェントプログラマーでした。 世界最高ではありませんが、彼が直感的に選択した特定のニッチでは、平等なものはまれでした。

ジーンは長い間一人で働いていましたが、常に世界のコミュニティと連絡を取り合っていたため、コードを書く方法としない方法を理解していました。

そのため、Geneは、ほとんどの場合無料で、オープンソースで製品を配布していました。 これは、消費者プログラマーがダウンロード、クローン、またはフォークしたものの内部を見続けていたときでした。

そして、これらの「内部の覗き見」は、Gennadyを恐怖に陥れました。 これから、govnokod Geneを書くことには道徳的権利はありませんでした。

大小を問わず、Geneはうまくやらなければなりませんでした。そのため、プログラマーは、配布されたときに、次のように言うことができます。

これらのまさに言葉-他のプログラマーの推定-は、遺伝子の薬になりました。 彼は「クライアント向け」または「クライアントの問題を解決するため」のコードをほとんど書きませんでした-プログラマーからいいねを受け取るためのコードを書きました。 彼の決定のほとんどすべては、可能な限り抽象的で、引き裂かれ、他のソリューションや他のクライアントに簡単に適用できました。

遺伝子がした最も奇妙なこと。 彼は数十のソリューションを作成し、それぞれが顧客のニーズを完全に（さらには十分に）満たす一方で、プログラマー間での無料配布でヒットしました。

しかし、Genaは困難に直面し始めました-彼はもはや「単なるコード」を書くことができませんでした。 すべてのクライアント、すべてのプロジェクト、すべての製品には、賢明ではないにしても簡単に解決できるタスクがあります。 そして、あなたが賢明であるかどうかを判断することは難しく、誰にでも合う美しい抽象的なソリューションを作ろうとします。

この問題は、Genaがすべてを連続して公開しなかったという事実によって悪化しました。これには十分な強度も時間もありませんでした。 コードをパブリックドメインに置くだけでは、いいね！ その結果、Genaは全世界のために生まれたソリューションのキューを形成し、1人のクライアントがそれらを使用しました。

ジーンはバカではなく、彼は何かが間違っていることを理解していました。 彼はクールで美しく、技術的でエレガントなソリューションを「テーブルに」作ります。 この状況は彼を落ち込ませました。 一方で、私は時間を見つけてすべてを公開したかったのですが、時間が経つにつれて困難がありました-ジーンは良いプログラマーであり、それゆえに人気のプログラマーでした。 一方、彼は恐怖症、またはmania病にかかっているという感覚を捨てず、最も一般的な問題を解決するために一生懸命に努力しています。 彼は、コードの各行から傑作を作成する試みをあきらめることをますます考えました。 コーディングの効率、そしてその結果、現在の収入がはるかに高くなることを理解しました。 最終的に、Geneは他のプログラマーのようなものを収益化できませんでした。

そして恐怖症は激化し続けました。 それぞれの問題を解決して、Geneはコードを引き裂き、他のプロジェクト、友人、見知らぬ人で使用できるようにコードを引き出して公開する方法を考えました。 このアプローチがどれほどの時間を費やしたかを理解しています。 彼は、アーキテクチャと通信を慎重に検討することを強制するだけでなく、タスクの条件を変更することも強制しました。

Genaがユーザーが入力したデータをチェックするように求められた場合、彼は任意の形式でチェックを実行できる抽象的なカスタムコンポーネントを作成しました。 Genaが販売ファネルのような図を描くように求められた場合、彼はほとんどすべての図を描くためのコンポーネントを作成しました。 Genaがシステムの現在のユーザーが実行するタスクの数でウィジェットを作成するように求められた場合、Genaは実行されたシステムのデータを表示する任意の数のウィジェットを描画するためのコンポーネントを作成しました。 Genaが商品のリストの価格を返すWebサービスを作成するように求められた場合、Genaは、アクセスレベルごとに可能で、本文で転送された設定に従って構成されるシステムレベルのデータを返すユニバーサルサービスを作成しました。

ジョブを変更すると、問題は悪化しました。 ジーンが公開する時間を持っていなかった決定のプールは前の仕事に残っていました-ジーンは誰かの権利を侵害したくありませんでした。 左のソリューションの急峻さを後継者に伝える試みはすべて失敗に終わりました。新しいプログラマーは、Gennadyのユニバーサルソリューションを捨てて独自のソリューションを作成することを好みました。 クールではなく、エレガントでも、抽象的でもありませんが、独自のものです。 それは理解できます-プログラマーは自分のコードを作成するために支払われ、他の誰かのコードを使用しないために支払われました。 はい、そして当局の目を少し上げて、彼の前任者の製品にたわごとを注ぐことは、まったく罪ではありません。

ジェンナディーの恐怖症は、人生そのものによって治癒しました。 企業間でのいくつかの移行の後、コミュニティの公開ソリューションと失われたソリューションの比率が脅かされました-1対9。ジーンは自分が何年も人生を無駄にしていたことに気付きました。 もちろん、完全に無駄ではありません-経験は残っていました、そして、彼が普遍的なコンポーネントを作成するタスクに直面したとき、Gennadyは平等ではありませんでした。 しかし、そのようなタスクは、さまざまなジョブで10〜50％でした。

彼は抽象的に他の問題の解決を止めました。 より正確には、彼は自分自身に対して異なるレベルの抽象化、つまり個人的な経験を思いつきました。 ソリューションを作成するだけでなく、今すぐ誰かに提供できる具体的な製品を作成する必要はありません。 この製品は、Genesで発生したこのような問題を解決するための個人的な経験です。コードを最初に作成するよりも、コードを再現する方がはるかに短時間で済むためです。

その結果、Gennady自身の評価によると、彼の総有効性は3〜5倍に増加しました。 この図には、抽象コンポーネントと状況依存ソリューションの両方が含まれています。

しかし最も重要なことは、Gennadyがユニバーサルソリューションを公開するラインを失ったことです。 はい、彼はそれらをより少なく作成し始めました。 しかし、100％を公開しました。 彼は、ただちに公開できない決定を下すことをやめました。

その結果、公開に至り、Gennadyのいいね！を集めたユニバーサルソリューションの総数は、損失の漏斗がなくなったため（9分の1）、2〜3倍に増加しました。

アルカディ

Arkadyは20世紀の製品です。 以前の患者も過去千年に生まれましたが、アルカディはその中で一生を過ごすことができ、彼は大人、成熟した人として新しい世紀に出会いました。 企業にインターネット、携帯電話、コンピューターがほとんどないときにコードを書きました。 当時は、プログラマーや製品がほとんどなかったため、コードを雑誌のように読むことができました。次のリリースを待ち、楽しみ、議論します（もちろんオフラインのみ）。

プログラマーとしてのArkadyの設立中、タスクは異なっていました-より基本的で、重要で意味のあるものでした。 当時、企業はファッショナブルなものを注文せず、本当に必要なものだけを注文しました。 技術の習熟度もまったく異なるものである必要がありました。すべてを知る必要がありました。 もちろん、当時の選択はもっと少なかった。 しかし、アセンブラは不可欠であり、データ交換インターフェースは言うまでもなく、ドライバでさえ独立して作成する必要がありました。

このすべての現実がアルカディに深刻な痕跡を残しました-彼は困難を恐れることを完全に止めました。 彼はあらゆるレベルのソリューションを作成することができます。あるいは、低から高までのすべてのレベルを含む複雑なソリューションを作成することができます。

21世紀には、アルカディは不快な傾向に直面しました-遠くなるほど、ますます狭い専門家、いわば消費者になった他のプログラマーに理解されなくなりました。 新しいタスクが発生すると、プログラマは既製のコンポーネントを探すために急いで行きました。 さらに、開発に必要な時間はできるだけ短くします。 APIヘルプが優れていて、コンポーネント呼び出しを作成するのが簡単であればあるほど良いです。 そして、アルカディアにとって最も理解しにくいことは、プログラマーがコードをまったく見なくなったことです。 既成のソリューションから製品を組み立てるだけで、最小限の労力で組立てられ、生産されます。

プログラム担当者は、複雑で大規模で複雑なソリューションについては考えていません。 数百、数千のプログラマーを持ち、それぞれが独自の専門性を持っている企業だけが、現在そのような製品を考えています。

現代のITの世界の現実は、Arkadyと他のプログラマとの間にかなり大きなギャップを作りました-彼らはもはやお互いを理解していません。 アルカシャが何を、どのように、そしてなぜ行うのか、誰も長い間理解していなかった。 彼の決定は大規模で、技術的にも方法論的にも複雑であり、コンポーネントの高度な分離と深い哲学的意味を持っていました。

長い間、ユーザーインターフェイスからでも、そのソリューションを完全に理解した人はいませんでした。数人しか見なかったコードは言うまでもなく、エラーが発生したときだけです。

まあ、それは何ですか、あなたは尋ねますか？ ファイナライズまたはリファクタリングでエラーまたはタスクが発生するまで、誰も長い間他の誰かのコードを見ていません。

はい、誰もこれをアルカディに説明していません。 または説明したが、彼は理解しなかった。 または理解したが、受け入れなかった。 または受け入れられたが、忘れていた。 ポイントではありません。

Arkadyは、プログラマーの全世界が彼と同じように配置されていること、誰もが自分のコードを見て、彼の決定を理解し、アーキテクチャとインターフェイスに関する実用的なアドバイスを与えることができることを依然として心から信じることが重要です。 そして、アルカディ自身もそのように振る舞います-彼は彼が扱うすべてのものの本質を掘り下げます。

彼のコードが読まれたという自信は、それに従ってArkadyを機能させ、無意味な最適化に多くの時間を費やします。

彼らが望んでおり、彼の決定を完全に理解するという自信は、常にアルカシャをうつ病に追い込んでいます-世界は、誰も何も理解したくないことを常に示しています。 時々、プロジェクトで人々と一緒に働いて、Arkadyは1年間、誰もがすべてを理解し、突然確信すると思います-再びすべてが上になります、それが速くなければ、飛んでいないだけです。

このような世界のデバイスによる経験は、数日間、通常の仕事のチャンネルからアルカディをノックアウトする可能性があります。 これらの数日間、彼はまったく結果を出さず、そこからさらに苦しみ始めます。

世界が彼の期待を満たさないことを確認するたびに、アルカディは驚き、dしている。 しかし、それは外側から見ることができます-魂にこれ以上の驚きはありません、またはほとんどありません。 シミュレートされたサプライズ、実際ではありません。

時間が経つにつれて、アルカディは彼の周りの人々は彼の期待を満たしていないという考えに慣れ、彼自身は彼らのようではありません。 そして彼は彼のこの非類似性を維持しようとしているので、彼は写真に驚かされ続け、他の人の決定を（彼がそれらを使用しなくても）完全に理解し、他の人に彼の基準とアプローチを遵守するように要求します。 簡単に言えば、アルカシャは恐怖心を維持しようとしていますが、彼は長い間理解していました-その下には長い間土がありません。 恐怖症-彼らは自己防衛しています。

まとめ

私はライブで見た3つの恐怖症について書きましたが、それらはもっとたくさんあることを理解しています-人と恐怖症の両方。

恐怖症は目に見えないため、複雑で危険です。 人はかなりまともに見え、うまく機能し、効果的に働き、笑顔でチームの普通のメンバーになることができますが、同時に恐怖症になり、それに苦しむことができます。

他人、そしてもちろん自分を観察すると、恐怖症の兆候に気付くことがあります。 主な症状は重要です。 タスク、アクション、属性、儀式、アプローチ、反応、少なくとも何か。 恐怖症があるとき、重要性があります。

戦闘中の偵察により、実験的に、あなたが間違っていなかったことを確認できます-人にとって過度に重要なもの、彼が取りつかれているもの、単純なまたはフリーズを引き起こすアクション、プロセスの抑制を削除し、オフにします。

状況が良くなった場合-素晴らしい、あなたは間違っていませんでした。 そうでない場合は、そのまま返して、もう一度見てください。

観察と信頼は恐怖症に対する最良のレシピですが、それらは主に指導者とともに働きます。 したがって、かなり少数の人々。 そして、これは単なる確率です。

わずかな監督者が、恐怖症の存在を判断するために、いつの間にか、穏やかに把握し、静かに観察することはほとんどありません。 「はい、あなたは鼻水で、お尻に行きました、あなたたち、または誰」と言う方がはるかに簡単です。 したがって、恐怖症は残ります、そして、彼らは彼らと共に運ばれなければなりません。 そして隠すので、お尻に再び送信されませんでした。

しかし、適切なリーダーにとって、恐怖症を扱うことは本当の宝です。人間の動機へのほとんど直接的なアクセスが開かれているからです。 特に、リーダーが人が恐怖症を克服するのを助けることができるなら、恐ろしい病気からの回復のように、これは決して忘れられません。