Solo .NETプログラマーがチームに移動[終了]


12

私は過去8年間、小規模な新興企業で単独の.NETプログラマーでした。かなりまともなソフトウェアをいくつかまとめましたが、ソース管理(SVN / TFS)などのベストプラクティスに準拠するように常に努力しています。私は他の分野のエンジニアのチームと非常に緊密に連携していましたが、ソフトウェアに至ったとき、私は唯一のプログラミングでした。プログラミングの技術が大好きで、ツールを磨くために新しいことを学ぶのが大好きです。

2週間以内に、20人の.NET開発者のチームで新しい仕事を始めます。私の立場は中級レベルになり、信じられないほど印象的なバックグラウンドを持つプログラマーの下で仕事をします。繰り返しになりますが、開発のチームの側面は私にとって新しいものなので、私はできる限り効果的で簡単に始めることができるいくつかの一般的な「新しい人」のヒントを探しています。

高度なヒントや、コミュニケーションに関する日々の小さなことなど、何でもできます。

回答:


19

主に常識ですが、私のアドバイスは次のとおりです。

最初の1週間は、テクノロジーではなく人々と過ごします。デスクトップのカスタマイズや、チームからあなたを隔離する何かをカスタマイズする初日を無駄にしないでください。できるだけ早く、できるだけ多くのピアを知るようにします。

仕事の馬が誰で、誰がすぐに火傷をするのかを把握してください。できるだけ熱傷を避けてください、すべてのチームがそれらを持っているので、あなたは1つとして分類されたくありません。

仕事や昼食後のビールだけでも、最初の数週間は社交行事に参加してください。

耳を傾けて書き留めて、手順の説明を繰り返すようにピアに頼み、彼らを困らせる。

最初の3〜6か月は、特定の問題について特に質問がない限り、手順/アーキテクチャ/などの変更を推奨しないでください。それらはあなたとは異なる働きをし、いくつかの要素は貧弱かもしれません-しかしそれには理由があり、それらはめったに過失または無知によるものではありません。

プログラミング側が実際に問題になるとは思いません。


1
昼食にビール?あなたはヨーロッパ人でなければなりません:Pほとんどの人は、ここ米国太平洋岸でそれをした場合、私はある種のアルコール中毒だと思うでしょう。
エドワードストレンジ

@Crazyエディ:私はカナダ人だ、と...私の会社はビールのために支払い、それが毎週金曜日オフィスにして持って来た
スティーブン・エヴァース

@SnOrfus-私は実際にカナダで両極端を経験しました。「許容できるビール」は減少していると思います。
スコットホイットロック

「一部の要素は貧弱かもしれません-しかし、それには理由があり、それらはめったに過失または無知によるものではありません。」この声明まで私がいた。私の専門的な経験では、無知のために特定のことが不十分に行われていることはかなり一般的です。無知で行われなかった場合、時間の制約で行われました。
maple_shaft

@Snorfus-米国でそれを行った会社を見つけた場合、それはおそらく唯一の会社でしょう:PIはCEOや他の高くて強大なタイプが昼食を飲みながら飲むかもしれないと思いますが、実際にはほとんどの場所でそれがハンドブックにあります、 「アルコールを仕事に持ち込むことはありません」。私たちの場所にはそれがありますが、それを醸造している私たちのものは貿易用の味見本を持ってきました。職場で実際に飲まないだけです。
エドワードストレンジ

8
  • 学ぶ!新しいプログラマーに会うことは、新しいトリックを学ぶのに最適な方法です。それらをタイプするのを見ると、いくつかのエディタートリックを学び、それらのコードを見ると新しいアイデアが得られます。

  • 5分ごとに同僚に迷惑を掛けないでください。しかし、本当に行き詰まっている場合は、遠慮なく助けを求めてください。あまりにも多くのプログラマーが2日間プログラムにとどまり、隣人に尋ねると1時間で解決するでしょう。

  • コード戦争は宗教戦争です。構文はそこでは多少異なるかもしれませんが(1行のステートメントに括弧を追加しますか?)、それをめぐって争う価値はほとんどありません。

  • 社交。彼らが毎週飲んでいるなら、必ず参加してください。これは一緒に食べるのと同じくらい簡単です。


3

Devil's Advocateをプレイして、チームメイトが有能であることを確認します。あなたが何か間違ったことをしたい人の数を常に上回るので、あなた以外の誰も「正しい」方法を行わないチームで働くことほど悪いことはありません。

素晴らしい背景を持つ開発者の下で働くことに言及しているので、有望に思えます。その場合、できることを学ぶことをお勧めしますが、「群れの精神」のために既に知っていることを決して忘れないでください。他の人が何か間違ったことをしていて、あなたがそれを正しくやったとしても、妥協しないでください。


正直に言って、ソフトウェアを記述する正しい方法と間違った方法あると固く信じているので、引用符を付けたくありませんでした、その古い議論を再ハッシュする気はありませんでした:)
ウェインモリナ

2

ジョンノに加えて、私は言うでしょう:

変更に備えてください。すべてのチームは異なる働きをします。優れたSWチームにはコーディングルールがあります。最初は奇妙に見えても、それらを受け入れる準備をしてください。

より多くのコミュニケーションに備えてください。自分で作業する場合、多くの詳細情報が頭の中にあります。チームで働くとすぐに、これらの詳細(少なくともそれらの一部)を共有して伝達する必要があり、これには時間が必要です。


2

あなたが話すよりももっと聞いてください。

答えようとする以上の質問をしてください(質問があなたに向けられていない限り)。チームの「古いタイマー」は、あなたが尋ねる質問によって、コードの学習でどれだけ進歩しているかを知っています。彼らはおそらく、彼らが期待している質問の精神的なリストを持っています。

一般的なスタイルに合わせてコードを記述します。これは、スペース、中括弧、大文字、変数名の長さ、メソッドの平均サイズ、コメントの密度、その他の問題のない場所に適用されます。物事を異なる方法で行う理由が本当にある場合は、チームが特定のスタイルを持っている理由を昔から聞いてみてください。チームの歴史と個性について興味深いことを学ぶことができます。それは次のポイントに私をもたらします。

チームの伝承を学ぶ。ほとんどの場合、伝承はどこにも書かれていませんが、それはチームの一般的な知識です。チームの伝承には、プロジェクトが現在の状態になった経緯、過去の間違い、過去の成功、その過程で学んだ教訓が含まれています。「再びフロブニッツのバグのような音」のような短い文で言及されています。チームメンバーが誰かの秘密のコメントに同意するのを見たり聞いたりすると、おそらくチームの伝承が関係しています。誰かに聞いて。

関係する人格と歴史を知るまで、コードを批判しないでください。誰が気分を害しているのかわかりません。


1

質問して答えを聞いてください。次の質問をする前に、前の質問の答えを考えて、答えを予想できるようにしてください。

可能な限り最高の仕事をするよう努めてください。来月コードを変更する必要がある場合、チームの他の誰かがあなたのコードをどう思うかを自問することに慣れてください。

対処する必要がある問題を見つけた場合は、問題に対する懸念を表明する前に、提供できる準備ができた合理的な解決策があるように最善を尽くします。問題を指摘するとき、ソリューションの実装の所有権を取得します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.