Le codage, comme toute autre compétence, nécessite de la pratique, si vous ne l’utilisez pas tous les jours, vos coups de codage s’engourdiront. Et si vous vous attendez à être génial, alors il ne s’agit pas seulement de coder tous les jours au travail, cela ne suffit pas, vous devez faire du codage votre vie. Pensez aux athlètes olympiques, ils ne s’entraînent pas seulement quelques heures par jour, ils vivent pour leur sport, ils s’entraînent 8 à 10 heures par jour, et puis ils font des compétitions. Ils sont obsédés par l’idée de trouver leurs points faibles et de les perfectionner.
Si vous voulez être un « codeur olympique », alors vous devez voir la pratique de l’écriture du code de la même manière. Écrire différentes versions des exemples de Hello World ne vous donnera plus les résultats que vous recherchez très bientôt, alors que pouvez-vous faire alors ?
Surtout si vous commencez votre carrière, en essayant de sortir de l’enfer des didacticiels, cela peut sembler trop. Mais ce n’est pas difficile, il suffit de savoir où chercher des idées.
Reproduire les projets des autres
Vous devez vous entraîner au codage et, si vous n’avez pas encore d’idée de projet à développer, la meilleure solution est de copier celle d’un autre.
Attention, je ne vous dis pas de cloner leur repos et de regarder leur code. Et je ne vous dis pas d’examiner leur code et de voir comment ils font ce qu’ils font.
Non, ce que je dis, c’est de choisir un projet que vous aimez, peut-être même une bibliothèque dont vous avez entendu parler, et d’essayer de faire de l’ingénierie inverse sur leur logique interne. C’est encore mieux que d’écrire votre propre projet original, parce que vous avez déjà la documentation détaillée décrivant comment tout fonctionne. Il s’agit donc simplement de trouver comment l’écrire.
Par exemple, si vous êtes un développeur de Node.js, écrivez un framework de type express-like, et dupliquez l’API d’Express. Ou si vous êtes un développeur Go, écrivez un clone de Kingpin en lisant leur documentation.
Le but ici n’est pas de créer un projet pour que quelqu’un d’autre l’utilise, en fait, vous ne l’utiliserez même pas à l’avenir. Mais en vous attaquant à un projet réel, vous serez confronté à des problèmes difficiles à résoudre, dont certains sont même inattendus. Et c’est là que votre codage passera au niveau supérieur. Ces projets vous permettront de sortir de votre zone de confort et d’aller vers l’inconnu, qui est le lieu de la croissance.
Contribuer aux projets OpenSource
Se lancer dans l’Open Source peut sembler être la voie à suivre à première vue, mais cela peut aussi être difficile à faire une fois que l’on se rend compte qu’il n’y a pas de moyen prédéfini d’y entrer.
La façon la plus simple, et généralement celle que je recommande, est de trouver un des projets que vous utilisez depuis un certain temps et de chercher son repos. Si c’est un projet Open Source, il aura un repos public, très probablement sur Github. Ils disposent d’une fonction de recherche très utile, alors vous pouvez peut-être commencer par là.
Une fois que vous l’avez trouvé, consultez leur ReadMe principal, qui devrait être visible et affiché sur la page d’accueil. S’ils recherchent activement une aide quelconque, ils en feront la publicité d’une manière ou d’une autre et cela devrait vous donner les détails de ce que vous devez faire.
S’il n’est pas fait mention de votre contribution, voici quelques autres signes d’une prise en charge active à laquelle vous pouvez contribuer :
- La section « Questions » contient de nouvelles questions, et plusieurs personnes différentes y répondent activement (c’est-à-dire qu’il n’y a pas qu’une seule personne qui fait tout).
- Il y a des questions étiquetées comme « meilleur premier problème » ou « chercher de l’aide ». Ce sont des tâches courantes sur les dépôts qui montrent un grand niveau d’organisation. Elles montrent qu’il y a une communauté active qui travaille pour aider les gens à contribuer.
- Il y a de nombreuses demandes d’extraction ouvertes et en cours d’examen.
- Il existe une liste de « contributeurs », soit sur le fichier ReadMe, soit sur un fichier séparé à la racine du projet (généralement nommé « contributors.md »)
Si vous repérez l’un de ces signes, n’hésitez pas à prendre contact avec le propriétaire du repo, en lui demandant deux choses :
- Permission de contribuer. Il est vrai que le fait que vous vouliez contribuer est une bonne chose, et cela devrait les rendre heureux. Mais il est également important de faire preuve d’un niveau de respect approprié en reconnaissant que ce n’est pas votre projet et que vous êtes là pour aider.
- Quel est le protocole à suivre quand il s’agit de contribuer. Encore une fois, ce n’est pas votre projet, et les différents responsables du projet peuvent vouloir suivre des protocoles différents. Demandez-les, c’est un autre signe de respect envers le travail qu’ils font. Et cela augmentera les chances que vos contributions soient réellement prises en considération.
Si on vous donne les informations dont vous avez besoin et qu’il n’y a pas de problème en suspens sur lequel vous pensez pouvoir travailler, il se peut que vos premières contributions soient bonnes :
- Ajouter les détails manquants à la documentation ou corriger les fautes de frappe. Bien que cela ne semble pas beaucoup, cela vous aidera à comprendre le processus et le fonctionnement des demandes de retrait.
- L’ajout ou l’extension des tests unitaires. Cela peut être aussi simple que d’ajouter 3 à 5 lignes de code, mais vous aurez un aperçu de ce que c’est que de contribuer au projet par du code. Les tests unitaires peuvent vous donner un bon aperçu de la logique interne.
Travail sur des projets personnels
Enfin, le dernier moyen est de travailler sur ses propres projets personnels. La première chose que j’ai dite ici est que vous n’avez pas à travailler sur vos propres projets, vous pouvez travailler sur ceux de quelqu’un d’autre. Et si c’est vrai, le fait d’avoir un projet passionnel aide aussi, c’est certain.
Mener son propre projet peut vous aider à comprendre beaucoup de choses, et je ne parle pas seulement de codage :
Planification
Il y a des développeurs qui commencent un projet avec une idée très simple de ce qu’ils veulent créer et il y en a d’autres qui ont quelques semaines pour planifier le tout. Quoi qu’il en soit, la planification devra être impliquée dans la création de votre projet personnel si vous prévoyez d’avoir une version de sortie dans un avenir proche. Sinon, vous risquez de rencontrer des problèmes tels que
- « Scope-creep hell », où l’on ne cesse d’ajouter de nouvelles fonctionnalités parce qu’elles semblent pertinentes par rapport à la première version. Le résultat final le plus probable : vous vous ennuyez.
- Le syndrome du « développement à la va-vite ». Vous sautez d’une idée à l’autre, transformant votre création en un véritable Frankenstein, où aucune fonctionnalité n’a de sens en même temps.
- Les « 10% sans fin ». Ici, vous êtes en proie à la règle des 90-10, où les premiers 90 % du projet prennent 10 % du temps total, tandis que les derniers 10 % prennent près de 90 % du temps du projet. Cela n’est pas seulement dû à une mauvaise planification, mais aussi à une situation très décourageante, surtout si vous travaillez seul. Vous pouvez avoir l’impression d’avancer plus lentement que d’habitude, comme si vous ne faisiez aucun progrès. Et cela peut vous conduire à vous ennuyer et à abandonner le projet.
Je dirais que ce dernier point est probablement l’une des principales raisons pour lesquelles les développeurs abandonnent leurs projets personnels avant qu’ils ne soient terminés : le manque d’expérience en gestion de projet et donc, les règles inattendues du 90-10. Si vous en êtes conscient, vous pouvez planifier en conséquence, mais sinon, cela ne fera que ronger votre motivation.
Rétroaction
Rendre votre code public peut être effrayant, mais à moins que vous ne travailliez sur un projet privé, vous publierez votre code pour que d’autres personnes puissent le consulter.
Cela conduit les gens à penser qu’ils peuvent soit vous dire comment écrire un meilleur code, soit simplement souligner les problèmes qu’ils ont rencontrés. Les deux peuvent être des expériences très constructives ou déchirantes. C’est à vous de décider.
Savoir prendre en compte les réactions, même si elles prennent la forme d’une insulte à votre capacité, est une compétence très précieuse. Si vous êtes capable de comprendre qu’il y a quelque chose à gagner d’un commentaire négatif, alors vous avez fait des progrès.
Il en va de même pour les commentaires positifs, lorsque d’autres développeurs soulignent ce qu’ils ont aimé dans votre projet et que votre code peut vous dire ce que vous devez redoubler d’efforts.
Persévérance
Tout le monde peut commencer un projet parallèle, mais très peu peuvent le terminer. C’est un fait de notre vie de développeur, et quand vous en démarrez un, vous devez en être conscient.
Et par « terminer », j’entends sortir une version prête à la production, que tout le monde peut utiliser, avec la documentation appropriée et peut-être même un site web ou une forme de campagne de marketing autour de cette version.
Cela implique beaucoup plus que du simple codage, et c’est ce qui rend la tâche si difficile, mais aussi si gratifiante une fois que vous l’avez fait. Le pot d’or au bout de l’arc-en-ciel qu’est votre idée de projet est réel, il y a beaucoup d’expérience à acquérir en travaillant sur votre propre projet, mais c’est un travail difficile, qui demande des efforts et de la persévérance.
Si vous n’êtes pas prêt à vous investir, vous n’en tirerez qu’une partie des bénéfices.
Codage
Oui, le codage est aussi l’une des choses que vous améliorerez en terminant votre propre projet. Bien sûr, il faut coder pour le terminer et pendant le codage, vous pourrez tester de nouvelles choses, de nouvelles façons de faire les choses, et vous apprendrez beaucoup au cours de ce voyage.
Cependant, il ne s’agit pas que de code, vous apprendrez d’autres choses en cours de route, comme les meilleures pratiques de codage, les modèles architecturaux, vous trouverez de nouveaux outils et modules que vous ne connaissiez pas auparavant. La liste peut s’allonger, mais le but est de porter votre idée à 100%, vous exposera à de nombreuses activités et expériences qui, bien qu’elles soient liées au codage, n’impliquent pas l’écriture de code.
Il n’est pas facile de faire progresser vos compétences en matière de codage, cela prend du temps et du travail, mais tout le monde peut le faire, même vous. Arrêtez de lire les tutoriels, le temps de l’apprentissage est terminé, maintenant c’est le temps de l’action.
Avez-vous des idées à ajouter à la liste ? Que faites-vous pour améliorer vos compétences en matière de codage ?
