Blog technique Wizaplace

La checklist des nouveaux arrivants

Par Matthieu le 29 March 2017

Wizaplace est en pleine phase de recrutement et cela implique d’accueillir les nouveaux arrivants dans les meilleures conditions.

Pour cela voici la checklist en 10 étapes que nous distribuons à nos collègues lors de leur premier jour au sein de l’entreprise :

  1. lire la documentation existante
  2. installer son environnement de développement
  3. jouer les tests
  4. découvrir le code
  5. découvrir l’infra et la production
  6. découvrir le fonctionnel
  7. faire une code review
  8. améliorer un truc technique
  9. améliorer un truc fonctionnel
  10. déployer en production

Nous conseillons généralement au nouvel arrivant de prendre la première semaine pour réaliser toutes ces actions.

Cela est cependant très variable, certaines personnes vont plutôt finir la checklist le plus vite possible pour prendre des “vrais” tickets et travailler sur des features. D’autres vont prendre cette semaine pour bien observer les pratiques, explorer le code et comprendre l’architecture plus en détail. Les deux sont possibles et la checklist aide simplement à fournir une première direction.

Lire la documentation existante

RTFM, c’est la base. Cette première étape permet également au nouvel arrivant de s’installer tranquillement à son bureau et de se plonger doucement dans cette nouvelle folle aventure.

Installer son environnement de développement

Les instructions pour installer le projet sont dans le README. Et ces instructions tiennent en fait en une ligne :

make dev-from-scratch

Avec une ligne de commande, le projet s’installe et est prêt à être utilisé en quelques minutes. Au delà du projet, il y a de nombreux autres outils à installer et nous avons tous nos claviers/terminaux/éditeurs/raccourcis claviers/… persos, cette étape prend le temps qu’il faut :)

Jouer les tests

Les tests sont importants et cette checklist n’y coupe pas. Les tests doivent passer en local, sans ça le développement est impossible.

Découvrir le code

GO ! C’est le moment de plonger dans le code, de poser toutes les questions nécessaires autour de soi (en général on préfère les questions sur Slack pour éviter d’interrompre les collègues, mais la 1ère semaine confère des pouvoirs spéciaux, et c’est plus sympa de discuter avec les nouvelles têtes).

C’est aussi le moment pour poser les questions génantes : “Pourquoi vous utilisez pas la lib X plutôt ?”, “Pourquoi y’a 2 moteurs de template différents ?”, “Pourquoi ces fichiers ne sont pas PSR-2 ?”… Ça fait du bien là ou ça fait mal, le regard frais d’un nouvel arrivant permet de challenger les vieux hacks qui trainent depuis trop longtemps, et quand on a la tête dans le guidon c’est nécessaire. Certaines de ces remarques finissent d’ailleurs parfois par une petite pull request dans la première semaine, pull request qu’on pensait impossible ou qu’on avait pas le temps de faire.

Découvrir l’infra et la production

Le code c’est cool, mais il faut que ça tourne en production, et qu’on soit dev frontend ou backend il est impossible d’ignorer cette composante. Pour ce point nous prévoyons une introduction de quelques heures avec un collègue (Guillaume par exemple), tableau blanc à l’appui parce que sinon ça fait beaucoup moins sérieux.

Découvrir le fonctionnel

Le monde des marketplaces et de l’e-commerce n’est pas simple, une introduction en bonne et due forme n’est pas de trop. Nous prenons donc quelques heures avec un collègue pour découvrir le back-office, les concepts et les features phares de notre produit ainsi que les marketplaces de nos clients qui sont en production.

Il y a aussi ce moment génant où on explique la différence entre les attributs de produit, les options de produit, les variantes d’attributs, les variantes d’options et les déclinaisons : génial !

Faire une code review

La code review est un élément important dans notre workflow, mais tous les développeurs n’ont pas nécessairement l’habitude de travailler avec. C’est pourquoi elle est explicitement mentionnée dans la checklist : cela force à passer le cap, et cela montre qu’elle n’est pas optionnelle.

La code review permet de trouver des bugs et de pousser à améliorer le code de tout le monde, mais elle sert aussi à apprendre et à comprendre ce qui se passe sur le projet. Nous accompagnons généralement cette étape de conseils pour faire une code review utile et constructive (futur article sur le blog).

Améliorer un truc technique

Ce point est volontairement vague : nous n’attendons pas de miracle d’un nouveau venu, nous voulons surtout l’encourager à s’approprier le projet. La première pull request peut être une typo dans un commentaire, un ajout de raccourci git super utile ou une optimisation de perfs, c’est génial.

Améliorer un truc fonctionnel

Cette étape est clairement la plus difficile. Encore une fois nous voulons placer la barre très bas, mais tout comme pour le code, nous voulons encourager à s’approprier le projet et le côté métier.

Nous utilisons un label Simple dans notre tableau Kanban qui permet de mettre en avant les tâches les plus faciles : un ajout de warning quand un formulaire est mal soumis, une traduction à corriger, une documentation d’API pas tout à fait à jour, etc.

Le pair programming est d’ailleurs fortement encouragé.

Déployer en production

L’objectif est que toute personne dans l’équipe puisse déployer en production, il est donc normal de passer par cette étape. C’est l’occasion de bien comprendre le processus de déploiement et d’avoir une vision complète du cycle de vie d’une tâche sur notre board, de la colonne “TODO” à “Terminée”.

Conclusion

Cette liste nous est très utile, mais elle n’est pas parfaite. À chaque nouvel arrivant nous essayons de l’améliorer. Partagez avec nous votre checklist sur Twitter ça nous intéresse !