Une liste de Slack communautaires sur pleins de sujets!
Comment être efficace à un poste de top management "Head of ..."
Globalement l'article se présente sous la forme d'une grande liste, pour moi les points les plus importants:
- créer un lien de confiance avec son équipe: discuter et déléguer pour faire émerger d'autres leaders
- évolution de carrière: définir clairement les potentielles évolutions de carrière avec les attentes et salaires pour chaque poste
- impliquation dans l'équipe dirigeante pour comprendre la stratégie de l'entreprise
- développer son réseau pour échanger avec d'autres tech leaders
- recrutement
- software delivery
- veille technologique
Un excellent article sur le management!
En tant que manager, on est responsable du management des processus tandis qu'on donne laisse libre les personnes dans leur travail (éviter le micro-management)
Pour lui les processus sont des attentes que l'ont rend explicites.
Par exemple, le processus de code review est une attente d'un code de qualité.
Il parle de beaucoup d'autres sujets intéressants:
- décision vs opinions: tout le monde à un opinion, le manager doit asseoir une décision
- ownership: essentiel de permettre aux gens de s'approprier leurs sujets
- confiance
- se séparer de quelqu'un
- et d'autres..
As a manager, everything is your fault.
You are in charge of processes and people.
You either created the processes where this outcome happened
or you hired (or did not fire) the wrong people.
Un article sur les métriques dans une équipe tech.
C'est quelque chose dont on peut se passer lorsque l'équipe est encore petite (<20 personnes) mais qui devient indispensable par la suite afin de comprendre le coût d'un effort et si il est réellement nécessaire.
Par exemple, ça permet de planifier (ou non) des chantier de refactoring de code ou de scaling infra.
Il y a plusieurs niveaux de maturité (Data Maturity Level):
- 0 Unaware: aucune collecte et utilisation de la donnée
- 1 Aware: certaines données sont collectées mais pas vraiment de responsable pour les surveiller
- 2 Reactive: présence de KPI produit, adoption légère
- 3 Proactive: présence de responsable sur les outils de collecte
- 4 Managed: la donnée est considérée comme critique pour l'entreprise et est communiquée au plus haut niveau
- 5 Effective: la donnée est publiée et utilisée à l'extérieur de l'entreprise
Excellent article sur le problème de la complexité qui est très souvent ce qui ralentit l'innovation autant au niveau technique que produit.
Un article intéressant sur les avantages de Deno.
Il y a de nombreux avantages en DX, notamment le support Typescript directement par Deno mais surtout je découvre un avantage non négligeable en terme de sécurité de la supply chain.
Les scripts (comme les entrées de scripts dans le package.json en Node.js) de Deno sont lancés dans un shell isolé spécial (deno_task_shell) et n'ont accès qu'a leur input, ce qui les empêche d'aller farfouiller sur le système (ce genre de truc https://arstechnica.com/information-technology/2022/03/sabotage-code-added-to-popular-npm-package-wiped-files-in-russia-and-belarus/)
L'approche des dépendances via URL est aussi intéressante, on est capable de charger du code depuis une URL tout en respectant des versions, des checksum, etc.
Un autre article clean-archi / archi hexagonale.
Celui la met l'accent sur les problèmes des architectures classiques ou le métier est "mélangé" avec les couches d'API et de persistence et sur la solution de cloisonnement qu'apporte l'architecture hexagonale.*
Les principes les plus importants:
- le domaine ne dépend que de lui même
- pas de framework dans le domaine
- inversion de contrôle via notamment l'injection de dépendances
- commencer par le domaine (et les tests associés!)
Une explication de l'architecture hexagonale avec un exemple simple de catalogue de produit en Typescript.
Une checklist orienté sécurité d'un produit en mode SaaS.
La liste est découpée en périmètre métier (code, infrastructures, employés) mais aussi en maturité de la société (seed, série A, série B)
Un article sur une bonne gestion de la dette technique.
J'aime notamment la règle qui impose de créer une issue tagué tech-debt à chaque PR introduisant de la dette technique.
Un outil de gestion de projet pour remplacer Jira qui semble toujours être le choix le plus populaire malgrés les boutons qu'il donne à ses utilisateurs.
L'UI est top, pleins de raccourcis clavier, des automatismes sympa (issue non finie directement au cycle suivant, status en fonction des PRs, etc)
À tester si vous cherchez quelque chose de neuf!
Les deadlines sont très souvent contre productive et particulièrement en programmation.
Elles rajoutent beaucoup de stress et contribuent souvent à dégrader la qualité de ce qui est produit ou à une augmentation des heures de travail.
J'aime beaucoup ce qui dit l'auteur à propos des choix qui s'offrent à nous quand on a raté une deadline:
- décider d'une autre deadline
- virer quelqu'un
- réduire le scope
Sous le coude
SPACE est un framework pour mesurer l'efficacité d'une équipe d'ingénieurs.
Il est découpé en 5 catégories qui doivent chacunes être évaluées avec différentes métriques:
- Satisfaction: rétention, satisfaction des développeurs
- Performance: vélocité code review, story point livrés, uptime
- Activity: lignes de codes, commits, fréquence déploiements
- Communication & Collaboration: time to merge, qualité des réunions, partage de la connaissance
- Efficiency: timing code reviews, nombre d'interruptions
Bien sur il n'est pas nécessaire de récolter des métriques pour chaques catégories et certaines métriques peuvent avoir moins de sens dans certaines équipes mais ça donne déjà de solides bases pour évoluer la performance d'une équipe.
Un retour d'expérience sur l'utilisation de Rust plutôt qu'un autre langage dans une startup qui développe un produit de type SaaS.
Sans surprise, c'est moins efficace de développer un SaaS en Rust qu'en Node.js ou en Python.
L'auteur met en avant les points qui freinent le développement de sa startup:
- la courbe d'apprentissage très longue de Rust
- le modèle de mémoire (borrowing) qui ralentit le développement et empêche de faire des "brouillons"
- la difficulté de trouver des développeurs
- la documentation et les lib qui manque de maturité
La moralité: don't jump over the hype train et surtout il faut utiliser les techno pour les usages ou elles ont du sens.
Explications sur le modèle de données utilisé par Notion en interne.
Tout repose sur un système de blocs organisés en arbre hiérarchique ou chaque bloc possède un type qui va définir la manière dont il est affiché par l'interface web.
Côté optimisations de leurs applications clientes, les modifications sont faites d'abord dans une DB locale (SQLite ou IndexedDB) puis synchronisées sur les serveurs de Notion.
Un article qui explique pas à pas le fonctionnement d'une base de données relationnelle.
Il utilise l'algèbre relationnel pour décrire chaque opération.
Dans une DB relationnelle, chaque ligne peut-être considérée comme un vecteur à N dimensions (les dimensions sont les colonnes).
"Adrien", 29, "Minsk" est un vecteur à 3 dimension (nom, age, ville) qui représente une personne.
A partir du la on peut dérouler toutes les opérations comme la projection (SELECT), la selection (WHERE), le produit vectoriel (JOIN)
L'histoire d'une grosse migration backend chez LinkedIn et un retour d'expérience très intéressant.
Les sujets de migration sont toujours très sensibles car ils ont un impact fort et sont sujets à de nombreux risques.
L'équipe de LinkedIn donne quelques conseils:
- s'assurer que tout le monde comprenne l'intérêt de la migration et du nouveau système
- écrire des instructions étape par étape clair et précises
- faire des outils automatiques dès que c'est possible
- faciliter un accès au support pour répondre aux questions
- monitorer les progrès
Quand on est manager et/ou expérimenté , il est important de faire attention à ne pas prendre trop de place afin de laisser les autres s'exprimer.
Cet article parle justement de la dynamique des pouvoirs et donne 5 conseils:
- soyez le dernier à contribuer
- invitez explicitement les autres à contribuer
- soyez plus sûr de vous dans vos paroles et dans vos actions
- créez de la confiance avec chacun
- déléguez explicitement le pouvoir de décision
(Merci Ludi pour le partage)
Un thread Twitter sur une gestion avec SCRUM qui a complètement débloqué