Solo.NETプログラマーがチームに移動
私は過去8年間、小さなスタートアップで.NETのソロプログラマーを務めてきました。私はかなりまともなソフトウェアをいくつかまとめました。私は常に自分自身を改善し、ソース管理（SVN/TFS）を含むベストプラクティスに準拠するよう努めました。私は他の分野のエンジニアのチームと非常に緊密に協力しましたが、ソフトウェアに関して言えば、プログラミングは私だけでした。私はプログラミングの技術が大好きで、ツールを磨くために新しいことを学ぶのが大好きです。
2週間以内に、20人の.NET開発者のチームで新しい仕事を始めます。私のポジションは中級レベルで、信じられないほど印象的なバックグラウンドを持つプログラマーの下で仕事をします。繰り返しになりますが、開発のチームの側面は私にとって新しいものになるので、最初からできるだけ効果的で簡単にうまくやっていくのに役立つ一般的な「新しい人」のヒントを探しています。
ハイレベルなヒントや、コミュニケーションに関する日常的なことなど、何でもうまくいきます。
ほとんどの常識ですが、私のアドバイスは次のとおりです。
最初の1週間は、技術者ではなく人と一緒に過ごします。デスクトップや、チームから孤立するようなものをカスタマイズする初日を無駄にしないでください。できるだけ早く、できるだけ多くのピアを知る。
働く馬が誰であるか、そしてお尻もすぐに誰であるかを理解するようにしてください。火傷はできるだけ避けてください。すべてのチームに火傷があり、1つに分類されたくありません。
仕事や昼食後のビールであっても、最初の数週間は社交イベントに参加してください。
物事を聞いて書き留め、手順の説明を繰り返すように同僚に依頼して、彼らを苛立たせます。
特定の問題について具体的に尋ねられない限り、最初の3〜6か月は慣れてください。手順やアーキテクチャなどの変更を推奨しないでください。それらはあなたとは異なった働きをし、いくつかの要素は貧弱かもしれません-しかしそれには理由があり、それらはめったに過失や無知によるものではありません。
プログラミング側が問題になるのではないかと思います。
学ぶ！新しいプログラマーに会うことは、新しいトリックを学ぶための素晴らしい方法です。それらがタイプするのを見ると、いくつかのエディターのトリックがわかり、それらのコードを見ると、新しいアイデアが得られます。
5分ごとに同僚に迷惑をかけないでください。ただし、本当に行き詰まっている場合は、遠慮なく助けを求めてください。多くのプログラマーが2日間プログラムに行き詰まり、隣人に尋ねると1時間で解決するでしょう。
コード戦争は宗教戦争です。構文はあちらで多少異なる場合がありますが（単一行ステートメントに括弧を追加しますか？）、争う価値はほとんどありません。
社交。彼らが毎週飲み物をしているなら、それに参加することを忘れないでください。これは 一緒に食べる と同じくらい簡単です。
Devil's Advocateをプレイして、チームメイトが有能であることを確認します。何か間違ったことをしたい人の数が常に多いので、あなた以外の誰も「正しい」方法を行わないチームで働くことほど悪いことはありません。
あなたは印象深いバックグラウンドを持つ開発者の下で働くことについて言及しているので、それは有望に聞こえるかもしれません。他のみんなが何か間違ったことをして、あなたがそれを正しくやったとしても、妥協しないでください。
ジョンノに加えて、私は言うでしょう：
変更に備えてください。チームによって作業は異なります。優れたSWチームにはコーディングルールがあります。最初は奇妙に見えても、受け入れる準備をしてください。
より多くのコミュニケーションに備えてください。自分で作業するときは、多くの詳細情報が頭の中にあります。チームで作業するとすぐに、これらの詳細（少なくとも一部）を共有および伝達する必要があり、これには時間が必要です。
あなたが話すよりももっと聞いてください。
あなたが答えようとするよりも多くの質問をしてください（質問があなたに向けられていない限り）。チームの「古いタイマー」は、質問することで、コードの学習がどれだけ進んでいるかを知ることができます。彼らはおそらく彼らが期待している質問の精神的なリストを持っています。
一般的なスタイルに一致するようにコードを記述します。これは、スペース、中括弧、大文字、変数名の長さ、メソッドの平均サイズ、コメントの密度、およびその他の重要でないすべてのものを配置する場所に適用されます。物事を違ったやり方で行う正当な理由がある場合は、昔ながらの人に、チームが指定されたスタイルを持っている理由を尋ねてください。チームの歴史や性格について興味深いことを学ぶことができます。それは私を次のポイントに導きます。
チームの伝承を学びます。ほとんどの場合、伝承はどこにも書き留められていませんが、それはチームの常識です。チームの伝承には、プロジェクトが現在の状態になった経緯、過去に発生したミス、過去に発生した成功、その過程で学んだ教訓が含まれます。これは、「フロブニッツのバグのように聞こえる」などの簡単な説明で言及されています。チームメンバーが誰かが行う不可解なコメントに同意するのを見たり聞いたりすると、おそらくチームの伝承が関係しています。誰かに聞いて。
関係する性格と歴史を理解するまで、コードを批判しないでください。誰を怒らせているのかわかりません。
質問をし、答えを聞いてください。次の質問をする前に、前の質問に対する回答を考えて、回答を予測できるようにします。
可能な限り最高の仕事をするように努めてください。チームの他の誰かが来月コードを変更する必要がある場合、あなたのコードについてどう思うかを自問自答してください。
対処する必要のある問題を見つけた場合は、問題について懸念を表明する前に、合理的な解決策を提供できるように最善を尽くしてください。問題を指摘するときは、ソリューションを実装する責任を負います。