Skip to content

Instantly share code, notes, and snippets.

@divarvel

divarvel/gist:fe5dcefe93ee11d2ea5eecb34e7dc4a7

Created January 23, 2026 13:09
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save divarvel/fe5dcefe93ee11d2ea5eecb34e7dc4a7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save divarvel/fe5dcefe93ee11d2ea5eecb34e7dc4a7 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
---
title: "Bon c’est bien joli vos technos de hipster, mais moi je fais de la prod"
#display-notes: true
#light: true
#ratio43: true
overlay: "@clementd"
author:
- name: Clément Delafargue
desc:
- Software developer at <a href="https://datadoghq.com">Datadog</a>
- <a href="https://framapiaf.org/clementd">@clementd@framapiaf.org</a>
- <a href="https://bsky.app/profile/clementd.wtf">@clementd.wtf on bluesky</a>
---
# Un plaidoyer pour l’utilisation de langages _non-mainstream_
::: notes
| 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
::: notes
| 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
- 2011 scala (en presta)
- 2013 haskell
- 2018 rust
- 2018-2022 haskell * purescript
- 2022-2023 haskell * elm
- 2023-2025 haskell * biscuit
::: notes
| aujourd’hui je fais un peu de tout (du rust entre autres) chez datadog, mais
| rust est déjà bien établi dans la boîte
:::
---
# La sagesse populaire dit que
- « on va jamais réussir à recruter »
- « on va passer notre temps à tout recoder »
- « il va falloir monter en expérience sur tout à la fois »
::: notes
| 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
- « on va aller 10x plus vite que les autres ça va tout rattraper »
- [Beating the averages](https://paulgraham.com/avg.html)
::: notes
| 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™
::: notes
| merci d’être venu à mon talk
:::
---
# Ce qui fait peur à votre patron / aux RHs
- le recrutement
- le cycle de vie d’une équipe
- ~~les syndicats~~
::: notes
| 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à »
::: notes
| 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
- le pool de départ est plus réduit, certes
- les RHs ne sont pas aligné’es avec le funnel
::: notes
| 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]{}]{.incremental}
des gens qui ont une longue expérience dans une techno, c’est rassurant… [[mais pas ouf]{}]{.incremental}
::: notes
| 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
- peu de candidat’es
- quasiment tous’tes très qualifié’es
- (mais pas de manière obvious)
::: notes
| 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
::: notes
| 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
::: incremental
- il faut accepter de former les gens
- attention aux équipes full-senior
- la moula
- pas de juniors: seniors qui stagnent
- risque d’une équipe fossilisée
:::
::: notes
| 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
- différent, mais pas nécessairement pire
- [[… modulo l’ego froissé des RHs]{}]{.incremental}
- recruit out of your league
- [[… soyez pas des pinces non plus]{}]{.incremental}
- besoin de former les gens en interne
- [[… c’est le cas partout]{}]{.incremental}
::: notes
| 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
- attention à l’entre-soi
- reach out
::: notes
| 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
- « on va tout recoder, y’a zéro lib »
- « on va aller trop vite »
- « impossible de faire du legacy, on fait du haskell »
::: notes
| il y a du vrai et du faux
:::
---
# Le manque de libs
- les libs de base sont là (web, db)
- [[en majorité de bonne qualité]{}]{.incremental}
- pas de vrai équivalent à spring boot, hibernate
- [[équivalents techniques sans hégémonie]{}]{.incremental}
- dev initial un peu plus lent
- [[mais plus rapide à travail égal]{}]{.incremental}
::: notes
| 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 »
- à feature équivalente, bof
- à qualité de code équivalente, à expérience équivalente, oui
- [[MAIS C’EST PAS AUTOMATIQUE]{}]{.incremental}
::: notes
| 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 »
<small>
- un bon langage *aide* une très bonne qualité de code
- un mauvais langage peut *empêcher* une très bonne qualité de code
- un bon langage *n’empêche pas* une mauvaise qualité de code
- un bon langage *n’empêche pas* une archi à la con
- une bonne archi *peut contenir* une mauvaise codebase
</small>
::: notes
| "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
- solutions "rigolotes" trop complexes pour le problème
- features dures à prendre en main
- [[… surtout vrai avec les devs haskell]{}]{.incremental}
- buy-in complet à une techno maximaliste
::: notes
| 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
- garder un œil sur la complexité des solutions
- évaluer les besoins et les capacités de maintenance
- *savoir dire non*
- le choix de la techno a déjà tapé dans le budget
- [[C’EST CONTEXTUEL]{}]{.incremental}
::: notes
| 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™
- testez dans des contextes limités
- you add it, you support it
- ne transigez pas sur l’archi
- choix d’équipe
::: notes
| 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
- équipe heureuse d’utiliser des bons outils
- équipe heureuse de bénéficier d’une bonne qualité de code
- équipe heureuse de ne pas passer son temps à debug
- équipe alignée sur les valeurs
- équipe autonome et mature
::: notes
| 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
- complexité (code ou archi)
- silotage / bus factor
- "cette réécriture en rust/haskell/ocaml va corriger tous nos problèmes"
- "c’est mon premier projet en haskell, je vais tout bien faire"
::: notes
| clairement la complexité, c’est l’ennemi numéro 1 et ça a été un gros problème
| chez bellroy, où des gens super forts en code ne gardaient pas les pieds sur terre:
| types iso-récursifs pour un petit DSL, kafka / dynamodb / lambdas haskell pour copier un JSON de
| 6Mio d’un job CI vers S3. Chez fretlink il y avait aussi 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
- buy-in du top-management
::: notes
| 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 les patrons moins cons, 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. (qui a dit "aller lécher le cul des chefs"?)
|
| 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
- à petite échelle, le recrutement est plutôt facilité
- l’amélioration technique / de vélocité est marginale
- l’important c’est les gens
- la techno c’est un proxy pour les valeurs
- [[trouvez ce qui vous rend heureux]{}]{.incremental}
---
# L’important c’est d’aimer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment