Sujet: Forum Ouvert
Meetup: Chttps://www.meetup.com/Software-Craftsmanship-Lyon/events/281690773/4546/
4 personnes

Forum ouvert

Questions subsidiaires
- Vous sentez-vous éloignés des autres développeurs de part votre pratique du craft, de la compréhension des paternes, de l’approche fonctionnelle qui ne semble pas la norme dans le secteur ?

Session 1 19h20 - 19h40 : Créer un bon processus de recrutement

Porteur : Gautier
Contexte
- Recherche une personne autonome
- Pas d’intérêt de trouver quelqu’un qui colle 100% au profil (éviter la checklist de compétences)
- Pas bons avis sur un process de recrutement
Objectifs du recruteur vs recruté
Exercices en pair
Exercices techniques
Préparations : https://www.amazon.fr/Cracking-Coding-Interview-6th-Programming/dp/0984782850
Le performances varies d’un jour à l’autre
Exercice hors du secteur, très théorique => peu intéressant à mon sens, hors sujet, tester un poisson à grimper un arbre
Plus à l’aise dans une discussion technique + exo classique
Discussion sur le code (code clinic + présentation)
Intéressant quand le code est celui de l’entreprise : moins de stress pour le candidat, moins de pression pour le critiquer => peut poser des biais si on voit pas le code du candidat (d’un point de vue critique du code)
Entretien technique avec tests unitaires codés, et signatures à remplir -> pas efficace parce que le design est pensé par les auteurs de l’exercice (+steps trop grosses parfois)
https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
Difficile parfois de se détacher du code quand les critiques sont fortes
Youtube

Porteur : Anthony
Du mal à ressentir quand on fait du fonctionnel ou de l’objet
C# -> F# => découverte du fonctionnel par l’incitation du langage
Important : code immuable
Ne pas se poser la question mais plutôt modéliser de manière naturelle (parfois fonctionnel, parfois objet)
Quand on pense SOLID, on est proche du fonctionnel
Apprentissage de langages au pif => Haskell => Formation => Paradigme fonctionnel
Enseignement => questions des étudiants + explications => simplifications de ce qu’est le fonctionnel
Code produit en fonctionnel => curée de vie très courte => facilement refactorable => design simple + typé
Concepts mathématiques derrière le fonctionnel peuvent avoir un jargon qui fait peur quand il est exprimé
Category Theory For Programmers : https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/
À l’école on apprend généralement l’objet et pas l’approche fonctionnelle => volonté d’avoir le même niveau sur le fonctionnel vs l’objet
Systèmes de types très pertinents avec les langages fonctionnels

Porteur : Romain
Opposition PR/pair prog ?
Parallèle entre egoless et la “violence” des PR/MR, aussi vrai pour le pair programming, aussi lié à la personnalité
Feedback MR/PR
Revues comme moyen de
Controller les contributions
Faire le gatekeeper
Partager le savoir (avoir la discussion à chaud plutôt qu’à posterio, quand je contexte est loin)
- Possibilité de relir à posteriori
- Alternative au Peer review : test && commit || revert (Facebook)
- Pas besoin de revues ?
  - Petits changesets
  - Reformatting
  - Refactoring

Scrum force à faire des estimations
Les estimations crée des attentes
Faire de meilleurs estimations : Youtube
Faire des sacrifices sur la qualités peut faire des accelérations temporaires, au prix d’une dette technique
Scrum permet de ritualiser les démos/priorisation
triptyque temps - budget - qualité ?
Dette technique : https://www.youtube.com/watch?v=R8QYVZIVSBE

unconf