Très bonne analyse de ce qu'il faut pour un véritable leadership.
Vous ne pouvez pas être responsable de quelque chose que vous ne contrôlez pas. Il faut le mandat.
Vous ne pouvez pas utiliser ce mandat efficacement pour quelque chose que vous ne comprenez pas. Vous avez besoin de connaissances.
Vous n’acquérez des connaissances que si vous êtes entièrement responsable des conséquences de votre mandat.
Un article sur l'architecture d'un RAG qui revient en détails sur les 4 composants principaux:
- data layer: ingestion des données et contrôle d'accès
- LLM layer: génération de la réponse augmentée
- reporting layer: monitoring et statistiques d'utilisation du RAG
- application layer: API et interfaces utilisateur
Un excellent article sur la manière de conduire un refactor sur le long terme.
Une alternative à l'organisation avec une Todo list
Des histoires d'ingénieurs à qui on demande de faire quelque chose d'illégal.
Moralité, si on vous demande de faire quelque chose d'illégale, documentez la demande et refusez.
Comment mesurer la répartition des connaissances au sein d'une équipe à l'aide de Skills Matrices.
Très utile pour identifier les bus factors sur lesquels une ou très peu de personnes seraient capable d'intervenir.
L'article donne une méthode pour créer cette liste de connaissances.
Les résultats d'un programme de recherche basé sur les DORA métriques pour évaluer les méthodes de travail ayant le plus d'impact.
-
les équipes qui se concentrent sur l'utilisateur ont de meilleures performances organisationnelles
-
une documentation de qualité amplifie l'impact des autres méthodes (~x2 en moyenne!)
Pour les pratique de développement pures:
- intégration continue
- vitesse des revues de code
- architecture découplée
- trunk based development
Récapitulatif sur les métriques possibles dans une équipe de développeurs.
DORA, un framework axé sur la qualité des processus de développement et du code:
- Lead Time for Change: combien de temps entre une idée de feature et son déploiement
- Deployment Frequency
- Change Failure Rate: % de code déployé qui cause des bugs dans le système
- Mean Time to Recovery: combien de temps pour fixer un bug
SPACE, un framework plus global sur la performance au sein d'une équipe:
- Satisfaction & Well Being: état mentale au sein de l'équipe pendant le travail
- Performance: observation de la vélocité de l'équipe
- Activity: observation de la quantité de travail réalisé
- Communication & Collaboration: qualité des interactions au sein de l'équipe
- Efficiency & Flow: qualité de l'organisation du temps de l'équipe
DevEx, un framework qui se concentre sur l'expérience des développeurs:
- Feedback Loops: processus et temps nécessaire à prendre en compte les retours
- Cognitive Load: qualité et taille de la codebase
- Flow State: organisation du temps de développement
Un article qui parle du chemin de carrière technique (vs le chemin managérial de l'engineering manager par exemple)
Les rôles de staff engineer sont des rôles de spécialistes technique avec une forte composante de leadership et de mentoring.
Ils doivent se concentrer sur les résultats des projets qu'ils prennent en main et sont plus pro-actifs que les développeurs senior.
Une liste de conseils pour CTO
Un article qui détaille les autres types d'approche que la classique pyramide unit - integration - e2e pour le testing
Une application de partage collaborative de lien.
Parfait pour faire de la veille technologique en équipe par exemple.
Une excellente pratique qui oblige à baser toute réunion sur un document.
La réunion commence par une revue du document afin d'être sur que tout le monde l'ait compris.
Les commentaires sont traités pendant la réunion mais aussi ensuite en async.
Un article sur la loi de Conway qui théorise un lien fort entre la structure d'un système (software par exemple) et la structure des moyen de communication de ceux qui le conçoive.
Une liste des niveaux d'ingénieurs dans plusieurs boites.
Un article sur les bonnes pratiques autour de la code review.
C'est souvent une part importante dans le Time To Deploy d'une équipe et l'auteur donne des conseils pour accèlérer ce processus:
- garder les PRs petites: <200 lignes de code
- faire les reviews rapidement: mettre un place un outil de notification aide beaucoup sur ce point
- automatiser le maximum: tests, lint
- utiliser des stacked diffs pour découper plus facilement une PR (pas dispo sur Github malheureusement)
- utiliser la méthode Ship/Show/Ask qui permet d'éviter la nécessité de reviews dans certaines situations
Plus j'entends parler du Stacked Diff/Trunk Based développement et plus ça donne envie d'essayer. Graphite semble proposer ce genre de fonctionnement et intègre Github
Un autre article qui parle de rejoindre une startup en early stage mais du point de vu concret d'un développeur et de ce qu'on peut apporter.
C'est aussi un bon résumé de comment arriver à un MVP
Un retour d'expérience sur comment organiser son process de recrutement.
Les conseils en plus de Fabien Ducher:
En amont
- l'organisation de la tech est suffisamment claire
- on est à l'aise sur la salary grid (qu'elle soit affichée publiquement ou non)
- on est sur d'avoir les ressources pour accompagner l'onboarding et rampup
- Les personnes qui font passer des entretiens sont formées à le faire (posture, ce qui est ok ou pas ok de dire, comment on le mène, les entretiens eux même, etc.)
- Checklist d'onboarding avec toutes les composantes (RH, IT, manager, newcomer) déjà existante.
L'offre
- inclusive! exemple: pas un empilement de compétences (soft et hard), mais un message clair sur le fait que c'est un repère et qu'il ne faut pas cocher toutes les cases pour candidater
- La description du process : les entretiens, avec qui, la durée et à quoi ils servent
Le process de validation
- s'il y a des tests / questions techniques, ce sont les mêmes pour tout le monde et on assess les résultats
- On liste à l'avance les red flag qu'on ne veut pas voir
- Max 2 semaines entre la prise de contact et la décision
- J'aimerai beaucoup tester aussi l'idée que la personne qui candidate vient avec un cas technique qu'elle discute avec des personnes de l'art. (ca brise le test commun à tous, mais c'est au moins un contexte que le candidat maitrise et qui sera moins stressant)
- Feedback clair et factuel après chaque entretien, surtout en cas de nogo à une étape
- Lors du dernier entretien, on est en situation d'échange libre où on répond à toutes les questions de la personne qui candidate, on ré-explique l'onboarding, le carreer path, la période d'essai, les attentes, etc.
- un comité d'évaluation à la fin avec toutes les personnes ayant réalisé un entretien
La proposition
- Salaire en comparant avec la grille, les stats de salaire à poste équivalent en interne (incluant l'équité homme / femme) et des bench extérieur (à noter ici que Figures est canon comme outil)
l'onboarding
- Welcome 1-1 où on présente la checklist d'onboarding, on cale les 1-1 hebdo,
- On présente les obj de PE la première semaine
- On s'assure que l'équipe l'accueil bien dans le day to day
Période d'essai
- on fait des 360 pour avoir le max d'avis et pas uniquement l'avis du manager
- On refait a minima un point à mi PE, voir tous les mois avec le newcomer
- Ou on coupe ou on valide, le renouvellement ne sert que pour des doutes mineurs qui n'auraient pas pu être levé dans le délai. Avoir une boule noire nuira à terme plus à votre organisation que n'avoir personne.
Très bon conseil pour booster une carrière.
Il est important de rester curieux et de s'intéresser aux autres métiers de la tech (product, management, marketing, sales), c'est ce qui permet d'avoir une meilleure compréhension de l'ensemble d'une entreprise et d'améliorer la qualité de ses contributions.
Les personnes ayant été à des rôles de manager et d'individual contributor sont très souvent plus ouvertes car elles connaissent les deux côtés de la barrière.
Un très bon article de l'équipe tech de Malt sur l'observabilité code/équipe en utilisant Git.
Cela permet d'identifier:
- les dépendances entre services
- les "hot spots" fréquemment édités
- les personnes ayant la meilleur connaissance de portions du code