プログラマーを尊重する方法を学ぶ

ITインターネット企業のこの失礼な現象は、専門家だけでなく、すべてのプログラマーに対しても向けられています。ただ、専門家はたくさんのことを見てきて、それに驚かないので、一般的に表面的なものを使って自分を強調することを好みません。しかし、その謙虚さゆえに、知識の少ない人々からは攻撃の標的になりやすいのです。この失礼な現象は普遍的であり、極めて有害な性質を持っているため、これについて具体的に話す必要があると感じています。以下では、IT 業界の人々を軽視する文化の起源を指摘すると同時に、プログラマーを真に尊敬する方法を人々に伝えるためにいくつかの提案をしたいと思います。これらの提案が会社経営の参考になれば幸いですし、同じ苦しみを抱えているプログラマの方々に精神的な励ましを与えられれば幸いです。

プログラマーを尊重する方法を知っている企業文化は、常に次の点に注意を払うべきだと思います:

コンピューターシステムの歴史的遺産を認識する

コンピューターサイエンスをある程度のレベルまで理解していれば、私たちが実際にはまだコンピューターの石器時代に生きていることを発見しました。特にソフトウェア システムは、歴史に残された数多くの悪い設計に基づいて構築されています。さまざまな設計の悪いオペレーティング システム (Unix、Linux など)、プログラミング言語 (C++ など)、データベースなどは、私たちを悩ませることがよくあります。そのため、いわゆる「経験」が非常に必要になります。 」。しかし、多くの IT 企業はこれを認めたがりません。彼らの通常のスタイルは、「すべてはプログラマーのせいです!」であり、「プログラマーとして、これを知っておくべきです!」というものです。これは、一種の「皇帝」の「新しいインストール」を生み出します。 「現象」: 誰もがデザインの悪いツールを使いたくありませんが、他人に笑われたり、自分の能力を疑われたりするのを恐れているため、誰もデザイナーの間違いを指摘しようとはしません。

私はこの「ハッカー文化」の反例です。特定のツールや言語がわからないという理由で誰かが私にアドバイスを求めるとき、私はいつもそのツールの設計者を簡単に笑って、あなたがそんなくだらないことを知る理由はない、と言いましたが、それはそういうことです。それから私は彼に、これが何なのか、どう使うのか、そして現在の奇妙な使用法につながっている設計上の欠陥について、単刀直入に話しました...すべての IT 実践者は、これらのツールに対してそのような嘲笑的な態度を持つべきだと思います。この方法によってのみ、ソフトウェア業界は、不適切な設計に悩まされたり、精神的な足かせを引き起こしたりすることなく、大幅な進歩を遂げることができます。

要するに、これは非常に重要な「態度の問題」です。ただし、この段階では、設計が不十分なツールを回避して、それらを使用してタスクを完了する方法を知る必要があります。しかし同時に、私たちはこれらのツールを教義として扱い、プログラマーを非難するのではなく、その悪い性質を直視し、認めなければなりません。この方法によってのみ、プログラマーの知性を効果的に尊重することができます。

本質的な知識と表面的な知識を区別し、「経験」をあまり真剣に考えすぎないでください

IT IT 企業には、一見複雑に見えるコマンド ラインや、難しいコマンド ラインに習熟していると考えている人がよくいます。・コマンドを使う プログラミング言語ってすごいですね。これらの人々は、自分の周りの同僚の一部が実際に知識の本質を持っていることに気づいていませんでした。彼らは、既存の知識からこれらすべてのツールを（単に使用するだけでなく）導き出し、さらにはそれらをより完全で便利で便利になるように設計することさえできます。使いやすい。 。より良いツールを設計および製造できる人は、より重要なタスクを抱えていることが多いため、既存のツールの使用法に混乱した場合、非常に謙虚に同僚に問題の解決を手伝ってもらい、混乱していることを大胆に認めます。

あなたがツールの使い方に熟練している人であれば、同僚のささいな要求を自分の「資格」を誇示するための時間と考えてはいけません。この同僚は本当に「恥ずかしがらずに質問する」ことがよくあります。それは彼が「理解していない」のではなく、単に無関心であり、そのような低レベルの問題について考える時間がないだけです。彼の混乱は、ツール設計者の間違いから生じることがよくあります。彼はそのことをよく知っていますが、礼儀正しさから、ツールの設計を直接批判することはなく、控えめに自分自身を責めることがよくあります。したがって、同僚があなたに「謙虚にアドバイスを求める」のは、単に友好的で調和のとれた雰囲気を作り出すためであり、それによって本当に重要なことを行う時間を節約することができます。この種の謙虚さは、彼があなたを崇拝し、自分の技術的能力があなたほど優れていないことを認めているという意味ではありません。

したがって、これに対処する正しい方法は、この混乱についての理解を誠実に表明し、ツール設計の不合理で不合理な側面を率直に認めることです。自分が専門家であると考えるのではなく、この種の謙虚な態度を取ることができれば、同僚はあなたから必要な表面的な知識を喜んで「学び」、次回この種の問題に対処する必要がないようにそれを覚えておくでしょう。 . 退屈なものは気になります。 「この素晴らしいスキルを知っているのは世界で私だけだ」という態度をとると、同僚はあなたとツールを軽蔑することがよくあります。次にこのものの使い方をまだ思い出せないでしょうが、二度と助けを求めに来ることはなく、何度も先延ばしにするでしょう。

命令口調は使わず、自分の意図を説明してください

同僚や部下は奴隷ではなく、コードサルでもないことを常に覚えておいてください。彼らはあなたのために働く必要はありません。彼らは合理的な人々ですが、お金をもらっているからといって、あなたの低レベルの命令に簡単に従うわけではありません。 Google のチームメイトがやったことは良い悪い例です。実際、この Googler は私に「このテキスト行を削除して、これに変更してください...」と言いたかっただけですが、この「高レベルの意図」を直接示したわけではなく、非常に低レベルのコマンドを使用しました。 : 「Ctrl -kを押してください! ...」 そして、その口調はまるで無知な小学生に話しているようでした。

Ctrl-kでテキスト行が削除されることを知らないEmacsユーザーはいるでしょうか?さらに、あなたが今直面しているのは、実際には経験豊富なEmacsユーザーであり、世界クラスのLispです。 プログラマー。ここで誰もが問題を理解できると思います。このような低レベルのコマンドは、論理が不明確であるだけでなく、攻撃的でもあります。私を何だと思いますか？ コードモンキー?この Googler が高レベルの意図を表明した場合、人々は心理的かつ論理的に受け入れやすいでしょう。たとえば、「構成ファイルのこの行を削除して、次のように変更する必要があります。」

と言うことができます。

同様のテクニックは、プロジェクト管理の他の場面でも使用できます。人に何かを頼む前に、まずそれをやりたい理由とその重要性を人々が理解できるように説明する必要があります。この方法でのみ、プログラマの IQ を尊重することができます。プログラマも人間であり、あなたの命令に従うだけのコード モンキーではないからです。

新しい人があなたから学ぶことを期待しないでください

多くのIT企業は、新しい人を初心者として扱い、彼らが自分たちから「学ぶ」ことを期待することを好みます。たとえば、Googleはすべての新入社員を「Noogler」（新人Googlerの意味）と呼び、特別なプロペラ帽子も送っています。これは、子供たちには謙虚であり、「偉大な人物」に敬意を払うべきであると教えることです。 「Google」を勉強すれば将来活躍できるでしょう。

これは実際には非常に間違ったアプローチであり、新入社員の既存の予備知識を無視し、彼らを「偉大なGoogle」の権威に屈服させ、目立たないネジにします。実際、Googleには学ぶ価値のあることが本当にたくさんあるのでしょうか?学校教育は本当に無意味なのでしょうか？それは真実ではない。正直に言えますが、私は最も重要な知識を教授から学びました。私は Google からそれらの本質を超えるスキルを学んだのではなく、その代わりに Google が想像できなかった世界で最も先進的なテクノロジーの多くを Google に提供しました。他の多くの博士学生はGoogleを軽蔑しています。なぜなら、Googleはめちゃくちゃなテクノロジーをたくさん持っているだけでなく、他の企業やすべての学校を超えて最先端のものとしてパッケージ化しており、他の人がそれらから「学ぶ」ことを傲慢にも期待しているからです。 。

外の世界から来た新参者がもたらした特別なスキルを理解し、尊重し、彼らの独自の強みを活かして最大限に活用することによってのみ、彼らが自分たちから「学ぶ」ことを盲目的に期待するのではなく、私たちはこれらの鋭いエッジを維持することができます武器を持って会社を維持します。

プログラマーの仕事量を時間内に測定することはできません

多くのIT企業経営陣は、プログラマーの仕事量を見積もる方法を知りません。あなたが非常に有能で、最も難しい問題を短期間で解決できる場合、彼らはあなたを怠けさせることはなく、他の低レベルのタスクを行うように求めます。これは非常に不合理なアプローチです。たとえば、非常に有能な従業員は、他の従業員の数十倍の馬力と速度を備えたF1レーシングカーのようなものです。もちろん、普通の人なら解決するのに長い時間がかかる、あるいはまったく解決できない問題も、彼の手にかかればあっという間に解決してしまいました。それは、他の人では長い時間がかかる距離を瞬く間にカバーできるF1車のようなものです。仕事量を時間で測定すると、このF1車がレース全体を完走するのにかかる時間は短いため、計算される仕事量は普通の車よりもはるかに小さくなります。 F1レーシングは十分な努力ができていないので、彼に早くもっと努力するよう求めるべきだと言えますか?これは明らかに間違っています。

物理法則は次のとおりです: エネルギー = 電力 x 時間。作業負荷も同様に計算する必要があります。プログラマーを真に理解している賢明な企業は、高レベルのプログラマーが休みなく働くことを期待しません。高レベルのプログラマは新しい方法を見つけることができることが多いため、1 人のプログラマが数人、場合によっては数十人の普通のプログラマに匹敵することもあります。彼らが扱う問題は普通の人よりもはるかに難しく、より多くの精神的エネルギーを必要とします。もちろん、より良い休息、メンテナンス、娯楽などが必要です...

もちろん、これはジュニアプログラマーが働きすぎるべきだという意味ではありません。プログラミングは骨の折れる精神的な作業であり、プレッシャーを伴う残業や過度の作業は効率の低下と品質の低下を招くだけです。

他の人に自分の バグを修正させないでください

これについては専用の記事で説明しました。あるプログラマに別のプログラマの BUG を修正させることは非効率であるだけでなく、プログラマの個人的価値を軽視することになるため、可能な限り避けるべきです。誰かが会社を辞め、その人が残したバグを誰かが修正しなければならない場合、その人は自分の発言に特に注意する必要があります。あなたは彼の助けが必要な特別な理由を具体的に指摘し、この問題はそもそも彼の問題ではないこと、彼がそんなことをすべきではなかったが、誰かが去ってしまったため他に方法がないことを強調し、心から謝罪する必要があります。そのようなことが起こっています。

この方法でのみ、プログラマーは、このまれで特別な瞬間に、他の人の バグを喜んで修正することができます。

無料で入手LAMPBrothersオリジナルPHPビデオチュートリアルCD/「PHPについて話そう」エディション、詳細 公式ウェブサイトのカスタマーサービスにお問い合わせください。

http://www.lampbrother.net

PHPCMS二次開発http://yun.itxdl.cn/online/phpcms/index.php?u=5

WeChat開発 php? u=5

JavaScriptコース

/yun.itxdl.cn/online/cto/index.php?u=5

以上、プログラマーを尊重する方法をその側面も含めて紹介しましたが、PHP チュートリアルに興味のある友人の参考になれば幸いです。