Programmeur Solo .NET se déplaçant dans une équipe [fermé]

Je suis un programmeur .NET solo pour une petite startup depuis 8 ans. J'ai mis en place des logiciels assez décents, et je me suis toujours efforcé de m'améliorer et de me conformer aux meilleures pratiques, y compris le contrôle de source (SVN / TFS). J'ai travaillé en étroite collaboration avec une équipe d'ingénieurs d'autres disciplines, mais en ce qui concerne le logiciel, j'étais le seul à programmer. J'adore l'art de la programmation et j'adore apprendre de nouvelles choses pour affûter mes outils.

Dans 2 semaines, je vais commencer un nouveau travail dans une équipe de 20 développeurs .NET. Mon poste sera de niveau intermédiaire, et je travaillerai sous des programmeurs avec des parcours incroyablement impressionnants. Encore une fois, l'aspect développement d'équipe sera nouveau pour moi, donc je suis à la recherche de conseils généraux pour les «nouveaux mecs» qui m'aideront à être aussi efficace et facile à comprendre que possible dès le départ.

Tout y passe, y compris des conseils de haut niveau et de petites choses quotidiennes sur la communication.

Surtout du bon sens mais mon conseil serait:

Passez autant de la première semaine avec des gens plutôt qu'avec la technologie. Ne perdez pas le premier jour à personnaliser votre bureau ou quoi que ce soit d'autre qui vous isolera de l'équipe. Apprenez à connaître le plus de pairs possible le plus rapidement possible.

Essayez de comprendre qui sont les chevaux de travail et qui sont les clochards aussi rapidement. Évitez les clochards autant que possible, chaque équipe en a et vous ne voulez pas être classé comme un.

Assistez à tous les événements sociaux au cours des premières semaines, même si ce n'est qu'une bière après le travail ou le déjeuner.

Écoutez et notez les choses, demandez à vos pairs de répéter les descriptions des procédures pour les agacer.

Passez les 3 à 6 premiers mois à vous familiariser, sauf si on vous le demande spécifiquement sur un problème spécifique, ne recommandez pas de modifications aux procédures / architecture / etc. Ils fonctionneront différemment de vous, et certains éléments peuvent être pauvres - mais il y aura des raisons à cela et ils sont rarement dus à la négligence ou à l'ignorance.

Je doute que la programmation soit réellement un problème.

• Apprendre! Rencontrer de nouveaux programmeurs est un excellent moyen d'apprendre de nouvelles astuces. En les regardant taper, vous apprendrez quelques astuces d'éditeur et en regardant leur code, vous aurez de nouvelles idées.

• Ne dérangez pas vos collègues toutes les cinq minutes, mais si vous êtes vraiment coincé, n'hésitez pas à demander de l'aide. Trop de programmeurs sont bloqués sur un programme pendant deux jours où demander à votre voisin l'aurait résolu en une heure.

• Les guerres de code sont des guerres de religion. La syntaxe peut être quelque peu différente là-bas (ajoutez-vous des crochets aux instructions singe line?) Mais cela vaut rarement la peine de se battre.

• Socialiser. S'ils font un verre chaque semaine, assurez-vous de le rejoindre. Cela peut être aussi simple que de manger ensemble .

Jouer Devil's Advocate et je vais dire assurez-vous que vos coéquipiers sont compétents. Rien n'est pire que de travailler dans une équipe où personne sauf vous ne fait quoi que ce soit de «correct», car vous êtes toujours plus nombreux que les gens qui veulent mal faire les choses.

Vous mentionnez travailler avec des développeurs avec une expérience impressionnante, donc cela semble prometteur et dans ce cas, je vous encourage à apprendre ce que vous pouvez, mais n'oubliez jamais ce que vous savez déjà pour la "mentalité de troupeau". Si tout le monde fait quelque chose de mal et que vous le faites correctement, ne vous compromettez pas.

En plus de Jonno, je dirais:

Soyez prêt pour les changements. Chaque équipe travaille différemment. Les bonnes équipes SW ont des règles de codage. Soyez prêt à les accepter, même si au début ils vous paraissent bizarres.

Soyez prêt pour beaucoup plus de communication. Lorsque vous travaillez seul, de nombreuses informations détaillées sont dans votre tête. Dès que vous travaillez en équipe, ces détails (au moins certains d'entre eux) doivent être partagés et communiqués et du temps est nécessaire pour cela.

Écoute plus que tu parles.

Posez plus de questions que vous ne tentez de répondre (sauf si les questions s'adressent à vous). Les "anciens" de l'équipe sauront à quel point vous progressez dans l'apprentissage du code par les questions que vous posez. Ils ont probablement une liste mentale de questions auxquelles ils s'attendent.

Écrivez votre code pour correspondre au style dominant. Cela s'applique à l'endroit où vous mettez des espaces, des accolades, des majuscules, la longueur des noms de variables, la taille moyenne des méthodes, la densité des commentaires et tout ce qui ne devrait pas avoir d'importance. Si vous avez une très bonne raison de faire les choses différemment, demandez à l'un des anciens pourquoi l'équipe a le style donné. Vous pouvez apprendre des choses intéressantes sur l'histoire et les personnalités de l'équipe. Ce qui m'amène au point suivant.

Apprenez la tradition de l'équipe. Il est très probable qu'aucune histoire n'est écrite nulle part, mais c'est une connaissance commune de l'équipe. L'histoire de l'équipe comprend l'histoire de la façon dont le projet est arrivé à son état actuel, les erreurs commises dans le passé, les succès réalisés dans le passé, les leçons apprises en cours de route. Il est fait référence à de brèves déclarations comme «sonne à nouveau comme le bogue de frobnitz». Lorsque vous voyez / entendez des membres de l'équipe d'accord avec un commentaire énigmatique que quelqu'un fait, il y a probablement une tradition d'équipe impliquée. Demande à quelqu'un.

Ne critiquez pas le code avant de connaître les personnalités et l'histoire impliquées. Vous ne savez pas qui vous pourriez offenser.

Posez des questions et écoutez les réponses. Réfléchissez aux réponses aux questions précédentes avant de poser la suivante afin d'essayer d'anticiper une réponse.

Efforcez-vous de faire le meilleur travail possible. Habituez-vous à vous demander ce que les autres membres de l'équipe penseront de votre code s'ils doivent y apporter des modifications le mois prochain.

Si vous voyez un problème qui doit être résolu, faites de votre mieux pour avoir une solution raisonnable prête à offrir avant d'exprimer votre inquiétude à propos du problème. Prenez possession de la mise en œuvre d'une solution lorsque vous signalez un problème.