DevWorld Conference
J’ai eu la chance d’être invité par un ami (merci !) à la DevWorld Conference. Il s’agit d’une conférence de développeurs qui a lieu annuellement à Amsterdam. Les sujets qui y sont abordés sont généralistes, allant des sujets Frontend, Backend, Devops, “Engineering management” sans oublier l’incontournable IA.
Sur le chemin du retour, comme à mon habitude, j’ai pris le temps de mettre au propre mes notes pour que vous puissiez vous faire une idée de l’événement.
Déroulement
La conférence a lieu au RAI Amsterdam, le centre de conférence proche du centre. Pour vous donner une idée de comment c’est organisé : il y a un grand hall, divisé en une scène principale (mainstage) et quatre scènes plus petites dans un grand espace au milieu des sponsors.
Évidemment, pour pouvoir entendre les conférences dans les plus petits espaces (les “Duck Stage”), des casques audios connectés en radio au micro du speaker sont mis à disposition. Dans le principe, “ça marche”. Dans la pratique, quand il n’y a plus de place, il n’y a plus de place… Vous ne pourrez que lire les slides et n’entendrez pas le speaker. J’ai “loupé” plusieurs talks à cause de ça.
Une fois n’est pas coutume : je ne vais pas lister tous les talks que j’ai vu. En effet, j’en ai vu BEAUCOUP, car quasiment tous les talks avaient une durée de 25 minutes, avec 5 minutes de battement entre chaque talk.
How good of a developer are you?
La première session que je suis allé voir. Dans ce talk Roy Wasse nous a parlé des différentes méthodes que nous mettons en place dans les processus de recrutement pour “juger” de la compétence d’un développeur.
La plupart de ces méthodes sont peu efficaces, et ce n’est pas Roy qui le dit, c’est la science. En effet, pour la plupart des méthodes couramment utilisées pour “tester” et classer les candidats par niveau de technicité (et ainsi choisir le/la meilleur⋅e), des papiers de recherches scientifiques montrent que c’est peu corrélé à un niveau de compétence réel.
Que ce soit le fameux l33tcode / renverser un binary tree, l’interro sur tableau blanc (qui met beaucoup de pression et qui n’est pas représentatif du travail sur IDE), des critères comme le CV, les références, les certifications ou même le niveau d’étude (qui a un impact positif lors des premières années uniquement), tout y est passé.
Si intuitivement ces conclusions ne vous surprendront peut-être pas (on connaît tous des gens talentueux qui ne sont pas ingés, n’ont que peu d’expérience et ne savent pas inverser un arbre binaire au tableau), ce talk donne pas mal à réfléchir sur notre industrie et les parcours de recrutement en 7 étapes ou plus (coucou les GAFAM), qui sont très certainement conscients que ces recherches existent, mais les ignorent quand même.
A la toute fin, Roy donne une autre manière de tester les développeurs sur différents types de taches, via un framework a priori plus pertinent et “scientifique” pour “tester”. Ça parait un peu trop beau pour être vrai, et c’est aussi assez cher…
Climbing the product management career ladder
Ce talk de Nicole Van Alphen m’a beaucoup plu.
Ayant commencé comme réceptionniste, Nicole (aujourd’hui Director of Product chez Vinted Go) détaille son parcours dans le product management, ce qui lui a permis d’y réussir et les différents attendus dans les différents postes.
Ce talk m’a permis d’avoir une meilleure vision du monde du produit, dont j’avais une vague idée, mais sans plus.
Évidemment, un must est de comprendre le “langage” des gens avec qui lesquels on travaille, autant du côté business (ex. connaitre le langage du retail si on travaille dedans) que du côté de la technique (comprendre le minimum pour être capable de saisir les difficultés rencontrées par les équipes techniques).
En y réfléchissant bien, les fois où j’ai travaillé avec des Product Managers talentueux/talentueuses ont toujours été les fois où je sentais que, sans comprendre la totalité de mon métier, iels étaient capables d’appréhender les concepts principaux de mon quotidien.
Nicole a terminé sur un message d’encouragement envers nous même, qui sommes parfois trop exigeants :
Be kind to yourself. Even those that you consider as “technical gods” sometime doubt themselves and wonder what they are doing there" “If you are where you are, you are probably at your place, and probably being good at it”
De Nederlandse Kubernetes Podcast
Un petit peu par hasard, en m’assaillant sur fatboy pour me reposer, je me suis retrouvé à être spectateur de l’enregistrement du podcast “De Nederlandse Kubernetes Podcast”, qui comme son nom l’indique est un podcast néerlandais sur Kubernetes.
Ça m’a intéressé à deux titres.
D’abord le sujet était intéressant, c’était un speaker du vendredi qui venait parler de son talk, que je suis allé voir par la suite.
Mais surtout parce que l’enregistrement se faisait en plein milieu de l’espace de conférence, dans le brouhaha. Mais au sein de cette “bulle”, le son était de bonne qualité et était retransmis en temps réel à l’extérieur, ce qui permettait d’avoir à la fois un son de qualité pour le podcast, tout en donnant la possibilité d’avoir un public.
En tant qu’organisateur de KCD France, j’ai eu cette problématique : j’étais responsable de l’enregistrement de quatre tables rondes où le son était difficile à maîtriser et où nous n’avons pas pu avoir de public. À garder en tête !
From Engineer to Engineering Manager
Je connaissais Emma Bostian de nom (elle a 200k followers sur Twitter). J’ai donc été voir son talk, dans lequel elle explique comment elle est passée (un peu malgré elle) d’ingénieure logicielle à manager.
Elle explique notamment les différences de compétences attendues entre les deux, donne des conseils et met en garde : tout le monde n’est pas fait pour devenir manager.
Sans tout lister, je retiens surtout que la composante principale d’un bon manager est le capital confiance qu’iel doit construire et conserver avec ses “direct reports”.
Cela passe par le fait de faire ce qu’on dit, savoir avoir les conversations difficiles (don’t be a people pleaser), reconnaître l’excellence, aider à la création de relations entre ICs (individual contributors).
Ce talk fait forcément écho à des situations que j’ai vécu ou qu’on m’a rapporté.
How to be an adult in (professional) relationships
Ce talk de Rachel Nabors est LE TALK qui m’a le plus marqué de toute la conférence. J’espère qu’il y aura un replay (si ce n’est à DevWorld, dans une autre conférence) car j’ai peur de ne pas y rendre justice dans ce blogpost.
Grosso modo, ça se résume en “We s**k at human relationships”. Au travers du talk, avec la juste dose d’humour et d’expériences personnelles, Rachel nous donne une liste d’outils pour améliorer ça.
Comment éviter de projeter ses propres pensées dans les actions des autres pour deviner leurs intentions réelles, se concentrer sur notre propre part (own your half of any situation), apprendre à dire “désolé” (et ne pas rajouter un “mais” derrière) et chercher sincèrement comment réparer une erreur.
Elle a également beaucoup insisté sur les “power dynamics” au sein d’un groupe, avec une analogie que j’ai trouvée très parlante big dog/small dog. Le gros chien, c’est la personne qui a plus de pouvoir, de légitimité, de charisme, dans l’entreprise. Il peut arracher la tête du petit chien d’un coup de griffe (influer sur la carrière du petit chien). Il doit être conscient de sa “taille”, et en profiter pour instiller le calme, le sentiment de protection.
Two people in the room, the third is power dynamics
En fin de talk, elle a parlé des problématiques liées à notre “work / life balance” (qui selon elle est un mensonge dans nos vies hyper connectées), de savoir gérer et reconnaître quand on ne maîtrise plus nos émotions et enfin, de l’importance de ne pas rajouter de la détresse aux personnes qui sont déjà en train de perdre le contrôle des leurs.
Vous le voyez, j’ai un mal fou à résumer tout ça. Je vais le revoir dès qu’il sort en replay.
The Cathedral, the Bazaar, and the Coffeehouse
Ce talk de Claude Warren à propos des stratégies pour limiter les risques (réels) liés à l’usage des logiciels open source était assez intéressant.
Entre les problématiques de maintenabilité des logiciels, exacerbés par les problématiques de dépendances, les problèmes de licences incompatibles et les communautés trop restrictives (coucou Hashicorp) ou au contraire trop laxistes sur les contributions, gérer ces risques ne doit pas être laissés à la chance dans une organisation.
Claude a introduit le concept d’OSPO (Open Source Program Office) pour gérer ces problématiques. Les OSPO sont des équipes au sein d’organisations qui sont responsables de jauger les projets utilisés dans l’entreprise, contribuer à ces projets et ainsi garantir leur pérennité, assurer un premier niveau de support pour les utilisateurs des logiciels open sources que l’entreprise utilise.
Il a également introduit le principe de “Coffee house” (grosso modo, regrouper des OSPO de plusieurs entreprises différentes avec des besoins similaires) pour mutualiser les efforts.
C’est un des seuls talks où j’ai réussi à trouver les slides 🙃.
Lost in Cyberspace: Tracking Down the Missing TCP Packet
Adrian Precub, staff engineer chez Tomtom nous a fait un postmortem d’un bug qu’ils ont eu entre des dizaines de milliers de voitures connectées et leur service de navigation.
TL;DR: nginx ingress controller, c’est vraiment pourri jusqu’à la moelle (ok, j’exagère, mais je vous jure, je n’en peux plus de ce logiciel qui n’a rien à faire dans Kubernetes, cf mon article Je déconseille nginx en tant qu’IngressController en production).
Sans trop rentrer dans les détails techniques, leur loadbalancer F5 savait gérer le ssl_handshake_timeout (fixé par défaut à 5 secondes), mais pas le nginx ingress controller derrière, ce qui faisait que certaines connexions entre les voitures et leurs services n’étaient fermées qu’au bout d’une heure d’inactivité (c’est plus compliqué que ça, il y a aussi une notion de packet resets qui n’arrivent pas dans le bon ordre, je vous invite à voir le replay).
La conclusion m’a un peu surpris. Adrian avoue que le bug leur a pris 5 mois à résoudre, et a mobilisé (pas à plein temps, bien sûr) 50 personnes différentes de quatre entreprises.
De quoi remettre en perspectives les fois où je m’en veux quand j’ai perdu tout seul 2 jours sur une mauvaise configuration de cilium…
Beaucoup de networking
Comme les sessions étaient parfois complètes ou démarraient en décalées (retards + pas assez de battement), j’ai eu beaucoup plus de temps que d’habitude pour aller voir les sponsors, engager des discussions.
J’ai eu une longue conversation avec LeafCloud, un cloud provider “green” qui utilise la chaleur des serveurs pour chauffer de l’eau et des bâtiments (même principe que Qarnot, mais à une plus petite échelle). Ils proposent un Kubernetes Managé (au-dessus d’OpenStack) auquel on peut ajouter des GPUs que je ne manquerai pas de tester.
J’ai aussi discuté avec ScyllaDB, Cloudinary, et d’autres. Ce n’étaient pas les sponsors que j’ai l’habitude de voir dans les conférences en France et c’était donc “rafraîchissant”.
J’ai passé du temps avec Pascal et j’ai eu la chance de pouvoir rencontrer Julien (👋) avec qui j’avais déjà échangé plusieurs fois sur Twitter. Nous avons eu des discussions passionnantes, c’était vraiment une parenthèse plus que bienvenu dans mon quotidien.
Vous l’aurez peut-être remarqué dans ce blogpost, les sujets qui m’ont le plus marqué sont majoritairement des sujets “non techniques”. Ça s’explique notamment, je pense, parce que les sujets techniques sont difficiles à “bien” traiter dans seulement 25 minutes (on reste vite sur sa faim). De plus, plusieurs sujets qui m’intéressaient étaient pris d’assaut et je n’ai pas pu les voir (j’ai loupé une super présentation sur Tauri 2.0 notamment). Il faudra attendre les replays.
Je suis cependant content de cette conférence dans sa globalité (même si tout n’était pas parfait…), particulièrement grâce à ces moments d’échanges entre les sessions et à des talks “non techniques” de très grande qualité.
Peut-être à refaire ! Au revoir, Amsterdam…
