Même pas peur !

Ylva painting (Jon Bratseth / Flickr)

Récemment je commettais ceci…

Ceci est un lapin. Il n’est pas inutile de le préciser. Qui plus est dessiné avec l’éditeur de Scratch. À non pas main levée mais souris levée… Cela fait peur…

La peur, moteur de la société, moteur politique, moteur de la communication, excuse trop souvent invoquée pour ne pas avancer.

La peur que je rencontre trop souvent dès que l’on parle d’innovation. Un obstacle pas impossible mais difficile à contourner.

Peur d’innover, de se distinguer…

Peur de se tromper…

Peur de décloisonner…

Peur d’outrepasser, de dépasser…

Je l’ai encore rencontrée récemment et sincèrement elle m’a surprise.

Je faisais une formation à Scratch auprès d’enseignants, une initiation quand, à la fin de la séance, une enseignante bien qu’enthousiaste, m’opposait ce bémol : « et si je me trompe devant les élèves ? »

J’avoue qu’il m’a fallu quelques secondes de réflexion avant de la regarder en souriant et de lui répondre simplement « Même pas peur ! ».

Revenons à mon dessin. La morale de ce dernier est que je ne sais absolument pas dessiner. Point n’est besoin d’argumenter ou d’insister pour s’en rendre compte.

Parfois les ateliers me forcent pourtant à le faire pour montrer par exemple aux enfants comment avec un peu de carbone n’importe quel dessin peut devenir connecté. Je m’excuse auprès d’eux par avance mais avec amusement de mes prouesses. « Ah oui tu ne sais vraiment pas dessiner », me lance une petite de CE2 alors que je venais de tenter un simulacre de fleur. « Regarde. Je vais te montrer. »

J’ai alors appris à dessiner une fleur, un ours, puis une autre m’a montré comment faire un papillon, puis un arbre. Je suis ressorti de cet atelier un peu moins nul.

Mais, wait a minute ! « Ce sont les enfants qui doivent apprendre quelque chose, pas moi ! », me dirait la tradition.

C’est bel et bien comme cela que l’on envisage trop souvent l’apprentissage. Il n’y a pas d’échange, juste du top-down, du vertical qui jure grandement avec ce monde qui devient de plus en plus horizontal.

Il est pourtant plus intéressant de revaloriser l’erreur. Le « redo from start » de mes premiers pas en programmation ou le « Game Over » de ma jeunesse de gamer ne me disaient pas « tu es fichu » mais « recommence ». « Game Over » était d’ailleurs accompagné de « start again ». « Même joueur joue encore !  » L’ordinateur comme la bonne d’arcade avaient le sentiment que je pouvais, que je devais nécessairement m’améliorer. Et ils avaient grandement raison.

Je fais mon maximum pour que les ateliers soient un échange et non une simple transmission. D’ailleurs je sais dessiner des ours et des papillons désormais. J’évolue… 😉

La fin du monde est derrière nous (pour peu que l’on se retrousse les manches)

Je sais que j’en risque d’en choquer une paire avec un titre aussi optimiste. Non, je ne me range pas derrière un Donald Trump qui espère un retour à la normale en faisant tout le contraire de ce qui devrait être. J’exprime un simple ras-le-bol face aux titres alarmistes dont les médias semblent raffoler depuis quelques temps.

Le temps n’est pas à l’optimisme béat mais non plus au fatalisme. Chaque fois qu’une lueur d’espoir semble pouvoir raviver la flamme, les pompiers de l’info nous arrosent d’une bonne douche froide. Pourtant ce n’est pas à coups de « ça marche pas » que l’on résoud les problèmes mais bel et bien en proposant des solutions.

C’est un article de Futura qui m’a décidé à écrire ce texte. Ce n’est qu’un exemple parmi tant d’autres. Gros titre : « Europe : les forêts ne pourront pas freiner le réchauffement ». Paf, prends-toi cela dans la g… Si l’on comptait sur les arbres et le reboisement, c’est fichu. Rentrez chez vous, messieurs-dames. Il n’y a rien à faire. Je ne vous apprendrai rien dans le domaine de l’information en vous indiquant que beaucoup de lecteurs se contentent de lire le titre et uniquement le titre. Que conclure de ce dernier ? Qu’il donne une furieuse envie de baisser les bras.

Vraiment ?!

En fait, il faut lire plus bas : « Le reboisement en soi n’est pas un problème, il est positif. Mais nos conclusions indiquent qu’il n’est pas un outil pour maîtriser la température si on émet des gaz à effet de serre comme on le fait actuellement.« 

Réécrivons donc le titre tel qu’il aurait du être écrit : « Europe : les forêts ne pourront pas freiner le réchauffement si nous ne réduisons pas notre empreinte carbone en changeant nos modes de consommation ». Un peu long certes et je ne l’écrirais pas ainsi mais un peu plus optimiste surtout. Avec une perspective d’action…

Je travaille souvent avec des enfants, des jeunes en difficulté. Je sais que leur environnement est très complexe et que personnellement je n’ai que peu d’emprise sur ce dernier. Je ne suis qu’un des tous petits maillons de la chaîne humaine et sociale qui les entoure mais j’ai à coeur de faire ma part. Je fais un pari sur l’avenir, sur son avenir et j’y apporte ma maigre mise. Je pense toujours au colibri qui, goutte par goutte, essaie d’éteindre l’incendie de la forêt. Si chacun fait sa part, si personne ne baisse les bras, il peut arriver des miracles et c’est cet état d’esprit de combativité, d’ingéniosité, de curiosité et de créativité que j’essaie d’insuffler aux enfants et aux jeunes.

Face à une armée de 1000 robots destructeurs, le fataliste attendra qu’on l’achève. Le hacker biberonné aux épisodes de MacGyver regardera le chewing-gum, l’élastique et le trombone trouvés dans sa poche en se disant, même si c’est un peu fou, « Même pas peur ! ».

12 trucs et astuces pour apprendre à coder (parce que 10 c’était trop court)

Étiquettes

apprentissage, auto-apprentissage, éducation, code, formation, méthode

 

1 – Prendre le langage qui vous branche, pas celui qui est la hype du moment

C’est la règle d’or : apprendre en s’amusant ou tout au moins aimer ce que l’on fait. Ne vous focalisez pas sur le langage du moment. S’il vous rebute, vous n’arriverez à rien. De plus, ce domaine évolue tellement vite que vous n’êtes pas à une surprise près. Le Javascript était par exemple particulièrement déconsidéré avant que l’on parle de HTML5 et qu’il devienne l’un des piliers du web. L’important est que le langage que vous choisissez attise votre curiosité et votre envie d’apprendre. Il est plus intéressant d’avoir des développeurs avec de multiples facettes que des profils tous exactement similaires. Qui plus est, vous trouverez toujours une solution pour aboutir à vos fins. Par exemple, le couple PHP – MySQL m’a toujours rebuté dans le domaine des bases de données. Cela ne m’a pas empêché d’y pallier en m’éclatant avec des langages et méta-langages comme Rebol (désormais Red), Python et XML.

2 – Trouver un projet qui vous passionne et le mener à bien

Le grand défaut de certains manuels ou formations au code est le manque de cas concrets. On vous apprend les commandes les unes après les autres mais le liant est quasi-absent. C’est comme apprendre des mots, des phrases sans jamais avoir de conversation. Je me suis ainsi pris une claque la première fois que je suis venu passer véritablement quelques temps en Angleterre. Rien à voir avec l’anglais de l’école. Il m’a heureusement fallu peu de temps pour m’adapter et plonger dans le grand bain linguistique. Le grand bain, c’est donc un projet qui vous passionne, pour lequel vous trouverez le temps et l’énergie de réfléchir, de développer, de vous casser peut-être et même sûrement les dents. Peu importe si ce type de logiciel existe déjà. C’est toujours plus intéressant de le faire soi-même. Répondez à un besoin, une envie. Construisez par exemple un outil pour compléter une autre de vos passions. Soyez créatifs et créateurs.

3 – Dédramatiser

Vous apprenez une nouvelle langue. Imaginez-vous dans un pays étranger où vous ne maîtrisez que quelques mots et où l’ordinateur est votre seul interlocuteur. Vous lui demandez le sel. Il vous répond qu’il ne comprend pas. Vous lui demandez de nouveau autrement. Il vous apporte le sucre. Rien de grave. Juste un problème de compréhension. Votre vie ne se joue pas à cet instant et l’ordinateur ne va pas barrer votre copie numérique d’un grand trait de crayon rouge ni exploser après avoir affiché un grand « syntax error » clignotant.

4 – Avancer pas à pas et en faire un peu tous les jours

Ce n’est pas 10 minutes par jour ou 5 heures tous les quinze jours qui feront de vous un développeur. Il vaut mieux apprendre et s’exercer un peu tous les jours. Une bonne régularité vous permet de mémoriser plus facilement. Ne visez pas non plus trop haut dès le départ. Vous risqueriez de déchanter. Dans le domaine de la programmation informatique, on s’imagine facilement devenir bilingue du jour au lendemain. Cela nécessite un peu plus de patience mais vos efforts seront toujours récompensés.

5 – Savoir lâcher du lest

Il faut parfois savoir abandonner provisoirement ce que l’on fait pour mieux y revenir. Ce n’est pas en restant bloqué devant l’ordinateur que l’inspiration vous viendra. Il est même fort probable que vous serez encore plus perdu. Quand je ne comprends plus rien, très souvent je m’éloigne de l’ordinateur, prends une feuille de papier et essaie d’exprimer ma pensée de manière simple. Cela me permet d’y voir plus clair et de repérer l’endroit où je me suis égaré dans le code. N’hésitez pas à passer à autre chose, carrément autre chose. La solution d’un bout de code qui me torturait l’esprit m’est apparue récemment en faisant mes courses, un paquet de nouilles à la main… Lorsque l’on se détache d’une activité, on libère le cerveau qui peut alors « à l’insu de notre plein gré » explorer de multiples voies alternatives. Bougez, marchez, aérez-vous l’esprit, détendez-vous devant un bon livre, une BD ou un jeu vidéo et il y a de fortes chances que tout s’éclaire et que vous vous écriiez tel le commissaire Bougret de Rubrique à Brac « Bon sang mais c’est bien sûr ! ».

6 – Commenter, synthétiser

Commenter le code s’avère vite indispensable. D’une part, pour expliquer ce que vous faîtes (particulièrement important quand on débute), d’autre part, comme aide-mémoire. Quand on saute d’un projet à un autre ou que l’on reprend un bout de code six mois plus tard, il est important de pouvoir s’y retrouver rapidement. Ce serait dommage de perdre du temps à s’interroger sur le fonctionnement du programme. De même, il peut vous arriver pour x raisons de ne pas coder de manière naturelle mais d’user d’un subterfuge, d’une porte dérobée. Six mois plus tard, il est fort probable que vous vous demanderez pourquoi vous n’avez pas codé telle ou telle fonction de manière classique. Ce que vous ferez immédiatement avant de vous rendre compte de votre erreur et du « pourquoi du comment » que vous avez agi différemment.

7 – Prendre des notes et synthétiser ses connaissances

Les manuels papier ou numérique, les cours en ligne sont très pratiques mais ne correspondent pas forcément à votre manière d’apprendre. Qui plus est, les explications sont parfois verbeuses et vous ne vous intéressez qu’à un petit bout de texte, à la syntaxe d’une commande par exemple. Faites-vous un document récapitulatif, pourquoi pas sous forme de carte heuristique. Lorsque l’information vous manque, pas besoin de devoir plonger dans le manuel. Un simple coup d’oeil sur votre synthèse vous permettra de retrouver l’information importante. Cela vous permet aussi de compléter l’information manquante ou de donner des exemples qui vous paraissent plus clairs que dans le manuel.

8 – Tester et expérimenter

Les manuels n’ont pas toujours réponse à tout et il se peut fort bien que le problème que vous rencontrez ne soit pas documenté. Je prends souvent en formation l’exemple du labyrinthe. On ne reste pas coincé au bout d’une allée. On revient sur ses pas pour tester la suivante jusqu’à ce que l’on trouve la sortie. Dans le code, idem. Si cela ne marche pas avec la méthode A, peut-être que la méthode B sera la bonne, ou la C ou la D ou la E… Vous ne perdez rien à essayer. Parfois même il vaut mieux isoler une commande, la tester en dehors de votre programme pour vérifier que vous avez bien compris son fonctionnement et qu’elle répond exactement à vos besoins.

Récemment par exemple, j’examinais dans un manuel une commande permettant de supprimer un caractère précis d’une chaîne de caractères, par exemple retirer les virgules d’une phrase. Je voulais cependant retirer toute la ponctuation et le manuel n’indiquait pas comment retirer plusieurs caractères en même temps. J’aurais pu répéter la même commande caractère par caractère mais cela me paraissait un peu fastidieux. J’ai simplement ajouté d’autres caractères entre les guillemets indiquant celui à supprimer et le miracle fût. J’aurais pu perdre mon temps à chercher sur internet ou rester bloqué. Un simple test m’a permis d’avancer.

9 – Sauvegarder régulièrement et utiliser le versioning

Sauvegarder régulièrement devrait être un réflexe naturel. Personne n’est à l’abri d’un souci technique ou d’une erreur de manipulation. Et zou, adieu le code tapé pendant de longues minutes fiévreuses… Sauvegardez régulièrement et n’hésitez pas à créer de multiples fichiers portant chacun un numéro de version. Cela vous permet de conserver un historique de votre progression et de repérer plus facilement les erreurs. Si la version 0.43 de votre code fonctionnait parfaitement, nul doute que les erreurs proviennent de ce que vous avez ajouté à la version 0.44.

Par convention, les versions comportant des chiffres après la virgule sont dites « mineures », c’est-à-dire que les modifications qui y ont été apportées ne sont pas importantes. Les versions avec un chiffre entier sont dites majeures car elles sont considérées comme fonctionnelles et apportant une réelle innovation dans la progression. Si je comparais avec la randonnée, les versions 0.43 et 0.76 indiquent que vous avancez sur le chemin, la version 1.0 que vous êtes arrivés à votre première étape, le refuge de la Chouette chantante sur le Mont Técarlo. La version 1.0 est un peu particulière car c’est la première version véritablement fonctionnelle.

Par exemple, je code actuellement pour le plaisir un analyseur de textes en Red et je suis à la version 0.56, ce qui signifie que mon programme tourne correctement mais qu’il est pas encore assez fonctionnel pour le public et qu’il reste des améliorations majeures à y apporter.

On peut utiliser des services en ligne comme Framagit pour sauvegarder son code et pouvoir suivre plus facilement l’historique mais, pour démarrer, ce n’est pas forcément nécessaire.

10 – Simplifier, optimiser votre code

Votre code fonctionne parfaitement ? Magnifique ! Mais le travail n’est pas fini. C’est le moment de simplifier, d’optimiser le programme. Simplifier en vérifiant s’il n’y a pas possibilité d’avoir un code plus concis ou d’user de méthodes plus rapides. Certaines commandes peuvent par exemple être réunies et combinées en une seule. Un code simplifié et optimisé est plus élégant, plus facile à lire et surtout fonctionne plus vite. C’est alors moins de temps machine utilisé, moins de dépense énergétique.

Optimiser, gagner en rapidité et en ressources, c’est aussi se soucier du matériel plus ancien. Quel intérêt a votre programme s’il faut systématiquement le dernier ordinateur en date pour le faire tourner ? Les utilisateurs se tournent plus facilement vers des solutions économes et votre souci d’optimisation montrera votre habileté et votre sérieux dans le code.

Optimiser, c’est aussi se soucier de l’utilisateur et des erreurs possibles. On tente alors de se mettre à la place de ce dernier et de lister les problèmes qu’il ou elle peut rencontrer. N’hésitez pas à tester votre programme auprès d’autres personnes. Quand on a le nez dans le guidon, il est souvent difficile de repérer ses erreurs.

Un exemple d’erreur ? De nombreux formulaires en ligne examinent la saisie au cours de la frappe et affiche un message d’erreur en rouge de manière un peu trop systématique. Lorsque vous entrez une adresse mail et que vous voyez apparaître le message « adresse mail non valide », il y a de quoi se poser des questions. En fait, tant que l’adresse entière n’est pas tapée, elle est forcément non valide. Un utilisateur averti saura de quoi il retourne. D’autres seront bloqués. La solution toute bête est de vérifier la saisie lorsque l’utilisateur valide le formulaire et non lors de la frappe. Erreur de design, erreur de développeurs qui ne se sont pas mis à la place de l’usager…

11 – Comparer, examiner le code des autres

On apprend en observant. Observer n’est pas copier, reprendre des bouts de code sans trop savoir à quoi cela sert. Observer, c’est examiner, analyser, essayer de comprendre la méthode de tel ou tel développeur et ensuite trouver sa propre méthode. Chaque fois que cela est possible, n’hésitez pas à examiner le travail des autres et à en tirer vos propres solutions.

12 – Poser des questions

Il existe des forums spécialisés, des sites regorgeant d’articles. Le problème sur lequel vous planchez ne trouvera pas forcément sa réponse immédiatement mais il y a de fortes chances que vous ne soyez pas le seul dans votre cas ou qu’un autre problème s’en rapproche. Après avoir fait quelques recherches, avoir documenté votre problème, n’hésitez pas à poser la question sur un forum non sans avoir clairement expliqué la situation qui vous bloque. Un « Ca marche pas » ne résout jamais rien.