Existe-t-il une méthode universelle ou une méthode pratique pour réussir ses débuts en tant que développeur de logiciels ?

Beaucoup de bouquins vont dans sens, mais chaque développeur finit par se faire son propre avis après quelques années d’expérience dans le domaine de l’ingénierie. En fait, il en vient à dresser une liste de quelques habitudes qui, d’après lui, permettent de grandir plus vite et de manière ciblée, et qu’il aurait aimé connaître dès ses premiers pas en tant développeur professionnel de logiciels. Voici une liste de règles recueillies dans la communauté.

Lire au moins deux livres par an sur le génie logiciel

Il y a un très grand nombre de livres de génie logiciel, et ce, dans un nombre très élevé de langages de programmation. Selon les personnes à l’origine de cette recommandation, chaque fois qu’ils ont donné de leur temps pour lire lentement et complètement un livre conseillé sur l’ingénierie logicielle, cela les a fait progresser. Il ne s’agit pas en effet de lire des bouquins pour se constituer un palmarès. Mais ils conseillent qu’en lisant, il faille prendre des notes, discuter des chapitres, griffonner des paragraphes, essayer des choses, et si possible revenir en arrière pour relire certaines choses.

Dans le choix des livres, il faut éviter les livres datés et surtout, vous devez rechercher des livres qui vont plus loin que ce que vous savez maintenant. Il peut s’agir d’un bouquin sur une technologie spécifique ou sur les pratiques du génie logiciel. Ils déconseillent aussi de lire des livres via des blogues, des vidéos, etc. Selon eux, ces canaux sont juste complémentaires aux livres. Ils sont des formats courts qui parcourent la surface, contrairement à un livre qui va en profondeur. D’après eux, les livres sont des connaissances approfondies et bien organisées. Enfin, il y a une dernière étape.

Elle consiste à rédiger des critiques sur un livre une fois que vous avez fini de le lire. Cela vous aide à développer votre sens critique, mais aussi vous permet de trouver d’autres alternatives à la résolution d’un problème, qui peuvent parfois se révéler meilleures que les conseils du livre. Notez bien, il ne faut pas être ambitieux, un seul livre tous les six mois suffit.

Apprendre le langage que vous utilisez au bureau en profondeur, vraiment en profondeur

Pour ceux qui recommandent cette approche, plusieurs développeurs n’ont qu’une maîtrise partielle des langages qu’ils prétendent connaître ou ne les connaissent qu’en surface, ce qui n’est pas un avantage. D’après eux, connaître en profondeur le langage que l’on utilise au travail est l’une des meilleures décisions qu’un ingénieur peut prendre afin de donner un élan décisif à sa carrière. En outre, ils recommandent aussi de ne pas hésiter à plonger dans les langages très populaires, notamment ceux qui reviennent tous les ans dans le top 3 des index.

Sur cette position qu’ils adoptent, ils estiment que, plus en connaissez et plus vous êtes à même de juger de leurs forces et de leurs faiblesses. De même, plus vous connaissez de langage et plus vous pouvez en choisir facilement de nouveaux et migrer plus facilement d’un langage à un autre.

S’associer plus souvent à d’autres développeurs

Le jumelage est-il aujourd’hui démodé ? Ceux-ci pensent que c’est le cas. Selon ces derniers, le jumelage contribue pourtant à donner naissance à de grands programmeurs. D’après eux, c’est cette approche qui donne lieu aux plus grands sauts professionnels, ajoutant que ces sauts se révèlent parfois plus significatifs que la lecture de n’importe quel livre. Ainsi, quand vous exposez vos idées sur un problème ou lorsque vous exposez votre code, requérez des commentaires, etc., vous apprenez beaucoup et vous devenez beaucoup plus performant avec le temps.

Écrire des tests unitaires et les exécuter en CI

Cette quatrième approche recommande d’écrire des tests unitaires et de les exécuter en CI (continuous integration – intégration continue). D’après ceux-ci, les tests unitaires permettent de sauver votre équipe d’ingénieurs et évitent que vous introduisiez dans votre code des erreurs graves, qui pourraient coûter cher à votre organisation. Ils permettraient également de se préparer à des changements majeurs à l’avenir.

S’habituer au refactoring et maîtriser ses outils

Le refactoring ou le réusinage de code est une technique disciplinée de restructuration d’un code existant, qui consiste à modifier sa structure interne sans changer son comportement externe. Le but est de faire une série de petites transformations qui préservent le comportement. Chaque transformation (refactoring) fait peu de choses, mais une séquence de ces transformations peut produire une restructuration importante. Comme chaque refactoring est petit, il est moins probable qu’il se produise des erreurs. Le système continue à fonctionner après chaque remaniement.

Cela réduit les risques qu’un système soit gravement endommagé pendant la restructuration. Selon cette recommandation, s’habituer au refactoring vous aide à devenir un expert dans la réduction de la taille du code, dans l’amélioration des performances d’un système, y compris sa vitesse… Cela permet également de savoir extraire une méthode d’un code, renommer une variable, passer à une constante… Enfin, maîtriser les outils du refactoring consiste à avoir une parfaite connaissance de ses EDI et les extensions servant au refactoring que vous avez ajouté à ces derniers.

Chercher à avoir beaucoup d’expérience

L’on estime qu’une bonne ingénierie logicielle est le résultat de beaucoup d’expériences, vous devez donc en obtenir assez. La plupart des ingénieurs ont tendance à se laisser influencer par les séniors, car ces derniers ont l’air de tout savoir ou d’avoir réponse à tout. Selon cette recommandation, l’on peut remédier à cela en étudiant les profondeurs de plusieurs langages, en travaillant avec les autres ingénieurs, en recherchant des opportunités de travailler sur différents piles, domaines et projets stimulants. Il ne faut pas non plus avoir peur de changer d’équipe à mi-chemin d’un projet.

En outre, ils recommandent aussi de se porter volontaire pour travailler sur de nouveaux projets et essayer de nouvelles technologies.

Enseigner ce que vous apprenez

Cette recommandation suit le dicton qui dit que : « la meilleure façon d’apprendre une chose est de l’enseigner ». L’approche consiste à parler de ce que vous apprenez ou ce sur quoi vous travaillez, en public devant d’autres ingénieurs et développeurs. La prise de parole en public vous oblige à correctement vous préparer, ce qui vous amène à étudier en profondeur les rouages de votre sujet de présentation. Cette approche est également connue sous le nom de “Learn in public”, et fonctionnerait très bien. Cela vous transforme en bon enseignant et mentor.

Et vous ?

 Selon vous, quels sont les conseils pour débuter en tant que développeur de logiciels ?