Code academy pour la team Évolt

Susanna Kaltenbaek

Published in

évolt stories

5 min readSep 17, 2015

by Évolt

L’été c’est bien pour la plage mais aussi pour faire toutes ces choses “qu’on fera cet été, on a pas le temps là”. Et, Thiên Ân, étudiant à Epitech et développeur à Évolt, avait préparé une petite formation au développement pour toute l’équipe. L’objectif : transmettre la posture développeur !

Dès la création de la boite, nous partagions une ambition commune : mettre en valeur nos différentes approches (designers, développeurs, stratèges, etc.) en partageant le plus possible. D’où l’idée de Thiên Ân, un de nos développeurs, de faire une formation à l’ensemble de l’équipe. L’objectif n’étant pas de transmettre des compétences techniques — on ne va pas tous coder demain — mais de transmettre un regard, une façon d’appréhender les choses.

La formation

On arrive donc lundi matin. Thîen Ân nous sépare en deux groupes et on découvre la panoplie du geek :

Un Raspberry Pi. C’est un micro ordinateur.
Une breadboard. En bref, c’est un support électrique qui permet de tester des circuits sans avoir à souder, etc.
Des câbles permettant de connecter le Raspberry Pi à la Breadboard.

Pour que l’on soit immergé dans le travail d’un développeur, Thiên nous a mis sur le terrain. En bref, il fallait connecter la breadboard au Raspberry Pi pour qu’il envoie l’information d’allumer les leds. La finalité opérationelle de la formation était de créer et programmer un objet de A à Z. Chaque groupe devait créer le circuit puis programmer le rasberry Pi pour qu’il envoie au circuit des ordres à exécuter, à savoir allumer les trois leds. Nous avons donc été confrontés à toutes les difficultés que rencontre un développeur, de la recherche (en anglais, s’il vous plait) jusqu’à la programmation.

Le parcours de la mort

1.

Construire le circuit

Pour résumer de façon honnête, Thien nous a donné des tableaux ressemblant à la bataille navale et nous a littéralement abandonné avec comme consigne : trouver les bons branchements entre le Raspberry Pi et la breadboard pour allumer les leds. Les leds et l’interrupteur étaient déjà placés sur la breadboard. Je pense donc que son objectif (caché mais pas trop) était de nous obliger à rechercher par nous-même pour comprendre le fonctionnement, la logique propre au matériel. Une fois qu’on a compris comment le courant passait dans la breadboard (ok, on a du user de fines stratégies pour avoir des indices), on a réussi les branchements !

2.

Apprendre les bases du code

Pour appréhender et comprendre la logique du code, on décroche du Raspberry Pi et de la breadboard. On a eu droit à un exercice a priori à la portée de tous : faire apparaître l’alphabet sur le terminal en utilisant le langage de programmation C++ (si vous aussi, vous trouvez ça flou, petite illu !).

3.

Coder pour interagir avec le circuit

Certes, faire apparaître l’alphabet c’est super impressionnant, mais on a toujours notre RaspberryPi et notre breadboard entre les mains et pas de leds qui s’allument. On a donc codé et… la lumière fut !

4.

S’amuser un peu

Forcément, on s’est sentis pousser des ailes. Non, sérieusement, c’est assez cool de voir qu’une fois la logique comprise, c’est pas si compliqué. Du coup, on a changé l’ordre d’allumage des leds et, l’espace de deux secondes, on a presque envisagé de fabriquer et programmer nous-mêmes nos guirlandes de Noël !

Les retours

Même si le terme “formation au dév” n’a pas animé l’ensemble de l’équipe au premier abord (et que ça me coûte un peu de faire des compliments à Thiên), il faut reconnaître que sa formation a un peu mis tout le monde d’accord. Ce qui a plus à Max, notre vidéaste, c’est d’appréhender la logique du code, de voir qu’une fois la logique comprise, on peut facilement essayer des choses, jouer avec le code. Julie, designer, en garde la satisfaction de taper une ligne de code et que ça marche, que cette ligne se matérialise !

En bref, cette journée code academy a été très utile à l’équipe. Quand 10 personnes aux compétences très variées bossent ensemble, c’est pas évident d’anticiper le boulot qu’une modif va engendrer pour les autres membres d’un projet.

C’est d’autant plus fréquent dans le code où l’on veut souvent modifier un élément graphique sans penser qu’il fait parti d’un ensemble pensé d’une certaine façon. Par exemple, nous avons développé il y a quelques mois un outil dans lequel il y a un questionnaire. Pour améliorer le design, on a voulu ajouter un élément marquant le passage d’une question à l’autre. Mais le questionnaire n’avait pas été pensé comme ça en amont et le boulot était beaucoup plus important que ce que nous pensions.

Avoir une vision du code, de sa logique et de ses règles permet de gagner beaucoup de temps car même si seuls les dévs ont la réponse, on se pose les bonnes questions et on anticipe les problèmes. Donc Thiên, merci beaucoup !