Article original : How to survive and thrive in your first junior developer job
Par Khalil Stemmler
Décrocher votre premier emploi de développeur junior est une réalisation formidable. Vous avez travaillé très dur pour acquérir les compétences nécessaires pour gagner votre vie et maintenant vous êtes prêt à prouver votre valeur dans votre nouveau travail.
Vous êtes définitivement excité. Et vous devriez l'être. Être développeur, c'est génial. Mais avec cette excitation, il est aussi normal de se sentir un peu nerveux. Ma première semaine en tant que développeur a été assez mouvementée. Le premier jour, on m'a donné une requête SQL de 200 lignes à essayer de comprendre... J'ai encore des flashbacks de cela. En général, vous allez avoir l'impression qu'il y a tellement de choses que vous ne savez pas ou ne comprenez pas, mais tout cela fait partie de l'expérience.
Afin de rendre votre transition dans le monde du travail en tant que développeur aussi fluide que possible et d'apporter vraiment de la valeur à votre équipe, voici mes recommandations professionnelles.
Comprendre vraiment Git et la gestion sémantique de version
Git est l'outil le plus populaire pour gérer le code source. Si vous avez terminé vos études ou un boot camp, vous êtes probablement au moins familier avec ce qu'est Git.
Une connaissance pratique de Git ne vous mènera que jusqu'à un certain point.
Lorsque vous commencez à travailler en équipe, vous serez introduit à des concepts et stratégies comme :
- Pull Requests (ou PRs comme on les appelle sur GitHub)
- Merge Requests (c'est ainsi que GitLab appelle les PRs)
- Fusion (Merging)
- Rebasage (Rebasing)
- Écrasement de commits (squashing commits) et
- Semver (gestion sémantique de version)
Ma première semaine en tant que développeur, je ne pouvais littéralement pas arrêter de transpirer. J'étais si nerveux à l'idée de supprimer toute l'entreprise par accident lorsque j'étais confronté à des options dans Git que je ne connaissais pas ou ne savais pas comment gérer.
Dans mon expérience, beaucoup d'équipes aiment utiliser Git Flow afin de gérer la façon dont le code est développé, versionné, étiqueté et publié dans les versions de production.
Pour les nouveaux développeurs, certaines des questions et confusions courantes que je vois sont :
- la différence entre fusion (merging) et rebasage (rebasing)
- quand devrais-je rebase ?
- comment fonctionnent les numéros de version ?
Si vous cherchez à comprendre chacun de ces termes, je pense que vous serez vraiment bien préparé pour savoir comment contribuer au sein d'une équipe et publier des fonctionnalités.
Venez préparé à vos réunions de standup
Si votre équipe pratique l'agile, on s'attendra à ce que vous rapportiez :
- ce que vous avez accompli la veille
- ce sur quoi vous travaillez aujourd'hui
- ce qui vous bloque
Cela peut être légèrement différent d'une entreprise à l'autre. Parfois, on ne vous demandera peut-être même pas de le faire. Mais quoi qu'il en soit, je pense qu'il est utile pour vous, en tant que développeur, de savoir sur quoi vous allez travailler le lendemain à l'avance. Parfois, il peut être facile de se retrouver piégé dans le mode de simplement répondre aux choses qui surviennent, et cela peut mener à l'épuisement professionnel et à la perte de concentration.
Essayez de venir préparé à vos réunions de standup en vous préparant à l'avance. Passez 3 minutes chaque matin avant le travail ou avant d'aller vous coucher pour exposer ce que vous avez accompli la veille, ce sur quoi vous allez travailler dans la journée, et ce qui vous bloque.
Non seulement vous impressionnerez votre responsable d'équipe en venant préparé, mais vous paraîtrez également beaucoup plus professionnel et crédible, même si vous êtes bloqué et n'êtes pas en mesure d'accomplir ce que vous vouliez faire ce jour-là.
Apprenez à demander de l'aide
Savoir comment et quand demander de l'aide en tant que nouveau développeur est si important. Ce qui pourrait vous prendre 5 heures à comprendre pourrait prendre à un autre développeur plus expérimenté 5 minutes (ou secondes).
Il est vraiment dans votre meilleur intérêt (et celui de l'entreprise) de demander de l'aide lorsque vous en avez besoin.
Cependant, ce n'est pas une bonne idée de demander de l'aide pour chaque défi qui se présente à vous sans avoir tenté de le résoudre vous-même d'abord.
Donc, avant de demander de l'aide pour quelque chose, assurez-vous de :
- essayer de comprendre par vous-même
- rechercher sur Google des réponses sur la façon de résoudre le problème (collez les logs ou les messages d'erreur)
Si rien ne fonctionne, alors il est définitivement temps de demander de l'aide. Voici comment demander de l'aide correctement :
Demander de l'aide en personne
Surveillez le langage corporel de l'autre personne. Si elle semble énervée, stressée ou dans sa bulle, il est peut-être préférable de la contacter d'abord et de lui demander si c'est un bon moment pour que vous veniez lui poser une question.
Méfiez-vous des personnes qui font le truc du "ol George Costanza : Faire semblant d'être occupé".
Demander de l'aide via messagerie instantanée
Lorsque vous pensez à contacter un autre développeur via IM pour obtenir de l'aide, il y a quelques façons d'augmenter vos chances d'obtenir une réponse positive et rapide.
Voici un mauvais exemple de la façon de demander de l'aide :
"Hey, peux-tu m'aider ? Je n'arrive pas à installer node.js sur mon ordinateur, ça ne marche pas."
Ce n'est pas une bonne façon de demander de l'aide. Voici comment cela pourrait être amélioré :
- Présentez-vous d'abord si vous n'avez jamais parlé à cette personne auparavant
- Assurez-vous d'inclure ce que vous avez essayé pour résoudre le problème. Donnez à l'autre personne le contexte du problème en fournissant les choses que ce n'est pas.
Voici une meilleure façon de demander de l'aide.
Bon exemple
"Hey John, je suis Khalil — le nouveau développeur ici. Ravi de te rencontrer. J'ai entendu dire que tu pourrais m'aider avec un problème particulier auquel je suis confronté. Basiquement, j'essaie d'installer Node.js sur mon ordinateur. J'ai essayé ce lien (collé le lien) et suivi les instructions, mais lorsque j'ai exécuté cette commande (insérer la commande), j'ai obtenu ce message d'erreur (insérer le message d'erreur). J'utilise l'un des nouveaux Macbooks. Une idée de ce qui se passe ?"
Il y a une raison pour laquelle cela est beaucoup mieux.
Cette façon de demander de l'aide fournit à l'autre personne tellement de contexte sur ce que vous avez probablement déjà essayé afin qu'elle puisse cibler plus rapidement ce que pourrait être le problème.
Lorsque vous n'incluez pas ces informations, vous mettez un fardeau sur l'autre personne pour qu'elle vous pose des questions pertinentes afin de trouver la racine du problème.
Imaginez combien de temps vous économisez en donnant à l'autre personne toutes les informations dès le départ. Il faut du temps pour poser des questions. Cette autre personne pourrait être occupée avec beaucoup d'autres choses à ce moment-là, alors pensez à cela comme suit :
Essayez d'aider l'autre personne à économiser autant de temps que possible en lui donnant autant d'informations sur le problème que vous pouvez dès le départ.
Lorsque vous recevez de l'aide
N'ayez pas d'ego. Je répète, n'ayez pas d'ego.
Lorsque quelqu'un prend le temps de vous aider, vous ne devriez pas chercher à faire savoir à l'autre personne que vous saviez comment le réparer depuis le début.
Lorsque votre problème est résolu, ne dites pas :
"oui, c'est ce que j'allais essayer ensuite"
Dites plutôt :
"Ça marche, merci !"
Faites attention à ne pas blâmer quelque chose qui ne fonctionne pas sur quelqu'un d'autre. Ne dites pas :
"L'équipe backend a tout gâché et c'est pour ça que ça ne marchait pas."
Dites plutôt :
"Je pense que cela pourrait avoir quelque chose à voir avec les changements récents sur le backend."
Assurez-vous toujours que lorsque vous avez enfin résolu votre problème, vous le faites savoir à l'autre personne. Elle pourrait encore réfléchir à des moyens de vous aider à résoudre votre problème alors que vous l'avez déjà résolu et que vous êtes passé à autre chose.
Assurez-vous de tester manuellement votre code
Je n'oublierai jamais ce moment dans mon premier emploi de développeur où j'ai négligé de tester mon code et j'ai simplement supposé qu'il fonctionnerait en production.
Ce code a atteint le client et s'est cassé dès qu'ils l'ont essayé.
Mon Dieu, j'ai eu droit à une sacrée engueulade ce jour-là...
Ne soyez pas comme moi, assurez-vous de tester manuellement que vos fonctionnalités fonctionnent ! Testez les chemins heureux et encore plus important, testez les chemins non heureux.
Essayez malicieusement de casser votre propre code. Si j'ai appris une chose en mettant du code en production, c'est que si vous avez écrit des bugs, vos utilisateurs les trouveront éventuellement.
Même si vous avez une équipe QA, visez à ce que QA ne trouve rien.
Apprenez à écrire du code testable et comment écrire des tests pour eux
Écrire du code testable n'est pas normalement quelque chose qui est enseigné à l'école, mais cela s'apprend facilement en appliquant les principes de conception SOLID.
De plus, demandez aux autres développeurs principaux comment écrire des tests pour quelque chose que vous avez écrit. Ils apprécieront que vous ayez demandé. Ils pourraient être en mesure de s'asseoir avec vous et de vous enseigner une chose ou deux. S'ils ne peuvent pas, ou si vous ne remarquez pas qu'il y a beaucoup de tests dans la base de code de toute façon, la meilleure chose à faire est de vous assurer que vous avez testé le code manuellement.
Apprenez constamment
Même si vous êtes un développeur front-end, apprenez le développement back-end et DevOps.
Si vous êtes un développeur back-end, recherchez l'IHM (interaction homme-machine) et l'UX.
Maîtrisez un outil que vous utilisez quotidiennement.
Dans cette carrière en tant que professionnel de la technologie, la quantité d'apprentissage et de croissance que vous faites déterminera finalement votre succès.
Conclusion
Nous venons de passer en revue certaines des meilleures façons de rendre votre premier emploi de développeur un succès, que vous soyez un développeur web junior, un développeur back-end junior, front-end ou autre. Si vous pratiquez certaines de ces choses, vous impressionnerez votre patron et comprendrez rapidement comment devenir productif en travaillant avec votre équipe.
Si vous cherchez toujours un emploi de développeur, vous devriez envisager de rejoindre Univjobs. Nous avons des centaines d'employeurs à la recherche d'étudiants et de jeunes diplômés en technologie. C'est vraiment une période formidable pour être développeur.
Publié à l'origine sur https://univjobs.ca le 9 mai 2019.