マネージャーは、人が良いプログラマーか悪いプログラマーかをどのように知るのですか？

プログラミングチームや部門を行うほとんどの企業では、コードを設計および作成するプログラマーと、管理作業を行うマネージャーで構成されます。単にコードを書いていないことを除けば、マネージャーは通常、チームが開発したコードを見さえせず、作業マシンに適切なIDEがインストールされていないことさえあります。

それでも、マネージャーは、人がうまく働いているか、何かを担当するべきか、特定の開発者を最も重要かつ責任のあるタスクに割り当てるべきかを判断する必要があります。最後になりましたが、マネージャーは通常、四半期ごとのボーナスを割り当てます！

上記を効果的に行うには、マネージャーは、もちろん他の特性の中でも、その人が優れたプログラマーであるかどうかを知る必要があります。問題は、彼らがそれをどのように行うのかということです。 彼らは人々が書いたコードすら見ていませんし、プログラマーが開発するコンポーネントの品質を直接評価することもできません...ほとんどの場合！

その秘密は何ですか？

通常、マネージャーは

• プログラマーは何かを成し遂げますか？
• 彼らの同僚は彼らについてどう思いますか？彼らが書くコードは？
• プログラマーはマネージャーと明確にコミュニケーションを取っていますか？
• プログラマーは新しいことを学ぶのを楽しんでいますか？彼らは他の人をうまく指導していますか？
• 彼らは仕事を成し遂げるために多くの管理の注意が必要ですか？
• プログラマーは自分の仕事を楽しんでいるようですか？

彼らは通常、従業員のコードを見ない（またはしばしば理解しない）のは事実ですが、上記の従業員のコードは、従業員が雇用主によって課されたプログラミングの役割にどれだけ適合するかを測定するための合理的なプロキシとして機能します。誰かが物事を成し遂げず、同僚から低学年を取得し、うまくコミュニケーションできず、異なるテクノロジーに不満を感じ、その後慣れていて、常に監督が必要であり、常に不幸である場合、それは良い兆候ですこの仕事とうまく噛み合う。*

*ただし、異なるコンテキストと環境では、彼らは非常に幸せで熱狂的であるかもしれません。たぶん、彼らが反対したそのような種類のプログラマーであり、異なるコンテキストで非常にうまくプログラミングできるかもしれません。「プログラマー」とは、場所によって非常に異なる仕事を意味する場合があります。しかし、マネージャーは主に彼らの「プログラマー」の役割と従業員がどの程度適合するかを気にします。

私は、マネージャーがコードを見ないという主張には同意しません。チームを管理したとき、すべてのエンジニアの出力の一部を見てきました。大きなものはコードです。しかし、それだけではありません-メール、デザイン文書、ホワイトペーパー-すべてが考慮されます。

しかし、それが間違いなく唯一の要因ではありません。ある男が隅に座って素晴らしいコードを書いているが、彼は話をする獣であり、質問に答えず、ステータスを共有せず、開発の問題が発生したときに妥協しない-私は彼がそうだとは確信していないチームへの資産。特に、中程度のまともなコードを書くが、上記のすべてを実行できる人と比較して。

私が報酬を与える立場にあるときに私が見ているいくつかのものがありますが、それは絶対に腸の反応であるという大きな警告で、これはどれも定量化できないので：

• ステータス -明確、正確、タイムリーですか？議論されたとき、その人は現状のトップにいますか、それとも現在の問題について少しぼやけていますか？その人は、何かが燃え上がったときに赤旗を上げる正しい判断を持っていますか？
• 問題解決 -質問と回答の両方が重要です。人はいつ助けを求めるべきか、またはどこで車輪を無期限に回すかを知っていますか？さらに良いことに、他の人が問題を抱えているとき、その人は解決策を見つけるのを助けますか、それとも問題の一部になりますか？問題があなたの専門分野にない場合は、後戻りするという意味でも、いくつかのポイントに値します。また、グループや会社の外に出て、このようなサイトや他のインターネットの回答に行くポイントもあります。
• プロセスへの注意 -通常、これはかなり明白です-非アナル保持型の会社であっても、誰かがシステムをバッキングしている場合、それは彼らが残した混乱の中で見られます。他の人がガイダンスやアーキテクチャを遵守していないために他の人の機能をクリーンアップしている場合、問題が発生します。ボーナスポイントは、一貫性と品質を簡単にする方法を見つけた人に与えられます。
• 完了率対バグ対複雑さ -物事を成し遂げますが、それを正しく成し遂げてください。誰もがいくつかのバグを持っていますが、もしその男が速くてバグのある仕事をしてくれたら、問題があります。通常、これは日常的に評価できるものではありません。リリース、フェーズ、または会計四半期を振り返る必要があります。

そして、他の人の入力。私は多くの場合、さまざまなエンジニアがプロジェクトのさまざまな部分を担当していました。チームをリードすることもあれば、特定の成果物（「ビルドガイ」など）の所有者だけをリードすることもあります。人々は、極端なこと-ヒロイズムの行為や問題の子供たちの欲求不満について話すのが大好きです。通常、これらの問題を実際にフォローアップする行為で、私は両方のパーティーについて多くのことを知ります。

人間の管理に関する要素もあります。他のエンジニアとまったく同じエンジニアはいません。そのため、すべてが同じ光で輝くわけではありません。1つは素晴らしいバグのないコードを記述しますが、もう1つはすべてのコードを壊す横断的な問題の解決に役立ちます。人は素晴らしく、書面は優れています。1つは午前9:00に支離滅裂で、もう1つは午後3時までに外に出ます。後退して、チームにとって最も有益なものと個人的な偏りの要因となるものを特定する必要があります（午前11時まで機能できないという理由で、午前4時のチッパーを殺したいなど）。 00 AM）。

これは、マネージャーの技術的専門知識に応じて膨大な量になります。

• ほとんどの場合、彼らはおそらくあなたのコミュニケーション方法についてあなたを判断しています。マネージャーとのコミュニケーション方法、および同僚とのコミュニケーションの様子。
• マネージャーに近いリード開発者がいるのが幸運であれば、マネージャーはリード開発者からの意見を求めることができます。
• マネージャーの主な責任は物事を成し遂げることであることに留意してください。彼は、ビジネスの計画を満たすために、さまざまな結果と目標を作成する必要があります。そのため、何らかの形で結果に直接影響を与えているように見える場合、これはあなたにとって良い前兆となります。

一般的に、そうではありません。

それが、プログラミングが「レモンの市場」である理由です。http://en.wikipedia.org/wiki/The_Market_for_Lemons

コードはめちゃくちゃになりますが、一般的にはあなたが知るまでに2〜3年はかかりません。プログラマーは通常18か月間滞在するため、失敗した犯人を見ることはありません。

マネージャーは、たとえばリリースには4か月と100回の反復が必要だという言葉を受け入れなければなりません。大量の展開ファイルを手動で編集し、ステータスと混在するエラーのログファイルを手動で読み取りますか？彼らはそれがもっと良くできることを知りません。

ですから、正直でプロフェッショナルになり、改善を試みてください。経験を積むと、マネージャーは良い行動と悪い行動のパターンを見始めます。

マネージャーは、人が良いプログラマーか悪いプログラマーかをどのように知るのですか？

大まかな抜本的な一般化から始めます。ほとんどのマネージャーは、「良い」プログラマーと「悪い」プログラマーを区別できません。

これで、ほとんどのマネージャー（私が会ったか働いた）がプログラマーで「良い」と考えるのは、他のプログラマーが「良い」と考えるのと同じスキルのセットではありません。

どうやってやっているの？

結果指向のマネージャーは、「スマート」や「物事を成し遂げる」などを探します。スケジュール通りに、予算通りに仕事が終われば、スウェットパンツで仕事をするかどうかは気にしません。

プロセス指向のマネージャーは、「物事がどのように行われるか」により関心があります。これは、適切な服を着て、TPSレポートに適切なカバーシートを持っているかどうか、時間通りに働くことを意味します。

彼または彼女が何かを担当する必要がある場合、人はうまく機能します

「担当する」ことは、コードを書くこととは異なるスキルを必要とします。人がチームをリードするために必要な人材スキルを持っている場合、その人はそれを行うためにタップする必要があります。現在実行しているジョブの主要なジョブ要素に基づいて人を昇進させると、最終的には現在は無能なレベルに到達します。これは、ピーターの原理と呼ばれます。

明らかに、実際にコードを読み、さらに重要なこととしてバグ追跡システムを掘り下げて、何が起こっているのかを理解し、すべてのバグが平等に作成されるわけではなく、悪いコードを時間通りに配信することは重要ではないことを知っているプログラミングリテラシーマネージャーを持つことは常に役立ちますずっと。

しかし、それは理想的なケースです。マネージャーが非技術的な観点からプログラマーの測定値を取得するには、いくつかの提案があります。

• 現在指定されている要件を満たすために物事を行うことに問題がある場所を迅速/定期的/一貫して強調し、それのために徹底的に迷惑です（これらの問題を抱えるほど複雑ではない場合、これは結局ソフトウェア開発です、実際の開発プロジェクトではありません）。
• 彼らが何かについて確信が持てない場合は、すぐにそう言います-自分の能力に自信があるプログラマーだけが実際にこれを行います（そして、あなたがそれを気に入らないなら、彼らは簡単に別の仕事を得ることができます）。逆に、自分が真剣に自分の深さから外れていることを知っている人は、隠れて隠蔽を探す傾向があります。
• チームの他のプログラマーは、他のプログラマーについて何を言っていますか、または暗示していますか？あなたが半分まともなマネージャーであれば、特に統合テスト/バグ修正時に、プログラミングチームと一緒にいることになります。したがって、このようなフィードバックが得られない場合は、他の誰かがあなたの仕事をしているはずです。
• そして私のお気に入り：私は「トムキャット」プログラマーと呼んでいます。しばらくして、さまざまなプログラマーが常に同じプログラマーの机の周りを動き回っていることに気づいている場合（彼らが仕事をしていて、面倒な問題について話し合っていると仮定し、クールで面白いWebの常駐ファインダーではない場合）...その人の机に引き寄せられています。彼らがまだチームリーダーでない場合、彼らはおそらく1人でできるだけ早くするべきです。

これらのいずれかまたはすべてが当てはまる場合、優秀なプログラマーが手元にいる可能性があります。優れたプログラマーによって、私は彼らのコーディング能力を評価するだけでなく、他の人間と通信できるような他の有用なものを評価することに注意してください;-)

マネージャーは、あなたが書いたコードが素晴らしいか、それが巨大な要因によって改善できるかを知らないかもしれませんが、彼が知っているのは、うまくいったコードで締め切りに間に合いましたか？あなたは彼が他の人々が作成する問題を解決するために信頼できる人ですか？クライアントまたはユーザーは、マネージャーにエスカレートされた問題に気付きましたか？時計に大きな災害がありましたか（ユーザーテーブルを削除し、バックアップを設定するのを忘れた、他の顧客から見たはずのない所有権データを顧客にメールで送信した、など） ）？人々はあなたの背中の後ろで良いことか悪いことを言っていますか？

1. あなたのコードがマネージャーによって評価されない場合、ほとんどの場合、ピアによって評価されます（正式に、またはコードで作業しようとするときに非公式に）。あなたの上司は、同僚の意見を（再び公式か非公式かを問わず）ある程度使用します。
2. 一般的な信頼性とタスクの進行と終了の速さは、コーディング能力とは別に、多くの場合非常に重要な要素です。
3. コミュニケーション。あなたが多くのことを成し遂げ、うまくやっているなら、あなたのマネージャーはそれについて知る必要があります！（もちろん、自慢することは避けてください）。単に受動的になるのではなく、「マネージャーを管理する」ことを学びます。上司があなたの仕事の仕方を知るのを助けてください。

マネージャーはコーダー自身であるため、簡単な観察でコーダーが良いかどうかを判断できます。

あなたのマネージャーがコーダーでない場合（そしてあなたがソフトウェアビジネスをしている場合）、あなたはうんざりしています。

マネージャーとして、プログラマーを評価するときに私が検討したことのいくつかを以下に示します。

• ピアフィードバック。私は自分のチームのプログラマーと、他のチームのプログラマーに、私の人々についてのフィードバックを送ってほしいと頼みました。

• 仲間の尊敬。私のプログラマーが解決できない問題にぶつかったとき、彼らは「アドバイスをどんどん聞いてみましょう」と言います。

• 物事を成し遂げます。「私はXが欲しい」と言い、翌日、Xは完了です。

• 物事をスマートに取得します。「私はXが欲しい」と言い、翌日、Xが行われるだけでなく、Xに似たものはすべて解決され、それ以上の注意は必要ありません。

• 私を修正します。「私はXが欲しい」と言い、プログラマーは「Xは正しくありません。Yをやるべきです。それが理由です」と言います。

優秀なマネージャーはそれほど多くありません（関連する質問を参照してください：詐欺師は、人が良いマネージャーか悪いマネージャーかをどのように知るのですか？）。人をうまく管理することは難しく、多くの時間と労力を要します。5人を管理するとすぐに、プログラミングの時間はほとんどありませんでした。私が8人以上の人を管理していたとき、私は彼らを当然のように管理できなくなりました。

あなたの質問の前提は、マネージャーが実際にコードを見ていないと断言するという点でいくらか欠陥があると思います。私は、マネージャーが仲間のエンジニアであり、コードレビューに積極的に参加した多くの状況で働いてきました。

ただし、非技術者がソフトウェアエンジニアを担当する状況は間違いなく複数あり、彼らは自分の知識と経験に頼ることができません。

これらの場合、責任ある管理者はエンジニアの同僚に助言を求めます。彼らは、エンジニアが関与する組織内の非技術者に、責任の増大に対応できる優れた人材スキルがあるかどうかを尋ねます。

無責任なものは、彼らの「腸」反応と一緒に行くだけであり、一般的にサポートされないある種の「メトリック」を使用します。

それはがらくたのシュートですが、いつでも辞め、他の場所でもっと良いものを期待できます。

私が働いているところで、従業員の評価が出てきたら、マネージャーは従業員と定期的にやり取りする人に非公式の匿名の質問者を送ります。仲間の開発者と顧客の両方。これにより、仲間の開発者は、他の方法ではマネージャーが見落とす可能性のあるコーダーとしてのパフォーマンスに関する情報を提供する機会を得ることができます。

マネージャーは測定可能なものを見なければなりません。仕事のどの側面が、仕事の達成、仕事の質の点で測定可能か。大量のエラーが発生したり、エンドユーザーが本来の目的を果たせない限り、彼らはあなたが質の高い仕事をしているかどうかを知らないかもしれません。

あなたの仕事は管理者の費用に費用がかかるため、雇用を継続するには経済的に利益がなければなりません。

これが最善の方法だと言っているわけではありませんが、顧客満足度に基づいている可能性があります。彼らがアプリケーションを気に入って、大量のバグを受け入れて、タイムリーに新しい機能を追加すると感じたら、開発者は本当にそんなにひどいのでしょうか？

もちろんできます。10人の人が2つの仕事をしているので、彼らはコーディングによって総当たり攻撃を行うことができます。または、アプリをそれほど安く販売しているため、顧客は満足しています。

このアプローチのもう1つの問題は、非技術系マネージャーが顧客からのフィードバックを得る前に、アプリケーションがほぼ完了するまで待たなければならないことです。アプリをリリースするためだけに1年間ビルドし、誰もそれを気に入っていない。

人々に「ただそれを機能させるだけ」と伝えることに頼ることができれば、人生はよりシンプルになるでしょう。人々が正しいプロセスを理解し、順守するようにすれば、多くの問題を排除できます。現実的な厳しい期限を設定できます。愚か者は非現実的な要求を思い付き、才能のある人々を失うリスクを冒すことができます。

技術チームの私たちのほとんどは、誰が揺れ、誰が吸うかを知っていると思います。ものすごい回転がない限り、クリームは上に上がり、自重は沈みます。ぎこちない開発者は常に何らかのトラブルに直面しています。彼らはチェックインする前にコードをテストすることを忘れているため、ビルドが壊れてしまい、何かを成し遂げられないときはいつでも言い訳ができます。

誰かが良いプログラマーであるかどうか、彼らはそうするスキルを持っていないので、彼らは知らないと思います。彼らは誰かが良い開発者であるかどうかチェックします。プログラミングは開発のアクティビティですが、開発には他にも多くのアクティビティがあります。だから彼らは、あなたが時間通りかどうか、あなたの見積もりが良いかどうか、あなたのバグ追跡システムでやったこと、あなたのソフトスキル、コミットメント、コミュニケーションなどに多くの欠陥があるかどうかをチェックします

Itの達人が時々忘れて動揺するのは、私たちの仕事はプログラミングだけでなく、他にもやることが非常に重要だということです。マネージャーは、コードがどのように見えるかについては見ていませんが（コードはまったく重要ではないため）、あなたがチームプレーヤーであり、責任があり、敬意を払い、全体として高品質の仕事をしているかどうかをチェックします。

時々、コードは過大評価されていると思います。

開発者の序列について十分に理解していない人はほとんどいません（マネージャーはもちろん）。誰もが自分が一流の開発者であると考えています。悪い開発者が誰なのかを知らない唯一の人は、それらの悪い開発者自身です。とにかく、もしあなたが周りを回って、彼らが一緒に働いている開発者をランク付けするように誰かに頼むなら、私はそれがほとんどの人々にとって簡単な仕事であると確信しています。だから、誰が非常にうまくいっているか、誰が普通か悪いかなどを判断するのに魔法はありません。についてですが、実際にはそうではありません。ほとんどのマネージャーは彼らに取り囲まれていますが、開発者はそうではありません。

その後、あなたのランキングを決定するのはあなたのマネージャーのバイアスです。一部の人にとっては、コーディングはエントリーレベルのタスクであるため、コーディングが得意であっても、探しているプロモーションは得られません。他の人は、設計またはアーキテクチャの側面を最も重要であると見なしています。また、要件の定義と収集（ビジネス分析など）が最も重要であると考える人もいます。マネージャーにとって何が重要なのか知りたいが、トップパフォーマーのランキングを取得できなかった場合、トップパフォーマーのランキングを取得するために何をする必要があるのか​​尋ねてください。あなたはその答えで彼らも重要であるものを学び、それからあなたが重要なそれらの分野で優れていることを確認するのはあなた次第です。