Feed on
Posts
Comments
Article en preparation:

surprise...

(x%)

Hier soir, alors que je discutais avec un collegue trader, le sujet s’invita dans la conversation. Les traders avec qui je travaille m’ont en haute estime, ce qui est un contraste assez saisissant avec comment ils considerent les autres developpeurs. Ils ont confiances en mes capacites de developpeur, mais au fond, qu’est-ce qui fait qu’on est un bon ou un mauvais programmeur?

Sachant le sujet plutot prone a argumentation de tout bord, je suis alle voir sur le net ce que les autres en disait. J’ai rapidement trouve tout et n’importe quoi, genre maitrise de la technologie/langage, passion de programmer ou fort en maths… puis, apres avoir bien rigole avec des trucs genre “sait ecrire en notation hongroise” ou encore “utilise agile”… il etait evident que chacun a sa propre definition de la chose.

Pour moi, faut pas chercher midi a 14h: Un bon programmeur, c’est “quelqu’un capable d’ajouter de la valeur au client de son application de facon rapide et continue grace a la programmation” et ca couvre globalement tout ce que j’ai pu voir de bon et de mauvais dans mes nombreuses annees de developpement.

Un programmeur est juge sur ses resultats, pas ses outils:

De la meme facon qu’il ne nous viendrait pas a l’idee de definir la qualite d’un peintre en fonction de sa capacite a melanger les couleurs ou la qualite de ses pinceaux a la place du resultat final, il en va de meme pour la programmation. Le truc important a comprendre est que la programmation n’est pas une fin en elle meme, mais plutot un moyen d’atteindre quelque chose d’autre (ce que beaucoup de junior et parfois meme seniors programmeurs perdent de vue facilement au benefice de challenges techniques et intellectuels qui n’ont pas besoin d’etre).

On differencie ainsi quelqu’un qui passera 2 jours a developper un lecteur de page web pour en extraire 10 valeurs clefs meme si le CSS change d’un autre qui dit, “tu entres ces 10 valeurs a la main, ca change qu’une fois tous les 6 mois, on en reparle dans 6 mois si ca marche pas”. Tout n’a pas besoin d’etre automatise via un programme. A la fin, seul le resultat compte, si votre programme est bourre de bugs c’est que vous avez mal fait votre boulot, ceux qui font bien leur boulot sont des bons programmeurs.

Un mauvais programmeur fait des trucs que seules des personnes intelligentes peuvent comprendre:

Dans mon travail de tous les jours, il y a un truc imparable qui me permet de determiner rapidement avec une grande exactitude si un programmeur est bon ou pas, c’est sa capacite a simplifier les problemes qu’on lui presente. N’importe quel programmeur peut compliquer un programme a chaque nouvelle requete, ca demande un vrai talent et savoir-faire de pouvoir simplifier le code au fur et a mesure des requetes.

Un mauvais programmeur se plante dans ses choix de priorites:

Au fil des annees, j’en suis venu a avoir mes propres “regles d’or” que j’utilise assez frequemment lorsque je forme des jeunes (et moins jeunes) programmeurs pour leur inculquer comment apprehender les problemes lies au developpement d’application.

Par exemple, lorsque je design un programme, je me penche surtout sur le role de chaque partie du programme. Un peu comme une palette de couleur, si vous voulez qu’elle soit efficace quel que soit la couleur demande, il vaut mieux ne pas tout melanger tout de suite. Du coup, distinguer le role de chaque partie du programme est vital pour etre reactif a chaque requete qui vient (ca c’est pour l’aspect continue de la valeur d’un programmeur). Savoir clarifier les responsabilites est une competence essentielle. Sans cela, vous ne pourrez pas reussir de facon repetee sur le meme projet (ca devient trop rapidement plus possible a maintenir).

Un mauvais programmeur cherche la perfection:

Tout est histoire de compromis, faut savoir ou mettre ses effort ou vous n’allez faire que re-ecrire votre programme constamment sans produire de valeur au client. Souvent (chez les jeunes surtout), on a du mal a s’arreter a juste ce qui est demande, genre: “et si l’utilisateur a besoin de ci ou ca?”. J’adore ce genre de questions car elles sont simples a repondre: si le design le permet, on fait rien, on saura quoi faire si on nous le demande. Si le design le permet pas, on a un mauvais design et on doit le retravailler ou savoir qu’on a une limitation en dure (pas bon). Du coup ca evite que les personnes fassent quelque chose qui n’est pas utile immediatement tout en ne fermant pas la porte aux futures requetes. Ca marche a tous les coups et les questions sont les bienvenues car elles testent le design avant que l’utilisateur ne le fasse et c’est bien plus rapide dans la tete que de compiler du code.

Un mauvais programmeur n’a pas de recule vie a vie de son code:

Le design justement est comme vos fondations dans le batiment. Si y’en a pas, vous etes mal barre pour toute demande de modification de la structure ou renovation de l’electricite. Ne pas avoir de design (je parle pas d’UML de class mais d’une vue globale de quelle partie du programme fait quoi et communique avec quelle autre) c’est naviguer a la loupe et ecrire du legacy software des le premier jour.

Mon approche est de laisser les jeunes se faire les dents sur l’implementation. Car la plupart du temps je m’en moque. Si elle est mauvaise on la change et rien d’autre n’est affecte a part une perte de temps puisque le design (structure) reste correcte. Savoir ou placer ses efforts pour l’impact maximal est crucial pour savoir delivrer rapidement. Les mauvais programmeurs perdent un temps fou avec des details d’implementation (genre faut utiliser une liste ou un vecteur?).

Un mauvais programmeur suit aveuglement:

Ceux qui n’ont pas eu la chance d’experimenter eux meme ou de travailler avec des bons programmeurs tentent souvent de pallier leur manque de savoir en se raccrochant a des faux dieux (ou gourou dans notre jargon). Genre un mec a ecrit un livre ou cree un langage (meme si c’est pas les meme competences) alors faut faire tout ce qu’il recommande. J’ai rien contre digerer le savoir de livres, bien au contraire, mais qu’on me serve pas ca comme pain benit, il faut savoir garder assez de recul. Experimenter avec un nouveau projet est souvent une tres mauvaise idee sur la duree. [edit: par projet j’entends projet avec but commercial au travail, non pas prototype ou projet personnels, qui eux, sont sains]

Alors moi j’ecris qu’un blog, peut etre qu’il faudrait que j’ecrive aussi un livre un jour pour que mon savoir soit valide par mes peres (y’aurait tant de choses et d’anecdotes a raconter sur le sujet). Toujours est-il qu’a la fin, c’est celui qui sait simplifier et garder cette simplification sur la duree qui gagne la course.

Un mauvais programmeur n’est pas condamne a le rester…

8 Responses to “C’est quoi un bon programmeur?”

  1. on 20 Oct 2011 at 15:39 Whirly

    Quand on m’a posé la question je crois que ma réponse était plus courte : “un bon programmeur c’est quelqu’un qui en a quelque chose à foutre de ce qu’il fait”. Et je pense que c’est la base dont découle le reste.

  2. on 20 Oct 2011 at 16:03 Klaim

    Hop je remet ici mon commentaire de Twitter pour que tu puisses répondre :) :

    AGREED!

    Par contre cette phrase est ambigue : “Experimenter avec un nouveau projet est souvent une tres mauvaise idee sur la durée.”

    Est-ce que tu voulais dire “experimenter dans un nouveau projet au boulot” ou “experimenter “?

  3. on 20 Oct 2011 at 16:04 Klaim

    Hop la fin de ma phrase :

    Est-ce que tu voulais dire “experimenter dans un nouveau projet au boulot” ou “experimenter dans un projet prototype“?

  4. on 20 Oct 2011 at 16:04 Drealmer

    J’approuve la définition de Whirly, et je note que ça s’applique à beaucoup de corps de métier :)

  5. on 20 Oct 2011 at 17:50 Vbseb

    “Au fil des annees, j’en suis venur a avoir mes propres “regles d’or” que j’utilise assez frequenmment lorsque je forme des jeunes (et moins jeunes) programmeurs pour leur inculquer comment apprehender les problems lies au developement d’application.”
    En effet, y’en a que j’utilise toujours…

    “peut etre qu’il faudrait que j’ecrive aussi un livre un jour pour que mon savoir soit valide par mes peres (y’aurait tant de choses et d’anecdotes a racconter sur le sujet)” Il faut !

  6. on 20 Oct 2011 at 19:30 Jeremy Chatelaine

    @Whirly: je dirais que c’est celle de comment on devient un bon programmeur ou ce qu’il faut pour le devenir. J’en connais beaucoup qui etait pleins de bonnes intentions lorsqu’ils ont ecrit leur premier singleton :)

    @Klaim: tout a fait, je parle d’experimenter une technologie non prouvee pour un projet commercial. On y va en etape avec les nouvelle techno, pas de big bang. Le fait que je sois un late adopter pour ce genre de truc au boulot a sauver mon p’tit cul plus d’une fois (contrairement a pas mal d’autres mouhaha >:))

  7. on 17 Dec 2012 at 17:53 ceriz sur le gâteau

    salut
    en faite je suis nouvelle dans le domaine de la programmation je veux savoir comment pourrais je devenir une bonne programmeuse??? quel sont les étapes
    par lesquels je dois passer ?? j’ai vraiment envie d’apprendre a programmer et si il y a des sites dans lesquels je peux trouver des recommandations et surtout des exercice n’hésitez pas a me le donner je vous serai vraiment très reconnaissante (j’ai commencer a aprendre a programmer en langage C )merci d’avance

  8. on 06 Dec 2014 at 11:26 Nassim

    Bonjour Jeremy,

    Personnellement je pense que la différence entre un bon et un mauvais programmeur réside dans l’étape qui se situe avant le codage. pour moi un bon programmeur c’est celui qui commence par réfléchir au problème et le modélise sur papier avant de commencer à le coder alors que le mauvais, c’est celui qui se lance directement dans le code sans trop réfléchir.

Trackback URI | Comments RSS

Laissez un message