Envie de devenir développeur : un maître

lundi 23 mai 2005 :: perrick :: Développement :: 9 commentaires :: aucun trackback

Puisque Dave Hoover m'a demandé d'étayer mes propos précédents avec des exemples, je me vois "obligé" d'y répondre. Je commencerais donc par un maître qui a jalonné mes errements informatiques.

Celui qui me revient est un camarade de mes années de mathématiques à Londres. Alors que tout le monde était obligé d'effacer ses emails d'une session à l'autre, il avait réussi à les stocker sur disquette (et donc à les conserver entre chaque session). Nous sommes en 1995 et encore loin des 1Go de Gmail ! C'est très gentiment qu'il avait accepté de mettre son programme (un fichier .bat) sur ma disquette pour que je puisse faire de même : cette disquette m'a ensuite servie pendant presque deux ans sans faillir. Le bord inférieur droit s'était peu à peu noirci -- à force de manipulation. Plus tard ce fut un projet informatique qu'il accepta de relire (aujourd'hui je dirais une revue de code). J'avais enfin un truc qui tournait et je voyais bien que le sien prenait 10 fois moins de temps que le mien. En 1/4 d'heure, je divisais par 5 le temps d'exécution de mes quelques lignes en Mathematica : on avait relu mon code, pas pompé le sien. Malheureusement son nom ne figure pas sur mon t-shirt de promotion (puisque j'ai continué en maîtrise et qu'il s'est arrêté en license). Il -- son nom, pas sa patience ni ses sourires d'encouragement -- est aussi sorti de ma tête...

Une des raisons qui m'a fait quitter mon premier job, c'était justement ce manque de "maîtres" en développement logiciel. J'avais à mes côtés de très bons graphistes (je connais désormais leurs outils, à défaut de leur art) mais pas d'informaticien. La question n'est pas résolue au sein de No Parking. Heureusement des lectures et des rencontres plus ponctuelles viennent remettre en cause les (mauvaises) habitudes : les rendez-vous avec AFUP, PHPLille ou PHPLondon, les blogs de Joel on Software, de David Heinemeier, de Paul Graham (il y en a plein d'autres), les groupes de praticiens XP. Réciproquement c'est probablement pourquoi j'avance si doucement avec Linux : faudra peut-être que j'aille de temps en temps du côté du CLX...

Vos commentaires et/ou trackbacks

Le mardi 24 mai 2005 à 20:03, commentaire par JMF :: site :: #

Je partage tout à fait ta vision sur ce point. Ce qui est d'ailleurs amusant, c'est que tu joues régulièrement ce rôle pour moi. :)

Le mardi 24 mai 2005 à 21:30, commentaire par perrick :: site :: #

Oulala ce n'est pas ce que j'avais prévu !!! Il me reste tellement de choses à apprendre avant d'atteindre mes galons de "maestro".

Le mercredi 25 mai 2005 à 11:39, commentaire par pascaltje :: #

ce qui est rigolo c'est d'être le "maitre" d'un apprenti qui code... une encyclopédie sur star wars.

ça donne un trip Jedi et une apparition dans les remerciements.

Pour moi le maitre offre surtout des conseils globaux (architecture...) et des aides sur des points précis (code).

Le mercredi 25 mai 2005 à 12:23, commentaire par perrick :: site :: #

pascaltje > Dans ta phrase, je lis que le maître ne donne pas de conseils ni d'aide sur certains domaines. Domaines qui n'est ni l'architecture, ni le code. D'où ma question : quel(s) est(sont) ce(s) domaine(s) ?
Pour moi le maître peut aussi faire des remarques non-techniques (relation dans l'équipe de dev, avec le client ou l'utilisateur, etc.)

Le mercredi 25 mai 2005 à 15:01, commentaire par pascaltje :: #

mauvaise interprétation de mes propos. Le maitre à mon sens revele l'eleve, il lui permets de progresser par lui même, lui fait découvrir de nouvelles choses.

ex: va voir telle fonction, elle fait ce que tu cherches; va voir telle doc, tu pourras modéliser plus facilement ton projet...

et ça passe aussi par la relecture du code et des encouragements.

Le mercredi 25 mai 2005 à 21:15, commentaire par JMF :: site :: #

J'ai dis "régulièrement" pas "toujours". ;)

Moi je voyais plus ça comme des confrontations d'idées, de méthodes et de visions de notre métier.

Il faut d'ailleurs reconnaitre que ce n'est jamais sur des points techniques mais sur des réflexions d'ordre plus théorique.

Le vendredi 27 mai 2005 à 12:43, commentaire par perrick :: site :: #

Cette confrontation -- que j'apprécie aussi très régulièrement -- tient peut-être d'un autre motif d'apprentissage : la confrontation avec les pairs... Une piste pour un prochain billet !

Envie de devenir développeur : un maître

Vos commentaires et/ou trackbacks

Ajouter un commentaire