La différence entre un bon et un mauvais développeur ?

octobre 10, 2019
developpeur web freelance maroc
Pour pousser un peu plus loin l’analogie avec le sketch des Inconnus, on peut répondre ainsi: “Y’en a pas. Le bon développeur, il voit un bug, il le fix. Le mauvais développeur, il voit un bug, il le fix

Mais toute la différence réside dans la manière dont nous allons résoudre cette erreur. Voici quelques exemples tirés de mon expérience, mais aussi de mon environnement.

Je suis un bon développeur avec expertise de plus de 10 ans dans le domaine

CONTACTEZ MOI

Vous ne corrigez pas un bogue par essais et erreurs. La technique « Je change un morceau de code, je teste. Si ça marche, tant mieux, si ça ne marche pas… je change un morceau de code, je le teste à nouveau. » C’est contre-productif. Lisez la documentation, revenez au morceau de code, apprenez à vous connecter et à lire les messages d’erreur.

 

Nous connaissons la base de code. Si vous devez travailler sur un morceau de code inconnu et que vous ne le comprenez pas, demandez une explication pour éviter les abus.
Nous planifions les tâches en équipe. Plutôt que de piocher bêtement dans une liste de choses à faire, les réunions et les méthodologies agiles permettent de discuter en amont des meilleures approches possibles pour un problème donné. De cette façon, nous savons rapidement si un collègue a déjà une piste ou si quelqu’un d’autre a déjà travaillé sur un problème similaire. Dans tous les cas, sans une idée claire du travail à faire, on ne se lance jamais tête baissée dans la production de code.

 

L’encadrement technique est une partie essentielle de l’activité. Nous nous inscrivons à la newsletter Github Explore, consultons les bibliothèques tendances et faisons tout notre possible pour éviter de tomber dans le pire piège du développement : la lenteur. J’ai eu le malheur de me laisser longtemps emporter par la chance d’être en contrat perpétuel et de produire un peu de code ici et là pendant longtemps sans essayer de comprendre ou de m’améliorer et la livraison était d’un niveau scandaleux.

 

Nous prenons le temps de maîtriser les bases. Des sites comme Roadmap permettent de comprendre rapidement les étapes nécessaires pour acquérir de nouvelles compétences en les hiérarchisant. Prenons le temps de les assimiler et laissons suffisamment de temps pour les expliquer simplement à un débutant.

 

Nous pensons au produit et donc à l’équipe. Si nous bloquons, nous le dirons. Si nous ne bloquons pas, nous demanderons si quelqu’un bloque. Nous communiquons sur les mises à jour des produits. Nous clarifions notre code soit en le documentant clairement, soit en créant un code concis avec une dénomination sensible.
Nous unifions les processus d’équipe et mettons en place un environnement de travail sain au plus vite : mêmes extensions dans l’IDE, même linter, mêmes templates pour les tickets et les pull requests, mêmes outils de gestion de projet.

 

Nous communiquons ouvertement sur les frictions internes. Si on sent qu’une rencontre ne nous est pas nécessaire, on en parle, on en discute. Si nous sommes plus efficaces le matin, nous prenons la responsabilité d’en tirer parti et l’équipe en bénéficiera. Quand on se sent mal, on le dit. La transparence sera toujours la meilleure attitude, surtout dans une petite équipe.
Nous demandons des commentaires. Pour l’UX et le design, nous pouvons demander au reste de l’entreprise. Pour la qualité du code, un développeur ne doit pas pouvoir valider sa propre pull request sans le consentement d’un autre développeur. Dans la mesure du possible, nous programmons le code par les pairs pour apprendre et discuter.

 

Quand on bloque, on s’arrête, on respire un instant. Lorsque frustré par un problème, j’avais tendance à trop me concentrer sur le morceau de code devant moi, plutôt que de regarder le problème dans son ensemble. C’est épuisant mentalement et conduit généralement à une avalanche de catastrophes. Alors respirez un grand coup, prenez l’air, buvez une tasse de thé avec vos collègues, quinze minutes pour vous détendre et vous déconnecter. Au pire, une bonne nuit de sommeil est toujours une bonne solution.

 

Pourquoi une liste aussi spéciale ? Peut-être qu’aucun de ces commentaires ne s’applique à vous. Peut-être que vous ferez sourire. Mais ils ont tous, sans exception, eu un impact sur ma carrière de développement jusqu’à ce que je sois capable de prendre du recul et de mettre mon ego de côté pour résoudre ces problèmes.