4 leçons clés pour devenir un développeur brillant

Devenir un développeur brillant ne se résume pas juste à écrire du code qui « marche ». C’est une quête d’amélioration constante, où chaque obstacle doit se transformer en une opportunité d’apprendre. De l’art des tests unitaires à l’observation des meilleurs, en passant par une remise en question régulière, exceller demande de la rigueur, de la curiosité et une volonté à sortir de sa zone de confort et viser toujours plus haut.

Vous aussi, avez entamé votre carrière de développeur en faisant beaucoup « trop » de copier-coller ? Quand on se lance dans une nouvelle carrière de développeur, peu importe l’âge, cela peut être intimidant. Plusieurs facteurs entrent en ligne de compte et peuvent vous déstabiliser rapidement.

La difficulté prend sa source dans différents paramètres avec lesquels il convient de jongler pour ne pas se retrouver dernier de la classe :

• Les technologies sont complexes et pour couronner le tout, elles évoluent très vite. De quoi en décourager plus d’un.
• Se comparer aux autres, à ses paires, aux développeurs seniors qui ont réussi.
• Manquer de repères : dans le cas d’une reconversion par exemple.
• Si l’on est plus tout jeune, on peut craindre d’être jugé ou ignoré à cause des stéréotypes liés à l’âge.
• La pression de la réussite, face à des enjeux financiers ou personnels, la pression augmente.

Mais le tableau n’est pas si noir, car avec de la pratique, de la patience, un brin de curiosité, de la persévérance, de la flexibilité, de la motivation tout au long du chemin, rien ne devrait vous empêcher de devenir un jour un développeur brillant.

Deux yeux et une bouche.

Si nous n’avons que deux yeux et une seule bouche, c’est bien par ce que l’observation est souvent plus importante que de parler et qu’elle précède bien la parole et l’action. Savoir regarder, observer, fait partie des piliers de base pour tout apprentissage et progression dans n’importe quel domaine. Le premier conseil est d’observer les développeurs que vous considérez comme « supérieurs », « meilleurs » que vous, de bien analyser comment ils travaillent, agissent, se comportent, échangent.

Inspirez-vous des développeurs plus intelligents que vous.

Et ensuite c’est simple, copiez-les, imitez-les jusqu’à leur ressembler.

Leçon n°1 : on ne peut pas reconnaître ce qui est médiocre sans avoir expérimenté ce qui est excellent

C’est trivial, toutefois pour aiguiser son discernement et avoir un point de vue plus travaillé sur quelque chose, on va toujours passer par un point de comparaison. Si vous n’avez vécu que des expériences médiocres et qu’en plus vous avez intégré ces expériences comme étant normales, vous n’avez alors pas de référence de ce qui pourrait être meilleur.

C’est seulement partir du moment où vous allez faire l’expérience de quelque chose de « véritablement bon« , de haute qualité ou d’efficace, que vous allez ouvrir les yeux (encore un lien avec le sens de la vue) et vous rendre compte des lacunes, des situations ou comportements que vous aviez acceptés jusque-là.

Ce raisonnement s’applique à de nombreux domaines : travail, relations, technologie, vie quotidienne…

Si, en tant que développeur, vous avez l’habitude de travailler avec des outils mal conçus ou non adaptés réellement à ce que vous faites, vous ne saisirez leur inefficacité que lorsque vous utiliserez des solutions bien pensées et adaptées à vous et à vos projets.

Leçon n°2 : cartographier le faux pour trouver le vrai

Avoir ce déclic, prendre conscience que nous sommes finalement dans le faux car nous avons rencontré le vrai est une donnée essentielle pour progresser en tant que développeur informatique.

On appelle cela cartographier le faux pour trouver le vrai.

Autrement dit, il faut savoir se tromper et commettre des erreurs, pour enfin trouver la méthode de travail qui fonctionne, le bout de code qu’il vous fallait.

Cela tient en une qualité, qui sera notre deuxième conseil « Penser à se remettre en question régulièrement » pas « toujours » mais souvent.

Si rien n’est à changer, ne changez rien, si une marge de manœuvre est visible pour gagner en efficacité, alors foncez !

En ce sens l’expérience du « bon » devient un puissant levier pour identifier, refuser et ensuite changer ou améliorer ce qui est « mauvais » et qui vous maintient dans votre médiocrité.

Vous êtes à la recherche de développeurs offshore pour compléter votre équipe de développeurs internes ? Contactez Quentin et échangez avec lui sur vos attentes.

Leçon n°3 : vouloir être le premier de la classe

Est-ce que cela vous est déjà arrivé de dire à votre lead dev « Je n’ai pas le temps d’écrire des tests, je veux juste que les choses marchent » ? Je suis sûr que oui. Vous aviez sans doute raison, peut-être n’aviez-vous jamais écrit de tests de votre vie de développeur, cependant, l’art des tests recèle des vertus qui pourraient révolutionner votre travail.

Eh oui, rédiger des tests avant de coder vous fera consommer beaucoup plus de temps de développement mais cette habitude vous mènera à des sommets.

Celles et ceux qui rédigent des tests unitaires AVANT de se lancer dans le développement sont perçus tels des messies.

Il ne se contentent pas de « Ça marche » ou « Ça fonctionne sur ma machine »

Ils garantissent un code fiable et surtout qui fonctionne comme prévu. Lorsqu’ils livrent en production, ils ne génèrent pas de pannes critiques. Vous voyez de quoi je parle n’est-ce pas ?

Si le code doit être modifié par la suite, les tests forment un filet de sécurité, qui détectera si la modification a introduit un problème ou non.

Le développeur qui a pris le temps de rédiger des tests est un développeur qui a compris en profondeur ce que son code est censé faire, ce qu’il n’est pas censé faire et quelles sont ses limites.

Les obstacles majeurs qui arrivent sur le long terme, ceux qui naissent dans des petits problèmes mineurs de code et s’accumulent, sont évités grâce aux tests.

En plus d’un travail impeccable, ce développeur rigoureux sur les tests aura gagné la confiance et la crédibilité face à l’équipe et au client.

Travaillez à être le premier de la classe, ne faites pas les choses pour les faire ou juste pour qu’elles fonctionnent sur votre machine, mais pour qu’elles fonctionnent bien.

Pour terminer, notre quatrième conseil sera sous forme de méthodologie à appliquer dès aujourd’hui lors de vos revues de code.

Leçon n°4 : les revues de code des développeurs brillants

• Lancez le code sur votre machine, en local, et vérifiez que la fonctionnalité « fonctionne » bien, toujours avant d’examiner les détails du code. Si la fonctionnalité ne marche pas, il n’est pas pertinent de poursuivre l’analyse.

• Analysez le nouveau code ligne par ligne pour bien comprendre les changements apportés.

• Posez des questions à votre équipe pour clarifier les éléments qui ne sont pas compréhensibles immédiatement.

• Organisez des réunions pour examiner ensemble les points cruciaux et demandez à l’auteur du code de vous expliquer ce qu’il souhaitait faire précisément.

• Effectuez vos revues de code en début de journée, votre tête est encore fraîche, bien reposée, avant de vous plonger dans vos propres développements et afin de rester concentré sur un seul sujet à la fois.

Un développeur brillant est tout simplement une personne qui prend le temps de faire ce qu’elle fait, de faire une tâche après l’autre, de prendre soin de son code en profondeur, en rédigeant des tests unitaires et qui s’inspire et imite les personnes meilleures ou plus intelligentes que lui.

Terminons par cette citation :

« Si vous êtes la personne la plus intelligente de la pièce, alors c’est que vous êtes dans la mauvaise pièce. »

Confucius

Vous souhaitez connaître les tarifs pratiqués concernant la mise en place de développeurs offshore dans votre entreprise ? Découvrez notre grille tarifaire.

Référence : brianjenney.medium.com – 3 Lessons from the Smartest Developers I’ve Worked With