Sarah Dayan d'Algolia sur ce qui distingue un ingénieur senior

Bien que de bonnes compétences en codage soient toujours appréciées, être un membre du personnel plus un ingénieur exige bien plus que de simples prouesses techniques. Que faut-il pour y arriver et, plus important encore, où pouvez-vous avoir le plus grand impact sur votre organisation ?

Lorsque vous atteignez le niveau supérieur sur une piste d'ingénierie, vous êtes censé être optimal dans vos compétences techniques. Vous êtes autonome, votre code est impeccable et vous avez une compréhension approfondie de la construction et de la livraison de logiciels. Mais entrer dans le personnel plus les rôles est une toute autre bête. Il y a la gestion de projet, le mentorat et l'enseignement, la prise de décision, l'établissement de relations, et la valeur que vous apportez à l'entreprise ne se mesure plus par la qualité des lignes de votre code mais plutôt par la conduite de l'organisation d'ingénierie vers l'avant.

L'invité d'aujourd'hui est passé par là. Sarah Dayan est ingénieure chez Algolia, une plate-forme « Search-as-a-Service » qui aide les développeurs à créer des capacités d'indexation et de recherche dans leurs propres plates-formes via une API, et l'hôte de deux podcasts technologiques : Developer Experience et Entre Devs. Elle crée des bibliothèques frontales, un rôle qui lui convient parfaitement compte tenu de sa passion de toujours pour l'expérience utilisateur, la conception et la construction d'objets. En fait, Sarah est obsédée par la création de sites Web depuis que ses parents ont installé l'Internet haut débit dans son sous-sol. C'était l'amour au premier clic. Elle a créé son premier forum phpBB à 15 ans, a écrit sa première page HTML peu de temps après et n'a cessé de créer des choses depuis.

Bien qu'elle n'ait pas de formation formelle en ingénierie, Sarah a décroché un emploi de développeur chez le consultant français Grand Manitou. Puis, il y a quatre ans, en 2018, elle a obtenu un emploi chez Algolia en tant qu'ingénieur logiciel. Elle a gravi les échelons avec diligence, pour finalement devenir le rôle de contributrice individuelle d'un ingénieur d'état-major. Et soudain, tout ce qui l'intéressait ces dernières années - devenir un meilleur ingénieur, écrire un meilleur code - a fait place à de nouveaux défis. Comment assurerait-elle la bonne direction technique pour l'entreprise ? Débloquer les goulots d'étranglement ? Encadrer et aider d'autres ingénieurs comme d'autres l'avaient fait pour elle ?

Dans cet épisode, nous nous sommes assis avec Sarah pour parler des nombreuses nuances, compétences et attentes d'un rôle d'employé et d'ingénieur.

Voici quelques-uns de nos plats à emporter préférés de la conversation :

• Si vous ne voulez pas prendre de retard, continuez à apprendre. Discutez d'idées et obtenez des commentaires d'autres ingénieurs avec des perspectives et des expériences différentes.
• En tant qu'ingénieur du personnel, une grande partie de votre énergie est consacrée à la collaboration inter-équipes pour la vision et la stratégie. Où en sera l'entreprise dans cinq ans ? Comment allez-vous y arriver?
• Avoir des ingénieurs du personnel comme mentors permet aux personnes plus juniors de clarifier les étapes à suivre pour atteindre ces rôles et vous accélérez le processus de création de leaders en ingénierie.
• Contrairement à la croyance populaire, un ingénieur d'état-major n'est pas une solution rapide à un problème structurel. Avant d'accepter un nouvel emploi, demandez-vous ce qu'on attend de vous pour éviter tout malentendu.
• Les ingénieurs du personnel doivent comprendre les besoins de l'entreprise afin de pouvoir l'aider à atteindre ses objectifs. Lors de l'intégration, lisez autant de documentation et parlez avec autant de personnes que possible.

Si vous aimez notre discussion, consultez d'autres épisodes de notre podcast. Vous pouvez suivre sur iTunes, Spotify, YouTube ou récupérer le flux RSS dans le lecteur de votre choix. Ce qui suit est une transcription légèrement modifiée de l'épisode.

Ne jamais arrêter d'apprendre

Brian Scanlan : Merci beaucoup, Sarah, de nous avoir rejoint dans l'émission aujourd'hui. Je suis ravi d'avoir l'occasion de discuter avec vous. Avant de parler de votre rôle et de votre travail chez Algolia, j'aimerais connaître votre parcours jusqu'à présent. Comment votre voyage vers l'endroit où vous êtes aujourd'hui a-t-il commencé ?

Sarah Dayan : Eh bien, bonjour, merci de m'avoir invitée. Eh bien, c'est en fait une drôle d'histoire. J'ai actuellement 32 ans, et nous avions accès à Internet haut débit et illimité à la maison quand j'avais 15 ans. J'ai toujours aimé construire des choses, et la première fois que j'ai vu des sites Web, je me suis dit : « Je dois savoir comment faire ça. De fil en aiguille, j'ai construit mon premier forum avec phpBB. PHP était vraiment, vraiment gros, et il est toujours gros, mais c'était vraiment le langage du web à l'époque.

« J'ai décidé que ce n'était pas mon truc, que je devrais peut-être faire ce que j'aimais. Alors, je suis retourné à ce que j'aimais - créer des sites Web »

À l'époque, avoir une carrière dans la technologie, en particulier en tant qu'ingénieur logiciel, n'était pas aussi cool et chaud qu'aujourd'hui. Mes parents ont pensé que je devrais envisager de devenir journaliste parce que j'étais bon en langues et en littérature à l'école. Et c'est la première chose que j'ai faite. J'ai fait ma première année en journalisme, que j'ai complètement ratée, puis j'ai décidé que ce n'était pas mon truc, que je devrais peut-être faire ce que j'aimais. Alors, je suis retourné à ce que j'aimais : créer des sites Web. J'ai obtenu mon premier emploi dans une agence et j'y ai passé six ans. Cela m'a beaucoup appris sur le travail, sur le travail avec les clients, avec des gens qui savent ce qu'ils veulent et des gens qui ne savent pas ce qu'ils veulent. Ensuite, je suis passé au monde des startups. Je code depuis plus de 15 ans, mais professionnellement, je le fais depuis 12 ans. Et c'est ce qui m'a amené à mon poste actuel chez Algolia. J'y suis depuis quatre ans et je compte.

Brian : Super. Avez-vous des leçons intéressantes que vous avez apprises au début et qui vous sont restées?

Sarah : Je n'ai pas de parcours classique vers la technologie. Je n'ai pas fait d'école d'ingénieur, et il est possible d'avoir une belle carrière dans la technologie si on ne fait pas ça. Vous pouvez certainement être autodidacte, vous pouvez apprendre des autres et vous n'avez pas besoin d'avoir un diplôme. Mais ne pas avoir de diplôme n'est pas une excuse pour ne pas apprendre. Il y a un excellent article de blog de Sarah Drasner, responsable de l'ingénierie chez Google, sur CSS-Tricks à ce sujet. Même si vous pouvez faire carrière dans la technologie sans diplôme, cela ne vous dispense pas d'apprendre et de rechercher des connaissances.

« Je n'ai pas eu de feedback, je n'ai pas eu de conversations avec d'autres personnes : avec d'autres ingénieurs, avec d'autres perspectives, d'autres parcours. Et donc j'ai pris du retard"

Et une chose que vous apprenez réellement à l'école est d'apprendre à apprendre, et c'est une compétence très importante. Au début de ma carrière, à l'agence dont je vous ai parlé, j'ai longtemps été le seul employé. J'étais tout seul. Et j'avais mon patron, qui codait aussi mais qui était un peu éloigné de ce que je faisais. Et bien que cela puisse être libérateur de travailler seul – vous avez beaucoup de confiance, beaucoup de liberté – vous n'apprenez pas aussi vite parce que vous n'avez pas de commentaires ou d'autres perspectives en dehors des vôtres. Et si vous ne faites même pas d'apprentissage actif, vous allez prendre du retard.

C'est une des choses qui m'est arrivée. Je n'ai pas eu de retours, je n'ai pas eu de conversations avec d'autres personnes : avec d'autres ingénieurs, avec d'autres perspectives, d'autres parcours. Et donc j'ai pris du retard. Je m'appuyais sur les connaissances que j'avais et je n'avais aucune raison de faire les choses différemment car cela fonctionnait. Ce serait l'une des plus grandes leçons que j'ai apprises au début de ma carrière. Surtout si vous n'avez pas un voyage classique sur la technologie, vous entourer d'autres personnes qui vous apportent des commentaires et leurs points de vue est inestimable, et cela va dynamiser votre carrière.

Brian : Je pense que c'est un excellent conseil pour quiconque dans n'importe quel rôle professionnel, mais il semble que cela ait vraiment fonctionné pour vous. Ne pas travailler avec PHP vous manque-t-il ces jours-ci ?

Sarah : Je pense que PHP est un excellent langage. Vous pouvez trouver beaucoup d'inspiration de PHP dans le JavaScript moderne. Je ne travaille plus avec lui car JavaScript a évolué à un point tel que vous pouvez l'utiliser partout où vous souhaitez utiliser PHP. Et surtout en tant qu'ingénieur front-end, il y a beaucoup d'avantages à utiliser le même langage sur le front-end et le back-end, comme le co-partage. Mais je pense que PHP est un excellent langage. Il y a beaucoup de mauvaises blagues et le "Oh, PHP est mort", mais quand on regarde le succès de quelque chose comme Laravel, j'ai l'impression que PHP est loin d'être mort.

Quand je suis entré dans PHP, le framework que les gens sérieux utilisaient s'appelait Zen framework. En fait, je crois que Zen est la société derrière PHP, ou du moins qui l'a repris. Personne n'utilise plus le framework Zen, du moins pas pour de nouveaux projets, mais c'est formidable de voir où en est PHP en ce moment. C'est toujours florissant, les gens aiment coder en PHP, et je pense que c'est génial. Ce n'est pas pour tout le monde, mais vous le faites. Chacun peut s'asseoir à table avec la langue qu'il aime.

Gravir les échelons de l'ingénierie

Brian : Vous êtes actuellement ingénieur du personnel chez Algolia. Parlez-moi un peu de ce rôle et de ce sur quoi vous travaillez, et nous passerons à ce qu'est un ingénieur d'état-major.

Sara : Bien sûr. Je suis ingénieur d'état-major et je travaille sur le front-end. Je fais partie d'une équipe appelée expériences front-end, FX en abrégé, et nous travaillons sur des bibliothèques front-end pour Algolia. Algolia est un moteur de recherche, donc c'est de bout en bout. Vous disposez du moteur et de certains clients API dans plusieurs langues pour envoyer vos données à la recherche, mais vous disposez également de bibliothèques frontales, car qui a le temps de créer un champ de recherche fonctionnel accessible, une liste de résultats, une liste de raffinement ou un menu hiérarchique ?

Toutes ces choses sont difficiles à mettre en œuvre correctement. Nous faisons donc cela pour les clients, et c'est l'équipe avec laquelle je travaille. Je suis un contributeur individuel (IC) et je ne suis sur aucune piste de leadership. Mais le fait est que, à mesure que vous évoluez vers des rôles plus élevés en tant que CI, votre réalité se confond un peu avec votre rôle de leadership. Je n'ai pas de reporting et je ne manage personne, mais je passe beaucoup de temps avec mon manager sur des sujets qui relèvent davantage de l'aspect vision des choses. Mais je code toujours tous les jours, et comme tout le monde, je donne des avis et reçois des avis. C'est donc toujours un rôle d'IC. Chez Algolia, vous pouvez évoluer jusqu'à un niveau assez avancé et rester un contributeur individuel qui apprend à coder tous les jours.

"Tout ce qui est au-dessus de senior et vous commencez à consacrer beaucoup d'énergie à la stratégie - quelle est la vision, où sera le produit dans cinq ans, et comment allons-nous réussir sur ces choses ?"

Brian : Combien de temps pensez-vous passer à expédier par rapport à tout le reste du travail ? Partager le contexte, travailler sur la stratégie, ce genre de choses.

Sarah : C'est difficile à évaluer. Je dirais 50/50. Il y a des moments où je code beaucoup, et j'inclus des critiques dans le codage parce que c'est la même énergie que vous utilisez. Mais il y a aussi beaucoup de temps pour élaborer des stratégies, beaucoup de réunions, beaucoup de documents de vision, beaucoup de réflexion, beaucoup de conversations pour recueillir des commentaires, comme travailler avec des PM, des chercheurs, des concepteurs... tout cela fait partie du travail . Chez Algolia, vous avez des cadres supérieurs, un directeur, etc. Tout ce qui est au-dessus de senior et vous commencez à consacrer beaucoup d'énergie à la stratégie - quelle est la vision, où sera le produit dans cinq ans et comment allons-nous réussir sur ces choses ? Comment pouvons-nous nous assurer que, si nous ne réussissons pas, nous avons un plan de secours ? Tout ce que vous pourriez penser appliquer à un projet comme le codage lorsque vous êtes un ingénieur senior, vous l'appliquez à la stratégie du produit. Vous travaillez beaucoup sur le produit, et c'est l'une des choses que j'aime le plus dans le travail dans une startup technologique.

Quand j'étais en agence, vous ne faisiez aucune stratégie, vous ne disiez pas ce que vous pensiez et on ne s'attendait pas forcément à ce que vous donniez des conseils. Vous avez fait ce qu'on vous a dit. Mais lorsque vous êtes ingénieur dans une startup, en particulier à ces niveaux, votre voix et votre vision comptent beaucoup. Nous construisons des produits pour les ingénieurs. Et même si nous devons faire très attention à ne pas construire nous-mêmes - nous avons la malédiction de la connaissance, nous connaissons le produit, nous savons comment l'utiliser et nous connaissons toutes les mises en garde - nous sommes toujours sensibles à ce que les ingénieurs se soucient sur ce qu'ils veulent et ce qui rendra leur vie facile ou difficile. L'accent est donc mis sur le produit, sur la présentation d'idées, sur la remise en question des idées, sur la garantie que vous construisez la meilleure chose qui durera.

« Après avoir passé des années à réfléchir à la façon de devenir un meilleur ingénieur, vous aurez besoin d'un changement de mentalité pour commencer à penser à d'autres choses. Comment puis-je aider les autres ? Comment puis-je débloquer des situations ? »

Brian : Combien de temps passez-vous à travailler avec d'autres membres du personnel et des ingénieurs principaux au-delà de votre organisation ou de votre équipe ? Est-ce une communauté active dans votre entreprise ? Vous arrive-t-il de faire beaucoup de travail en collaboration avec cela ? Travaillez-vous en grande partie de manière indépendante dans vos groupes ? Ou y a-t-il un sous-ensemble d'autres ingénieurs seniors avec lesquels vous travaillez ?

Sarah : Pas autant que je le voudrais. Dans toute organisation, plus vous montez dans les niveaux, moins vous avez de personnes. Ce n'est donc pas comme s'il y avait une tonne d'IC ​​cinq, d'IC ​​six, d'employés et de directeurs. Nous embauchons beaucoup de cadres en ce moment, donc ma réponse pourrait être différente dans six mois. J'ai passé un temps normal à parler avec d'autres membres du personnel ou même des ingénieurs principaux, mais ce n'est pas comme s'il y avait une communauté ou quoi que ce soit d'officiel simplement parce que nous ne sommes pas si nombreux. Maintenant, j'ai passé beaucoup de temps à discuter avec des seniors et plus car cela fait partie de mon rôle.

Une partie de mon rôle consiste à aider les personnes au niveau supérieur à progresser et à être promues au niveau du personnel. En tant qu'ingénieur senior dans de nombreuses entreprises, en particulier de la taille d'Algolia, vous savez ce qu'il vous reste à faire pour y arriver. C'est plus une check-list. Après, ça se complique parce qu'il y a beaucoup de choses qui peuvent être sujettes à interprétation, des choses que tu peux faire très différemment d'une autre personne en fonction de ta personnalité. Mais l'idée est que, lorsque vous atteignez le niveau senior, nous nous attendons à ce que vous soyez optimal dans votre ensemble de compétences. Nous savons que vous êtes bon, que vous avez atteint un certain niveau technique, et nous ne nous attendons pas à ce que vous progressiez beaucoup plus haut que cela, mais on va vous demander de développer d'autres types de compétences.

«Nous devrions trouver ce dans quoi vous êtes doué, ce que vous aimez faire qui vous aidera à briller et cultiver cela. Il y a beaucoup de mentorat impliqué »

Après avoir passé des années à réfléchir à la façon de devenir un meilleur ingénieur, d'écrire un meilleur code, de faire de meilleures critiques ou d'avoir moins de commentaires lorsque vous recevez une critique, vous aurez besoin d'un changement d'état d'esprit pour commencer à penser à d'autres choses. Comment puis-je aider les autres ? Comment puis-je débloquer des situations ? Comment puis-je créer ma propre charge de travail ? Ce ne sont pas nécessairement des choses auxquelles vous devez penser avant d'atteindre ces niveaux. J'aide les gens à l'aborder, à comprendre ce qu'ils veulent dire et à comprendre quelle partie de leur personnalité ils vont pouvoir utiliser pour y arriver.

Certaines personnes aiment être sur scène et faire des conférences, par exemple. Et si c'est quelque chose qu'ils aiment, par tous les moyens, je devrais les aider à décrocher de meilleurs engagements de conférence et à rédiger de meilleurs appels à contributions. Mais si ce n'est pas votre truc, il n'y a aucune raison pour que nous investissions là-dedans. Nous devrions trouver ce dans quoi vous êtes doué, ce que vous aimez faire qui vous aidera à briller et cultiver cela. Il y a beaucoup de mentorat impliqué. C'est l'une de mes parties préférées d'être à ce niveau d'ancienneté.

Pour une entreprise, ce n'est pas vraiment intéressant d'avoir un employé ou un ingénieur senior - vous voulez en avoir 3, 5, 8, 16. Et la seule façon d'y parvenir est d'avoir les gens qui sont déjà là aider les gens qui sont un niveau inférieur. Vous ne pouvez pas vous attendre à ce que votre responsable technique le fasse tout seul avec toute l'équipe. Lorsque vous avez des ingénieurs qui aident d'autres ingénieurs à faire le travail qu'ils ont fait un an ou deux ans auparavant, vous avez cet effet multiplicateur. Et je pense que c'est vraiment excitant pour les gens parce qu'ils apprennent des autres, des gens qui ont suivi le processus dans la même organisation. Il est certain que s'ils suivent ces étapes, s'ils écoutent, cela pourrait fonctionner. Je veux apprendre des ingénieurs principaux qui peuvent m'aider à comprendre ce que je dois faire pour y arriver.

C'est particulièrement intéressant pour la personne qui enseigne, car elle peut disséquer ce qu'elle a réellement fait. Cela devient flou après, et vous vous dites : « Ouais, j'ai juste fait un peu de ceci, un peu de cela. Non. Qu'avez-vous fait ? Quelles sont les mesures concrètes que vous avez prises ? Quelles sont les choses auxquelles vous avez dit oui ? Quelles sont les choses auxquelles vous avez dit non ? Je pense que cela vous aide à clarifier vos idées, à clarifier votre processus et cela vous rend plus efficace pour les suivants.

Personnel d'intégration et ingénieurs

Brian : Vous avez mentionné l'intégration de nouveaux employés et d'ingénieurs principaux dans une organisation, ce qui peut être assez délicat. Est-ce quelque chose dont vous avez de l'expérience ?

Sarah : Ce n'est pas quelque chose que nous avons fait beaucoup, pour être honnête. Nous avons trois ou quatre ingénieurs principaux, et tous ne font pas partie de mon équipe. L'expérience que j'ai consiste principalement à faire venir des ingénieurs de haut niveau. Maintenant, il y a des choses qui sont communes à tout le monde, et puis il y a des choses qui pourraient être intéressantes pour les ingénieurs principaux, et je peux encore essayer de m'y mettre.

"Une personne très, très expérimentée peut vous aider pour beaucoup de choses, mais elle ne réglera pas les problèmes structurels de l'entreprise ou d'une équipe"

La clarté est extrêmement importante et, bien sûr, vous ne vous attendez pas à la même prise en main lorsque vous embauchez un membre du personnel ou un ingénieur principal. Vous voulez qu'ils soient autonomes. La clarté ne consiste pas à vous dire ce qu'on attend de vous, toutes les tâches, etc., mais plutôt à vous donner une idée de votre mission. Quel est votre but ici ? Que faites-vous ici? Et je dirais que cela commence au niveau de l'entretien. Ma recommandation pour un membre du personnel ou un ingénieur principal rejoignant une entreprise serait de poser des questions à ce sujet car parfois, les gens essaient d'embaucher des postes très supérieurs pour résoudre leurs problèmes. Ils disent : « Oh, embauchons simplement quelqu'un de très, très expérimenté parce qu'il sait des choses que nous ignorons. Et ce n'est pas vrai. Une personne très, très expérimentée peut vous aider dans de nombreux domaines, mais elle ne résoudra pas les problèmes structurels de l'entreprise ou d'une équipe.

Et d'un autre côté, un directeur de l'ingénierie devrait se demander pourquoi il pense avoir besoin de cette personne. La plupart du temps, vous n'engagez pas quelqu'un à ce niveau pour la grandeur du codage. Si vous avez un ingénieur senior dans votre équipe, ce serait IC 4 chez Algolia. Ils sont déjà parfaitement capables de coder, ou du moins ils devraient l'être. Un membre du personnel ou un ingénieur principal vient avec l'expérience de quelque chose que vous voulez faire, et vous pourriez en avoir besoin, par exemple, lorsque vous savez que vous devez atteindre une échelle que personne dans l'équipe n'a atteinte auparavant. Vous pourriez peut-être le comprendre, mais vous voulez un accélérateur, et c'est ce qu'une personne très expérimentée va faire dans votre équipe.

Poser ces questions à l'avance est un bon moyen de s'assurer qu'il n'y a pas de décalage par rapport à ce qui est attendu. Si vous êtes très expérimenté et qu'on vous demande de coder ou de travailler à un niveau supérieur simplement parce qu'il y a eu un désalignement, vous allez être déçu et vous allez probablement partir. Vous ne voulez pas passer beaucoup de temps à embaucher une personne à ce niveau juste pour la faire partir, car cela coûte extrêmement cher.

Après cela, je m'attendrais à ce que quelqu'un à ce niveau d'ancienneté fasse beaucoup de lecture et ait beaucoup de conversations. C'est quelque chose que vous ne faites généralement pas lorsque vous êtes un ingénieur junior. Vous venez dans votre organisation, on vous confie votre première tâche, et ça coule de source – vous commencez à travailler, vous commencez à coder, et c'est ce que vous devriez faire parce que c'est ce qui vous mènera à l'étape suivante.

« Votre rôle consiste à vous assurer que le produit livré conviendra et évoluera. Et vous ne pouvez pas le faire si vous n'en discutez pas avec d'autres personnes de l'entreprise. »

Mais lorsque vous êtes à ces niveaux supérieurs, il est important que vous compreniez où vous en êtes, ce qui se passe, qui fait quoi. Vous devez créer des relations non seulement avec d'autres ingénieurs et personnes expérimentées, mais aussi avec des personnes plus juniors, des chefs de produit, des concepteurs et des chercheurs. Vous devez comprendre le fonctionnement de l'entreprise et comment vous pouvez vous y intégrer, ce que vous pouvez aider à améliorer. S'il existe une documentation interne écrite, lisez-la et, lorsque vous avez terminé, lisez-la à nouveau.

Ensuite, demandez à votre directeur de l'ingénierie quelles sont les personnes que vous devriez rencontrer. Chaque fois que vous parlez à une nouvelle personne, demandez-lui à qui il serait intéressant de parler. Cela vous donnera des ailes car vous créerez des relations et comprendrez ce qui se passe. Quels sont les produits ? Quels sont les combats actuels ? Où pouvez-vous aider? Et comment votre équipe et les produits que vous construisez s'intègrent-ils dans ce schéma ? Parce qu'à ces niveaux, avec cette focalisation sur le produit, il ne s'agit plus seulement de la qualité du code. Les seniors de l'équipe s'en occupent déjà, et ils le font parfaitement bien. Votre rôle consiste à vous assurer que le produit livré conviendra et évoluera. Et vous ne pouvez pas le faire si vous n'en discutez pas avec d'autres personnes de l'entreprise.

Nouveaux défis

Brian : Pour les auditeurs qui ne connaissent pas, Algolia est une puissante API de recherche hébergée. Cela ressemble à une entreprise assez prospère de l'extérieur, mais je suis sûr qu'il y a beaucoup de défis et de choses dans votre esprit. Pourriez-vous nous donner une idée de certains des gros problèmes auxquels vous pensez ou sur lesquels vous travaillez?

"L'idée est que peu importe le chemin que vous empruntez pour rechercher ces données, les obtenir et atterrir sur la page, vous obtenez les bonnes données"

Sarah : Comme vous l'avez dit, Algolia est une API de recherche hébergée. C'est la plus grande API que nous ayons, et c'est la plus réussie pour l'instant, mais nous nous sommes également un peu développés. Actuellement, il existe un produit appelé Algolia Recommend, qui utilise le même ensemble de données que vous utilisez pour la recherche, mais basé sur un produit donné, il vous donne des recommandations.

Le but d'Algolia n'est pas seulement de rechercher mais de faire apparaître du contenu. Vous avez beaucoup de contenu, mais tout n'est pas pertinent en même temps pour les mêmes personnes. L'idée est que, quel que soit le chemin que vous empruntez pour rechercher ces données, les obtenir et atterrir sur la page, vous obtenez les bonnes données. C'est le point d'Algolia. Il y a des défis avec ça. Nous sommes des experts en recherche, mais l'aspect recommandation et apprentissage automatique est une technologie beaucoup plus récente, nous apprenons donc avec les dernières nouveautés. Nous avons beaucoup à apprendre par rapport à la recherche. Ce n'est pas le plus grand défi, mais c'est toujours un défi de s'assurer que nous pouvons réitérer le même succès que nous avons eu avec la recherche.

Maintenant, il y a des choses pour lesquelles Algolia n'est pas douée. C'est un moteur de recherche, pas une base de données. Ça va être rapide, ça finira par être cohérent, mais vous n'avez aucune garantie que vous aurez toutes vos données, que vos données seront toujours cohérentes ou que toutes vos données seront là. C'est un choix de conception autour du moteur de recherche, ce qui le rend très différent d'une base de données. Cela étant dit, beaucoup de gens aiment utiliser Algolia comme base de données car il est très facile d'envoyer des données à Algolia, et c'est là, et c'est rapide. Il y a peut-être quelque chose à apprendre à ce sujet. Il pourrait peut-être aussi s'agir d'une base de données, et je ne dis pas que ce sera le cas, mais peut-être que ce pourrait être le cas. Peut-être y a-t-il quelque chose d'autre que nous devons comprendre et rechercher.

Il existe de nombreux cas d'utilisation avec lesquels Algolia ne peut pas fonctionner. L'un d'eux est le cas d'utilisation de la réservation. Si vous souhaitez réserver un Airbnb, lorsque vous le recherchez, il apparaît dans vos résultats, ce qui signifie qu'il est disponible. Mais dès que vous atteignez la page, elle n'est plus disponible car vous répliquez vos données de votre base de données vers Algolia. Lorsque vous enregistrez quelque chose dans votre base de données, vous allez envoyer cette modification à Algolia dans un format légèrement différent. Et parce qu'il y a ce retard - ce n'est pas en temps réel - quelque chose comme le cas d'utilisation de la réservation ne peut pas fonctionner. Lorsque vous traitez avec Airbnbs, quelque chose de disponible en ce moment peut ne pas être disponible en 30 secondes, mais il peut toujours apparaître dans votre moteur de recherche car lorsque vous avez enregistré, vous avez peut-être besoin de 10 secondes ou quelque chose comme ça pour qu'il soit propagé à Algolia, et peut-être que cela a échoué et que vous devez le refaire. Ce sont des choses au niveau des moteurs de recherche auxquelles nous pensons. Est-ce quelque chose que nous pourrions jamais soutenir? Est-ce hors de question ? Quelle est l'analyse de rentabilisation derrière cela? Parce qu'il entraîne beaucoup de choses.

« Il devrait être invisible ; ça devrait être sans couture. Le fait qu'il s'agisse d'API distinctes n'est pas votre problème. C'est notre problème à résoudre"

Maintenant, concernant l'équipe frontale, j'ai mentionné Algolia Recommend. Lorsque vous êtes client, vous ne vous souciez pas vraiment du fait qu'il existe différents produits. Vous ne vous souciez pas d'avoir Algolia Search avec ces fonctionnalités et Algolia Recommend avec ces sous-fonctionnalités. Vous vous abonnez à Algolia et payez vos frais mensuels ou annuels pour un ensemble de fonctionnalités qui, selon vous, fonctionnent bien ensemble. Vous ne voulez pas et n'avez pas besoin de comprendre les frontières artificielles que nous avons créées en interne entre cette API et les API de données.

Il y a ce dicton, "n'expédiez pas votre organigramme", et je pense que c'est l'un des prochains grands sujets pour nous. Comment s'assurer qu'en amont, lorsque vous utilisez la bibliothèque frontale Algolia, vous n'ayez pas à vous demander si vous avez besoin de ceci ou de cela ? Que vous ne sentez pas ces limites ? Il devrait être invisible ; ça devrait être sans couture. Le fait qu'il s'agisse d'API distinctes n'est pas votre problème. C'est notre problème à résoudre.

Nous avons créé des bibliothèques qui étaient très fortement couplées à l'API de recherche, et maintenant nous devons nous étendre à de nouvelles API qui peuvent fonctionner ensemble, et parfois vous devez faire un appel à l'une, puis un appel à l'autre pour obtenir la réponse finale. Toutes ces choses en ce moment ne sont pas aussi transparentes que nous le souhaiterions. C'est encore un peu difficile sur les bords lorsque vous souhaitez connecter ces API ensemble. C'est possible, mais vous devez lire des tutoriels, suivre, faire un peu de changement ici et là et écrire du code passe-partout. Ce n'est pas délicieux, ce n'est pas amusant, et c'est trop de travail. Si nous devons vous dire « utilisez cette bibliothèque », elle doit faire un travail que vous ne voulez pas faire. Rien ne justifie l'utilisation de la bibliothèque si les primitives de niveau inférieur sont aussi faciles à utiliser, n'est-ce pas ?

À l'heure actuelle, l'un des plus grands défis est de s'assurer que nous augmentons la valeur des bibliothèques. Ils font déjà beaucoup de choses que la plupart des gens ne veulent pas faire, mais à un certain moment, pour certains clients, ce n'est plus aussi transparent et agréable qu'avant lorsque nous n'avions que la recherche. Et c'est le sentiment que nous recherchons. Ce sentiment de "Wow, c'est tellement plus simple que je ne le pensais."

Brian : Enfin, où nos auditeurs peuvent-ils aller pour vous suivre ?

Sarah : Vous pouvez donc me trouver principalement sur Twitter, je suis frontstuff_io. Je suis douloureusement conscient que c'est la pire poignée sur Twitter. Vous pouvez aussi me retrouver sur sarahdayan.com et me suivre sur GitHub si vous le souhaitez ; Je commets des choses parfois. Mais oui, si vous voulez discuter, je crois que mes DM sont ouverts, alors envoyez-moi n'importe quoi.

Brian : Super. Sarah, merci beaucoup de m'avoir rejoint aujourd'hui.

Sarah : Merci de m'avoir invité. C'était amusant.