C’est la Code Week. Et si l’on apprenait à se tromper ?
Lancée en 2013 par la Commission européenne, la Code Week (Semaine européenne du code) se tient du 15 au 23 octobre dans 46 pays, dont la France. A cette occasion, enfants et adultes, enseignants et grand public se voient proposer des ateliers pour s’initier aux langages java ou python et à d’autres rudiments de la programmation.
Le codage informatique, c’est d’abord une compétence et un métier bien sûr, c’est parfois un loisir, mais c’est aussi un état d’esprit, lié au statut particulier du bug, ce dysfonctionnement qui fait planter l’ordinateur – en général juste au moment où il ne faut pas… Pendant ce temps (et c’est encore plus agaçant), les informaticiens restent placides, eux qui se sont heurtés à des centaines, des milliers de bugs. Et s’attendent sans angoisse à en rencontrer bientôt de nouveaux.
Or, cette routine du codeur a de vraies répercussions sur la manière d’appréhender l’erreur, considérée comme une étape normale, voire nécessaire pour avancer. Apprendre à coder, c’est apprendre à se tromper. Et ce n’est pas si courant.
« Erreurs » d’entrepreneurs
Que ce soit à coup de stylo rouge à l’école ou de regards apitoyés en société, la culture française a tendance à stigmatiser l’erreur et l’échec. Pour réussir, il faut suivre le modèle. De là à décourager les tentatives de sortir du cadre, il n’y a qu’un pas, non sans conséquences sur le plan de la créativité et de la prise de risque.
Nombre d’entrepreneurs le disent, en effet : pour se lancer, il ne faut pas avoir peur de se tromper. La Silicon Valley regorge de success stories qui ont démarré par un échec. En France, c’est moins évident.
“Apprendre à coder, c’est apprendre à se tromper.”
Pédagogie par l’erreur
Néanmoins, l’idée fait son chemin petit à petit et certains enseignants n’hésitent plus à parler de pédagogie par l’erreur – dans le primaire et le secondaire davantage cependant que dans le supérieur où il est difficile de faire descendre la connaissance de son piédestal. Si aucune discipline n’est exclue de cette approche, les formations en informatique ont par nature un avantage, puisqu’il faut bien que les élèves apprennent à débuguer un système. Ce faisant, ils s’appuient sur des erreurs pour progresser.
Contrairement aux idées reçues et au cliché du geek programmeur sans imagination, il faut même parfois faire preuve de créativité pour s’en sortir. Et ne pas hésiter à demander de l’aide, qu’il s’agisse de son voisin de classe ou de l’Internaute à portée de clic, dans un esprit de collaboration. Deux qualités désormais mises en avant pour promouvoir l’apprentissage du code.
Fierté du codeur
Evidemment, si l’erreur a un intérêt pédagogique, l’enjeu reste tout de même de résoudre le problème. La satisfaction intellectuelle est alors d’autant plus forte que le code a des effets très concrets quand on réussit enfin à faire tourner le programme souhaité et que la suite de quelques milliers de caractères se matérialise dans la réalisation d’un jeu vidéo ou la construction d’un site Internet.
Une expérience vécue par la plupart des participants au forum de la Grande école du numérique, organisé le 29 septembre dernier par EdFab, la « fabrique des nouvelles formations numériques » de Cap Digital. Jeunes ou seniors, ils apprécient la dimension concrète et pratique de ces formations qui permettent de « sortir la tête des cahiers », comme le dit Tibilé Coulibaly, étudiante au PoleS, labellisé Grande école du numérique.
Racontant son parcours, la jeune fille de Seine-Saint-Denis exprime ainsi une certaine fierté à devenir développeuse : « dans les quartiers populaires, explique-t-elle, on a souvent tendance à se dénigrer. Créer une page html nous montre qu’on sait faire des choses. »
24 Responses
On devrait pendre ceux et celles qui disent “programmateur” au lieu de “programmeur”, avec les tripes de ceux qui disent “digital” au lieu de “numérique”…
Je suis bien d’accord… “programmateur”, c’est la minuterie pour le four ; quant à digital, c’est un anglo-barbarisme dû à la feignantise de traduire un faux-ami de la perfide Albion…
+1
“programmateur” ça ferait plutôt penser à ça… https://ibin.co/2yRlpQ4NHyeQ.jpg (et accessoirement ça sonne aussi comme la fusion de “programmeur” et “amateur” 🙂
(quant à “digital” — qui se réfère donc aux doigts en langue Française — il ne faut pas beaucoup d’imagination pour faire des blagues tendancieuses…)
livrons les a daesh
oui mais ce n’est pas écrit en gras, donc ça ne compte pas
moi c’est “code week” qui me chiffonne, l’UE va continuer à parler anglais même sans le Royaume Uni, pas de jaloux ! Avec un peu de chance on aura un French Language’s Day.
“Apprendre à coder, c’est apprendre à se tromper. Et ce n’est pas si courant.”
NON NON NON.
Apprendre à coder, c’est devoir admettre qu’on fait des erreurs. C’est beaucoup plus dur.
Combien d’apprentis sorciers débutants et ignares commencent à incriminer l’OS ou le compilateur avant de d’admettre que l’erreur conne et stupide est dans LEUR code ????
déjà entendu comme argument d’une personne justifiant sont incompétence suite à une remarque sur du code foireux “blabla mais il y a différentes façon de coder blabla”.
On avait donc à faire à un philosophe du code, mais dont le code ne marchait néanmoins pas. ^^
A chaque fois que l’on m’appelle programmateur je rappelle que je ne ressemble pas à une machine à laver… Et sinon il faut apprendre à faire passer ses idées sans avoir recours au gras à tout bout de champs, ça vous aidera dans la vie.
L’erreur est tellement intégrée au métier de développeur informatique, que les recherches d’erreurs et leurs corrections font pleinement partie du processus de l’industrie informatique.
.
On ne cherche même pas à avoir des développeurs qui ne font pas d’erreur – à peine à les former dans ce sens – : on part du postulat qu’ils en feront, et on adapte les procédés de production. La recherche d’erreur, leur correction, évaluation des coûts est théorisée, organisée, automatisée, standardisée. Et elle représente une proportion majeure des coûts de cette industrie, et des recherches pour les faire baisser.
.
L’hypothèse est qu’un développeur fait d’autant plus d’erreur qu’il travaille beaucoup, et qu’elles sont d’autant plus compliquées à débusquer que l’équipe de développement est grande ; que certains ne se connaissent parfois qu’indirectement, voire pas du tout, certains utilisant des couches logicielles développées sur d’autres continents, parfois à d’autres époques.
.
Et s’il y a des erreurs, il faut faire avec, c’est une donnée de plus au problème à résoudre, comme la météo favorable ou défavorable peut l’être pour un automobiliste, un capitaine au long cours ou un pilote de ligne.
Tout ça me paraît bien vague et relevant plus de clichés que d’analyses rigoureuses.
1. Un informaticien ne reste pas forcément placide devant un bug, à attendre le suivant. Un bug peut causer la panique et des heures de pression pour le corriger ou en mitiger les effets.
2. Programmer, c’est accepter que des bugs sont possibles, mais ce n’est pas nécessairement s’appuyer sur des erreurs pour progresser. Il existe toutes sortes de techniques pour limiter le risque de bugs — voire garantir leur absence sur la partie logicielle de la machine, en cas de langage vérifiable. Un programmeur expérimenté qui néglige ces techniques et produit un code “sale” encourt le mépris de ses collègues.
3. “Errare humanum est” n’a rien de spécifique à la programmation. Une démonstration mathématique peut elle aussi paraître correcte au premier abord, mais souffrir d’un “bug” rédhibitoire. Un enseignant peut intégrer ces erreurs dans sa pédagogie, au moins dans les domaines scientifiques (ceux où une formulation est absolument démontrable, sans vérité relative).
4. Sur la créativité et la peur de se tromper, là non plus les particularités ne sont pas flagrante. En cuisine comme en programmation, on peut parfois agir de façon mécanique, et parfois faire preuve de créativité. Certains développeurs se plaignent d’un travail routinier, d’autres travaillent dans un cadre plus souple avec une liberté qui les laissent essayer de nouvelles solutions (algorithmes, langages, etc).
Par ailleurs, en deux décennie dans le milieu informatique, j’ai presque toujours rencontré le mot “programmer”, alors que le monde politique et médiatique, voire enseignant, semble préférer “coder” sur le modèle anglais. Et “codage” au lieu de l’habituel “programmation”.
Les journalistes eux aussi ont le droit de se tromper, du moment qu ils corrigent et se corrigent…
En effet et c’est corrigé !
Passé le cape de l’apprentissage de l’algorithmique et des structures de données ainsi que des architectures matériels et logiciels, le code c’est du pipi de chat. Pour le reste mon seul conseil: R.T.F.M.
Et G.I.Y.F.
Les journalistes eux aussi ont le droit de se tromper du moment qu ils corrigent et se corrigent….
On connaît la propension des programmeurs à créer des bugs, mais de là à se focaliser sur l’apprentissage par essais et erreurs, c’est un peu trop. Les bons programmeurs sont ceux qui ont la rigueur qui permet de limiter le nombre d’erreurs. Imaginez un architecte qui vous explique que le mur va s’écrouler, mais que ça n’est pas si grave car il a appris de son erreur.
Pour commencer, l’informatique est une science.
On est obligé de faire avec les erreurs parce-que les bonnes pratiques de développement ne sont pas généralement pas appliquées.
La raison majeure est que l’informatique est vue comme un cout par le métier, plutôt qu’un investissement.
L’autre raison est la flemme ou l’incompétence des développeurs.
Donc toutes les bonnes pratiques sont faites en “best effort”, c’est à dire “si il y a le temps”, donc tout ce qui est bonne pratique de développement avec mise en place de revue de code, tests unitaires, tests d’intégration, voir pire, tests de non régression, tests de charge, passent à la trappe.
Il y a des bugs graves et des bugs moins graves, vous le saurez quand on vous mettra dehors suite à un bug.
Pour ce qui est de l’utilisation non professionnelle, oui biensur les bugs n’ont pas d’importance puisque vous ne pouvez pas vous faire virer.
L’informatique est une science: mais non!
C’est juste un outil rigolo que même les apprentis journalistes peuvent prétendre maîtriser. C’est kikoolol, alors tout le monde peut en faire.
Les UFR de sciences à la fac, c’est juste de la blague.
Non, et non.
Tu dois distinguer le processus de développement du système livré. On ne te met pas dehors suite à un bug pendant le processus de développement (ou alors la personne qui le fait est simplement hautement irresponsable et doit rapidement consulter)
.
Durant le développement il y a des erreurs parce qu’il n’est simplement pas humain de ne pas en faire étant donné la taille et la longueur des sujets traités. Lorsque tu as des projets qui mobilise 20 personnes sur 3 ans, que personne ne fasse aucune erreur est une vue de l’esprit.
.
Un développeur qui viendrait pour travailler avec moi en m’affirmant qu’il ne fait jamais aucune erreur serait éconduit directement : soit il ment, soit il est incompétent, et dans tous les cas il ne tient pas compte du reste de l’équipe qui elle, fait des erreurs : dans tous les cas il ne fait pas l’affaire. Il est un humain, pas un compilateur.
.
Ce qui m’intéresse, c’est moins sa capacité à faire ou à ne pas faire des erreurs, mais à anticiper sur les méthodes à mettre en place pour les corriger /systématiquement/ et à tous les niveaux de la chaine de développement et d’intégration.
.
Là on parle de processus industriel, pas d’individu.
Pitié : parlez de programmation pas de codage. ça ne paraîtra pas désuet, je vous assure, simplement moins laid.
Et sans rancune, vous n’êtes pas le seul, la majorité des “non pratiquants” me font siffler les oreilles.
Concernant le fond de l’article, la programmation n’est pas la seule discipline où l’erreur est salutaire. En maths ou en physique tant qu’on n’a pas fait d’exercice on n’a rien fait. Et les situations où l’on sèche sont généralement les plus instructives. Peut-être cependant que ces disciplines sont moins accessibles ou moins dans l’air du temps…
Il y a pas mal de problèmes dans cet article.
Oui, l’erreur fait partie de la programmation, et le processus de déboguage ou rétro-analyse fait simplement partie du métier.
Mais le “blogueur” manque un élément essentiel du métier: la loi de Murphy. Le “programmateur informatique sur ordinateur digital” paye extrêmement cher ses plus infimes erreurs, et c’est pourquoi il doit au contraire apprendre à ne PAS se tromper. A faire une analyse rigoureuse du problème avant de se lancer à coder, à diviser pour régner, à tester, etc.
Même comme cela, les erreurs résiduelles sont toujours présentes peuvent être lourdes à corriger, et lourdes de conséquences aussi. La pédagogie à base de “sortons du code on verra bien YOLO”, c’est simplement un mirage à pédagogos. C’est le meilleur moyen de produire du code, parfois très long, qui ne marchera jamais et que même les pros ne pourront pas déboguer.
TLDR; un programme, c’est comme une maison. Si les fondations sont faites n’importe comment, faut pas essayer de construire dessus. C’est pas pour rien qu’on fait faire des tests de logique aux programmeurs, et c’est pas demain que les (vraiment) nuls en maths pourront faire carrière en programmation (ce n’est déjà pas le cas de tous les informaticiens).
J’ai toujours apprécié dans la programmation 1) de me tromper, car le plaisir vient quand l’erreur est trouvée et qu’enfin cela fonctionne, 2) que l’ordinateur ne puisse pas se commander avec de belles paroles. En lisant des commentaires et souvent aussi des articles, je remarque qu’on peut avec un certain talent dire des choses fausses. Il est possible de tricher en maniant les mots et les idées. Avec le code on peut certes bidouiller mais jamais être tout à fait dans des postures idéologiques. Il ramène constamment au concret.
“l’informatique est une science.”: plus exactement je dirais: c’est à la fois une science, une technique et un art.
Dire que la faute majeure est de ne pas appliquer les “bonnes pratiques de développement” est un leurre qui oublie le coté “art” (au sens noble: comme il y a un art de la médecine). ça fait 35 ans que j’enseigne “les bonnes pratiques de développement” mais aussi que je dis qu’il faut réfléchir et relativiser: L’application aveugle de “bonnes” procédures ne conduit pas à un logiciel de meilleure qualité.
oui l’informatique est une science “humaine”!