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.

Numérique : comment dépasser l’effet Wahou (jusque l’infini et au-delà) ?

Je n’étais pas très grand quand j’ai pu découvrir ce qu’était la visioconférence bien avant que l’on parle d’internet. Je me souviens de chapiteaux installés par France Telecom sur la place de Béthune, la ville où j’ai grandi et, du haut de mes 10 ans en 1986, je naviguais entre les différents prototypes présentés. Il devait y avoir le premier téléphone portable mais je ne m’en souviens plus. À la même époque, le maire de la ville, Jacques Mellick, faisait élever dans le quartier du Mont Liébaut l’IRCOM (Institut Régional de Communication). J’ai eu le privilège de le visiter et mes yeux ébahis ont pu découvrir des dizaines d’ordinateurs implantés un peu partout dans les salles, un espace bourré d’écrans et de « racks » qui devait préfigurer ce que serait un data center et, dans chaque salle, un décor digne d’un film de science-fiction. Inutile de vous décrire mon excitation. Elle était à son comble. Je n’ai malheureusement pas pu profiter du lieu, celui-ci ayant été ravagé par un incendie en 1989.

Ce fut mon effet « wahou », mon entrée dans le numérique. Par la suite, j’ai eu de la chance. Le fait de pouvoir aller régulièrement au théâtre m’avait poussé à plonger dans les bacs de musique classique, contemporaine et électronique de la médiathèque plutôt bien fournie. Mon père disposait dans ses bureaux d’ordinateurs que je squattais régulièrement, ayant dans mon cartable plutôt qu’un goûter un paquet de disquettes 5″1/4 acheté au centre commercial du coin. Enfin, mon collège possédait des ordinateurs un peu poussifs mais que j’appris rapidement à maîtriser grâce aux ouvrages de la médiathèque et à quelques magazines informatiques. Je me repens d’ailleurs en ces lignes (mais il y a prescription) d’avoir régulièrement « bidouillé » en cours de maths de 6éme lors des séances informatiques en modifiant le code source des programmes et leurs variables. De même, non, le « serveur » qui administrait la quinzaine de MO6 de la salle n’était pas capricieux ; j’en prenais simplement le contrôle. Par la suite, j’eus rapidement mon propre ordinateur (et même une imprimante, ce qui coûtait un bras à l’époque) et mes professeurs purent enfin goûter une accalmie bien méritée.

« Avoir de la chance » ne devrait pas être une condition. Je suis conscient d’avoir été privilégié et c’est loin d’être le cas de tout le monde. À l’époque, il n’était pas toujours si facile d’accéder au numérique malgré le déferlement des ordinateurs personnels (Amstrad, Amiga, Atari…) et des premières consoles (Atari 2600, NES, Master System…). Je rencontre parfois des personnes de ma génération qui ont tâté elles-aussi du BASIC, voire de l’Assembleur, non sans nostalgie. De mon temps, les jeunes… 😉

Le matériel informatique est aujourd’hui à profusion, ne serait-ce qu’au travers des téléphones portables dont on change comme de chemise (et c’est bien dommage) sans en avoir tiré un centième des possibilités. L’effet « wahou » se démocratise au travers de nombreuses initiatives et d’ateliers éphémères. Je suis moi-même amené à intervenir dans différents lieux pour quelques heures et la magie s’opère. Ensuite, est-ce que l’on a la chance ou pas de disposer du matériel nécessaire chez soi, d’être entouré de personnes pouvant nous aider, de vivre dans un environnement inspirant ou tout simplement d’avoir du temps de cerveau disponible pour cogiter non sur les soucis du quotidien mais sur de fantastiques projets ? La question ne devrait pas se poser. On ne peut pas agir à tous les paliers mais il est important de créer de prime abord des conditions qui permettent de faire perdurer cet effet « wahou ».

Que l’on s’entende bien cependant : je ne dénigre pas l’effet « wahou ». Il est nécessaire et primordial. Sans étincelle, pas de feu… Mais sans papier, petit bois et bûches, pas de feu non plus…

Comme d’habitude, pas de recette miracle mais quelques pistes de réflexion.

Primo, n’utiliser que des ressources disponibles facilement, voire gratuitement. En cela, les logiciels libres constituent une solution optimale. Je me souviens il y a plus de 10 ans avoir refusé d’animer un atelier consacré à la musique électronique. Motif : l’apprentissage d’une vingtaine d’heures allait bénéficier d’un matériel et de logiciels hauts de gamme dans un studio éphémère. Une fois l’atelier terminé, basta ! On laisse les jeunes sans ressources pour poursuivre. Rien ne me fait plus plaisir que de les entendre dire durant l’atelier « je vais continuer chez moi » et ce, quel que soit le milieu social. Bonjour Scratch, Code.org et l’extraordinaire catalogue de logiciels libres constitués par l’association Framasoft, Framalibre. Idem pour la documentation : ne pas partir sans laisser de pistes ou quelques liens.

Secundo, concrétiser. Attention ! J’ai bien écrit « concrétiser » et non pas « tangible » comme la mode le veut actuellement, n’en déplaise aux tenants des fameuses « interfaces tangibles » (une télécommande est une interface tangible pour info…) . Bien que les deux termes soient présentés comme synonymes, il n’en est rien dans l’esprit. Tangible, c’est pouvoir toucher, être face à un objet qui existe. Concret est un peu plus philosophique et, à mon sens, plus intéressant. L’utilisation du terme « tangible » semble plus réanimer un vieux débat inintéressant entre manuel et intellectuel, entre ceux qui fabriquent et ceux qui ont le nez dans l’ordinateur. C’est bien la question dont on se fiche. L’important est de concrétiser, c’est-à-dire de créer de l’intérêt pour l’apprenant, pour qu’il ait envie de poursuivre. Parlons par exemple de mathématiques et de géométrie. S’il utilise un théorème quelconque pour modéliser et imprimer une forme en 3D ou développer une animation en Processing ou, plus hardcore, coder un script bash pour vérifier la faisabilité d’un triangle en fonction de la longueur des trois côtés, l’important n’est pas le résultat mais bien l’intérêt qu’il y trouve. Je me souviens d’un collégien qui m’avait envoyé balader lors d’un atelier code tout au long de l’année scolaire. Je me suis cassé les dents plusieurs fois jusqu’à ce qu’il m’explique qu’il faisait du rap. Ok ! Nous avons codé les rythmes et il s’est raccroché au groupe.

Tertio, créer des espaces de créativité, des « hackerspaces ». Plus facile à écrire qu’à faire car tout dépend non pas de votre bonne volonté, mais de celle du commanditaire. Sans avoir l’air de jouer au commercial ou de donner des injonctions, j’essaie toujours de m’intéresser à leurs projets futurs. Que va devenir l’espace que nous avons utilisé ? Quels sont les ateliers proposés ? Y a-t-il un accès libre ? Si un projet plus large est possible, tant mieux. Aidez-le à grandir, à tendre vers le hackerspace, c’est-à-dire un espace de possible, de créativité, de partage de ressources, de connaissances, de matériel, de culture…

Enfin, est-il utile de l’écrire ? Certes, on peut avoir une tendance solitaire (mea culpa ou pas 😉 ) mais il est souvent difficile de faire bouger les choses seul. S’il est possible de créer de la communauté autour d’un projet, il y a de fortes chances que l’action se poursuive. Trois-quatre gamins qui se retrouvent régulièrement dans une médiathèque, c’est déjà une communauté que bien souvent vous retrouvez sur d’autres événements. Autant en profiter et les aider à grandir sans oublier d’impliquer les intervenants, animateurs, parents… qui les entourent.

Je ne suis pas magicien ou petite chronique d’animation numérique

C’est l’histoire d’un restaurateur…

Un mois auparavant : « Nous disons donc 10 adultes et 4 enfants. C’est bien cela ? »

Le jour même : « Ah oui désolé. En fait, ils sont 25 dont 7 enfants. »

Et le restaurateur restaura comme il pût 25 personnes pour ne pas que les convives en pâtissent.

Un mois auparavant : « Île flottante en dessert, ça vous convient ? »

Le jour même : « Vous n’avez pas été prévenus qu’ils sont allergiques aux oeufs ? »

Et le restaurateur donna ses îles flottantes au foyer d’à coté et prépara avec ce qu’il avait sous la main un autre dessert pour ne pas que ses convives en pâtissent.

Un mois auparavant : « Trente bavettes avec sauce au poivre et frites ? C’est d’accord. »

Le jour même : « Personne ne vous a dit que nous sommes végétariens ? »

Et le restaurateur fit preuve d’imagination une nouvelle fois pour ne pas que ses convives en pâtissent.

Un mois auparavant : « La cuisine est entièrement équipée. Vous y serez au paradis. »

Le jour même : « Oui, désolé. On a une coupure de gaz depuis 4 jours. Ça va aller quand même ? »

Et le restaurateur cuisina au feu de bois pour encore une fois ne pas que ses convives en pâtissent.

Un mois auparavant : « Nous avons quatre fours à disposition. Vous n’aurez pas de soucis pour réchauffer vos 200 plats. »

Le jour même : « Oui, on a déplacé les fours dans un autre espace. On a pensé que vous n’en auriez pas besoin mais, si nécessaire, il y a des micro-ondes dans l’arrière-salle. »

Et le restaurateur réchauffa comme il put ses 200 plats à l’aide de micro-ondes, en s’organisant comme un malade pour sans surprise ne pas que ses convives en pâtissent.

Un mois auparavant : « Oui, notre piano est compatible avec les casseroles et cocottes XYZ. »

Le jour même : « Mais qui a bien pu vous dire cela ? C’est un modèle de 1996. Il n’accepte pas les casseroles et cocottes XYZ. »

Et le restaurateur heureusement avait dans son camion quelques casseroles et cocottes compatibles mais pas suffisamment pour pouvoir travailler efficacement. Il fit cependant de son mieux pour ne pas que ses convives en pâtissent.

Un mois auparavant : « Ce sont des novices. Si vous réussissez à leur faire faire des crêpes, ce serait déjà très bien. »

Le jour même : « Des crêpes ??!! Mon assistant m’a pourtant parlé de Tournedos Rossini. »

Et le restaurateur fit ce qu’il put pour que les participants réalisent des Tournedos Rossini pour ne pas que leur apprentissage en pâtisse.

Un mois auparavant : « Vous aurez 5 aides en cuisine et quelqu’un sera là pour superviser la salle. »

Le jour même : « Avec les arrêts, vous savez : c’est compliqué. On a envoyé quelqu’un vous chercher les clés de la salle. Ils ont du oublier de mettre une personne d’astreinte. »

Et le restaurateur avec 3 personnes en moins et une bonne heure de retard cuisina quand même son repas car il ne fallait pas… que ses convives en pâtissent.

Un mois auparavant : « Tout est ok sur le plan logistique. A vous de jouer ! »

Le jour même : « Oui, on nous a demandé de faire une maintenance du réseau électrique ce matin. Pourquoi ? Ça pose un problème ? »

Et le restaurateur attendit que l’électricité soit rétabli avant de pouvoir cuisiner. Il y mit tout son courage malgré le temps perdu car il ne fallait définitivement pas que ses convives en pâtissent.

Le restaurateur s’en tira pas trop mal de ces différentes situations. Cela lui causa cependant beaucoup de stress, de fatigue et il perdit un temps fou à devoir recommencer tout ce qu’il avait déjà préparé. Mais le pire c’est qu’il n’était pas satisfait : cela ne correspondait pas à son objectif « qualité ».

Je ne suis pas restaurateur et je ne suis pas magicien non plus. C’est pourtant le quotidien d’un animateur numérique que je dépeins. Les enfants sont les convives et ils ne doivent jamais faire les frais des différents problèmes qui peuvent survenir. Il y a certes des problèmes techniques mais ce n’est pas le plus important. J’ai insisté x fois sur le fait d’être autonome mais c’est extrêmement fatigant de devoir en sus sans cesse improviser. Ne voyez cependant pas le mal là où il n’y en a pas. Il y a essentiellement méconnaissance de vos besoins.

Alors que fait-on ? S’assurer que tout le matériel est à disposition et que tout fonctionne avant l’atelier ne vous garantit malheureusement pas les surprises. C’est bien en amont cependant que le travail doit être fait en sensibilisant vos partenaires à la spécificité des ateliers numériques. Ce ne sont en effet pas des ateliers comme les autres qui demandent parfois une configuration particulière. Cette configuration, vous pouvez la cartographier en voyant avec eux si leurs équipements sont véritablement « numérique ready ». Conseillez-les. Définissez une grille de critères. Insistez s’il le faut. Certes, cela n’empêchera pas d’essuyer les plâtres ou d’avoir encore quelques surprises mais cela permet d’avancer et de partir ensuite sur des bases saines. Comme toujours, documenter, documenter et encore documenter…