Article original : How to Become an Outstanding Junior Developer

Par John Mosesman

Si vous lisez ceci, vous avez probablement obtenu votre premier emploi dans le domaine de la technologie — alors félicitations ! Obtenir le premier emploi est l'une des choses les plus difficiles que vous ferez dans le domaine de la technologie. Il y a déjà tant de travail et d'efforts derrière vous.

Ou peut-être que vous n'avez pas encore votre premier emploi, mais vous voulez savoir à quoi vous attendre.

Dans les deux cas, dans cet article, je vais aborder les préoccupations et questions courantes concernant ce à quoi s'attendre sur le lieu de travail, et comment réussir une carrière en tant que développeur.

Voici ce que nous allons couvrir :

  1. À quoi s'attendre sur le lieu de travail (premiers jours/semaines)
  2. Votre plan à court et moyen terme
  3. L'état d'esprit pour réussir
  4. Comment être un nouveau développeur exceptionnel

À quoi s'attendre sur le lieu de travail

Le grand jour arrive enfin. Vous entrez dans le bureau (ou rejoignez la réunion matinale de l'équipe à distance) pour la première fois en tant que nouveau développeur. Même si vous êtes nerveux, essayez de vous souvenir et de profiter de votre premier jour. C'est un moment excitant !

Votre premier jour sera probablement consacré à des choses logistiques : configurer votre ordinateur, des orientations ou des formations, et des formalités RH (informations bancaires, assurance, etc.).

Cependant, il devient une pratique courante de faire en sorte que les nouveaux développeurs effectuent un push en production dès leur premier jour. Il s'agit généralement de quelque chose de très petit — comme ajouter votre nom et votre photo ou corriger une faute de frappe sur le site web de l'entreprise. Cela teste que la configuration de votre ordinateur est prête, et cela vous donne également une victoire rapide et vous permet de rejoindre le reste de l'équipe qui livre du logiciel.

Votre entreprise veut que vous réussissiez

En tant que nouveau développeur, l'entreprise qui vous a embauché connaît les limites de vos connaissances et compétences actuelles. Ils comprennent qu'ils devront investir beaucoup de temps dans votre croissance pour vous enseigner et vous former.

Rappelez-vous, cette entreprise veut que vous réussissiez ! Ils sont de votre côté. Cette entreprise a fait un effort énorme pour vous trouver, vous interviewer et vous embaucher. C'est un processus coûteux à la fois en temps et en argent pour l'entreprise. Ils ne vont pas vous laisser tomber — ce serait une mauvaise façon de traiter leur investissement en vous.

Il y a certaines compétences que vous apportez dès le début, mais il y a certaines compétences qui sont difficiles (bien que pas impossibles) à acquérir en dehors d'un environnement de travail professionnel.

Puisque c'est votre premier emploi, il est probable que vous n'ayez jamais collaboré avec une grande équipe en utilisant le contrôle de source ou maintenu des applications en production — et c'est normal ! Ces compétences sont plus faciles à acquérir dans un environnement de production.

Vos premiers jours/semaines

Une fois votre ordinateur configuré et que vous avez accès à tous les outils dont vous avez besoin, vos premières tâches seront probablement des améliorations mineures de fonctionnalités ou la correction de petits bugs — juste des choses pour vous familiariser avec les différents projets.

En dehors des connaissances techniques pures, dans chaque entreprise, il y a des connaissances spécifiques au domaine ou une "logique métier" (ce que font les produits ou services de l'entreprise et comment ils le font) que vous devrez acquérir.

Si l'entreprise a plusieurs produits, ils peuvent vous donner de petites tâches dans chaque base de code pour commencer à explorer ces produits. Il est également probable qu'ils assignent une autre personne de l'équipe pour travailler avec vous — ou au moins être disponible pour répondre à vos questions tout au long des premières semaines.

Dans ces premiers jours et semaines, vous n'avez qu'un seul objectif : apprendre, apprendre, apprendre.

Apprenez sur la technologie que vous utilisez, apprenez sur l'entreprise et son fonctionnement, et apprenez à travailler avec vos coéquipiers. Votre production de travail n'est pas importante à ce stade — votre taux de croissance l'est.

Plonger dans une base de code de production

Lorsque vous commencez à travailler sur les différentes bases de code de votre entreprise, vous vous sentirez probablement comme un poisson hors de l'eau. C'est tout à fait normal — il est beaucoup plus facile d'écrire du code que de le lire.

Une base de code de production est très différente des tutoriels que vous avez suivis ou des projets d'apprentissage avec lesquels vous avez travaillé.

Pour commencer, cette base de code existe probablement depuis de nombreuses années et a été travaillée par de nombreuses personnes différentes — chacune avec son propre style et chacune faisant ses propres erreurs.

Il est également probable qu'il y ait beaucoup plus de packages logiciels ou de plugins injectés dans cette application que vous n'en avez rencontrés auparavant. Toutes les astuces pratiques ou cas particuliers qui étaient ignorés dans un tutoriel (comme la gestion des erreurs) doivent être traités ici — c'est une vraie application.

Cela peut être accablant au début, mais lire le code des autres est une compétence que vous devez développer, et c'est une compétence que vous utiliserez toute votre carrière (et à la fin de cet article, je vous donnerai quelques conseils pour vous aider avec cela).

En fin de compte, n'ayez pas peur de demander de l'aide ! Vos coéquipiers sont là pour vous soutenir, et à un moment donné dans le passé, ils ont dû poser les mêmes questions exactes.

Attentes pour les nouveaux développeurs

Tout d'abord : cette entreprise ne s'attend pas à ce que vous vous lanciez et commenciez à réaliser des fonctionnalités. Ils savent que vous aurez besoin de temps pour développer des compétences que vous n'avez pas encore, comprendre les bases de code et apprendre à travailler efficacement avec l'équipe.

Il est probable que votre patron se réunisse avec vous et crée un plan pour 30/60/90 jours. S'ils ne le font pas — demandez ! Tout superviseur appréciera que vous preniez en charge votre travail et vos attentes professionnelles.

Dans les 30 premiers jours, vous ferez probablement des améliorations mineures de fonctionnalités et des corrections de petits bugs — juste des choses pour connaître les produits et les bases de code de l'entreprise. À 60 jours, il est probable que vous travailliez sur des fonctionnalités et des corrections de bugs légèrement plus grandes. À 90 jours, la portée aura un peu augmenté, mais ils ne s'attendront toujours pas à ce que vous preniez en charge et fassiez avancer de grandes fonctionnalités vous-même.

En fin de compte, l'entreprise veut simplement que vous continuiez à apprendre et à absorber les informations autour de vous. Vous ne saurez pas tout en arrivant, ou après 90 jours, et c'est normal ! Prenez les choses un jour à la fois.

L'état d'esprit du nouveau développeur

En entrant dans une nouvelle entreprise, il y a beaucoup de choses que vous ne pouvez pas contrôler, mais il y a une chose très importante que vous pouvez contrôler : votre état d'esprit. Vos pensées quotidiennes, vos pratiques et la façon dont vous intériorisez ce qui se passe autour de vous détermineront votre succès.

Parfois, vous serez confus, parfois vous vous sentirez submergé, et parfois vous douterez même de pouvoir faire cela (je l'ai fait). La façon dont vous intériorisez ces pensées compte. Rappelez-vous, ce n'est pas unique à vous — chaque nouveau développeur a fait face à cela. Gardez votre esprit sous contrôle et vous passerez à travers.

Lorsque vous rencontrez quelque chose de confus ou de frustrant, repositionnez votre esprit : cet obstacle est une opportunité d'apprentissage.

C'est une opportunité de comprendre quelque chose de nouveau et de grandir. C'est nul, ça fait mal, mais peu de temps après cela, vous serez un meilleur développeur. Et cela arrivera souvent — c'est juste la réalité d'être nouveau dans quelque chose.

Au lieu d'intérioriser :

"Je me suis bloqué 10 fois aujourd'hui."

Essayez plutôt :

"J'ai eu 10 opportunités d'apprendre aujourd'hui."

C'est un changement puissant, et il sera évident pour vos coéquipiers et dans votre performance au travail.

Rester au top de votre esprit et ne pas laisser le sentiment de défaite s'installer vous aidera non seulement à mieux performer dans la situation, mais cela augmentera également les connaissances et les compétences que vous retirez de la situation. Prenez une profonde inspiration, faites une pause, demandez de l'aide — mais continuez à avancer.

Et puis à la fin de la journée : haussez les épaules et laissez tout tomber. Laissez tout sur le sol lorsque vous quittez le bureau ou fermez votre ordinateur pour la journée. Commencez la journée suivante frais et prêt pour ses propres aventures.

Aussi, n'oubliez pas de célébrer les petites victoires en cours de route ! Ces petites victoires s'accumuleront et deviendront une grande montagne de succès avec le temps.

Voici une autre chose importante à retenir : accordez-vous la liberté de faire des erreurs. Vous allez casser la production, vous allez faire de mauvaises mises à jour de la base de données (je l'ai définitivement fait) — c'est récupérable, ce n'est pas la fin du monde ou de votre travail, et tout développeur expérimenté l'a fait. C'est juste une partie du processus.

Votre plus grande compétence en tant que nouveau développeur

Vous ne vous en rendez peut-être pas compte, mais votre plus grande compétence en tant que nouveau développeur est que vous avez appris à apprendre.

Vous avez appris à prendre quelque chose de difficile, de complexe, d'obscur, et à le décomposer en morceaux — à le travailler étape par étape.

Plus que d'apprendre JavaScript, React, Ruby, ou autre chose, la meilleure chose que vous avez apprise est comment vous enseigner à vous-même. Prenez cette compétence pratiquée que vous avez et montrez-la chaque jour.

Prenez en charge votre croissance — personne d'autre ne le fera.

Cela pourrait être l'énoncé le plus important pour un développeur à n'importe quelle étape de sa carrière : votre carrière vous appartient. Vous devez en prendre la responsabilité, et vous devez prendre en charge votre croissance.

Parfois, votre entreprise, votre poste ou votre patron vous aidera à faciliter votre croissance, mais en fin de compte, c'est à vous.

La plupart des entreprises ont une sorte de processus d'évaluation planifié — peut-être trimestriel ou annuel. Si elles le font, c'est bien, mais si elles ne le font pas, prenez en charge votre croissance ! Demandez régulièrement à votre superviseur des commentaires, et faites ce qu'ils disent. Si quelqu'un mentionne quelque chose que vous n'avez jamais entendu, demandez-leur à ce sujet ou allez faire vos propres recherches !

"Le Pouvoir des Petits Gains"

https://jamesclear.com/marginal-gains https://jamesclear.com/marginal-gains

L'un de mes livres préférés, Atomic Habits de James Clear, a un excellent diagramme intitulé "Le Pouvoir des Petits Gains." C'est un diagramme simple. Il montre la différence entre une amélioration de 1 % et un déclin de 1 % chaque jour.

Si vous vous améliorez de 1 % chaque jour, après un an, vous serez presque 38 fois meilleur que vous ne l'étiez au début de l'année ! C'est le pouvoir des "petits gains", et c'est tout aussi vrai pour devenir un excellent développeur de logiciels.

Chaque jour, vous avez l'opportunité d'apprendre quelque chose de nouveau — peu importe à quel point c'est petit. Peut-être que c'est une nouvelle fonction sur les tableaux que vous ne connaissiez pas, une méthode différente pour structurer le CSS, un nouveau raccourci de l'éditeur de texte, ou quelque chose de complètement nouveau comme apprendre le SQL et comment les données sont stockées au niveau de la base de données.

Quoi qu'il en soit, visez à être 1 % meilleur chaque jour (la plupart des jours, vous finirez par faire beaucoup plus) et la croissance des premières années de votre carrière sera stupéfiante.

Une page par jour

Image

J'ai entendu une histoire dans un podcast de développeurs sur le gars qui maintient le gem pg pour Ruby. C'est le gem qui fait l'interface entre votre code Ruby et la base de données Postgresql. C'est assez sérieux, et il est utilisé par la plupart des développeurs Ruby chaque jour.

L'histoire de la façon dont il est devenu le mainteneur de ce gem était intéressante. Il a dit que lorsqu'il a commencé, il ouvrait la documentation de Postgresql et lisait une page — juste une page chaque jour.

Avec le temps, il a acquis une connaissance approfondie de Postgresql et a pu commencer à contribuer au gem pg. Après un peu plus de temps, il est devenu le mainteneur de ce gem.

C'est l'exemple parfait de petits gains qui s'accumulent — juste une page par jour. Nous pouvons tous le faire, et je vous encourage à prendre la même philosophie et à l'appliquer à n'importe quel langage ou système avec lequel vous travaillez !

"La pratique rend parfait"

Vous avez probablement entendu cette phrase auparavant : "la pratique rend parfait."

Mon professeur de piano, lorsque j'étais enfant, utilisait une phrase différente : "la pratique parfaite rend parfaite."

Je pense qu'il avait raison. Je pouvais pratiquer le piano de la mauvaise manière — avec une mauvaise technique, de manière négligée, sans un rythme régulier — et c'est le résultat que j'obtiendrais : un jeu de piano négligé.

Ce n'est pas juste la pratique, mais comment vous pratiquez qui compte. Je pouvais pratiquer la première mesure d'une chanson encore et encore et la maîtriser parfaitement, mais si je ne dépassais jamais la première mesure, je n'apprendrais jamais la chanson. Je pouvais jouer cette première mesure de la chanson au niveau d'un pianiste de classe mondiale, mais je voulais jouer du piano, alors j'ai dû apprendre toute la chanson.

C'est un parallèle parfait pour le développement. La manière dont vous "pratiquez" le développement (vos habitudes quotidiennes, méthodes et routines pour le développement) détermine le type de développeur que vous deviendrez.

Au début, vous ferez beaucoup d'erreurs (tout le monde en fait), mais si vous êtes conscient de votre travail, vous remarquerez des domaines que vous pouvez améliorer. Ce sont des moments de pratique parfaite : l'opportunité d'apprendre quelque chose de nouveau ou de faire quelque chose de manière meilleure.

Lorsque vous regarderez en arrière sur votre carrière dans dix ans, vous voudrez avoir eu dix ans de croissance, de pratique et d'apprentissage — pas une année de croissance, de pratique et d'apprentissage répétée dix fois.

Alors posez ces questions stupides. Posez les questions évidentes. Lorsque quelqu'un mentionne quelque chose que vous ne connaissez pas, demandez hardiment, "Qu'est-ce que c'est ?" Mon espoir est qu'ils répondent de manière gentille et enseignante, mais quoi qu'il en soit, soyez prêt à apprendre.

Tout revient à prendre en charge votre croissance.

Les personnes en forme de T

Une personne "en forme de T" Une personne "en forme de T"

Au début de votre carrière de développeur, il y a tant de sujets dont vous pouvez bénéficier en les connaissant, donc vous voulez répartir vos efforts et vos connaissances sur un large éventail de sujets.

Si vous visez à devenir un développeur full-stack, cette liste peut inclure des choses comme HTML, CSS, JS, un langage backend de votre choix, SQL, Git, etc. Il y a tant de connaissances et de bénéfices facilement accessibles à la surface de chacun de ces sujets qui peuvent être acquis en jetant un large filet et en absorbant tout.

Avec le temps, vous découvrirez quel type de développement vous préférez. Peut-être que c'est le frontend, le backend, le travail sur les bases de données, les opérations, le design — ou une combinaison de ceux-ci et plus encore.

Au fur et à mesure que votre carrière progresse, vous commencerez à devenir une "personne en forme de T". Une personne en forme de T est quelqu'un qui, comme la lettre "T" est visualisée, a une connaissance et une expérience larges mais peu profondes sur beaucoup de choses, et quelques domaines avec une grande quantité de connaissance et d'expérience.

Cette connaissance approfondie prend un certain temps à se construire, et chaque étape en profondeur demande de plus en plus d'efforts que la précédente — c'est simplement la réalité lorsque vous approchez de la maîtrise d'un sujet. Au début, ramassez tous ces gains faciles pour débutants sur un large éventail de sujets.

Avoir cette capacité en forme de T vous aidera à devenir un meilleur développeur dans l'ensemble. Les développeurs frontend qui comprennent le schéma de la base de données ou les développeurs backend qui comprennent comment ces tables de base de données vont être utilisées comme modèles dans le frontend seront plus compétents et de meilleurs coéquipiers que ceux qui sont cloisonnés dans leur propre domaine.

Au début, cette petite incursion dans tous les aspects du développement est également utile pour trouver ce qui vous attire, et pour vous donner une vue d'ensemble de toutes les pièces mobiles dans le monde du logiciel.

Suivez vos intérêts et restez affamé d'apprendre !

Conseils pour être un excellent nouveau développeur

Maintenant que nous avons couvert vos attentes et comment les aborder, voici quelques conseils pratiques pour faire de vous un excellent nouveau développeur — celui que vos coéquipiers adorent travailler avec.

#1 Communiquez vraiment vraiment vraiment vraiment vraiment vraiment bien

Vous n'avez peut-être pas des connaissances et des compétences incroyables en développement en arrivant votre premier jour, mais vous pouvez avoir des compétences incroyables en communication.

En tant que nouveau développeur, vous allez demander de l'aide et des conseils — beaucoup. Et c'est normal ! Voici un conseil pour demander de l'aide efficacement.

Être bloqué est frustrant (c'était le cas pour moi). Dans ces moments, il est facile de laisser cette frustration vous submerger et de poser des questions à votre coéquipier à côté de vous (ou peut-être par e-mail ou une application de chat).

Des choses comme :

"je suis bloqué"
"ça a généré une erreur"
"la page ne se charge pas"

Maintenant, faites un pas en arrière et voyez cela du point de vue de la personne à qui vous demandez de l'aide. Un message comme "la page ne se charge pas" n'aide pas du tout cette personne à vous aider. Il n'y a pas de contexte. Il n'y a pas d'informations sur lesquelles elle peut se baser. En fait, elle doit demander plus d'informations de votre part. Cela est incroyablement inefficace et très frustrant pour la personne qui essaie de vous aider.

Une meilleure façon de demander de l'aide est de le voir comme un Mad Lib (si vous vous en souvenez) :

Je travaille sur _,
mais lorsque j'essaie _,
_ se produit à la place.

J'ai essayé _, _, et _.
et j'ai regardé _ et _.

Un exemple de ce message pourrait être quelque chose comme ceci :

Je travaille sur le bug de réinitialisation du mot de passe de l'utilisateur,
mais lorsque j'essaie de générer un lien de réinitialisation du mot de passe,
le jeton de l'utilisateur est déjà vide.

J'ai regardé où le jeton est défini, et je peux voir le jeton dans la base de données,
mais le jeton est manquant à la ligne X du fichier Y.

Si vous envoyez à quelqu'un le message ci-dessus, il peut comprendre :

  • Sur quoi vous travaillez
  • Quel est le problème
  • Ce que vous avez déjà essayé
  • Où se trouve le problème

C'est une mine d'informations pour la personne à qui vous demandez de l'aide. Elle appréciera grandement que vous lui ayez donné ces informations de manière si claire — et que vous avez déjà essayé de le réparer vous-même. Cela leur montre que vous respectez leur temps, et que vous ne cherchez pas simplement une solution facile.

Il n'y a rien de mal à obtenir de l'aide, mais si quelqu'un résout simplement le problème pour vous, il vous a en réalité volé l'opportunité d'apprendre et de grandir vous-même.

Ce n'est pas comme s'il y avait dix problèmes à résoudre et que vous en aviez fini pour le reste de votre vie — vous serez confronté à des problèmes chaque jour en tant que développeur. Donc le meilleur résultat est qu'ils vous donnent suffisamment d'aide pour vous débloquer mais vous permettent de résoudre le problème vous-même.

#2 Perfectionnez votre Google Fu

Tout comme le développement de compétences dans l'art martial physique du Kung Fu, avec le temps en tant que développeur, vous développerez des compétences dans l'art du Google Fu — c'est-à-dire l'art de trouver des réponses en les cherchant sur Google. C'est une vraie compétence que tout développeur expérimenté possède et qui se développe avec le temps.

Parfois, il suffit de chercher le problème exact que vous avez (cela fonctionne très bien avec les messages d'erreur) :

Parfois, coller le message d'erreur entier fonctionne Parfois, coller le message d'erreur entier fonctionne

Parfois, chercher le message d'erreur exact produira le résultat correct, comme cela a été le cas ci-dessus. Vous avez rencontré un problème technique, et quelqu'un d'autre a rencontré le même problème exact.

Mais parfois, vous devez modifier légèrement la requête de recherche pour supprimer les informations spécifiques au projet :

Trop d'informations spécifiques au projet ne donne aucun résultat Trop d'informations spécifiques au projet ne donne aucun résultat

Dans l'image ci-dessus, Google n'a jamais vu la fonction whos_that_pokemon_its_pikachu() dans le fichier gotta_catchem_all.rb (sauf maintenant qu'il l'a vu puisque je l'ai recherchée :)). Supprimer ces informations spécifiques au projet et ajouter des informations génériques donne de meilleurs résultats.

L'erreur générique sous-jacente L'erreur générique sous-jacente

#3 Utilisez un "minuteur d'essai"

En tant que nouveau développeur, vous allez souvent être bloqué. Il y aura des messages d'erreur que vous n'avez jamais vus auparavant, et la façon dont vous gérez ces situations déterminera la rapidité avec laquelle vous grandirez en tant que développeur.

Bien que ces moments puissent être terriblement frustrants, ce sont les moments où vous apprendrez et grandirez. Vous n'apprenez pas en faisant le même type de travail encore et encore — c'est en traversant ces bosses sur la route que la croissance a lieu.

Lorsque vous rencontrez l'un de ces problèmes, prenez le temps d'essayer de le résoudre vous-même. Certaines entreprises vous diront cela dans le cadre de l'intégration — quelque chose comme "essayez pendant 30 minutes avant de demander de l'aide." Dans d'autres entreprises, ce n'est pas aussi clairement défini, mais le message est toujours là : faites de votre mieux et ensuite, si vous êtes toujours bloqué, demandez de l'aide.

Cela vous permet non seulement l'opportunité de le résoudre et d'apprendre par vous-même, mais cela respecte également le temps de vos coéquipiers qui sont concentrés sur leur propre travail. Interrompre quelqu'un pour quelque chose que vous auriez pu résoudre rapidement vous-même est une perte nette pour l'équipe.

Alors essayez bien, et ensuite bien sûr demandez de l'aide !

Voici le secret pour être un excellent nouveau développeur : réinitialisez toujours le minuteur.

Disons que vous êtes bloqué, vous essayez pendant 30 minutes, puis vous demandez de l'aide. La prochaine fois que vous êtes bloqué, essayez à nouveau pendant 30 minutes avant de demander de l'aide.

Cela peut sembler évident, mais ces jours où il semble que vous ne rencontriez que problème après problème, vous allez vous frustrer et vous allez vouloir commencer à demander de l'aide dès que le prochain problème arrive — c'est juste naturel.

Prenez une profonde inspiration, faites une petite promenade, et abordez chaque problème avec une nouvelle perspective.

(Cela est, bien sûr, plus facile à dire qu'à faire !)

#4 N'oubliez pas de vous détendre et de faire des pauses !

N'oubliez pas de faire des pauses lorsque les choses commencent à devenir accablantes.

Allez vous promener. Allez chercher un verre d'eau. Dormez dessus si vous le pouvez. Parfois, il suffit de se lever et de bouger pendant une minute pour se recentrer.

Rappelez-vous que chaque développeur a déjà été à votre place, et vous allez vous en sortir.

Le développement sera toujours frustrant dans une certaine mesure — vous ne cesserez jamais de faire des erreurs ou de rencontrer des problèmes. Mais avec le temps, vous deviendrez simplement meilleur pour les gérer, et votre confiance pour résoudre ces problèmes augmentera, donc cela vous dérangera de moins en moins.

#5 Demandez au canard

Avez-vous déjà écrit un e-mail ou un message texte décrivant un problème que vous avez à quelqu'un, et juste avant d'appuyer sur envoyer, vous réalisez la solution ? Dans le monde du logiciel, il y a une phrase pour cela — rubber duck debugging :

Le nom fait référence à une histoire dans le livre The Pragmatic Programmer dans laquelle un programmeur transportait un canard en caoutchouc et déboguait son code en se forçant à l'expliquer, ligne par ligne, au canard.

Vous voyez, en écrivant un e-mail ou en parlant à une autre personne, vous êtes forcé d'expliquer tout le contexte de manière logique afin que l'autre personne comprenne ce qui se passe.

Pour expliquer le problème de cette manière, vous-même devez être capable de le penser et de l'ordonner logiquement. Le simple fait d'essayer de préparer ce contexte pour quelqu'un d'autre peut vous amener à penser au problème sous un angle différent, et souvent vous trouverez la solution vous-même.

Alors, en relation avec l'utilisation d'un minuteur d'essai, avant de demander de l'aide, essayez d'expliquer (ou de taper) le résumé du problème dans un e-mail que vous n'envoyez pas. Les chances sont que vous gagnerez un nouvel aperçu du problème sans avoir à interrompre une autre personne, et dans le pire des cas, vous aurez un excellent e-mail ou message de chat à leur envoyer.

(J'ai vu beaucoup de gens mettre des canards en caoutchouc réels sur leur bureau aussi !)

#6 Prenez des notes

Ce conseil peut sembler évident... mais prenez des notes !

Vous serez introduit à de nombreuses choses différentes lorsque vous rejoindrez une entreprise pour la première fois : bases de code, produits, personnes, logique métier, et il sera impossible de tout retenir. Écrivez ces choses.

Lorsque j'ai commencé mon premier emploi, mon patron m'a dit qu'il n'avait aucun problème à m'expliquer quoi que ce soit, mais qu'il ne voulait pas avoir à le faire deux fois. J'ai compris alors, mais maintenant huit ans plus tard, je comprends vraiment — il s'agit de respecter vos coéquipiers et leur temps.

S'il m'explique quelque chose et que je l'oublie, nous avons perdu le temps de tous les deux — et je devrai lui demander à nouveau. Sur sa recommandation, j'ai même commencé à mettre des notes autocollantes physiques sur mon moniteur de choses que je voulais voir souvent et me souvenir. Des choses comme :

  • ESSAYEZ PENDANT 30 MINUTES
  • VÉRIFIEZ QUE LA CONSTRUCTION RÉUSSIT AVANT DE DEMANDER UNE REVUE DE PR
  • ASSUREZ-VOUS D'AVOIR LE DERNIER CODE

#7 Luttez contre le syndrome de l'imposteur quotidiennement

Si vous ne savez pas ce qu'est le syndrome de l'imposteur, cela ressemble à ceci dans votre tête :

Je ne suis pas à ma place. Je suis un imposteur. Tout le monde comprend cela sauf moi.

C'est un état d'esprit que vous devez combattre quotidiennement. Il y aura des moments frustrants en tant que développeur, mais vous avez déjà fait face à la frustration et vous l'avez surmontée. Chaque développeur a ressenti cela, et cela passera aussi.

En réalité, le syndrome de l'imposteur ressemble plus à ceci :

Syndrome de l'imposteur Syndrome de l'imposteur

La différence clé entre un développeur "senior" et "junior"

Bien sûr, un développeur senior a plus de connaissances et d'expérience qu'un nouveau développeur, mais ce n'est pas ce qui les distingue. Un développeur senior a un système de résolution de problèmes.

Lorsque j'ai commencé dans le développement, je pensais qu'éventuellement je cesserais de faire des erreurs — que je cesserais de rencontrer des erreurs.

L'inverse s'est produit. Je fais encore un nombre incroyable d'erreurs chaque jour. Mauvaise syntaxe, mauvais fichier, mauvaise fonction.

Je n'ai pas cessé de faire des erreurs — je suis simplement devenu incroyablement rapide pour les corriger.

C'est une compétence qui se développe avec le temps, et elle nécessite une résolution de problèmes intentionnelle.

Voici quelques conseils sur la façon de construire ce système.

5 Conseils de débogage

#1 Ne maltraitez pas votre code !

L'une des choses que je faisais en tant que nouveau développeur — et que je vois de nombreux autres nouveaux développeurs faire lorsqu'ils rencontrent un problème — est qu'ils commencent à changer frénétiquement des choses dans leur code. Au lieu d'avoir un processus d'évaluation systématique, ils font simplement un tas de changements rapides en essayant de voir si cela corrige le problème.

C'est une très mauvaise habitude. Vous ne ferez que créer plus d'erreurs en faisant cela. Ce que vous devriez faire est :

#2 Lisez le message d'erreur !

Ce conseil peut sembler évident, mais lisez vraiment le message. Quelle est l'erreur ? Quel est le fichier où cette erreur se produit ? Quelle ligne cette erreur provient-elle ? Ce sont toutes des informations vitales.

Si vous résistez à simplement changer votre code rapidement, vous pouvez sauter directement à l'endroit exact où l'erreur se produit.

C'est ce que fait le développeur expérimenté. Lisez le message — allez directement au problème.

Faire cela vous fera économiser une quantité incroyable de temps et d'efforts mentaux gaspillés.

#3 Ne perdez pas de temps sur l'impossible ! (Ou du moins l'improbable)

Ne perdez pas de temps sur l'impossible ! Ne perdez pas de temps sur l'impossible !

C'est quelque chose que je vois souvent les nouveaux développeurs faire. Ils font face à une erreur dans leur code, ils trouvent quelque chose qu'ils pensent être le problème, et ils ne peuvent pas croire que ce n'est pas vrai. Par exemple :

"Je vois que le problème est à la ligne 14, où il vérifie si la variable is_admin est true, et elle n'est pas true — mais l'utilisateur est un admin !!!

Ils abordent ce problème en pensant, "Comment cela peut-il être !!!" au lieu de, "Comment cela peut-il être ?"

Il y a des moments où vous rencontrerez un bug de langage ou de framework de base, mais 99,9 % du temps, vous avez fait quelque chose de mal ou la situation n'est pas telle qu'elle apparaît.

Au lieu de passer du temps à vous émerveiller de l'impossible qui se déroule devant vos yeux, remettez en question vos hypothèses sur la situation. Quelque chose n'est pas tel qu'il semble. Être horrifié par l'impossible n'est qu'une perte de temps — commencez votre système de résolution de problèmes.

#4 "En cas de doute, imprimez plus." - Une personne sage

Je ne sais pas qui a dit cela à l'origine, mais c'est l'une des techniques de débogage les plus efficaces qui existent. Lorsque vous ne savez pas ce qui se passe, commencez à imprimer l'état de votre programme à des endroits où vous pensez que le problème se produit.

Qu'y a-t-il dans la variable user ? Quelle est la réponse de la requête HTTP ? Avons-nous pris la branche if ou else dans cette situation ? Avons-nous même appelé cette fonction ou sommes-nous même sur cette page ?

J'ai vu d'innombrables développeurs essayer de déboguer et de corriger un problème (et je l'ai fait moi-même de nombreuses fois aussi) alors qu'ils ne travaillaient même pas dans le bon fichier ! Un rapide print ou console.log vous montrera que vous regardez en fait le code réel qui est exécuté.

#5 Prenez-le une étape à la fois.

Une erreur courante que fait chaque nouveau développeur : ils font trop de choses à la fois.

Ils veulent écrire du code pendant 30 minutes, cliquer sur exécuter, et le voir fonctionner. Ce qu'ils découvrent, c'est qu'ils ont passé 30 minutes à écrire des bugs et des erreurs, et c'est maintenant un cauchemar à corriger.

Lorsque je vais créer une nouvelle page dans une application, la première chose que je fais est de mettre <p>hi</p> sur la page. Je veux m'assurer que tout mon code interne est configuré correctement et que je vois ce hi sur la page. Je le prends une. étape. à. la. fois.

Faites une chose à la fois. Faites imprimer "hi" sur la page. Ensuite, obtenez l'entrée de l'utilisateur. Ensuite, validez l'entrée. Ensuite, enregistrez l'entrée. Si vous faites de petits pas, vous savez exactement où corriger le problème lorsqu'il se produit.

Même huit ans plus tard dans une carrière de développement, je prends toujours les choses étape par étape. Je sais que je vais faire un tas d'erreurs, et je veux savoir immédiatement quand et où cela se produit.

Conclusion

Vous avez déjà parcouru un long chemin, mais il reste encore beaucoup devant vous.

Il y a beaucoup à apprendre, et de nombreuses compétences à développer, mais il y a aussi beaucoup de travail amusant et gratifiant à venir !

Gardez la tête haute, et n'oubliez pas de faire des pauses. Améliorez-vous de 1 % chaque jour, et dans un an, vous serez émerveillé par les résultats !

Si vous avez aimé cet article, j'écris des choses similaires sur mon blog ici.

Merci d'avoir lu !