Comment devenir un bon joueur d'équipe? [fermé]

Je programme (de manière obsessionnelle) depuis mes 12 ans. Je connais assez bien le spectre des langages, de l'assemblage au C ++, en passant par Javascript, Haskell, Lisp et Qi. Mais tous mes projets l'ont été par moi-même.

J'ai obtenu mon diplôme en génie chimique, pas en génie informatique ou en génie informatique, mais pour la première fois cet automne, je vais travailler sur un grand projet de programmation avec d'autres personnes, et je ne sais pas comment me préparer. J'ai utilisé Windows toute ma vie, mais ce projet va être très unixy, j'ai donc acheté un Mac récemment dans l'espoir de me familiariser avec l'environnement.

J'ai eu la chance de participer à un hackathon avec des amis l'année dernière - les deux majors CS - et assez excitant, nous avons gagné. Mais j'ai réalisé en travaillant avec eux que leur flux de travail était très différent du mien. Ils ont utilisé Git pour le contrôle de version. Je ne l'avais jamais utilisé à l'époque, mais j'ai depuis appris tout ce que je pouvais à ce sujet. Ils ont également utilisé de nombreux frameworks et bibliothèques. J'ai dû apprendre ce que Rails était à peu près du jour au lendemain pour le hackathon (d'un autre côté, ils ne savaient pas ce qu'étaient la portée lexicale ou les fermetures). Tout notre code fonctionnait bien, mais ils ne comprenaient pas le mien et je ne comprenais pas le leur.

J'entends des références à des choses que les vrais programmeurs font quotidiennement - les tests unitaires, les revues de code, mais je n'ai que le sens le plus vague de ce que c'est. Normalement, je n'ai pas beaucoup de bogues dans mes petits projets, donc je n'ai jamais eu besoin d'un système de suivi des bogues ou de tests pour eux.

Et la dernière chose est qu'il me faut beaucoup de temps pour comprendre le code des autres. Les conventions de dénomination variables (qui varient avec chaque nouvelle langue) sont difficiles (__mzkwpSomRidicAbbrev), et je trouve le couplage lâche difficile. Cela ne veut pas dire que je ne couple pas les choses de manière lâche - je pense que je suis assez bon dans ce domaine pour mon propre travail, mais quand je télécharge quelque chose comme le noyau Linux ou le code source Chromium pour le regarder, je passe des heures à essayer pour comprendre comment tous ces répertoires et fichiers aux noms étranges se connectent. C'est un péché de programmation de réinventer la roue, mais je trouve souvent qu'il est juste plus rapide d'écrire moi-même la fonctionnalité que de passer des heures à disséquer une bibliothèque.

De toute évidence, les gens qui font cela pour gagner leur vie n'ont pas ces problèmes, et je vais devoir y arriver moi-même.

Question: Quelles sont les étapes à suivre pour commencer à "intégrer" avec tout le monde?

Merci!

Je pense que vous devenez un peu anxieux et excité à l'idée de travailler pour un groupe.

Aucun de nous n'a appris à travailler dans un groupe ou une équipe à partir de livres ou n'a reçu de petits pas ou un "Guide pour les nuls sur le travail en équipe".

Nous apprenons simplement à travailler AVEC des groupes en travaillant dans des groupes.

Tout ce que vous avez entendu sur les programmeurs professionnels, se mettra en place progressivement au fur et à mesure que vous travaillerez en équipe.

Pour moi, le résultat est

Faites partie d'une équipe.

Je vais choisir certaines de vos phrases et faire quelques remarques générales:

(d'autre part, ils ne savaient pas ce qu'étaient la portée lexicale ou les fermetures). Tout notre code fonctionnait bien, mais ils ne comprenaient pas le mien et je ne comprenais pas le leur.

...

J'entends des références à des choses que les vrais programmeurs font quotidiennement - les tests unitaires, les revues de code, mais je n'ai que le sens le plus vague de ce que c'est. Normalement, je n'ai pas beaucoup de bogues dans mes petits projets, donc je n'ai jamais eu besoin d'un système de suivi des bogues ou de tests pour eux.

...

Je passe des heures à essayer de comprendre comment tous ces répertoires et fichiers aux noms étranges se connectent ... Je trouve souvent qu'il est juste plus rapide d'écrire moi-même la fonctionnalité que de passer des heures à disséquer une bibliothèque.

Je pense que la plus grande chose que vous devrez apprendre est la suivante:

Pour une norme donnée de capacité de développeur, une équipe de ndéveloppeurs fait moins de nfois le travail que l'un des développeurs pourrait faire seul - mais ils font toujours plus que n'importe qui .

La raison est simple: lorsque vous travaillez avec d'autres personnes, vous devez passer une partie de votre temps à échanger des informations avec ces autres personnes; alors que lorsque vous travaillez seul, l'échange d'informations se déroule dans votre tête. Ce qui est naturellement plus rapide.

L'autre chose importante est:

Certains de vos collègues seront moins capables que vous, certainement dans certaines compétences; certains seront même moins capables que vous dans toutes les compétences

Avec ces deux idées à l'esprit, tout ce que j'ai cité ci-dessus est logique. Beaucoup de gens n'obtiennent pas de fermetures.Les tests et les révisions de code visent à garantir la qualité et à réduire les risques lorsque le code est produit par un groupe de personnes aux capacités mixtes . Le suivi des bogues est dû au fait que lorsque vous produisez des systèmes suffisamment grands, les bogues sont inévitables. Et les bibliothèques sans fin avec leurs conventions sont parce que sans conventions, il y a juste trop de code pour l'apprendre ou l'écrire à chaque fois que vous en avez besoin.

Vraiment, je pense que la seule façon d'apprendre à travailler en équipe est de le faire; mais j'espère que ce qui précède vous aidera à vous préparer mentalement. Bonne chance!

Le moyen le plus efficace est de faire partie d'une équipe.

Rejoindre une équipe peut sembler difficile, car je comprends que vous ne faites pas encore partie d'une équipe, comme de nombreux étudiants et de nombreuses personnes dont le travail consiste à travailler avec aucun autre développeur.

Je vous recommanderais de participer à un projet open-source très actif et favorisant une communication fréquente sur les canaux modernes ouverts à tous (tracker problème, liste de diffusion, wiki, etc.). Une communication ouverte est importante car vous commencerez probablement par observer comment les autres interagissent, évitez donc les projets qui reposent sur les e-mails entre développeurs principaux ou IRC non archivé.

Préférez un projet qui semble accueillant, avec plusieurs contributeurs assez fréquents , plutôt qu'un projet avec 1 personne qui fait tout. Aussi, préférez les projets où tout le monde est autorisé à toucher à tout (plutôt que chaque développeur ayant sa zone délimitée), car c'est plus amusant et offre plus de possibilités de communication.

Plug sans vergogne: vous êtes les bienvenus ici !

Je ne répéterai pas ce que tout le monde a déjà dit à propos de cela "just do it", mais j'ajouterai un point supplémentaire que je n'ai pas vu mentionné: un bon manager vous aidera vraiment à vous intégrer dans l'équipe.

Bien que vous ayez toutes les bonnes informations à votre sujet pour la partie programmation du travail, vous pourriez manquer certaines des choses plus interpersonnelles et liées au développement logiciel. Un bon manager vous guidera vers les pratiques des équipes (à la fois en soft skills et en hard skills) pour vous aider à vous gélifier, et vous dira aussi, espérons-le, si vous avez fait ou faites quelque chose qui s'oppose à ces pratiques; parce que vous ne pouvez pas réparer quelque chose que vous ne savez pas est cassé.

Un autre conseil que je voudrais vous donner, c'est qu'il n'y a pas deux équipes identiques et que même une équipe existante changera lorsqu'une ou plusieurs personnes la rejoindront.

Une équipe est issue de l'interaction d'individus qui apprennent à se connaître et essaient de comprendre comment travailler ensemble jusqu'à ce qu'ils trouvent une voie commune (voir par exemple les étapes de développement de groupe de Tuckman ).

Mon conseil ne serait donc pas d'essayer de trouver des réponses à vos questions maintenant, mais de voir ce qui se passe lorsque vous commencez réellement à travailler dans la nouvelle équipe. Certains de vos problèmes peuvent être considérés comme non-problématiques par vos collègues, d'autres seront considérés comme pertinents et vous aurez la possibilité de les discuter ensemble ou même de faire valoir votre propre opinion sur le sujet. Et enfin, vous aborderez probablement aussi des aspects auxquels vous n'aviez pas pensé.

Je suis d'accord avec ElYusubov que vous avez besoin de beaucoup de patience et donnez à vous-même et aux nouveaux collègues une équipe pour apprendre à travailler ensemble jusqu'à ce que vous deveniez une équipe. Si vous pratiquez un sport d'équipe, vous devriez déjà en avoir fait l'expérience.

Un dernier commentaire sur le fait de passer beaucoup de temps à comprendre le code des autres. Travailler en équipe signifie que vous allez travailler sur le code de quelqu'un d'autre et que d'autres développeurs vont travailler sur votre code. Parfois, le code est trop complexe pour être réécrit à partir de zéro. Une solution typique consiste à demander au développeur d'origine de revoir vos modifications, afin que vous ayez un peu plus de confiance que vous ne cassez rien dans leur code.

Ce fut pour moi un grand saut dans la transition d'un programmeur solo à un programmeur d'équipe: vous travaillez sur du code que vous ne comprenez que partiellement et vous devez vous y habituer. Cela implique beaucoup plus de communication avec vos collègues, beaucoup de respect (oui, les conventions de nommage sont étranges pour leurs variables, alors quoi?) Et la confiance mutuelle (même si elles ont un style de codage différent, je sais qu'elles fournissent du code de travail) .

Être un bon membre d'équipe signifie communiquer sans crainte, faire confiance à vos collèges et surmonter les obstacles dans un projet en équipe etdeliver project as a team.

Cela prend du temps , prend du patient et nécessite d'apprendre pour se sentir à l'aise et confiant en tant que programmeur. Il est également vrai que tous les programmeurs ne sont pas un bon joueur d'équipe , et les joueurs d'équipe partagent leur succès et tirent les leçons des échecs.

Il serait utile de mettre en évidence certains personnages d'un bon membre de l'équipe .

a) Un bon membre de l'équipe est une personne qui est orientée vers un but plutôt que vers soi.

b) Qualités: penser davantage à une vue d'ensemble plutôt qu'à l'autosatisfaction. Ceci est un point clé. Toutes les autres qualités (comme la fiabilité, la communication constructive,) héritent de celle-ci

c) Comment s'améliorer: Essayez de qualifier comment avez-vous interagi avec votre équipe pendant la journée, définissez les bons et les mauvais points, faites-y attention lors des prochaines réunions. Essayez également d' examiner les décisions de l' équipe sous plusieurs angles. Placez-vous sur les rôles de l'autre, réfléchissez à la façon dont vous pouvez affecter le travail des autres.

Tout d'abord, félicitations pour être le genre de personne qui semble vraiment apprécier la programmation. Cependant, la programmation n'est pas le début et la fin de la livraison de systèmes utiles. Vous allez avoir un défi devant vous et ce sera à vous de décider si vous retournez à des programmes de loisir ou poursuivez une carrière où vous pouvez faire ce que vous aimez et être payé pour cela.

Vous êtes désavantagé dans la mesure où vous n'avez aucune formation en construction de logiciels. Dans cette éducation, il y a plusieurs choses enseignées (pas seulement comment programmer) que pour les diplômés CS et les développeurs de logiciels expérimentés, ce sera une seconde nature. Non pas que cela revienne souvent sur le lieu de travail (bien que ce soit le cas pour moi, une fois), mais NP-hard est un exemple de terme qu'ils peuvent comprendre et que vous ne pourriez pas. Vous n'avez probablement aucune expérience en théorie formelle derrière le calcul, mais ça va, tant que vous êtes prêt à en savoir plus. Peut-être un master en CS dans votre avenir? Il semble que certains de vos codes puissent être idiomatiques, dans le sens où vous avez un style de programmation qui vous semble clair, mais pas aux autres. Faites attention dans les revues de code et soyez prêt à accepter la critique et à apprendre. Cela va prendre du travail, et vous pourriez être frustré,

Ce que vous avez pour vous est inestimable. Vous semblez vraiment apprécier la programmation. Je pense que vous apprécierez également les autres aspects du développement de systèmes, tels que la conception, l'architecture, les tests, l'optimisation, etc. La programmation est une partie du puzzle et vous devrez acquérir d'autres compétences pour devenir développeur de logiciels. Hackathons mis à part, une grande partie de l'entreprise implique la communication, l'apprentissage mutuel, l'écoute et la planification. J'ai travaillé avec beaucoup de gens qui sont diplômés de CS et qui aimaient le développement de logiciels plus que la vente de voitures ou la peinture de maisons, mais je n'en avais pas vraiment l'amour.