Article original : 11 do’s and don’ts for your first programming job

Par Eden Adler

Les premières fois sont excitantes mais peuvent aussi être accablantes. Lorsque j'ai commencé mon premier emploi en programmation, je savais qu'il y avait beaucoup de choses que je devais apprendre sur le plan technique. Mais ce que je n'avais pas réalisé, c'est qu'il y a beaucoup d'autres compétences nécessaires pour être un bon développeur, outre la programmation. Maîtriser chacune de ces compétences est essentiel pour accélérer votre croissance professionnelle. Plus vous les apprenez tôt, plus vous vous débarrasserez rapidement de ce titre de "junior".

À faire : Trouvez un mentor 💡

Trouvez quelqu'un (ou plusieurs personnes) en dehors de votre entreprise à qui vous pouvez poser des questions et demander des conseils. Les mentors au sein de votre entreprise sont formidables et importants aussi, mais je recommande de trouver au moins une personne en dehors du travail auprès de qui vous pouvez apprendre. Ils auront un avis impartial, et vous n'aurez pas à vous soucier des conflits d'intérêts, vous pourrez donc vous sentir vraiment à l'aise pour poser n'importe quelle question.

Comment trouver un mentor ? Cela pourrait faire l'objet d'un article entier. Mais la version rapide est : allez à des meetups, assistez à des événements technologiques et présentez-vous aux gens, suivez-les, et faites savoir aux gens que vous êtes nouveau dans le secteur et que vous cherchez un mentor. Vous seriez surpris de voir à quel point les inconnus sont prêts à aider.

À ne pas faire : Ayez peur de poser des questions ❓

Je pensais autrefois que poser des questions était un signe de faiblesse. Que cela révélerait mon manque d'expérience. Maintenant, je réalise que poser des questions fait partie intégrante du fait d'être programmeur. Laissez-moi expliquer.

Il existe des milliers de mots à la mode, et de nouveaux sont ajoutés chaque jour. Même les personnes qui travaillent dans ce secteur depuis des années apprennent constamment de nouvelles choses. Il est impossible de tout savoir absolument. Donc poser des questions est une partie essentielle de la programmation.

Être bon pour poser des questions est une compétence. Plus vous la développez tôt, plus vous gagnerez rapidement en confiance en tant que programmeur.

Voici un conseil pour savoir quand poser une question :

Rassemblez suffisamment de recherches pour communiquer efficacement : ce qui fonctionne, ce qui ne fonctionne pas, ce que vous avez essayé jusqu'à présent, et quelles informations vous manquent pour résoudre le problème.

Exemple de "mauvaise" question : "Je n'ai aucune idée de ce qui se passe ici, mais quelque chose ne fonctionne pas..."

Exemple de "bonne" question : "J'ai vérifié les logs et j'ai pu le reproduire localement. Il semble que le problème soit quelque part entre X et Y. Je pense que c'est soit un problème avec la version de l'API que nous utilisons, soit une valeur inattendue qui est envoyée. Pensez-vous qu'il y ait autre chose que je pourrais manquer ?"

À faire : Partagez vos succès 🎉

Pas tous les succès. Mais si vous êtes vraiment fier de quelque chose, partagez-le avec votre équipe. Que ce soit par email ou Slack, rédigez un résumé de ce que vous avez fait, comment vous avez résolu le problème, ce que vous avez appris et quelle valeur cela apporte.

Si vous avez un excellent manager, il devrait vous encourager à en parler lors d'une réunion de l'équipe de développement, ou peut-être même vous encourager à en parler lors d'un meetup ou même d'une conférence. Si ce n'est pas le cas, vous devriez prendre l'initiative et trouver des meetups pour présenter, organiser une réunion de l'équipe de développement pour en parler, ou même écrire un article de blog à ce sujet.

Cela peut sembler gênant de sonner votre propre cloche, mais croyez-moi, la visibilité est importante et vous aide à gagner du respect et de la reconnaissance au travail. Personne ne saura à quel point vous êtes formidable jusqu'à ce que vous le montriez.

À ne pas faire : Paniquez 😱

Les problèmes arriveront inévitablement. Que vous les ayez causés directement ou non. Ce n'est pas une question de si, mais de quand. Donc, lorsque le problème survient, informez les parties prenantes concernées (chef de produit, responsable technique, coéquipiers) dès que possible, puis discutez avec votre responsable technique ou votre manager de ce que vous prévoyez faire pour le résoudre. Plus vous êtes calme et posé, plus vous paraîtrez confiant. Cela arrive aux meilleurs d'entre nous, et la vie de personne n'est en jeu. La seule façon de garantir l'absence de bugs est de ne pas écrire de code... Cela fait partie du territoire.

À faire : Parlez lors des réunions 🗣️

Cela peut sembler intimidant au début d'être dans une réunion avec des coéquipiers qui sont tous beaucoup plus expérimentés que vous (croyez-moi, j'ai été là). Mais ne laissez pas cela vous affecter. Vous êtes un regard neuf, donc quelque chose qui vous semble étrange ou confus l'est probablement exactement : étrange et confus.

Si vous connaissez le sujet discuté à l'avance, essayez de faire des recherches sur Google et de faire quelques recherches préliminaires avant la réunion. Si ce n'est pas le cas et qu'ils discutent d'un sujet que vous ne connaissez pas, demandez une explication de haut niveau ou un peu de contexte. Faites cela au début de la réunion. Cela montrera que vous êtes engagé et que vous vous souciez. Si vous attendez jusqu'à la "période de questions" à la fin, cela ne reflétera pas bien sur vous que vous ayez assisté à une réunion entière confus et sans comprendre.

À ne pas faire : Essayez continuellement de vous prouver 💪

Lorsque vous commencez, ne mettez pas trop de pression sur vous-même pour faire des choses grandes, folles et impressionnantes qui vous feront remarquer par votre équipe. Vous gaspillerez beaucoup d'énergie et n'obtiendrez pas la réponse que vous espérez.

La vérité est que tout le monde est occupé et concentré sur ses propres tâches et responsabilités. Personne ne remarquera ou ne se souciera que vous avez terminé une fonctionnalité en un temps record ou que vous avez pris en charge 8 fonctionnalités supplémentaires en plus de votre charge de travail ou que QA n'a jamais trouvé de bug dans aucune de vos fonctionnalités. Donc ne vous épuisez pas. Cela n'en vaut pas la peine. Croyez-moi.

Ce qui aide à gagner le respect de vos coéquipiers, c'est d'être fiable, passionné, curieux et réfléchis. Montrez à votre équipe que vous êtes au top en : pensant de manière holistique à l'impact de votre fonctionnalité sur d'autres zones du produit, en soulevant des problèmes potentiels, en testant minutieusement votre fonctionnalité (et en demandant des idées de test aux autres), en abordant les cas limites potentiels avec le chef de produit, en posant des questions chaque fois que vous n'êtes pas sûr de quelque chose, etc.

Conseil bonus : Si vous voulez vraiment aller plus loin, choisissez de faire un mini-projet qui aide tout le monde dans le flux de travail de votre équipe. Soyez attentif et trouvez des points de douleur dans votre travail et créez un petit script shell pour l'automatiser. Ou si votre équipe utilise Slack, créez ou trouvez une intégration qui aidera. Assurez-vous qu'il y a vraiment un besoin et que ce serait une manière pratique de le résoudre. Demandez à un coéquipier ce qu'il en pense et s'il peut passer en revue le code avec vous. Vous obtiendrez des points doubles pour avoir pris l'initiative et créé quelque chose qui aide tout le monde dans leur travail quotidien.

À faire : Soyez extra communicatif ✅

Au début, j'avais l'état d'esprit de "baisser la tête et travailler". Si le designer apportait des modifications, si un coéquipier changeait l'API de manière inattendue, ou si vous rencontriez un gros bug que vous deviez régler en premier, je pensais que je devais l'accepter tel quel et continuer à travailler. Je pensais que dire quelque chose serait perçu comme une plainte ou des excuses. Non. Il est vraiment important de communiquer ces choses avec le chef de produit et le responsable technique.

C'est leur travail de prioriser les fonctionnalités et de déléguer les tâches selon les emplois du temps de chacun. Si des choses surviennent qui impactent le temps estimé alloué au projet, ils doivent le savoir dès que possible afin de pouvoir ajuster.

De plus, il est important pour eux de savoir pourquoi les choses prennent plus de temps. Sinon, ils pourraient supposer que c'est parce que vous êtes lent ou que vous ne performez pas. Ce n'est PAS le cas, et il est important qu'ils comprennent cela.

Vous ne recevrez pas de plaintes pour une surcommunication. Mais vous causerez des problèmes si vous sous-communiquez.

À ne pas faire : Cherchez la reconnaissance des autres 🙏

Vous venez d'avoir un moment "ah, ha !" avec la fonctionnalité sur laquelle vous travaillez. Vous vous dites à vous-même, "Wow, je n'arrive pas à croire que je viens de faire ça !" Vous vous êtes impressionné vous-même et cela devrait suffire. Vos coéquipiers ne se souviendront peut-être même pas de ce que cela faisait de déployer leur première fonctionnalité, d'implémenter une fonction récursive, ou de faire leur première migration de base de données. C'est excitant pour vous, et cela devrait l'être. Trouvez ces personnes au travail avec qui vous pouvez partager des choses et qui seront sincèrement heureuses pour vous.

À faire : Faites un effort pour apprendre les raccourcis clavier ⌨️

Faites attention à vos collègues. Vous remarquerez qu'ils touchent à peine leur souris ou leur trackpad. Ils peuvent changer d'applications, sauter autour de leur éditeur de texte, et rechercher et remplacer dans leur sommeil. Apprendre ces raccourcis simples vous rendra plus efficace dans votre travail et est une autre façon de "monter de niveau" en tant que développeur. Mais n'essayez pas de tous les apprendre en même temps. Il existe même quelques excellents outils de ligne de commande que vous pouvez télécharger. Demandez à vos coéquipiers quelques conseils et astuces.

À ne pas faire : Dites 'oui' à tout 🤝

Au début, je disais 'oui' à tout parce que je voulais être un joueur d'équipe et montrer que les gens pouvaient compter sur moi. Mais j'avais tort, ce n'est pas la bonne façon de faire. La seule chose qui en a résulté est que je me sentais submergé, surmené, sous-estimé, et cela m'a fait perdre le focus.

"Se concentrer, c'est dire non." — Steve Jobs

Il doit y avoir un équilibre. En tant que junior, vous aurez souvent les tâches que personne d'autre ne veut faire. C'est bien. Vous voulez mettre la main à toutes sortes de travail et peu importe à quel point la tâche est "ennuyeuse", vous apprendrez toujours. Mais cette tâche ne devrait pas vous submerger ou vous faire regretter d'avoir dit 'oui' lorsque une autre opportunité se présente à laquelle vous devez maintenant dire 'non'.

À faire : Impliquez-vous dans des choses en dehors du travail 🌟

Découvrez ce qui vous passionne, puis cherchez des opportunités pour faire du bénévolat, trouvez des meetups auxquels assister, impliquez-vous dans des groupes/organisations, travaillez sur des projets parallèles, écrivez des articles de blog, etc. Être développeur signifie faire partie d'une communauté et partager des choses avec cette communauté. Alors lancez-vous !

Pour être honnête

Il faudra un certain temps avant que vous ne vous sentiez à l'aise de faire ces 11 choses. Il est difficile de toutes les maîtriser. Franchement, je travaille encore sur quelques-unes d'entre elles moi-même 😅. Mais ce sont toutes des choses que j'ai apprises par expérience et que j'aurais aimé que quelqu'un me dise lorsque je commençais.

Essayez de travailler sur chacune de ces choses une à la fois. Les points clés à retenir ici sont :

  1. Défendez-vous
  2. Soyez confiant
  3. Posez des questions
  4. Entourez-vous de personnes encourageantes et bienveillantes

Merci d'avoir lu 😊 ! J'adorerais avoir vos retours, n'hésitez pas à me contacter sur Instagram et à consulter mon site web ✨