Le bon développeur, c’est un gars on lui file un objectif, y code !
Tout le monde peut devenir un bon développeur
Dans une entreprise, la différence entre un bon et un médiocre développeur n’est pas à mon sens une affaire de neurones. Une brute en algorithmie peut finalement se relever être un développeur tout ce qu’il y a de plus mauvais pour une entreprise.
C’est plutôt dans l’attitude que l’on reconnaît les bons développeurs.
Apprenez à maîtriser plusieurs langages
Une personne parlant déjà couramment Français, Anglais et Allemand aura plus de facilité à apprendre le Néerlandais, qu’une personne ne parlant que le Français. Avec les langages de programmation, c’est pareil, plus vous en maîtrisez, plus il est facile d’en apprendre de nouveaux.
Je vous conseille donc de sauter sur l’occasion si on vous propose de participer à un projet utilisant un langage que vous ne connaissez pas encore. Si l’occasion ne se présente pas, provoquez-la en apprenant par vous même un langage à la mode.
L’idéal pour un développeur est de connaître au moins 1 ou 2 langages dans chacune des catégories suivantes:
- Langages bas niveau: C, assembleur, …
- Langages Orienté Objets; Java, C#, Eiffel, …
- Langages de Script: Python, JavaScript, Groovy, …
- Langages Fonctionnel: Ruby, Erlang, Caml, …
Le fait de connaître plusieurs langages vous permettra de vous sentir à l’aise avec tout type de code, de connaître les forces et les faiblesses de chaque langage pour en tirer la quintessence.
Le bon développeur sait donc qu’on ne programme pas de la même façon en Java et en C.
Soyez Perfectionniste
Je connais trop de gens qui se satisfont d’une interface graphique médiocre ou d’une fonction à moitié développée. Je répète souvent à l’envi que lorsqu’on développe une fonctionnalité, écrire le code qui fonctionne ne représente même pas la moitie du travail.
Prenez l’exemple d’une épreuve de philosophie lors du bac, il y a une différence entre rendre un brouillon et rendre une copie propre et relue (OK, ça ne vous empechera pas de vous prendre un 4/20, mais ça c’est une autre affaire).
A titre d’exemple, voici les étapes minimum que je m’essaye de m’imposer lorsque j’écris une nouvelle fonctionnalité:
- Casser la faisabilité, obtenir un premier code qui marche dans le cas nominal, en écrivant des tests unitaires si besoin.
- Pour chaque instruction, relire le code et gerer tous les cas d’erreurs qui pourraient se presenter
- Refactoriser et si besoin optimiser le code si besoin
- Mettre au propre:
– Enlever les bouts de code commentés qui ne servent plus à rien.
– Revoir le nommage des variables et des noms de méthodes
– Enlever les warnings de compilation si besoin
– Commenter les bouts de code qui ne sont pas triviaux à comprendre - Committer le code sur l’outil de gestion de sources (CVS, SubVersion, …)
Inutile d’etre perfectionniste quand ce n’est pas necessaire, sur un prototype jetable par exemple.
En revanche, ne faites pas l’erreur classique d’abaisser votre niveau d’attente envers vous-même parce que le projet est en retard. C’est justement quand on est pressé que le premier jet est bourré de fautes !