上級プログラマーの自信を取り戻す
上司は私が彼が思っているほど賢くないことを知りました。
私の経験からの例：
私はジュニアプログラマーで、上司（シニアプログラマー）と私という2つのチームで働いています。
私は、私たちが働いている会社の内部Webアプリケーションの開発を任されました。私はバックエンドをフロントエンドに書き込みました（データベースの設計は既に行われており、サーバーテクノロジが選択されていました）。彼は、動作中のWebアプリケーションを観察することで私の進行状況を定期的にチェックし、それが実行されていることに満足していました。私がウェブアプリを完成させたとき、彼は最終製品がどれだけうまくできたかに満足していました。
数日前に彼はコードに興味を持つようになったので、私が使用したテクノロジー（フロントエンドに使用）を彼に伝えました。 Webアプリのフロントエンドには、JavaScriptフレームワーク（Backbone.js）を使用しました。なぜそんなことをするのかと聞かれると。私の応答は、フレームワークがこのアプリに非常にうまく適合し、コードを最初から作成した場合よりもコードを構造化するのに役立つと感じたからです。
したがって、この例を考えると、私の質問は次のとおりです。
シニアプログラマーで、ジュニアプログラマーの能力に対する自信がなくなった場合、自信を取り戻すために、ジュニアプログラマーに何を期待しますか？
[〜＃〜] edit [〜＃〜]：素晴らしい回答と協力的なフィードバックをありがとうございました！
彼があなたが作った製品が好きだったが、Backboneの使用に行き詰まっている場合は、どちらも目的の技術スタックについて話し合う必要があります。
開発者は、すぐに利用できるツールを使用する必要があります。その結果、作業の流れをスムーズに進めることができます。フロントエンドをゼロから構築することを彼が期待した場合、彼は明示的であり、十分な理由があったはずです。
彼が最初に製品を楽しんだという事実は、あなたがうまくやったことの十分な証拠であり、十分に「賢い」です。
tl; drよくやりました。先輩と話し、彼があなたに何を期待しているかを見てください。
彼はそのように迅速な判断を下すために私にはあまり「年長」ではないようです。 「四角いホイールを再発明する」アンチパターンではなく、常に適切なフレームワークを使用する傾向があります。彼が本当に年上だったら彼はよいフレームワークの価値を理解し、知っているでしょう。せいぜい、彼が別のMVC JavaScriptフレームワークよりもプロセスの早い段階でBackbone.jsの選択に疑問を投げかけることを期待しています。彼はあなたを後輩として適切に指導し、確認することに失敗し、適切な開発経路に沿ってあなたを助けました（彼の心の中で）。
彼の方向性（想定）が不十分であり、より有能な開発者になるために取り組んでいるため、プロジェクトの開発において正しい選択をしたようです。フレームワークの選択、フレームワークが適切だと感じた理由を説明し、プロジェクトが完了したこと、そして十分に文書化されサポートされているフレームワークを使用したことで彼が満足したことを彼に説明することに価値があると思います。あなたが進歩することができないなら、おそらく彼の目によく見えることは価値がないでしょう。あなただけがそれに答えることができます。
回答とコメントの大部分は、あなたと先輩が何らかの議論をする必要があり、先輩があなたの選択に同意しなくても、あなたの決定を強化し、擁護することが重要であるという点で正しい考えを持っています。
私がシニアとして見たいものについてのあなたの質問に答えるために：
私の若い開発者たちが、ほんの少しの失望でも、立ち上がって彼の決定を守ることができるかどうかを見たいと思います。製品に満足しているが実装には満足していない場合、後輩は製品を提供するときに仕様にもっと具体的である必要があることをジュニアに指摘することを期待します。私は彼らが彼らの立場を立てることができるようにしたいのですが、彼らがそうであるならば彼らが正しい選択をしなかったかもしれないことを認めることもしたいです。
PS：私は、私が何か新しいことを学ぶ機会を与えてくれるので、私がプロレベルで間違っていることが証明されるのを愛する先輩であることを言及しなければなりません。そして、スプリント/タスクの終わりに驚きが少ない/少ないように、私のチームの他の人がどのように物事をやっているかに気づきたいです。
まず第一に、これは失敗ではなく、機会として捉える必要があると思います。期待には明らかにミスマッチがあり、それがどこから来ているのか、すべてを軌道に戻すために何が必要なのかなどは明確ではありません。
第2に、これを現在の障害と見なす場合、または望まない電力関係を設定すると考えるほど賢くない場合。したがって、弁護可能であると確信する決定をした場合は、ある程度まで弁護する意思がある必要があります。
あなたが会話をしたいというduggieawesomeに同意しますが、それだけでは十分ではありません。準備を整え、設計のアイデアについて話し合い、なぜ自分がしたことをしたのかを説明し、推論を守る必要があります。また、正解は1つだけではないこと、上級プログラマーには別のデザインを好む正当な理由がある可能性があること、また、意思決定が悪かったことを認めずに、その理由に耳を傾けたいと思うことを受け入れる必要があります。あなたが知っていることについて（あなたがあなたがあなたがより良く知っているべきであると決めない限り、そしてそれは別の問題です）.
通常、デザインはトレードオフの問題であることを覚えておいてください。あなたはトレードオフが何であるかを喜んで議論したいと思います、そして、あなたが将来デザインのトレードオフを議論することができることを確実にするためにあなたが両方が何ができるかを見ます。たぶん、あなた2人はあなたがあなたよりも同じページにいることを期待しているだけですか？たぶんあなたの上司はばかです（それは時々起こるかもしれません）？たぶんあなたは本当にあなたが要件について知っていることを考えると間違っていた決定をしたのですか？しかし、オープンマインドで自信を持って参加し、これについて本当に話してみてください。
編集：私はスマートであることについて何かを追加したいです。私が知っている最も賢い人々は、誰からも学ぶべき何かがあると考えている人々です。閉ざされ、正しい方法は1つしかないと信じている人は、デザインなどの分野で想像力に優れた決定を下すことにはならず、みんなから学びたい人ができるように物事を結び付けることができません。アイデアを共有したり、前後にバウンスしたりすることをいとわないことは、スマートで自信があることの表れです。デザインの違いは、必ずしも一方が他方より優れているという問題にはなりません。有能なデザイナーを想定すると、異なるデザインは異なる方法で最適化されます。
私は、あなたが何も間違ったことをしていないという一般的な意見を持っています。彼は上級開発者として、アプリケーションの開発方法と結果に関心を持っていたはずです。プロジェクトが完了した後にやって来て、彼がそれがどのように行われたのか好きではないと言うことは、彼の側ではあまり専門的ではありません。
しかし、あなたの主要な質問に答えるために：それが失われたかもしれない後、あなたはどうやってあなたの先輩の意見を取り戻すのですか？まず、彼らがあなたがそれをやるべきだったとどう感じているかを尋ねます。理解していない場合は質問し、メモを取ります。学びたいことを示します。
次に、次のタスクで、説明に残っているものがあれば、アイデアを考え出して、上級開発者が実行します。どうやってそれをするのか一気に尋ねないでください、これはあなたの彼らの意見を助けません。しかし、独自のアイデアと独自の解決策を思いついた場合は、正しい方向に進んでいるかどうかを尋ねると、自分が試みていることと、仕事を成し遂げるスキルがあることを示します。これは、「ねえ、-yを実行するときにxを使用することを計画しています。何か考えはありますか？」
第三に、彼らがあなたのやり方を見るために頭をぶつけたとき、あなたのコードを見ずに彼らを去らせないでください。
基本的に、コミュニケーションの線を開きます。あなたの上級開発者はあなたやあなたのコードにあるタイプではないようですので、あなたはステップアップしてコミュニケーションする人になる必要があります。関係するすべての人が、何かが当初正確に考えられていないことを後でよりも早く見つけるのが良いです。
すぐに確認する必要があることの1つは、選択したフレームワークを包括的に防御できなかったために落胆したのか、それともフレームワークを使用したためにそうなったのかということです。
前者の場合、プロジェクトに含めるサードパーティのコードを評価および選択する方法を学び、上司にその決定を明確に説明し、正当化してそれを支持する準備をする方法を知っていることが重要です。これは覚えるのが難しいスキルですが、経験が付いています。サードパーティのライブラリをプロジェクトに含めるとすぐに、他の開発者が完全に理解できず、完全に制御できず、バグを含む可能性があるコンポーネントを導入するので、これは学ぶのに良いスキルです。セキュリティホールやその他の注意点。
あなたが一から書いていないので彼ががっかりしているなら、それはまったく別の問題です。彼がフレームワーク（上記で説明したものなど）の使用をやめさせる十分な理由があるか、またはそれらに対する会社のポリシーがあるか、作成できるフレームワークの選択を制限している可能性があります。どちらにせよ、彼はそれをあなたに伝えるべきであり、彼が彼の側の失敗を示していないという事実。一方、彼はフレームワークに偏見を抱くケースがあるかもしれません。フレームワークがもたらす可能性のある問題にもかかわらず、それらはまた、あなたが知っていると確信しているように、大きな利点を持っています。 「Not Invented Hereシンドローム」のために既に行われ、一般に公開されている作業をやり直すことを意味する場合でも、彼はあなたがすべてを自分で作成する必要があると考えているかもしれません。
彼があなたにフレームワークを使うことに失望している理由を彼が説明しなかったということは、確かに彼の側の効果的なコミュニケーションの失敗です。答えが「何もない」となる可能性がある場合、彼はあなたが間違ったことを疑問に思ったままにしておきます。彼はまたあなたにあなた自身に疑問を投げかけました、そしてそれはあなたが将来あなた自身のイニシアチブを使う傾向を少なくするようになるに違いありません。優れたプログラマーが持つ余裕のない特性が1つあれば、それはイニシアチブの欠如です。そして、私はそれが意図的ではないと確信していますが、彼の態度は、あなたが仕事をどのように成し遂げたかについての細かい細部にわたって行われた仕事に対する賞賛を突然取り下げたので、士気を傷つけています。
彼が上級プログラマーであるという理由だけで、彼を間違いなくしません。
上司は何か新しいことを学ぶ必要があることに気が動転すると言ったあなたのフォローアップコメント...
あなたが言及していないこと以外にそれがない限り、私はHIMに悩まされるでしょう。
新しいテクノロジーの学習は私たちの仕事の大きな部分であり、すべてのチームが学習と自己改善を受け入れる必要があります。
しかし、経営陣は他にも気にする必要があります。彼らには期限があり、トレーニングの予算が限られているか、まったくありません。
人的管理の観点からは、あなたの代わりにプロジェクトのフェーズ2で作業している誰かがいる可能性があります。あなたの上司は、その仕事をするために他の誰かの耳をマークされているかもしれません、そして彼はその人が今何か新しいことのための学習曲線を持っていることを知っています。
そして今、以前のBUTのBUTですが……これはあなたの上司の責任です。あなたが新しくて若い場合、彼は少なくともいくつかのガイダンスを提供しているはずです。それほどではありませんが、使用する技術に関するガイダンスを求めることもできます。
あなたが上級プログラマーであり、後輩プログラマーの能力に対する自信を失った場合、自信を取り戻すために後輩に何を期待しますか？
あなたが彼があなたが使ったフレームワークを使う方法を学びたくなかったとあなたが言ったとすると、私は問題は次のようになるべきだと思います： "あなたが上級プログラマーで、あなたが能力を失ったならジュニアプログラマーから学ぶために、自分を整理するにはどうすればよいですか？ "
あなたはプロの開発者として学習を止めません。ずっと。そうすると、停滞することになります。一部の地域では問題ないかもしれません。バンキングには、稼働が必要なレガシーシステムが多数あります。そのため、非常にゆっくりと動く古いシステムの知識は問題ありません。私の友人は、銀行のCOBOLを編集して、修正していたソースコードが約30年も変更されていないことを発見しました（元の著者は大学のCOBOL講師でした）...それでも、彼はまだ古いシステムを新しいシステムに統合する必要があるため、新しいことを学びます。
シニア開発者に戻ります。あなたは「彼は何か新しいことを学ぶ必要があることに腹を立てていました」と言いました、そして私の意見ではそれはいくつかのかなり大きな警報ベルを鳴らしています。
私はいつも学んでいます。雇用主に毎年教育費を徴収してもらいたいのですが、実際に必要だと感じている金額に近い金額を費やすことはめったにありませんが、雇用可能である必要があることを知っているので、2000ポンド程度のどこかで費やしています毎年、私自身の教育に対するGBP（約3000米ドル）。
先輩が新しいことを学んでいないと、彼らは悪い決断を下し始め（おそらく彼らはすでにそうです）、あなたが扱っているコードの品質は、彼らがわだかまりに陥っていて、得る必要性を感じていないので低下しますそのわだちから。
私が今まで一緒に働いた中で最高の開発者の一人は、私が見る機会がなかったあらゆる種類のものを知っていたジュニア開発者でした。彼はテーブルにたくさん持ってきて、私はしばしば圧倒されました。しかし、私は彼の努力に感謝し、私はそれによって「意気消沈」することはありませんでした。彼が時間をかけてすべての可能性を理解し、チームに提示したことを嬉しく思いました。彼は現在チームを率いていて、テーブルに物を持ってくる開発者や彼から学んでいることについて私に語り続けています。
あなたの上級開発者は物事を学ぶ必要があります。彼らは自分の不備を隠すために感情的な言葉（「心を落ち着かせる」など）を使わないように学ぶ必要があります。彼らは新しいフレームワークを学ぶ必要があります（全体を学ぶことができない場合でも、それが何をするか、どのように問題を解決するかを学び、将来必要になる場合は、時間をより深く学ぶために投資することができます）。そして、彼らは常に学び続けなければならない仕事にいることを学ぶ必要があります。