Hey, Salut. Je reviens avec un article qui n’est pas aussi technique que d’habitude. Je pensais partager avec le monde quelques astuces que j’ai appris en parcourant du développement de logiciels pendant quelques années. Quand j’ai commencé mon aventure, j’étais seul, devant mon vieux PC Packard Bell, dans ma chambre quelque part au Cameroun avec un vieux “Sams t’apprends le C en 21 jours” et une mauvaise connexion internet. Je n’avais aucun mentor, aucun compagnon, juste moi et mon désir d’être aussi intelligent et habile que Chloe O’brian (de 24h Chrono) et Shadow Walker (de Nikita). Comme vous l’avez peut-être deviné, je me suis égaré plusieurs fois, j’ai appris des choses complètement obsolètes et j’ai utilisé des outils de manière inappropriée. Heureusement, je n’ai pas abandonné et j’ai trouvé le bon chemin.
Je ne suis pas un développeur superstar, je n’ai pas encore tout vu dans ce domaine, j’apprends de nouvelles choses tout les jours, mais j’e pense quand même que ce que j’ai appris peut aider n’importe quel développeur, c’est la raison pour laquelle j’écris cet article. J’aurais aimé lire un article tel que celui ci quand je me lançais dans cette aventure. N’hésitez pas à partager, liker et vous abonner aux notifications. Vous pouvez me contacter et me suivre sur les réseaux sociaux pour en savoir plus.
Ce que j’aurais aimé savoir en tant que développeur junior
Avant de commencer, je vous demande de partager votre opinion sur ces conseils dans la section des commentaires. Ce sont mes principes et ils fonctionnent pour moi, mais je souhaite également savoir ce qui fonctionne pour vous. Dites moi si vous partagez mon avis ou pas. Et si vous êtes un développeur junior lisant ceci, faites moi savoir si cela vous aide 😊.
1- Le code des tutoriels doit être utilisé avec sagesse
Le plus souvent, les tutoriels que nous voyons en ligne contiennent du code uniquement à des fins de démonstration et ne doivent pas toujours être utilisés tels quels. Les personnes qui écrivent le code omettent le plus souvent certaines choses par souci de brièveté. Lorsque vous avez commencé à créer des logiciels, je peux parier ce que vous voulez que vous pensiez naïvement que suivre un tutoriel en ligne avec des extraits de code signifiait que le code pouvait être utilisé tel quel en environnement de production, pour cette fonctionnalité de votre projet.
Je m’explique. Par exemple; vous apprenez un nouveau langage de programmation et vous suivez un tutoriel vous expliquant comment utiliser un client HTTP pour appeler une API depuis votre application cliente. Ce tutoriel vous indique; les clients HTTP doit toujours être libéré “dispose()”. Vous le suivez, et la prochaine chose que vous faites est de plonger dans votre projet et de créer un nouveau client HTTP dans chaque méthode ou classe appelant une API, et de libérer le client HTTP après utilisation. Cela semble normal au début, mais une fois que vous avez plus d’expérience et que vous commencez à travailler sur des projets du monde réel (en environnement de production), vous remarquez que la bonne chose à faire est d’utiliser une fabrique de clients HTTP ou de réutiliser le même client pour la durée de vie de l’application selon ce que vous construisez. Pour plus d’informations sur la raison pour laquelle ce n’est pas la première chose à faire, vous pouvez lire cet article que j’ai écrit.
Pour éviter de tomber dans ce piège, vous devez parcourir et vous inspirer du code source de plusieurs logiciels utilisé en production, qui utilisent la fonctionnalité que vous souhaitez implémenter, même si vous avez suivi un tutoriel sur cette fonctionnalité. Vous pouvez également demander conseil à la personne qui a écrit ce tutoriel.
2- On s’attend à ce que tu demandes de l’aide si nécessaire. Tu ne seras ni jugé ni méprisé
Tu as commencé ce premier emploi ou stage en tant que développeur logiciel. Tu as passé des heures à maîtriser ton langage de programmation et ton Framework préféré. Tu veux montrer ce que tu vaux, mais bam! Les premier jours, on te confie une tâche que tu ne peux pas terminer ou même comprendre comment l’aborder. Tu passes des heures, voire des jours, à chercher et à essayer des choses tout seul. tu ne trouves pas de solution, mais tu ne veux pas demander de l’aide parce que tu penses que tu devrais le faire par toi-même, de peur d’être jugé comme incompétent, ou méprisé.
Arrête toi! et demande de l’aide. Il est préférable de demander de l’aide dès que tu réalises que tu es bloqué au lieu de perdre des heures à comprendre ce qu’un développeur senior pourrait te montrer en quelques secondes. On s’attend à ce tu vous poses des questions. En fait, beaucoup de questions. Par contre, prends des notes. Tes collègues ne doivent pas se répéter trop souvent et sois assez intelligent pour assimiler rapidement. N’oublie pas que le développement de logiciels est un travail d’équipe.
3- Rejoint une communauté le plus tôt possible
Imagine que tu te lances dans quelque chose qui nécessite de la persévérance et du travail acharné, serait-il mieux de le faire tout seul ? Ou avec des camarades qui partagent ta passion, dans une communauté où vous pouvez vous entraider, partager des astuces, des idées et des opportunités ? Je préfère ce dernier. De toute évidence, être dans une communauté en ligne ou locale peut être un catalyseur pour ta croissance. Il existe plusieurs communautés sur internet ou même des communautés locales. plus tôt dans ma carrière, j’étais un membre actif de ma communauté locale à (Silicon Mountain) Cameroun et cela m’a beaucoup aidé. Surtout quand il s’agissait de motivation. Si tu as un framework ou un langage de programmation que tu aimes ou que vous aimerais apprendre, fait une recherche Google des groupes d’utilisateurs autour de toi. Tu trouveras plusieurs groupes de meetup, voire des groupes Facebook, des serveurs slack ou discord avec des personnes qui t’accueilleront. Au fait, si tu es au Cameroun et que tu aime du dotnet, tu peux me contacter ou rejoindre notre groupe meetup 😉.
4- La clé pour comprendre le code d’un projet mal documentée est de lire d’abord les tests unitaires
C’est quelque chose que j’ai appris à la dure. Au fait, partages-tu mon avis ici ? cela te semble très évident ? ou tu as une autre méthode? À l’époque où j’avais suffisamment de temps libre pour jouer avec le code sur GitHub et explorer des Frameworks et des exemples de code, j’avais du mal à parcourir tout le code du projet, puis à relier les points. Lorsque tu ne sais pas quelle portion de code fait quoi, vas simplement dans les tests unitaires. Ils te montrent exactement ce que le code est censé faire, ainsi que le résultat attendu après l’exécution du code. Cette astuce fonctionne partout, à chaque fois, tous les jours, même le dimanche lol.
5- La qualité de ton travail est plus importante que le nombre d’heures passé au boulot
C’est mieux de produire un travail de qualité rapidement et de partir tôt, que de rester tard, le dernier mais d’avoir un rendement médiocre. Il y a cette culture qui consiste a prouver son dévouement en se présentant tôt et en partant tard. Bien que ce soit formidable, cela ne fonctionne que si on s’investis vraiment et que l’on fait suffisamment d’efforts dans la bonne direction pendant qu’on est au lieu de travail. Tu dois toujours te concentrer sur les performances plutôt que sur les heures que tu passes a travailled. Ceux que je respecte le plus sont les personnes productives qui font les choses à leur rythme et qui savent aussi quand utiliser le temps supplémentaire dont elles disposent pour être plus productives. Tous les endroits où j’ai travaillé ont toujours privilégié la productivité comme indicateur de performance, plutôt que le temps passé au travail. Je crois que les gestionnaires qui ne pensent pas de cette façon ont tout faux.
If you find this article useful, please follow me on Twitter, Github, Linkedin, or like my Facebook page to stay updated.Follow me on social media and stay updated
6- Les softskills comptent énormément
Se concentrer uniquement sur les compétences techniques ne te mènera pas loin. Je l’ai appris à la dure. Au début de mon parcours, je pensais que l’amélioration de mes compétences techniques était la chose la plus importante, la seule qui comptait, et tout le reste était loin derrière en priorité. Si tu penses cela aussi, tu es sur la mauvaise voie.
Voici quelques compétences non techniques que tu dois ajouter à ton sac à dos pour continuer ton aventure en douceur.
- Comprendre les exigences fait partie du processus de développement, et vous devez prendre cela au sérieux. Ne vous précipitez pas dans la mise en œuvre simplement parce que c’est la partie la plus excitante. Prenez le temps de noter ce qu’on vous demande de faire, posez des questions et ne vous arrêtez pas tant que vous n’êtes pas sûr d’avoir compris. Le pire serait de mettre les bons efforts dans la mauvaise direction, et vous devriez éviter cela.
- La conscience de soi est inestimable. Soyez conscient de vos limites, de vos forces et de vos faiblesses. Lorsque vous en êtes conscient, vous pouvez rechercher des conseils et un mentorat appropriés. N’oubliez pas que nier que vous ne savez pas quelque chose est considéré comme une faiblesse. Personne ne sait tout, les meilleurs professionnels sont ceux qui disent avec confiance, je peux faire ceci et je ne peux pas faire cela.
- Essayez d’être autodidacte. Vous aurez besoin d’apprendre constamment et savoir comment apprendre est un must. Tant de développeurs sont autodidactes, donc ce n’est peut-être pas un gros problème.
- L’intelligence émotionnelle est importante, surtout parce que le développement de logiciels est un jeu d’équipe. Imaginez que vous êtes un développeur senior travaillant avec un développeur junior qui se met constamment en colère et se dispute lorsqu’il est corrigé ou lorsque ses erreurs stupides sont signalées pour être améliorées. Ou imaginez un développeur senior qui n’admettra pas et ne corrigera pas ses erreurs lorsqu’elles sont signalées par un développeur junior parce qu’il n’est pas assez humble et objectif. Vous devez être émotionnellement intelligent pour faciliter la communication et la collaboration. J’ai rencontré des gens avec qui c’était un enfer de travailler avec eux. Ne soyez pas ce genre de personne.
7- Travailler en équipe est très différent de travailler seul sur votre projet parallèle
Si vous êtes comme moi, un loup solitaire qui a appris la plupart du temps tout seul, seul dans le noir la nuit sur son projet parallèle, Lorsque vous rejoignez plus tard une équipe, vous remarquerez qu’il y a des différences. N’oubliez pas que vous devez respecter les normes établies par l’équipe. Cela pourrait inclure;
- Respectez le style de codage, les règles, les conventions de nommage, etc.
- Vous ne pouvez pas commit n’importe quel fichier ou laisser des journaux de console ou des remarques pour vous-même dans votre code.
- Ne soumettez pas de pull request avec du code qui casserait les pipelines de build.
- Faites en sorte qu’il soit aussi facile que possible pour vos collègues de prendre votre code après votre absence.
- Facilitez le processus de revue de code.
- N’oubliez pas de fusionner ou de mettre à jour votre code avant de poursuivre votre processus d’implémentation.
8- La meilleure façon d’apprendre est de faire
Voulez-vous apprendre java ? Construisez quelque chose avec Java. Voulez-vous apprendre Flutter ? Créez une application avec. Voulez-vous apprendre Angular, React Vue, etc ? Créez une application Web avec. Peu importe ce que vous construisez, faites-le. Le processus de vous demander comment implémenter une fonctionnalité vous fera apprendre plus que quelqu’un qui lit simplement des livres de programmation, suit des cours, essaie de mémoriser des mots-clés et pense qu’il est prêt à devenir développeur de logiciels.
J’ai un ami qui se plaignait de quelqu’un qu’il avait rencontré qui pouvait lui raconter l’histoire du langage de programmation Java, les mots-clés et les concepts de haut niveau, mais qui ne pouvait pas écrire de code Java fonctionnel. Si vous pensez que vous apprendrez le développement de logiciels comme vous appreniez l’histoire, la littérature ou la géographie à l’école, alors vous n’irez jamais loin. Apprenez plutôt en faisant.
9- Vos compétences ne valent rien tant que le monde ne les connaît pas
Vous êtes peut-être extrêmement habile, mais quelle valeur cela a-t-il si vous ne pouvez pas prouver facilement vos compétences au monde ? Lorsqu’il s’agit d’obtenir un emploi, la personne qui vous embauche doit être en mesure d’évaluer rapidement vos compétences et de les comparer à vos pairs. Réussir les épreuves d’un entretien d’embauche ne suffit pas toujours pour cela. Le moyen idéal de prouver au monde vos compétences en génie logiciel est de ;
- Construire des logiciels utilisés par des personnes en production.
- Contribuer au code open source sur GitHub
- Créer du contenu ; tutoriels vidéos YouTube, blogs, rédaction technique, etc.
10- Tenez-vous au courant des développements logiciels tous les jours
Rappelez-vous toujours ceci; Dans ce domaine, les choses peuvent devenir obsolètes en un clin d’œil. Vous devez vous tenir au courant de ce qui se passe. Une fois que vous avez commencé votre aventure dans le monde du développement de logiciels, vous ne devez jamais vous reposer et arrêter d’apprendre. S’il y a une chose qui devrait être constante dans votre vie, ce devrait être l’apprentissage. Si vous faites une pause de seulement 6 mois, vous reviendrez et serez obsolète ! Les choses vont extrêmement vite.
Voici des moyens que j’utilise pour rester constamment à jour et être à la pointe de tout ce qui se passe.
- Abonnez-vous aux notifications de publication de Github de vos frameworks et bibliothèques. Lisez ensuite les notes de publication lorsque vous en êtes averti.
- Suivez sur les réseaux sociaux, les ingénieurs qui construisent les outils que vous utilisez pour faire votre travail. De nouvelles annonces viendront très probablement d’eux.
- Suivez les blogueurs/YouTubeurs dans votre domaine (front end, mobile ou back end dev).
- Abonnez-vous aux newsletters hebdomadaires sur tout ce qui se passe dans votre domaine.
- Abonnez-vous aux notifications de pull request ou issues Github de vos frameworks et bibliothèques.
Conclusion
Le génie logiciel est le domaine d’expertise le plus passionnant. Ce que j’aime le plus, c’est la capacité de matérialiser vos pensées en quelque chose de réel. Les seules limites que vous avez sont celles que vous vous fixez. Cet article est celui que j’aurais aimé lire lorsque j’ai commencé à écrire du code. J’écris ceci dans le but d’avoir un impact positif sur tout développeur junior qui le liront. N’hésitez pas à partager, commenter et me contacter sur les réseaux sociaux 🙂
Follow me on social media and stay updated