Mon plan pour aider les juniors à trouver un emploi
Comment la Craft Academy va propulser les développeurs web juniors dans le monde du travail.
Trouver un emploi à la sortie d’une formation accélérée type Bootcamp est difficile. Très difficile. Il faut souvent de longs mois avant de trouver un poste, et parfois un poste qui n’est pas à la hauteur des espérances.
Avant de lire la suite, si tu as 2 minutes à m’accorder, j’ai besoin de ton avis ! https://sein140equx.typeform.com/to/X6fcWRJ6
Pourquoi tant de difficultés ?
entre 30k et 50k personnes se reconvertissent chaque année dans le développement web en France
les entreprises sont de plus en plus frileuses à recruter des profils sans expérience
le niveau technique demandé est plus élevé qu’il y a ne serait-ce que 2 ou 3 ans
Le métier de développeur web génère beaucoup de fantasmes. C’est le métier le plus recherché en 2018 par les recruteurs. Beaucoup de gens y voient donc une opportunité pérenne de reconversion professionnelle.
C’est donc le parcours du combattant pour les développeurs juniors pour se démarquer, être à la hauteur des attentes, etc.
Comment se démarquer pour trouver un emploi
Il n’y a de secret, pour se démarquer il faut travailler. Beaucoup, beaucoup travailler. Les bootcamps ont l’avantage indéniable de mettre rapidement le pied à l’étrier, en formant souvent sur une seule techno précise (react par exemple).
Cibler ses connaissances sur une seule technologie est une bonne stratégie pour s’insérer plus facilement dans le milieu du travail. Mais ce n’est pas suffisant.
Il faut absolument continuer de se former à la sortie du bootcamp !
Mais devant l’ampleur des choses à apprendre, un junior se sent très vite découragé : “Comment est-ce que je vais apprendre tout ça ? Par où commencer ?”. Cette question génère du stress, voire de l’anxiété, et finalement éteint complètement toute velléité d’apprentissage.
Apprendre intelligemment avec la loi de Pareto et la connaissance en forme de “T”
Pour avancer dans la bonne direction, il faut un plan. Un développeur junior fraîchement sorti de son bootcamp aura à cœur de trouver rapidement un travail pour rembourser les frais de sa formation. Il est donc pressé par le temps, et c’est là que le plan devient indispensable.
La loi de Pareto
“Le principe de Pareto, aussi appelé loi de Pareto, principe des 80-20 ou encore loi des 80-20, est un phénomène empirique constaté dans certains domaines : environ 80 % des effets sont le produit de 20 % des causes.” - Wikipédia
Appliqué à l’apprentissage, ce principe stipule donc que pour comprendre 80% d’un sujet, en apprendre les 20% les plus fondamentaux est suffisant.
Qu’est-ce que cela signifie pour un junior ?
Tout simplement qu’il est important de creuser un sujet non pas en détails, mais avec intelligence. Comprendre les points cruciaux, essentiels. Les 80% restants seront tous les détails, les exceptions, les cas complexes, etc.
Connaître les grands principes du fonctionnement d’internet sera par exemple suffisant pour comprendre et tenir une conversation sur le sujet dans 80% des cas. Et surtout, cela nous permet de savoir qu’on ne sait pas quelque chose, et donc de pouvoir rechercher précisément le savoir qu’il nous manque, au moment voulu.
Ce principe a toutefois besoin d’un cadre dans lequel évolué quand il s’agit d’apprentissage. Et c’est là qu’intervient la notion de “connaissance en forme de T”.
La connaissance en forme de “T”
“Le concept de connaissance en forme de T est une métaphore qui décrit les compétences d’une personne à travers la forme de la lettre T. La barre verticale du T représente une spécialisation dans un domaine précis, alors que la barre horizontale représente un ensemble de connaissances générales sur des domaines précis qui permettront de collaborer dans ces disciplines avec des experts du sujet.” - Wikipédia
Ce concept est LA CLÉ pour n’importe quel développeur, et particulièrement pour un développeur junior.
Il stipule qu’il est important d’être spécialisée dans un domaine, mais de ne pas négliger pour autant les autres disciplines importantes du métier. Ce sont vraiment ces autres disciplines qui vont faire la différence au sein d’une équipe de sénior et/ou d’expert, car elles vont vous permettre de comprendre beaucoup mieux les problématiques rencontrées, voire de pouvoir proposer des solutions (même si vous n’êtes pas capable de les implémenter).
Avoir cette connaissance multiple vous démarque totalement des autres profils juniors.
Et la bonne nouvelle, c’est qu’en la combinant avec la loi de Pareto, vous comprenez qu’il n’est pas nécessaire (ni souhaitable) de devenir expert dans tous ces domaines !
Tout ce qu’il vous manque maintenant, c’est un plan d’apprentissage, et c’est là que j’interviens avec la Craft Academy
La Craft Academy : former les juniors aux bonnes pratiques du développement web pour se démarquer, obtenir un poste épanouissant et rémunérateur.
Mon objectif avec la Craft Academy est donc d’accompagner le plus de juniors possible dans leur parcours d’apprentissage post reconversion (ou post école).
La barre verticale du T, les bootcamps s’en sont normalement chargés (en spécialisant sur une techno particulière comme React). Bien sûr que vous n’êtes pas expert pour autant, mais disons que c’est là où vous êtes le plus “opérationnel”.
Mon rôle à moi est de m’occuper de la barre horizontale. De vous apprendre les bonnes pratiques du développement web de manière générale, pour couvrir globalement les notions principales que vous serez amenés à rencontrer en entreprise.
L’objectif de ces cours est de permettre aux étudiants de créer un produit de A à Z en fil rouge tout au long de la formation, afin de présenter sur leur portfolio un projet cohérent, suivant les bonnes pratiques de développement.
Voici le plan d’apprentissage que j’ai en tête. Il est possible qu’il change à mesure que j’obtiens des retours quant à ma pédagogie, mais ce sont du moins les grandes lignes :
1 - Le Clean Code
Notion fondamentale pour écrire un code propre, modulable, et qui sera facilement compréhensible et maintenable par vos collègues (et par vous-même d’ici quelques mois en revenant sur votre propre code).
On y voit entre autre :
L’importance du nommage et du style de code
L’intérêt des fonctions pures, de l’immuabilité et de l’encapsulation
La différence entre un code déclaratif et impératif
Différents principes fondateurs comme le SRP, CQS, DRY, YAGNI, KISS et j’en passe
Comprendre quand il est pertinent d’écrire un commentaire et quand c’est à éviter
Les principes SOLID
Comment refactorer son code au quotidien en appliquant tous les principes vus précédemment
2 - La compréhension du domaine métier et de ses besoins
Beaucoup de développeurs souhaitent se ruer sur le code quand un projet démarre. On parle donc très vite de choix techniques, quelle base de données, quel framework, etc.
“Ce qui est déployé en production est ce que l’utilisateur (n’)a (pas) compris des spécifications.” - Alberto Brandolini
Comprendre le besoin métier est primordial pour un développeur. Il est extrêmement important de comprendre le domaine dans lequel évolue le projet.
Pour ce faire, voici ce que je propose :
Comprendre les besoins métiers grâce au Domain Storytelling
Comprendre les besoins métiers grâce à l’EventStorming
Transformer les besoins en User Stories grâce au Story Mapping
Établir des règles et critères d’acceptations clairs grâce à l’Example Mapping
3 - Les tests automatisés
Toute application professionnelle se doit d’être testée de façon automatisée. C’est-à-dire par des tests exécutés automatiquement et régulièrement afin de s’assurer que l’application répond aux spécifications et ainsi éviter les bugs et les régressions.
J’y aborde :
Les définitions (controversées) des différents types de test automatisé
La pyramide des tests
Qu’est-ce qu’un bon test unitaire ?
Comment écrire un bon test unitaire ?
Qu’est-ce qu’un test fragile ?
Le compromis permanent entre DRY et DAMP
Des tests maintenables grâce au pattern builder
Les différents types de mock et quand les utiliser
Le test coverage
Les tests d’intégration avec Test Containers
Les tests end-to-end
4 - Test Driven Development (TDD)
Pratique qui nourrit beaucoup de fantasmes, mais souvent mal comprise, j’aborderai donc dans ce cours :
La définition du TDD
Différence entre TDD, test first et test after
ATDD, BDD, TDD, quelles différences ?
Les erreurs et incompréhensions courantes qui freinent l’adoption du TDD
L’importance du feedback permanent
Le cycle Think - Red - Green - Refactor
L’importance des “baby steps”
Changer de vitesse : TDD “shift gear down”
Les Katas pour s’entrainer
Le TDD dans la vraie vie au sein d’un vrai projet
5 - L’Architecture Hexagonale
L’architecture hexagonale est partout aujourd’hui, mais finalement elle n’est que l’expression des bonnes pratiques de développement, au niveau architecture logicielle :
Qu’est-ce qu’une bonne architecture ?
Clean architecture, Onion architecture, architecture hexagonale : trois noms pour les mêmes principes
La couche Domain : là où doit résider la logique métier
La couche Application : le point d’entrée de notre application
La couche infrastructure, les Driven Adapters : ce qui va être appelé par notre couche applicative, la persistence en base de données par exemple
La couche infrastructure, les Driving Adapters : ce qui va appeler notre couche applicative, ce qui “contrôle” notre application
Transaction Script
TDD et Architecture Hexagonale
Introduction à CQRS et à l’event sourcing
6 - Domain Driven Design
Très en vogue depuis quelques années, le Domain Driven Design (DDD) est un cadre de travail qui combine les pratiques vues précédemment dans l’objectif de créer un code maintenable, évolutif, qui répond au besoin du client, avec une connaissance du domaine métier partagée par tous :
Naissance et définition du DDD
Différence entre “problem space” et “solution space”
Bounded Contexts, Context Mapping
Entity et Value Object
Aggregates : à quoi servent-ils et comment les déterminer
Domain Events
Le principe CQS appliqué à la couche applicative : Use Case d’écriture VS Use Case de lecture
7 - Architecture Hexagonale et TDD dans le frontend
Le frontend est de plus en plus complexe. Beaucoup de logique métier y est maintenant déporté et en ce sens on se doit de tester rigoureusement notre application.
Mais les tests frontend sont pénibles à écrire et maintenir, il faut tester à travers les composants (React par exemple), et fragiles, car dès qu’un composant est modifié alors le test va casser…
L’intérêt de l’Architecture Hexagonale côté frontend est de justement séparer notre logique métier des composants en eux-mêmes, et ce afin de pouvoir tester notre application sans contrainte liée à l’UI, et se faire guider par le TDD.
Voici comment :
Qu’est-ce que la logique métier côté frontend ?
Use case et View Models
Des composants “humbles” : le Humble Object Pattern
TDD avec Redux Toolkit
Pas envie de Redux ? TDD en React avec les hooks et les contexts
Dans quel cas et comment tester un composant ?
L’importance des tests end-to-end avec Cypress
Ce plan de cours n’est pas exhaustive, elle est amenée à évoluer, mais elle donne une bonne indication sur ce que je souhaite transmettre. Je m’adresse ici aux 20% de chacun de ses sujets qui vont feront comprendre 80% des problématiques que vous rencontrerez ! Je n’ai pas la prétention de tout connaître, j’apprends en permanence moi aussi :)
Happy Coding et à bientôt sur la Craft Academy !