Siegfried Ehret était présent à dotCSS et en a profité pour échanger avec Tim Carry. Il nous partage ses expériences de speaker à dotCSS et de Developer Advocate chez Algolia. Une interview passionnante qui nous a vraiment inspiré en interne chez SFEIR !
SFEIR: Bonjour Tim ! Peux-tu te présenter ?
Tim Carry : Je m’appelle officiellement Timothée Carry-Caignon, mais tout le monde m’appelle Tim Carry. Je suis Developer Advocate chez Algolia, et aujourd’hui j’étais speaker à dotCSS. (ndlr : l’interview a été réalisée pendant la conférence)
Raconte-moi ton histoire avec dotCSS…
Je crois que je suis venu à toutes les éditions de dotCSS, j’allais aux conférences dotJS et une année ils ont annoncé qu’ils allaient faire la conférence «petite soeur» dotCSS, et je me suis dit «c’est génial, il faut absolument que j’y aille». Je n’ai pas du tout été déçu, même si c’est une conférence qui est uniquement sur une après-midi, j’ai trouvé que la qualité des talks condensés était excellente. J’ai beaucoup aimé : il y avait un mélange de ce qui allait se passer côté CSS dans le futur, avec du «regardez j’ai fait un hack de ouf en 3D en CSS» ! Tu sors de là en te disant «c’est génial, CSS est vraiment un langage qui évolue, il y a plein de choses à faire, et on en est vraiment juste au début».
Je suis devenu Developer Advocate chez Algolia après, et les conférences dot sont pour moi un très gros gage de qualité. Je me disais “si un jour on a quelqu’un de chez nous qui parle lors d’une conférence dot, on aura atteint un certain niveau de maturité”. J’avais essayé de voir si on n’avait pas des sujets qui pouvaient coller pour dotScale ou dotJS, mais il n’y avait jamais rien. L’année dernière j’ai proposé un lightning talk pour dotCSS qui a été accepté, où je refaisais le logo dotCSS avec un seul div, en utilisant pas mal de petites techniques:
Ça avait pas mal plu ! Cette année ils ont ouvert le CFP pour les talks officiels, j’ai proposé quelque chose, et Sylvain m’a contacté il y a 3 semaines pour me dire que c’était bon, mon talk était accepté. Un peu court pour préparer les slides, mais tant pis, je me suis dis “je vais parler à dotCSS, il faut que je fasse un truc vraiment bien !” J’ai donc retravaillé les slides d’un talk qui durait 35 minutes en 18 minutes. J’ai reçu de l’aide d’un collègue Designer pour les retravailler et que ça rende bien. J’ai passé un excellent moment pendant ces 18 minutes à présenter, je me suis vraiment bien amusé à le faire et apparemment les gens ont apprécié, donc c’est pour moi un «achievement completed» !
Je parle vraiment de hacks en CSS : pourquoi est-ce intéressant de faire un truc qui n’a l’air de servir à rien et qui paraît complètement impossible.
Tu peux nous parler d’Algolia ?
Sans problème, puisque c’est un peu mon métier ! Nous faisons de la recherche sous forme d’API. Si tu connais Stripe, ils font du paiement sous forme d’API. Twillio fait de l’envoi de message sous forme d’API. Chacune de ces boîtes fait un truc et le fait bien, et nous c’est la recherche. C’est à dire que tu as tes données, initialement sous un format JSON, tu les envoies sur notre API, du coup on va l’indexer d’une certaine manière, on a plein de clients d’API dans tous les langages pour faire ça, et avec le même client tu peux faire des requêtes pour interroger ces données, faire des recherches avec des mots-clés ou des parties de mots-clés, trouver ce qui correspond à ça, et te les renvoyer.
Un de nos gros avantages c’est qu’on est extrêmement rapides. Ça prend en général 20 millisecondes pour une recherche. Ce qui est instantané pour l’oeil humain et qui permet donc d’afficher des résultats en temps réel au fur et à mesure que les gens sont en train de taper.
Lucas me disait qu’il y a 2–3 ans vous étiez 30, et aujourd’hui près de 200.
Oui ! On a des bureaux à Paris, San Francisco, Atlanta, New York et on va ouvrir à Londres. Toute l’équipe tech est à Paris. Les personnes qui vont travailler sur le coeur du moteur, les clients d’API, les librairies frontend, tout est ici.
Dans les autres bureaux, on a des rôles qui sont un peu hybrides. Des rôles techniques comme moi, Developer Advocate, on en a à Londres ou à San Francisco, mais ils ne font pas que du dev. Mon travail de tous les jours, ça ne va pas être de vraiment commiter sur les clients d’API principaux. Si je vois un bug et si je sais le régler, je peux soumettre une pull-request, je peux le faire, mais ce n’est pas la première chose qu’on attend de moi.
On a un rôle qui s’appelle Solutions Engineer, qui est pour schématiser à moitié Dev et à moitié Sales. Une fois que tu es client Algolia, que tu es un gros site et que tu as besoin d’aider pour l’implémentation, on a quelqu’un de l’équipe qui te sera dédié pour ça. Cette personne viendra dans tes locaux, former ton équipe, faire en sorte que tu aies la meilleure implémentation possible pour répondre à ton besoin. Moi je suis technique et je parle aux communautés, eux sont techniques et parlent aux clients.
Donc on recrute sur tous ces profils-là évidemment, et on a envie de rendre la vie des développeurs plus facile, quel que soit le langage qu’ils utilisent. Comme ça évolue très rapidement et qu’il va y avoir un nouveau framework JavaScript dans 3 mois, si tout le monde est dessus et qu’il est vraiment bien, il faudrait qu’on ait une implémentation pour.
Chaque fois qu’un site sort, on vous voit débarquer pour la recherche. C’est vous qui allez vers eux ou est-ce que c’est vous qui les contactez pour bosser avec eux ?
Qu’est-ce que tu appelles un nouveau site ?
Je pense à Yarn, ou les docs de Hugo.
Yarn est un très bon exemple. Algolia est une boîte très tech initialement, les 2 fondateurs sont très tech eux-mêmes. Ce sont 2 anciens d’Exalead, une boîte qui fait des moteurs de recherche orientés plus «entreprise», à chercher dans des PDF, des documents Word, etc. Ils savent faire et ont décidé de monter leur entreprise dans la recherche, mais orientée utilisateurs. Quand tu recherches, tu tapes et tu t’attends à avoir des résultats, et il n’y avait pas de solution qui adresse ce problème simplement.
On fait une API, les gens qui vont nous utiliser sont des développeurs, donc on peut vraiment parler tech avec ces gens-là. Et la tech est vraiment fondée sur l’open source, auquel on essaie de contribuer un maximum. Le coeur de notre moteur est closed source (même si on est transparent sur son fonctionnement), mais tous nos clients d’API et tout ce qu’on fait autour, on essaie de le faire en open source. Donc on essaie de contribuer à ça soit en aidant financièrement les projets open source, soit avec une petite tradition : tous les ans, à Noël, on fait un cadeau à la communauté.
- Le premier cadeau était une extension Chrome et Firefox pour rechercher instantanément dans tous les repositories Github.
- L’année d’après on a fait DocSearch, qui est un outil utile si tu as une librairie open source avec un site de documentation, et on fournit un crawler qui va parcourir les pages de ton site toutes les 24 heures et te proposer un outil de recherche de ta documentation. On le fait pour tous les sites open source, c’est juste une demande, 2–3 trucs à configurer chez nous, et après tu peux utiliser ça, quel que soit ton volume, et c’est complètement gratuit !
- L’année dernière, le site de Yarn était sorti, et npm existait et la recherche de ce dernier laissait vraiment à désirer. On les a contactés pour essayer de travailler ensemble, et ils n’ont pas vraiment répondu. On a contacté Yarn et ils étaient super emballés. Du coup, on a commencé à travailler sur «quelle est la recherche de package dont nous, en tant que développeurs, on rêverait». On a commencé à agréger des informations depuis plein de sources différentes : depuis npm lui-même, en répondant au hook à chaque fois qu’un nouveau paquet est ajouté ou autre, en regardant le nombre d’issues, pull requests, stars sur Github, et plein d’autres sites pour avoir le nombre de téléchargements, etc. Et prendre tout ça en compte dans la manière donc les résultats sont filtrés. Donc quand tu cherches quelque chose sur Yarn aujourd’hui, ça nous utilise.
- Et pour cette année… TalkSearch : ça m’arrive souvent de me dire : “Je me souviens avoir vu un talk super intéressant, mais je ne sais plus trop dans quelle conférence c’était ni le nom du speaker. Mais à un moment, au milieu d’un talk sur Docker, il a dit un truc super intéressant sur JavaScript… Comment je peux retrouver ça ?”. C’est ce problème que TalkSearch cherche à résoudre : rechercher dans les vidéos des talks des conférences techs. Pas que dans les titres et les descriptions, mais aussi dans le contenu prononcé. C’est un service gratuit (comme DocSearch pour la documentation), offert à tous les organisateurs de conférence. Il suffit de nous donner l’URL d’une playlist YouTube et on donne un petit snippet de JS à inclure qui permet de rechercher dans toutes les vidéos.
Pour la documentation de Hugo, ils utilisent DocSearch. Ils n’avaient pas de recherche, ils nous ont contactés et le lendemain on leur a transmis un snippet qu’ils pouvaient intégrer pour avoir directement la recherche.
Peux-tu me décrire ton rôle de Developer Advocate ?
C’est une question très compliquée, il y a autant de manières de faire ce job que de Developer Advocate. La manière dont j’aime bien l’expliquer c’est qu’en tant que développeurs, nous sommes équipés d’un détecteur de bullshit hyper performant… Globalement, nous sommes imperméables au marketing traditionnel. On a des adblocks qui font qu’on ne voit pas les pubs, quand on nous demande notre adresse email, on ne la donne jamais parce qu’on sait qu’on va se faire spammer, etc. Toutes les techniques traditionnelles que les gens apprennent en école de marketing ne marchent pas sur les développeurs. Et vu que notre audience, ce sont les développeurs, et qu’on a quand même envie que de plus en plus de personnes sachent ce que l’on fait et aient envie d’essayer notre produit, il faut que l’on trouve d’autres techniques. Le travail du Developer Advocate, c’est d’être un développeur qui sait comment parler à d’autres développeurs.
Globalement mon rôle c’est de faire en sorte qu’il y ait de plus en plus de personnes qui sachent qu’on existe, qui aient envie de d’utiliser notre service, qui aiment ce que l’on fait et qui en parlent autour d’eux. Notre crédibilité en temps que développeurs va nous aider à convaincre. Quand tu dois choisir un nouveau framework ou une nouvelle technologie, ce n’est pas parce que tu as vu une nouvelle annonce dans un journal que tu vas dire «ah, ça a l’air vachement bien» ! Tu vas demander à tes collègues développeurs ce qu’ils utilisent, quel est leur retour, etc. C’est ce que l’on fait : on essaie d’être transparents au maximum sur les forces et faiblesses d’Algolia, dans quel cas c’est pertinent ou pas. On utilise notre produit tous les jours, on connaît vraiment ses avantages et inconvénients, on peut le mettre en avant et expliquer comment cela fonctionne. Celà nécessite d’être développeur soi-même, de baigner dans un univers de développeurs et de faire partie de cette boucle de feedback : où les utilisateurs en ont-ils entendu parler, s’ils l’ont utilisé, où s’ils ont été bloqués quleque part, pour que l’on améliore nos features et notre documentation.
Donc tu codes toujours ?
Je code toujours !
Comment tu organises ton temps ?
C’est assez difficile, mais je m’améliore. Quand je code, je ne peux pas être vraiment concentré sur un sujet pendant une heure entre deux meetings. J’ai besoin d’être sur le sujet pendant 4 heures ou une journée pour vraiment comprendre toute l’abstraction du problème que je suis en train de résoudre, coder, rentrer dans le truc, et vraiment réussir à avancer.
Par exemple, quand Algolia sort une nouvelle feature, c’est chouette, mais si personne ne le sait, c’est un peu raté. Je vais donc essayer de faire une démo qui l’utilise au maximum : coder un vrai produit qui l’utilise. C’est la première partie, celle du code, où je mets la feature en application. Après, il faut faire en sorte que les gens la connaissent, donc ce que j’essaie de faire c’est d’écrire un article de blog qui a du sens du point de vue du développeur. Pas « On a sorti une nouvelle feature c’est génial ! », mais « Comment ça marche, comment peut-on l’utiliser ». Faire des talks pour en parler, en parler autour de moi, et inciter d’autres personnes à l’utiliser et à avoir leurs retours. Et idéalement, avoir ces personnes-là qui en parlent à leur tour !
Il n’y a pas vraiment de journée ou de semaine type, ça dépend de plein de choses ! Il faut jongler entre le « j’ai besoin de me focus pour faire un vrai projet » et les événements du calendrier que tu ne peux pas déplacer. Globalement, ce que j’essaie de faire, c’est quelque chose que je faisais déjà avant : participer à des meetups et à des conférences, dans l’audience, et rencontrer les gens pour discuter sans vendre le produit, mais pour voir ce qu’ils font. Quand ils me demandent ce que je fais, je leur présente nos solutions, en espérant que ça puisse les intéresser.
On t’a vu tourner avec les drapeaux en CSS, et aujourd’hui avec le moteur de recherche en CSS. Ça fait deux chefs-d’œuvre pour toi…
Avec les drapeaux, c’était vraiment ça. Ce talk, c’est un peu la continuité du premier. J’avais une formule qui marchait, je savais que ce n’est pas parce que ça avait l’air impossible et complètement idiot que ce n’était pas réalisable.
Dans mon talk sur les drapeaux, j’utilise des tricks en CSS hyper avancés et obscurs, ça a fait rire les gens qui découvraient à quel point j’avais poussé CSS dans ses retranchements, et des conférences m’ont contacté pour que j’aille y faire la même présentation. C’était une surprise pour moi car quand je propose des talks pour parler d’une nouvelle feature d’Algolia, les gens me disent non, parce que c’est trop commercial, ou qu’ils n’ont pas envie d’avoir de la pub dans une conférence. Ce que je comprends parfaitement. Mais néanmoins, si je suis intimement persuadé que la feature est intéressante, il me faut trouver un moyen de la présenter. J’avais vu que les tricks CSS ça marchait bien, alors je me suis dit que de présenter un moteur de recherche en CSS me permettrait de faire d’une pierre deux coups.
Dans ce talk, je ne parle pas d’Algolia, mais de bonnes pratiques pour faire un moteur de recherche : ça doit être pertinent, rapide, facile à utiliser… Il n’y a rien de plus frustrant qu’un moteur de recherche qui te dit « Vous avez tapé ça, êtes-vous sûr que vous ne vouliez pas avoir cela à la place ? » Pourquoi me poser la question si tu sais que c’est ça que je voulais ? Il y a pas mal de frustrations que tu peux éviter avec un moteur de recherche efficace. Notre expérience dans le domaine nous a permis de compiler plein de bonnes pratiques, qu’on met dans nos librairies et features. C’est ce que je veux essayer de transmettre dans un talk comme ça, tout en faisant rire les gens.
Des idées de ce que sera le prochain ?
Je ne sais pas encore. CSS n’est pas vraiment le truc que je fais dans ma vie de tous les jours, c’est vraiment pour les side-projects. Mais ce sont ceux que je présente. Je vois CSS un peu comme jouer aux legos : t’as des tas de briques, et tu peux les emboîter les unes dans les autres avec des sélecteurs, des propriétés, et parfois tu fais des trucs qui marchent mieux que ce que tu imaginais !
Pour le moment, je n’ai pas encore d’idée de truc à pousser un peu dans ses retranchements comme je l’ai déjà fait, mais ça fait longtemps que je n’ai pas participé à un hackathon. J’aimerais bien en faire un. Je fais du software, mais je suis nul en hardware, dès qu’il faut souder un truc ou brancher deux machins ensemble, je suis complètement perdu. J’aimerais participer à un hackathon où il y a des gens compétents là-dedans, qu’ils puissent m’apprendre. Je pense que ça me donnerait des idées d’IoT, de trucs que je pourrais réellement construire.
Vous faites beaucoup d’open source chez Algolia. Comment fait-on pour vous aider ?
Toutes nos librairies sont open sources et sont sur github. Les développeurs les utilisent dans des conditions bien différentes de nos conditions de tests, il y a des trucs qu’on a pu rater. Donc faire des issues, idéalement en mettant une capture d’écran de ce qui ne fonctionne pas et du résultat attendu, ou un lien vers le site dans lequel ça ne marche pas, et nous on va essayer d’améliorer.
Les features request sont aussi très utiles, en nous expliquant ce que vous cherchez à faire plutôt que «je voudrais que l’API fasse exactement ça». Nous, en agrégeant toutes ces requêtes, on peut faire la meilleure implémentation possible dans notre API pour pouvoir régler ce problème.
Participer avec des pull-requests c’est encore mieux, mais si ça vous plaît, en parler autour de vous c’est super ! Et bien sûr, nous rejoindre pour le faire, en étant payé pour ça.
As-tu une citation favorite ?
J’aime bien celle que j’ai en tête et que j’avais à la fin de mon talk, même si c’est de moi :
Impossible, ça veut seulement dire qu’on n’a pas encore trouvé la solution.
L’idée est qu’il ne faut pas se dire que c’est complètement impossible et qu’on ne va jamais y arriver tant qu’on n’a pas essayé. Ça vaut le coup de tenter des trucs qui paraissent absurdes pour voir jusqu’où on peut aller. Même si tu n’arrives pas exactement là où tu voulais aller, tu apprends énormément de choses le long de ce voyage et ça permet de voir beaucoup plus clair.
Pour reprendre l’exemple de CSS, en essayant de le pousser au maximum, tu vois vraiment ses forces et faiblesses et tu sais beaucoup mieux quand les utiliser. Tu acquiers de l’expérience en faisant des trucs complètement absurdes.
Quelle est ta propriété CSS préférée ?
Je pense que ce sont les pseudo éléments avec content, avec les ::before et ::after. Avec ça, tu peux avoir un div et en avoir deux supplémentaires en quelque sorte, sur lesquels tu peux faire plein de choses. Ça te permet de garder un markup super simple et de multiplier par 3 tous les divs que tu peux avoir. Ça permet vraiment plein de possibilités.
Super ! Merci !
De rien, c’était spontané et très chouette !
Liens
- Algolia
- Les slides du talk Building a search engine with CSS
- Suivez Tim sur Twitter: pixelastic
- Les photos de dotCSS
The post Interview de Tim Carry (Algolia) appeared first on SFEIR Mag.