リードよりもプログラミングを好むリードプログラマー向けのオプションはありますか？[閉まっている]

今年の初めに、私たちのチームの主任開発者が別の部門に移動した後、主任開発者の役割に昇進しました。私は約5年の職務経験があり、可用性と過去のパフォーマンスのために、プロジェクトをリードするための経営陣の第一選択でした。私は少し不安でしたが、キャリアの向上と経験のための良い機会であると判断したので、受け入れました。

しかし、これまでの私の結論は、以前の開発者の地位ほどには楽しんでいないということです。私は5人の開発者から成るチームをいくつかのリリースで成功させてきましたが、コードにはほとんど触れません。代わりに、コードレビューとともに、計画と設計、チーム管理を実行します。さらに多くのことを追跡し、タスクをチームに割り当てることができるように計画する必要があるため、ほとんど毎日頭痛がします。私は残業することはめったにありませんが、仕事を辞めると毎日燃え尽きてしまい、結果として仕事以外の時間を楽しんだことさえないと思います。

私の質問：そのような状況をどのように処理しますか、またはどのように処理しましたか？ 同様の状況にある人々のために、仕事を楽しませたチーム、タスク、時間をより良く管理する方法を見つけましたか？または、開発指向のポジションに戻す方法を見つけましたか？主任開発者の職位はほとんど常に高い給料を支払うことを知っていますが、現在の仕事を楽しんでいるよりもお金や昇進を気にかけないようになっていることがわかります。

少なくとも1年間は調整を試みるべきだと考えたため、経営陣とはこれについて話し合っていません。

ここで提供する答えは、潜在的に機能する可能性があるものの最善の推測ですが、あなた自身があなたを見つけている同様の状況から抜け出そうとしているので、私はそれが機能するのを見ていません。全体は私にとってまだ学習の経験ですが、私のチームには前向きな傾向が見られます。

私の会社では、チームリーダー（「デザインリード」と呼ばれます）に昇格しました。製品を知っていて十分な経験がある人が不足しているため、2つの異なるチームを率いてボランティアをしました。数か月前に「スケジュールを支援するために」、経営陣はこれら2つのチームの規模を2倍にしました。

私がやろうとしてきたこと...

1. 私と他のすべての人の立場は永久的な任務ではないことをすべての人（経営陣を含む）に明確にしてください。誰もがプレートにステップアップし、プロジェクトのより広い視野を取り、アーキテクチャ/設計の決定に参加することを歓迎します。解決策がないという意見の相違がある場合、（今のところ）最終決定権を持ちますが、これまでのところ、それは起こりませんでした。
2. 他の人の成長と成長を支援することに焦点を当てます。コーディングと設計、および物事を行うためのさまざまなアプローチについて、さまざまな時期にさまざまな開発者と（ほぼ哲学的な）議論を重ねてきました。それらの議論のいくつかは実際の仕事に関連しており、他の議論は純粋な思考運動です。私は20年以上の経験を持つ男がいて、本棚に戻ってC ++の本を手に入れました。彼は、テンプレートメタプログラミングで行った低レベルのものに興味があったからです。これらの議論はやや伝染性があり、これらのトピックを十分に取り上げた後、人々は自分でこのことについて考え始めます。
3. 他の人にできる限り委任してください。私は多くのことを検討していますが、すべてのコードレビューに参加しているわけではありません。その代わりに、私は中間の人のためにコードレビューを行い、それらの人に環境に優しい人々の一部のためにコードレビューをさせます。コードレビューは、「すべての行を読んで、考えられるすべてのバグを見つけよう」ではなく、知識移転ツールのようなものです。
4. インターフェイスが定義され、基本設計が整ったら、新しい人でもクラスの内部を可能な限りコーディングできるようにします。はい、そのコードの多くは完璧にはほど遠いですが、テストされて動作します。「コードのにおい」に関して特定の主観的な境界を越え、リファクタリングしていない場合、特定のクラスを分割または再配置する必要があることをお勧めします。痛いこともありますが、数日後に確認して「認めたくありませんが、このコードは今ではずっと良くなっています」という応答を受け取ったとき、それは実際に私に暖かく、あいまいな感じを与えます。
5. 人に挑戦します。製品に追加する機能を単に割り当てるのではなく、それらの機能を追加するように依頼しますが、既存のクラスの関数/データメンバーの数を増やすことなく行います。何か新しいものを入れなければならない場合は、既存のものを取り出し、それが何であるかを理解するために時間をかける必要があります。リファクタリングについては誰もが知っていますが、最初は余分な力がなければ、人々は実際にそれを実行するための支援を必要としているようです。少なくとも、ほぼすべてのコードレビュー中にこのポイントにアクセスすることをお勧めします。
6. すべてがバランスです。あなたはチームの他の全員を見ている唯一の年配の人になることはできません。1週間を会議やレビューに費やすことはできません。チームが犯すすべてのミスをキャッチできるとは期待できません。一日の終わりには、自分がリードになるための時間を割り当てる必要がありますが、開発者になるための時間も割り当てる必要があります。コーディングできなかったら夢中になります。他のすべてであっても、コードだけでなく、本当に気の利いたものを書く時間があることを確認します。テンプレートメタプログラミングの本を手に入れて、Boostの中を掘り始めました。そのようなものを思いついた人は、（良い意味で）正気でなければなりません。管理者が、すべてがレビューされていない理由や、noobが別のnoobsコードをレビューしている理由についてあなたにバグを報告し始めた場合、バランスのこと全体を説明する必要があるだけで、チームには十分な経験のある人がいないだけで、結局は「それが何であるか」です。チームに上級者がいる場合は、その時点で権限を与え、独自の設計/レビュー/他者を支援する自由を与え、単なるコードジェネレーターとして扱わないようにします。エンパワーメントには自由が伴い、人々は自由を愛します。自由/権限委任を気にしない開発者がいる場合、それは問題ありません。すべてのチームには依然として純粋なコーダーが必要です。バランスを取るように努力してください。その後、権限を与え、独自の設計/レビュー/他者を支援する自由を与え、単なるコードジェネレーターとして扱わないようにします。エンパワーメントには自由が伴い、人々は自由を愛します。自由/権限委任を気にしない開発者がいる場合、それは問題ありません。すべてのチームには依然として純粋なコーダーが必要です。バランスを取るように努力してください。その後、権限を与え、独自の設計/レビュー/他者を支援する自由を与え、単なるコードジェネレーターとして扱わないようにします。エンパワーメントには自由が伴い、人々は自由を愛します。自由/権限委任を気にしない開発者がいる場合、それは問題ありません。すべてのチームには依然として純粋なコーダーが必要です。バランスを取るように努力してください。
7. あなたの時間は貴重です。そのため、チームが回答を得るまでに数時間待つことができるすべての非重要な質問を電子メールで送信するように依頼します。質問されたら、チーム全体をコピーする必要があります。最終的に、あなたが一日の休憩をとるとき、あなたは問題を見て、その人を助けることができますが、多くの場合、他の誰かがすでにあなたをbeat打しているかもしれず、あなたは何もする必要はありません。明らかにリードとして、私はまだ自分を利用できるようにし、その事実を明確にします。なぜなら、私の目標の1つは、チームの誰もが進歩せずに長時間立ち往生しないようにすることだと信じているからです。
8. チームがコミュニケーションをより効果的にするために、できるだけ多くのツールを使用するようにしてください。たとえば、ウィキサイトがあり、同じ問題が何度も発生する場合は、最後にウィキページの作成を手伝った人に尋ねます。

私はこれを経営陣の誰とも話しませんでした

これはおそらく役立つと思います。不快感をポジションに伝えることは、必ずしも具体的に何かを指定することではありません。経営陣は自分がどのカードを持っているかを知ることができ、それが適切な管理であれば、彼らはあなたの最高の可能性を活用する方法を見つけようとします。少ないために解決しないでください。

プロジェクトが終了したら、社内または社外のプログラマ志向の職を探してください。

経営陣とのやり取りを減らし、スキルに関する技術的な「手」を増やしたいと話し合う。

あなたがPMの立場にいるのとリード開発者のように思えます。リード開発者はもっとコーディングすることを検討します。

雇用主の視点：

あなたが現在の仕事を楽しんでいて、そこに良い歴史があるなら、私はあなたを維持し、あなたのための場所を見つけたいので、私は彼らと話すことについてあまり心配しません。

優れた開発者は価値がありますが、ジャグリング行為よりもコーディングやデザインを行う価値があることを売り込む必要があります。

後継者計画を立てることで、彼らにあなたを後退させる道を与えます。基本的には、現在のチームで頭痛の種になることに興味を持っている人を見つけます。次の6〜9か月間、それらを訓練し、1つずつタスクを与えます。

毎週のステータス更新など、最初に簡単なものを選択してください。

• ステータスの更新を行うときに、隣に座ってください。
• 彼らが次のステータス更新を行うとき、彼らの隣に座ってください。
• 彼らに自分でそれをさせて、それが決勝に出る前にそれをレビューします。

その後、追加の責任の大部分を引き継ぐまで、追加のタスクを徐々に与えます。

これらの望ましくない仕事がより多く支払われる理由は、彼らが誰も彼らをしないなら、彼らがより高いレベルのスキル...需要と供給を必要とするので、不注意にではないからです。

あなたがより高い支払いを続けるために...それが私であれば、あなたが周りに滞在していることを聞きたいと思います、あなたは必要に応じてこの人を助け、新しい人のメンターになり、デザイナー/キーブレイン/プロジェクトリーダーではなく、ドメインエキスパート。基本的にこれは貴重なポジションであり、他の誰かが走り回ってジャグリング行為を行うことができます（明らかにより多くの賃金のため）。

雇用主に6〜9か月の計画を提示するとしたら、

• 他の責任者よりもコーディングに焦点を当てることに戻るのが良いと思う理由の良い説明。
• 誰に代入するか、または誰かを見つける必要がありますか？これが私が考える重要な決定要因になります。
• 6か月間、1か月間、新しい人にどのような責任を引き渡すか
• 責任を負うもの（デザイン、コードレビューなど）。
• 賃金の引き下げのアイデアは、彼らがこれを育てることを許可しますが、喜んで取るでしょう（元と現在の間のどこか）。

私の計画として、雇用主としてそれを一緒に得たら、それを実現するためにあなたと一緒に働くことは幸せです。

がんばろう。

私はまさにあなたの状況にいます。答えは、マネージャーとの関係にあります。私の場合、それは非常に良いものだったので、ある日彼を脇に連れて行き、仕事を楽しんでいない、ストレスを感じている、コーディングに戻りたいと言った。彼はそれを聞いて私を歩いてやめるよりもずっと幸せでした。そこで、他の誰かがチームリーダーとして引き継ぎ、私がコーディングに戻る計画を立てました。

投稿から明らかでない2つの質問：

• あなたが書いたソフトウェア（Google、Microsoft、Fog Creekなど）から直接利益を得ている会社にいますか、それとも（銀行や食品会社のような）補助的な機能にいますか？

• CEOは技術者ですか、それともビジネスの役割で立ち上がった人ですか？

技術者のCEOを持つソフトウェア会社であれば、心配しないでください。企業のリーダーシップは、貴重な開発者が誰であるかを知り、それらを維持するために必要なことは何でもします。幹部がすべて「人を管理する」または「予算を管理する」ストライプを取得した人である場合は、心配する必要があります。社内のIT部門にいる場合は、二重に心配してください。この場合、ワークライフバランスが良いことが開発者にとどまることの報酬であることを受け入れなければなりません。

最後のポイント-あなたが幸せになるようなことをしてください。このようなキャリア選択に関する他の皆のアドバイスは、彼らを幸せにするものに関するものです-そしてこれはあなたについてです。