Pièges critiques que les nouveaux développeurs doivent éviter au cours de leurs premières semaines

Au cours des 6 dernières années, j'ai travaillé dans 5 équipes chez Palantir.

J'aurais aimé que quelqu'un me prévienne de ces 7 erreurs au début de ma carrière.

Prêt ? Commençons.

? Téléchargez mon livre GRATUIT de 101 trucs et astuces React pour prendre une longueur d'avance.

Erreur n°1 : donner des opinions bien arrêtées sur des choses que vous ne comprenez pas encore complètement

Nous voulons prouver notre valeur dès les premiers jours d'un travail.

C'est naturel de vouloir montrer à vos collègues que vous valiez la peine d'être embauché ?.

Cependant, cela peut conduire à donner des opinions bien arrêtées sur des choses que vous ne comprenez pas encore complètement.

Exemples

• Quelqu'un pose des questions sur les tests → vous proclamez : « C'est criminel de ne pas avoir une couverture à 100 %. »

• Quelqu'un parle de bibliothèques de gestion d'état → vous vous demandez pourquoi l'équipe utilise Redux et suggérez Zustand.

• L'équipe décide de supprimer des fonctionnalités pour respecter un délai → vous parlez de la façon dont cela se serait retourné contre votre entreprise précédente, des utilisateurs perdus, yada yada...

Je peux vous le dire tout de suite : cela n'atterrira pas bien dans 99 % des cas.

Pourquoi ?

• Vous n'avez pas le contexte complet, donc votre contribution est, au mieux, bruyante et, au pire, contre-productive.

• Vous faites perdre du temps à vos collègues qui se disputent ou vous expliquent les choses.

• Vous pouvez passer pour un « frimeur » sans vous en rendre compte. Ce n'est pas la meilleure façon de se faire des amis ?.

Alors, faut-il se taire pendant ses premières semaines ? Absolument pas.

Vous avez été embauché pour contribuer à l’équipe et partager votre point de vue. Cependant, assurez-vous que :

• Vous collectez autant de contexte que possible sur l'équipe et le produit : demandez d'abord « pourquoi ».

• Vous ne vous attachez pas trop à vos opinions. Présentez-les comme des suggestions plutôt que des dures vérités.

• Vous « montrez, ne dites pas » autant que possible.

Erreur n°2 : essayer de tout comprendre par vous-même

À moins que vous ne soyez la seule personne de votre équipe, demandez de l'aide.

Demandez après avoir essayé pendant un temps raisonnable. Ce qui est raisonnable dépend du type de question :

• Si vous êtes sûr de ne pas trouver de solution même après une heure, ou si le problème bloque votre productivité, demandez immédiatement. Par exemple, vous devez poser des questions telles que « Comment configurer cet ordinateur pour qu'il fonctionne avec des tests ? » instantanément.

• S'il s'agit d'un problème technique que vous pouvez résoudre en recherchant sur Google ou en utilisant des outils d'IA, essayez-le d'abord. Si cela ne fonctionne pas, demandez de l'aide après 30 minutes.

Pourquoi demander de l'aide ?

• Vous ne savez pas ce que vous ne savez pas.

• Le temps passé à découvrir ce que les autres savent déjà est du temps que vous pourriez consacrer à un travail productif.

Si vous êtes dans un environnement où l’aide n’est pas facilement disponible, vous devrez comprendre les choses.

Assurez-vous de documenter vos découvertes pour la personne suivante. Cela construit une base de connaissances et vous rapporte des points de « bon coéquipier ».

Erreur n°3 : trop se concentrer sur l'intégration et ignorer le travail de vos collègues

Je suis super introverti ?.

Donc, j'ai du mal à toucher de nouvelles personnes au hasard.

Cependant, chaque fois que je rejoins de nouvelles équipes, je me force à parler à mes coéquipiers, et cela porte toujours ses fruits.

Comment ?

• L'intégration m'a semblé moins intimidante lorsque j'ai réalisé que mes collègues étaient des personnes normales prêtes à aider.

• J'ai acquis un contexte précieux et compris ce qui comptait le plus pour l'équipe.

• J'ai construit un réseau de personnes vers qui je pourrais me tourner pour obtenir du soutien.

Alors, dès que vous rejoignez une nouvelle équipe, organisez des rencontres individuelles avec vos coéquipiers.

Interrogez-les sur leur travail, l'histoire de l'équipe, comment ils perçoivent leur rôle et tout conseil qu'ils pourraient avoir.

Erreur n°4 : essayer de tout mémoriser

Dans mon équipe première, je me sentais super perdue ?.

Les gens utilisaient des acronymes lors des réunions et j'avais du mal à suivre les conversations. Même lorsque je connaissais certains acronymes, je me sentais toujours dépassé.

J'ai essayé de tout mémoriser.

Mais c'était inutile.

Tout finira par devenir une seconde nature. Il est normal de se sentir dépassé au début.

La clé est de continuer à poser des questions de clarification.

Au fil du temps, vous comprendrez mieux les choses et développerez votre mémoire musculaire.

Erreur n°5 : se plaindre excessivement des systèmes de votre équipe

Aucune base de code n'est parfaite.

Aucune équipe n’est parfaite.

Les livres et les blogs donnent souvent l'impression que :

• Tout le monde devrait utiliser les dernières bibliothèques ou frameworks.

• Tout le code existant doit être refactorisé.

Lorsque vous atterrissez dans une équipe avec des pratiques différentes ou un code « désordonné », vous pourriez commencer à vous plaindre.

Vous pourriez même dresser une liste de tout ce qui ne va pas. ?‍♀️

C'est la pire façon de commencer un nouvel emploi.

À moins que vous ayez été embauché pour remanier l’équipe et ses processus (et même dans ce cas), ne faites pas cela.

Pourquoi ?

• Vous insinuez que l’équipe est « pauvre » en raison de choses manquantes.

• Vous ajoutez du travail non sollicité pour vos collègues.

• Vous aliénez les gens qui ont construit les systèmes sans comprendre les contraintes auxquelles ils étaient confrontés.

Ayez plutôt une attitude positive :

• Recherchez des moyens de fournir de la valeur.

• Montrez, ne dites pas : introduisez de meilleurs modèles dans vos demandes de tirage.

• Débats techniques ouverts avec l'équipe.

Si vous n'êtes pas satisfait des systèmes, envisagez de passer un entretien ailleurs ?.

Erreur n°6 : tenter de refactoriser le code sans contexte

J'ai commis cette erreur.

Je voulais apporter de la valeur, alors j'ai refactorisé le code sans qu'on me le demande.

Ça ne s’est pas passé aussi bien que je l’espérais.

Plus tard, quand quelqu'un a rejoint l'équipe et a refactorisé mon code sans rien demander, j'ai eu un avant-goût de ma propre médecine ?.

Refactoriser le code de quelqu'un sans contexte peut ressembler à une attaque. C'est comme si quelqu'un gâchait votre art.

Ne me @me pas : je sais que ce n'est pas sain ?.

Pourquoi c'est un problème :

• Vous manquez le contexte expliquant pourquoi le code existe.

• Vous négligez des tâches plus essentielles.

Au lieu de cela, refactorisez le code uniquement si :

• Quelqu'un demande de l'aide.

• Vous pouvez intégrer le refactor dans un travail significatif (par exemple, une pull request).

Erreur n°7 : Fixer des attentes irréalistes

Ne travaillez pas 12 à 14 heures par jour pendant vos premières semaines, sauf si vous prévoyez de le faire à long terme.

Cela peut sembler une bonne idée car :

• Vous voulez prouver votre valeur.

• Vous sentez qu'il y a trop de choses à apprendre.

• Vous êtes en probation.

Mais cela peut se retourner contre vous :

• Cela crée des attentes irréalistes pour votre équipe. Une réduction ultérieure pourrait créer des frictions.

• C’est insoutenable et peut conduire à l’épuisement professionnel.

Au lieu de :

• Répondre d'abord aux attentes de l'équipe.

• Si vous voulez faire plus, assurez-vous que c’est durable et bénéfique.

Les premières semaines sont un délai de grâce. Les gens s’attendent à ce que vous appreniez, pas que vous apportiez immédiatement de la valeur.

C'est fini ?.

L'intégration est un défi.

Mais certaines erreurs peuvent aggraver les choses :

• Partager des opinions fortes sans contexte.

• Agir sans contexte.

• Ne pas tirer parti de vos collègues.

Évitez ces erreurs et vous vous intégrerez rapidement dans votre nouvelle équipe.

Et n'oubliez pas de laisser un "???".

Si vous apprenez React, téléchargez mon livre 101 trucs et astuces React GRATUIT.

Si vous aimez les articles comme celui-ci, rejoignez ma newsletter GRATUIT, FrontendJoy.

Si vous voulez des conseils au quotidien, retrouvez-moi sur X/Twitter ou Bluesky.

? CONSEIL DE LA SEMAINE

? MATIÈRE À RÉFLÉCHIR

<script> // Detect dark theme var iframe = document.getElementById('tweet-1877747297402142883-419'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1877747297402142883&theme=dark" } </script> <script> // Detect dark theme var iframe = document.getElementById('tweet-1876901704563872142-960'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1876901704563872142&theme=dark" } </script>

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!