Loading

Bon c’est bien joli vos technos de hipster, mais moi je fais de la prod

$ whoami

@clementd

Un plaidoyer pour l’utilisation de langages non-mainstream

l’idée est de démystifier un peu l’utilisation de langages “pas mainstream”
et d’essayer de faire un petit retour d’expérience pour mettre les appréhensions
en rapport avec ce que j’ai pu voir en pratique
note importante: non-mainstream est hautement contextuel. par exemple dans le
monde de la crypto haskell est plus proche du mainstream que par exemple dans
le monde du transport routier (exemples choisis totalement au hasard)

Disclaimer

ce que je vais dire concerne surtout des petites boîtes / des petits départements
tech au sein de boîtes pas majoritairement tech
les dynamiques sont totalement différentes sur les grandes entreprises tech
qui ont des besoins de standardisation spécifiques, des capacités de support interne dédié, etc
j’en veux pour preuve que ce que je dis n’est pas du tout applicable à mon employeur actuel

Je suis gros hipster

aujourd’hui je fais un peu de tout (beaucoup de go ces temps-ci) chez datadog, mais
rust est déjà bien établi dans la boîte

La sagesse populaire dit que

il y a du vrai et du moins vrai là dedans
l’argument qui revient le plus c’est vraiment la peur de ne pas trouver de devs

Les hipsters comme moi disent que

il y a du vrai et du moins vrai là dedans
il y a quelques années, l’essai de paul graham était souvent cité pour
justifier des choix techniques, euh, audacieux

En vrai, ça dépend™

merci d’être venu’es à mon talk

Ce qui fait peur à votre patron / aux RHs

fort logiquement, les patrons / managers / RHs ne vont pas se focaliser sur
l’aspect technique, ce n’est pas leur boulot
donc iels vont se focaliser sur les points négatifs, pas sur l’expressivité du système de types

« on va jamais trouver des devs qui maitrisent ton langage chelou là »

les RHs avec qui j’ai pu bosser par le passé avaient pour la plupart la vision
de l’entonnoir de recrutement avec plein de candidates peu qualifiées au début,
triées par le département RH, puis quelques élues présentées à l’équipe de dev
pour un choix final
en gros un rôle central des RHs

Contrepoint

encore une fois, valable surtout pour des petites boîtes
mais perso, je n’ai que très rarement vu des profils amenés uniquement par
les RHs. Dans la plupart des cas c’était soit directement de la cooptation
soit via le partage des offres d’emploi dans le réseau des devs

Contrepoint

un gros pool de départ c’est rassurant… mais pas ouf

des gens qui ont une longue expérience dans une techno, c’est rassurant… mais pas ouf

encore une fois, valable pour les petites boîtes
en pratique, je me suis souvent battu avec les RHs pour faire passer des
profils qui rentraient pas dans leurs cases, et leur expliquer pourquoi le
candidat super sur le papier n’allait pas

Recrutement

dans la plupart des cas des gens volontaires, il faut savoir aller chercher
les expériences transverses et compter sur la montée en compétence

Recrutement: la partie facile

en haskell, chez fretlink et bellroy, les recrutements ont été incroyablement
faciles. à chaque ouverture de poste, le plus dur c’était de dire non aux gens

Gestion de l’équipe

si vous ne cherchez que des devs senior avec grosse expérience en haskell,
vous n’allez pas en trouver ou alors très cher, et il y a une chance sur deux
qu’iels essayent de se foutre sur la gueule
faire monter des juniors en compétence, c’est aussi faire monter les seniors
qui les encadrent (mentoring, délégation, etc)

Conclusion RH / management

sur mes quelques expériences, bilan globalement positif. on a pu bosser avec
des gens normalement embauchables très cher par des grosses boîtes car on a
su proposer quelque chose d’intéressant

Conclusion RH / management

on s’appuie beaucoup sur le réseau, et on va chercher des gens qui ont le
temps et l’énergie d’aller jouer avec des technos non-mainstream, donc si
on ne fait pas gaffe on va repousser des gens d’autres horizons
ceci étant dit, les commus rust et haskell sont assez diverses avec une
bonne représentation LGBTQIA+ (pareil, ça peut aussi nécessiter d’aller
mettre des taquets à des gens un peu vieux jeu)

Sur la partie technique

il y a du vrai et du faux

Le manque de libs

on se retrouve à assembler des briques de base solides, plutôt qu’à prendre
des trucs tous faits
un peu frustrant au début, mais on a quelque chose de très agréable à utiliser
vraiment adapté à son usage. d’ailleurs je n’ai jamais vraiment apprécié les
boilerplates et les trucs tout faits au dessus de servant ou autre

« On va aller trop vite »

d’expérience, on avait une très bonne maitrise sur notre socle technique
(peu de trucs automagiques, bon type system, etc), et on passait très peu de
temps à corriger des bugs, grâce à la bonne qualité de code globale du
système
ça c’est des choses qui ne se voient pas à court terme quand on ne fait que du neuf
mais quand on commnence à repasser sur de l’existant c’est très appréciable

« Impossible de faire du legacy, on fait du haskell »

« Impossible de faire du legacy, on fait du rust »

« Impossible de faire du legacy, on fait du ocaml »

« Impossible de faire du legacy »

“faire du legacy” ça n’a pas de sens de toutes façons
la qualité de code, c’est un travail constant de tout le monde. un langage
bien typé peut énormément aider, mais ça n’est pas magique

Galaxy brain

si vous ne donnez des problèmes pas intéressants à des gens, iels vont s’inventer des problèmes à la hauteur de leur intelligence.
c’est amplifié par les points vus précédemments: on a un peu plus de décisions techniques à prendre, plus de libertés
certaines technos poussent des systèmes très homogènes complètement à part (persistence, runtime, déploiement, communication inter-services): vigilance accrue car pas moyen de fragmenter le risque

Complexity budget

le budget complexité c’est le meilleur outil pour garder conscience du coût
moyen-long terme des solutions rigolotes.
ce n’est pas quantitatif, c’est plus un état d’esprit et une vigilance à garder
sachant que le budget est déjà largement entamé par le choix de la techno

Ça dépend™

je ne suis absolument pas en train de défendre des trucs genre boring haskell, si on utilise le langage c’est quand même pour pouvoir se servir de ses points forts

le but n’est pas de rien utiliser comme features avancées, mais de le faire de manière délibérée et en prenant bien en compte les coûts
l’idéal c’est de trouver des contextes limités dans lequel tester (ou confiner) les parties complexes. par exemple avec MTL chez fretlink, on était quelques uns à être à l’aise dans ces couches là et on fournissait le support aux autres quand c’était nécessaire, ça marchait bien

un autre bon moyen complémentaire c’est de rendre les personnes qui introduisent des technos responsables de leur maintenance. ça fait réfléchir un peu, et ça encourage les gens à faire monter les autres en compétence
l’archi reste le meilleur moyen de se protéger de ça, soyez très attentifs aux choix d’archi poussés par une techno. c’est souvent très risqué, donc il faut bien peser le pour et le contre

pour finir, c’est contextuel, il n’y a pas une liste de features autorisées et d’autres interdites. ça dépend de l’équipe, du problème, du contexte, etc

l’idéal c’est quand même d’avoir un garde-chiourme qui est là pour réfréner les ardeurs et demander si on a vraiment besoin d’utiliser les lens dans la suite de tests ou trees that grow dans les DTOs

Les points positifs

expérience commune chez fretlink et outscale, en partie aussi chez bellroy
ne pas avoir à passer de temps sur de la correction de bugs c’est vraiment
incroyable (et c’est facilment atteignable, avec un bon langage ou d’autres
approches comme une bonne discipline de code)

Les points de vigilance

clairement la complexité, c’est l’ennemi numéro 1 et ça a été un gros problème
chez un employeur passé, où des gens super forts en code ne gardaient pas les pieds sur terre:
types equirécursifs pour un petit DSL, kafka / dynamodb / lambdas haskell pour copier un JSON de
6Mio d’un job CI vers S3. chez un autre il y avait des bouts qui évoluaient lentement
à cause d’une grosse complexité technique pas assez contrebalancée par des usages
concrets

un autre risque est qu’une personne monte toute seule en compétences sur un point
et ponde du code incompréhensible. ça se combine avec les réflexions sur le
budget complexité. que toute l’équipe maitrise toutes les libs, pas forcément
la peine

pour l’introduction d’une techno de niche dans un contexte existant, il faut
absolument y aller de manière itérative pour valider les hypothèses au fur et
à mesure, éviter d’avoir la pression pour sortir un truc parfait réécrit 15 fois

Les points de vigilance

un truc que j’ai vu plusieurs fois dans des grosses boîtes où une équipe faisait une techno cool, c’est que le vent peut tourner très vite à la direction technique et du jour au lendemain avoir un nouveau chef qui débarque et qui veut tout standardiser sur spring boot pour pas se faire chier

clairement j’ai pas de solution miracle pour rendre une direction conne moins conne, mais on peut toujours éviter de tendre le bâton pour se faire battre. là ce qui aide c’est de communiquer avec les autres équipes, mettre en avant ce qui a bien marché, proposer de l’aide, etc.

dans une grande boîte, à moins d’être à un poste de VP ou plus de toutes façons vous n’allez pas décider de la politique technique de la boîte, mais vous pouvez quand même essayer de vous assurer qu’on vous fout la paix et qu’on laisse votre oasis en paix

Pour conclure

L’important c’est d’aimer