Apprenez à programmer en dix ans

Pourquoi être si pressé ?

Entrez dans n'importe quelle librairie et vous verrez " Apprendre Java en 7 jours" aligné à côté d'une immense collection d'ouvrages sur le même thème : "Apprenez Visual Basic/Windows/Internet... en quelques jours/heures". La recherche suivante lancée sur Amazon.com :

        pubdate: after 1992 and title: days and
        (title: learn or title: teach yourself)
      

Deux conclusions s'imposent : soit les gens sont très pressés d'apprendre l'informatique, soit cette discipline est incroyablement plus facile à apprendre que n'importe quelle autre. Aucun livre n'enseigne comment apprendre Beethoven, la physique quantique ou bien le dressage des chiens en quelque jours.

Analysons ce qu'un titre comme "Apprenez le Pascal en trois jours" peut vouloir dire :

• Apprendre : En trois jours, vous n'aurez pas le temps d'écrire quoi que ce soit de significatif, ni d'apprendre de vos succès et erreurs. Vous n'aurez pas non plus le temps de travailler avec un programmeur expérimenté et de comprendre les subtilités de cet environnement. Bref, vous n'aurez pas le temps d'apprendre grand chose. Un tel livre ne peut donc parler que d'une vague familiarité et non d'une véritable compréhension. Comme le dit Alexander Pope : "Il est dangereux de n'apprendre qu'un peu".
• Pascal : En trois jours, vous apprendrez peut-être la syntaxe du Pascal (à condition que vous connaissiez déjà un langage similaire), mais vous ne pourrez pas apprendre comment utiliser cette syntaxe. En supposant que vous savez programmer en Basic (par exemple), vous apprendrez à écrire des programmes dans le style "Basic" avec une syntaxe "Pascal". Vous n'apprendrez cependant pas dans quelles applications Pascal est bon (ou mauvais). Où est le problème ? Selon Alan Perlis, "un langage qui ne change pas votre façon de penser ne mérite pas d'être appris". Il est possible que vous appreniez un peu de Pascal (ou plus probablement Visual Basic ou JavaScript) pour "interfacer" avec un outil déjà existant afin de réaliser une certaine tâche. Dans ce cas, vous n'apprenez pas à programmer mais simplement à accomplir cette tâche.
• en trois jours : Malheureusement, ce n'est pas assez, comme vous le verrez dans la suite.

Apprenez à programmer en dix ans

Des chercheurs (Hayes, Bloom) ont mis en évidence qu'il faut environ dix ans pour devenir expert dans une multitude de domaines aussi variés que le jeu d'échecs, la composition musicale, la peinture, le piano, la natation, le tennis ou la recherche en neuropsychologie et en topologie. Il ne semble pas y avoir de raccourci : même Mozart, prodige à l'age de quatre ans, ne commença à produire des oeuvres de premier plan que treize ans plus tard. Dans un autre genre, les Beatles ont semblé apparaître sur scène du jour au lendemain en 1964 dans le Ed Sullivan show. Mais leurs véritables débuts datent de 1957 et leur première oeuvre majeure, Sgt. Peppers, est sortie en 1967. Pour Samuel Johnson, il en faut bien plus : "Dans quelque domaine que ce soit, l'excellence ne s'atteint qu'au prix du travail d'une vie entière; elle ne s'achète pas à moindre prix.". Et Chaucer d'ajouter : "La vie est si courte, le métier si long à apprendre."

Voici ma recette pour devenir un bon programmeur :

• Intéressez vous à la programmation et faites en parce que c'est amusant. Prenez suffisamment de plaisir pour pouvoir y consacrer dix ans.
• Rencontrez d'autres programmeurs, lisez leurs sources. C'est plus instructif que n'importe quel livre théorique ou cours.
• Programmez. La meilleur façon d'apprendre est "d' apprendre en faisant". Plus techniquement, "un individu n'atteint pas automatiquement, dans un domaine précis, le plus haut degré de réussite grâce à sa longue expérience, mais il peut augmenter ses performances au prix d'efforts délibérés et arriver à ce plus haut degré." (p. 366) et "l'apprentissage le plus efficace exige des tâches bien définies, avec un niveau de difficulté adapté à chaque individu, un feed-back instructif et la possibilité de répéter et de corriger ses erreurs." (p20-21) Le livre Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life est une référence intéressante sur ce point de vue.
• Si vous le voulez, passez quatre ans ou plus dans une école ou une université. Cela vous permettra d'accéder à des postes qui nécessitent une certaine qualification. Une telle position vous permettra d'accéder à une compréhension plus profonde du domaine. Cependant, si les études ne vous attirent pas, vous pouvez aussi bien acquérir professionellement une expérience similaire. Dans tous les cas, apprendre dans les livres ne sera pas suffisant. Comme le fait remarquer Eric Raymond, auteur de The New Hacker's Dictionary , "L'enseignement de l'informatique ne peut transformer quiconque en un programmeur expert, pas plus que l'étude des pinceaux et des pigments ne peut faire de quelqu'un un grand peintre". Un des meilleurs programmeurs que j'aie jamais employé n'avait que le bac pour seul diplôme. À ce jour, il est l'auteur de bon nombre d'excellents logiciels, possède son propre groupe de discussion et est sans aucun doute beaucoup plus riche que je ne le serai jamais.
• Travaillez sur des projets avec d'autres programmeurs. Soyez le meilleur programmeur sur certains projets, soyez le pire sur d'autres. Quand vous êtes le meilleur, vous pouvez tester vos capacités de chef de projet et être une source d'inspiration pour les autres membres du groupe. Quand vous êtes le pire, vous apprenez des meilleurs, ainsi de ce qu'ils n'aiment pas faire (car vous le faites à leur place).
• Reprenez le travail d'autres programmeurs. Efforcez vous de comprendre un programme écrit par quelqu'un d'autre. Voyez comme c'est difficile de comprendre et corriger quand les programmeurs originaux du projet ne sont pas là. Imaginez comment concevoir votre programme pour qu'il soit plus facile à maintenir par la suite.
• Apprenez au moins une demie douzaine de langages. Choisissez un langage qui supporte l'abstraction de classe (comme Java ou C++), un qui supporte l'abstraction fonctionnelle (comme Lisp ou ML), un qui supporte l'abstraction syntaxique (comme Lisp), un qui supporte les spécifications déclaratives (comme Prolog ou C++ Templates), un qui supporte les coroutines (comme Icon ou Scheme) et un qui supporte le parallélisme (comme Sisal).
• Rappelez vous que l'informatique est la science des ordinateurs. Sachez le temps qu'il faut à votre machine pour exécuter une instruction, lire un mot en cache L1 (avec et sans pénalité d'accès), lire ou rechercher une donnée sur le disque. (Réponses ici.)
• Soyez impliqué dans le processus de standardisation d'un langage. Cela peut être le comité ANSI C++, ou simplement décider si votre style local d'indentation comporte 2 ou 4 niveaux. Dans les deux cas, cela vous apprendra ce que les gens aiment dans un langage, à quel point ils aiment ce langage. Vous apprendrez même en partie pourquoi.
• Ayez le bon sens de vous dégager dès que possible de ce standard.

Fred Brooks, dans son essai No Silver Bullet ("Pas De Solution Miracle"), isole trois facteurs pour identifier de bons développeurs :

• Identifier systématiquement les meilleurs designers le plus tôt possible.
• Assigner un mentor au nouveau venu pour l'aider à mettre au point et gérer son plan de carrière.
• Permettre aux "jeunes loups" d'interagir. Cela les stimulera mutuellement.

Vous pouvez donc acheter ce livre sur Java, vous lui trouverez certainement une utilité. Mais ne rêvez pas, il ne changera pas votre vie, pas plus qu'il ne changera radicalement votre vision de la programmation en 24 heures, quelques jours ou même quelques mois.

Références

Bloom, Benjamin (ed.) Developing Talent in Young People , Ballantine, 1985.
Brooks, Fred, No Silver Bullets , IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.
Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.
Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life , Cambridge University Press, 1988.

Réponses

Notes

• Cet essai est aussi disponible :
  • en japonais (Yasushi Murakawa)
  • en chinois (Xiaogang Guo)
  • en espagnol (Carlos Rueda)
  • en allemand (Stefan Ram)
  • en anglais (Peter Norvig, version originale)
• T.Capey fait remarquer que la page du "Complete Problem Solver" sur Amazon fait maintenant référence à "Apprenez le bengalais en 21 jours" et "Apprenez la grammaire et le style en 24 heures" dans la rubrique "Customers who shopped for this item also shopped for these items" (ndtr : allez voir chez amazon pour voir de quoi il s'agit :). Je pense qu'une grande partie des personnes qui jettent un oeil à ce livre viennent de cette page.
• Gromerci à ceux (pour l'instant, y en a qu'une :) qui m'ont donné un coup de main pour la traduction : Camille Piat.

SEARCH:

Related searches:
eacute agrave egrave apprendre apprenez

gipoco.com is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.