Sarah Dayan de Algolia sobre lo que distingue a un ingeniero senior

Si bien siempre se aprecian las buenas habilidades de codificación, ser un ingeniero más personal exige mucho más que solo su destreza técnica. ¿Qué se necesita para llegar allí y, lo que es más importante, dónde puede tener el mayor impacto en su organización?

Cuando alcanza el nivel superior en una pista de ingeniería, se espera que sea óptimo en su conjunto de habilidades duras. Eres autónomo, tu código es inmaculado y tienes un conocimiento profundo de la creación y el envío de software. Pero entrar en roles de personal más es otra bestia completamente diferente. Está la gestión de proyectos, la tutoría y la enseñanza, la toma de decisiones, la creación de relaciones, y el valor que aporta a la empresa ya no se mide por la calidad de las líneas de su código, sino por impulsar la organización de ingeniería.

El invitado de hoy ha pasado por eso. Sarah Dayan es ingeniera de planta en Algolia, una plataforma de "búsqueda como servicio" que ayuda a los desarrolladores a crear capacidades de indexación y búsqueda en sus propias plataformas a través de una API, y la anfitriona de dos podcasts tecnológicos: Developer Experience y Entre Devs. Crea bibliotecas front-end, un rol que se adapta perfectamente a ella dada su pasión de toda la vida por la experiencia del usuario, el diseño y la construcción de cosas. De hecho, Sarah ha estado obsesionada con la creación de sitios web desde que sus padres instalaron Internet de banda ancha en su sótano. Fue amor al primer clic. Creó su primer foro de phpBB a los 15 años, escribió su primera página HTML poco después y no ha dejado de crear cosas desde entonces.

A pesar de no tener una educación formal en ingeniería, Sarah consiguió un trabajo como desarrolladora en la consultora francesa Grand Manitou. Luego, hace cuatro años, en 2018, consiguió un trabajo en Algolia como ingeniera de software. Ascendió diligentemente a través de las filas, y finalmente se convirtió en el rol de colaboradora individual de una ingeniera del personal. Y de repente, todo lo que le importaba en los últimos años (convertirse en una mejor ingeniera, escribir mejor código) dio paso a nuevos desafíos. ¿Cómo proporcionaría la dirección técnica adecuada para la empresa? ¿Desbloquear cuellos de botella? ¿Ser mentora y ayudar a otros ingenieros como otros habían hecho por ella?

En este episodio, nos sentamos con Sarah para hablar sobre los muchos matices, las competencias y las expectativas de un puesto de personal e ingeniero.

Estas son algunas de nuestras conclusiones favoritas de la conversación:

• Si no quieres quedarte atrás, sigue aprendiendo. Discuta ideas y obtenga comentarios de otros ingenieros con diferentes perspectivas y antecedentes.
• Como ingeniero de personal, gran parte de su energía se dedica a la colaboración entre equipos para la visión y la estrategia. ¿Dónde estará la empresa dentro de cinco años? ¿Cómo vas a llegar allí?
• Tener ingenieros de plantilla como mentores permite que más personas jóvenes obtengan claridad sobre los pasos a seguir para alcanzar esos roles y acelerar el proceso de creación de líderes de ingeniería.
• Contrariamente a la creencia popular, un ingeniero de personal no es una solución rápida para un problema estructural. Antes de aceptar un nuevo trabajo, pregunte qué se espera de usted para evitar malentendidos en el futuro.
• Los ingenieros del personal deben comprender las necesidades de la empresa para poder ayudarla a alcanzar sus objetivos. Durante la incorporación, lea toda la documentación y hable con tantas personas como pueda.

Si disfruta de nuestra discusión, vea más episodios de nuestro podcast. Puede seguir en iTunes, Spotify, YouTube o tomar la fuente RSS en su reproductor de elección. Lo que sigue es una transcripción ligeramente editada del episodio.

Nunca dejes de aprender

Brian Scanlan: Muchas gracias, Sarah, por acompañarnos en el programa de hoy. Estoy encantado de tener la oportunidad de hablar contigo. Antes de que hablemos sobre su rol y trabajo en Algolia, me encantaría saber sobre su viaje hasta este punto. ¿Cómo comenzó tu viaje hasta donde estás hoy?

Sarah Dayan: Bueno, hola, gracias por recibirme. Bueno, en realidad es una historia graciosa. Actualmente tengo 32 años, y teníamos banda ancha e Internet ilimitado en casa cuando tenía 15 años. Siempre me gustó construir cosas, y la primera vez que vi sitios web, pensé: "Tengo que saber cómo hacer eso". Una cosa llevó a la otra y construí mi primer foro con phpBB. PHP era muy, muy grande, y sigue siendo grande, pero en ese entonces era realmente el lenguaje para la web.

“Decidí que esto no era lo mío, que tal vez debería estar haciendo lo que amaba. Así que volví a lo que amaba: crear sitios web”

En aquel entonces, tener una carrera en tecnología, especialmente como ingeniero de software, no era tan atractivo como lo es hoy. Mis padres pensaron que debería considerar convertirme en periodista porque era bueno en idiomas y literatura en la escuela. Y eso fue lo primero que hice. Hice mi primer año de periodismo, que fracasé por completo, y luego decidí que esto no era lo mío, que tal vez debería estar haciendo lo que amaba. Entonces, volví a lo que amaba: crear sitios web. Conseguí mi primer trabajo en una agencia y pasé seis años allí. Me enseñó mucho sobre el trabajo, sobre trabajar con clientes, con personas que saben lo que quieren y personas que no saben lo que quieren. Luego, me mudé al mundo de las startups. He estado programando durante más de 15 años, pero profesionalmente lo he estado haciendo durante 12. Y esto es lo que me llevó a mi puesto actual en Algolia. He estado allí durante cuatro años y contando.

Brian: Súper. ¿Tienes alguna lección interesante que aprendiste desde el principio que te haya quedado grabada?

Sarah: No tengo un camino clásico hacia la tecnología. No fui a la escuela de ingeniería, y es posible tener una gran carrera en tecnología si no haces eso. Definitivamente puedes ser autodidacta, puedes aprender de otras personas y no tienes que tener un título. Pero no tener un título no es una excusa para no aprender. Hay una excelente publicación de blog de Sarah Drasner, gerente de ingeniería de Google, en CSS-Tricks sobre eso. Aunque puedes tener una carrera en tecnología sin un título, no te exime de aprender y buscar conocimiento.

“No recibí retroalimentación, no entré en conversaciones con otras personas: con otros ingenieros, con otras perspectivas, otros antecedentes. Y entonces me quedé atrás”

Y una cosa que realmente aprendes en la escuela es aprender a aprender, y esa es una habilidad muy importante. Al principio de mi carrera, en la agencia de la que les hablé, fui el único empleado durante mucho tiempo. Estaba completamente solo. Y tenía a mi jefe, que también estaba codificando pero estaba un poco alejado de las cosas que yo estaba haciendo. Y aunque puede ser liberador trabajar solo (tienes mucha confianza, mucha libertad), no aprendes tan rápido porque no tienes comentarios ni otras perspectivas aparte de la tuya. Y si ni siquiera haces ningún aprendizaje activo, te vas a quedar atrás.

Esa es una de las cosas que me pasó. No recibí retroalimentación, no entré en conversaciones con otras personas: con otros ingenieros, con otras perspectivas, otros antecedentes. Y así me quedé atrás. Confiaba en el conocimiento que tenía y no tenía motivos para hacer las cosas de manera diferente porque funcionó. Esa sería una de las lecciones más importantes que aprendí al principio de mi carrera. Especialmente si no tiene un viaje clásico en tecnología, rodearse de otras personas que le brindan comentarios y sus perspectivas es invaluable, y va a potenciar su carrera.

Brian: Creo que es un gran consejo para cualquier persona en cualquier rol profesional, pero parece que realmente funcionó para ti. ¿Echa de menos algo de no trabajar con PHP en estos días?

Sarah: Creo que PHP es un gran lenguaje. Puede encontrar mucha inspiración de PHP en JavaScript moderno. Ya no trabajo con él porque JavaScript ha evolucionado hasta un punto en el que puedes usarlo donde quieras usar PHP. Y especialmente como ingeniero front-end, existen muchas ventajas al usar el mismo lenguaje en el front-end y en el back-end, como compartir. Pero creo que PHP es un gran lenguaje. Recibe muchos chistes malos y el, "Oh, PHP está muerto", pero cuando miras el éxito de algo como Laravel, siento que PHP está lejos de estar muerto.

Cuando entré en PHP, el marco que usaba la gente seria se llamaba marco Zen. En realidad, creo que Zen es la compañía detrás de PHP, o al menos eso lo recuperó. Ya nadie usa el marco Zen, al menos no para ningún proyecto nuevo, pero es genial ver dónde se encuentra PHP en este momento. Todavía está floreciendo, la gente disfruta de la codificación en PHP, y creo que eso es genial. No es para todos, pero tú sí. Todos pueden tener un asiento en la mesa con el idioma que les gusta.

Subiendo la escalera de la ingeniería

Brian: Actualmente eres ingeniero de planta en Algolia. Cuéntame un poco sobre ese rol y en qué trabajas, y pasaremos a lo que es un ingeniero de personal.

sara: por supuesto Soy un ingeniero de personal y trabajo en el front-end. Estoy en un equipo llamado experiencias front-end, FX para abreviar, y trabajamos en bibliotecas front-end para Algolia. Algolia es un motor de búsqueda, por lo que es integral. Tiene el motor y algunos clientes API en varios idiomas para enviar sus datos a la búsqueda, pero también tiene bibliotecas front-end, porque ¿quién tiene tiempo para crear un cuadro de búsqueda funcional accesible, una lista de aciertos, una lista de refinamiento o un menú jerárquico?

Todas esas cosas son difíciles de implementar correctamente. Así que hacemos eso por los clientes, y ese es el equipo en el que estoy trabajando. Soy un colaborador individual (IC) y no estoy en ningún camino de liderazgo. Pero la cosa es que, a medida que creces a roles más altos como IC, tu realidad se mezcla un poco con tu rol de liderazgo. No tengo ningún informe y no administro a nadie, pero paso mucho tiempo con mi gerente en temas que están más relacionados con el aspecto de la visión de las cosas. Pero sigo codificando todos los días y, como todo el mundo, doy reseñas y recibo reseñas. Así que sigue siendo un papel de IC. En Algolia, puede crecer hasta un nivel bastante avanzado y seguir siendo un colaborador individual que codifica todos los días.

“Cualquier cosa por encima de senior y comienzas a verter mucha energía en la estrategia: ¿cuál es la visión, dónde estará el producto en cinco años y cómo vamos a tener éxito en esas cosas?”

Brian: ¿Cuánto tiempo crees que dedicas al envío en comparación con el resto del trabajo? Compartir contexto, trabajar en la estrategia, ese tipo de cosas.

Sarah: Eso es difícil de medir. Yo diría 50/50. Hay momentos en los que codifico mucho e incluyo revisiones en la codificación porque es la misma energía que usas tú. Pero también hay mucho tiempo en la elaboración de estrategias, muchas reuniones, muchos documentos de visión, mucho pensamiento, muchas conversaciones para recopilar comentarios, como trabajar con PM, investigadores, diseñadores... todo eso es parte del trabajo. . En Algolia tienes personal senior, director, etcétera. Cualquier cosa por encima de senior y comienzas a verter mucha energía en la estrategia: ¿cuál es la visión, dónde estará el producto en cinco años y cómo vamos a tener éxito en esas cosas? ¿Cómo podemos asegurarnos de que, si no tenemos éxito, tenemos un plan de respaldo? Cualquier cosa que se te ocurra aplicar a un proyecto como la codificación cuando eres un ingeniero sénior, lo aplicas a la estrategia del producto. Trabajas mucho en el producto, y esa es una de las cosas que más me gustan de trabajar en una startup tecnológica.

Cuando estaba en una agencia, no hacías ninguna estrategia, no decías lo que pensabas y no se esperaba necesariamente que dieras consejos. Hiciste lo que te dijeron. Pero cuando eres ingeniero en una startup, especialmente en esos niveles, tu voz y tu visión importan mucho. Estamos construyendo productos para ingenieros. Y aunque tenemos que tener mucho cuidado de no construir cosas por nosotros mismos (tenemos la maldición del conocimiento, conocemos el producto, sabemos cómo usarlo y conocemos todas las advertencias), seguimos siendo sensibles a lo que les importa a los ingenieros. sobre lo que quieren y lo que les facilitará o dificultará la vida. Por lo tanto, hay un gran énfasis en el producto, en traer ideas a la mesa, en ideas desafiantes, en asegurarse de construir lo mejor que dure.

“Después de pasar años pensando en cómo convertirte en un mejor ingeniero, necesitarás un cambio de mentalidad para comenzar a pensar en otras cosas. ¿Cómo puedo ayudar a otras personas? ¿Cómo puedo desbloquear situaciones?”

Brian: ¿Cuánto tiempo pasa trabajando con otro personal e ingenieros principales más allá de su organización o equipo? ¿Es esa una comunidad activa en su empresa? ¿Puedes hacer mucho trabajo en colaboración con eso? ¿Trabaja en gran medida de forma independiente en sus grupos? ¿O hay un subconjunto de otros ingenieros senior con los que está trabajando?

Sarah: No tanto como me gustaría. En cualquier organización, cuanto más subes de nivel, menos personas tienes. Así que no es que haya un montón de IC cinco, IC seis, personal y director. Estamos contratando a muchas personas mayores en este momento, por lo que mi respuesta podría ser diferente en seis meses. Pasé una cantidad normal de tiempo hablando con otros miembros del personal o incluso con los ingenieros principales, pero no es como si hubiera una comunidad o algo oficial solo porque no somos tantos. Ahora, pasé mucho tiempo discutiendo con personas mayores y superiores porque eso es parte de mi función.

Parte de mi función es ayudar a las personas de alto nivel a crecer y ser promovidas a nivel de personal. Como ingeniero sénior en muchas empresas, especialmente del tamaño de Algolia, sabe lo que debe hacer para llegar allí. Es más una lista de verificación. Después de eso, se vuelve más complicado porque hay muchas cosas que podrían depender de la interpretación, cosas que puedes hacer de manera muy diferente a otra persona según tu personalidad. Pero la idea es que, cuando llegue al nivel superior, esperamos que sea óptimo en su conjunto de habilidades. Sabemos que eres bueno, estás en cierto nivel técnico y no esperamos que crezcas mucho más que eso, pero se te pedirá que desarrolles otro tipo de habilidades.

“Deberíamos encontrar en qué eres bueno, qué te gusta hacer que te ayudará a brillar y cultivar eso. Hay mucha tutoría involucrada”

Después de pasar años pensando en cómo convertirse en un mejor ingeniero, escribir mejor código, hacer mejores revisiones o tener menos comentarios cuando recibe una revisión, necesitará un cambio de mentalidad para comenzar a pensar en otras cosas. ¿Cómo puedo ayudar a otras personas? ¿Cómo puedo desbloquear situaciones? ¿Cómo puedo crear mi propia carga de trabajo? Estas no son necesariamente cosas en las que debe pensar antes de alcanzar esos niveles. Ayudo a las personas a abordarlo, entender lo que quieren decir y comprender qué parte de su personalidad podrán usar para llegar allí.

A algunas personas les encanta estar en el escenario y dar charlas, por ejemplo. Y si esto es algo que les gusta, por todos los medios, debería ayudarlos a conseguir mejores compromisos en conferencias y escribir mejores convocatorias de artículos. Pero si esto no es lo tuyo, no hay razón por la que debamos invertir en eso. Debemos encontrar en qué eres bueno, qué te gusta hacer que te ayudará a brillar y cultivar eso. Hay mucha tutoría involucrada. Esta es una de mis partes favoritas de estar en este nivel de antigüedad.

Para una empresa, no es realmente interesante tener un solo miembro del personal o un ingeniero senior: desea tener 3, 5, 8, 16. Y la única forma en que podrá hacerlo es tener personas que estén ya hay ayuda a las personas que están un nivel más abajo. No puede esperar que su gerente de ingeniería haga eso solo con todo el equipo. Cuando tienes ingenieros que ayudan a otros ingenieros a hacer el trabajo que hicieron uno o dos años antes, tienes este efecto multiplicador. Y creo que esto es realmente emocionante para las personas porque pueden aprender de otros, de personas que realmente pasaron por el proceso en la misma organización. Hay confianza en que, si siguen esos pasos, si escuchan, podría funcionar. Quiero aprender de los principales ingenieros que puedan ayudarme a comprender lo que debo hacer para llegar allí.

Es particularmente interesante para la persona que enseña porque puede diseccionar lo que realmente hizo. Después se vuelve borroso y dices: "Sí, acabo de hacer un poco de esto, un poco de aquello". No. ¿Qué hiciste? ¿Cuáles son los pasos concretos que tomó? ¿Cuáles son las cosas a las que dijiste que sí? ¿Cuáles son las cosas a las que dijiste que no? Creo que te ayuda a aclarar tus ideas, aclarar tu proceso y te hace más eficiente para los siguientes.

Incorporación de personal e ingenieros

Brian: Mencionaste incorporar nuevo personal e ingenieros principales a una organización, lo cual puede ser bastante complicado. ¿Es esto algo con lo que tienes experiencia?

Sarah: Esto no es algo que hayamos hecho mucho, para ser honesto. Tenemos tres o cuatro ingenieros principales y no todos están en mi equipo. La experiencia que tengo es principalmente con traer ingenieros senior. Ahora, hay cosas que son comunes a todos, y luego hay cosas que podrían ser interesantes para los ingenieros principales, y todavía puedo intentarlo.

“Una persona muy, muy senior te puede ayudar en muchas cosas, pero no va a solucionar problemas estructurales de la empresa o de un equipo”

La claridad es extremadamente importante y, por supuesto, no espera la misma atención cuando contrata personal o un ingeniero principal. Quieres que sean emprendedores. La claridad no se trata de decirte lo que se espera de ti, todas las tareas, etcétera, sino de darte un sentido de tu misión. ¿Cuál es tu propósito aquí? ¿Qué estás haciendo aquí? Y yo diría que esto comienza en el nivel de la entrevista. Mi recomendación para un miembro del personal o un ingeniero principal que se una a una empresa sería preguntar sobre eso porque, a veces, las personas intentan contratar puestos de alto nivel para solucionar sus problemas. Son como, "Oh, contratemos a alguien muy, muy senior porque sabe cosas que nosotros no". Y eso no es cierto. Una persona muy, muy senior puede ayudarte con muchas cosas, pero no va a solucionar los problemas estructurales de la empresa o de un equipo.

Y por otro lado, un gerente de ingeniería debería preguntarse por qué cree que necesita a esa persona. La mayoría de las veces, no contratas a alguien de este nivel para codificar la grandeza. Si tiene un ingeniero senior en su equipo, ese sería IC cuatro en Algolia. Ya son perfectamente capaces de codificar, o al menos deberían serlo. Un ingeniero principal o del personal viene con la experiencia de algo que usted quiere hacer y es posible que los necesite, por ejemplo, cuando sabe que necesita alcanzar una escala que nadie en el equipo ha alcanzado antes. Tal vez podrías resolverlo, pero quieres un acelerador, y esto es lo que una persona muy importante hará en tu equipo.

Hacer esas preguntas de antemano es una buena manera de asegurarse de que no haya desalineación con lo que se espera. Si eres muy senior y te piden que codifiques o trabajes en un nivel senior solo porque hubo una desalineación, te sentirás decepcionado y es probable que te vayas. No desea pasar mucho tiempo contratando a una persona en este nivel solo para que se vaya porque es extremadamente costoso.

Después de eso, esperaría que alguien con este nivel de antigüedad leyera mucho y tuviera muchas conversaciones. Esto es algo que normalmente no haces cuando eres un ingeniero junior. Llegas a tu organización, te asignan tu primera tarea y simplemente fluye: comienzas a trabajar, comienzas a codificar y esto es lo que debes hacer porque esto es lo que te llevará al siguiente paso.

“Su función es asegurarse de que el producto entregado se ajuste y se amplíe. Y no puedes hacer eso si no lo comentas con otras personas en la empresa”

Pero cuando estás en esos niveles superiores, es importante que entiendas dónde estás, qué está pasando, quién hace qué. Debe crear relaciones no solo con otros ingenieros y personas de alto nivel, sino también con personas más jóvenes, gerentes de productos, diseñadores e investigadores. Debe comprender la forma en que funciona la empresa y cómo puede encajar en eso, qué puede ayudar a mejorar. Si hay alguna documentación interna escrita, léala y, cuando haya terminado, léala de nuevo.

Luego, pregúntele a su gerente de ingeniería quiénes son las personas con las que debe reunirse. Cada vez que hables con una persona nueva, pregúntale con quién cree que sería interesante hablar contigo. Esto te dará alas porque crearás relaciones y entenderás lo que está pasando. ¿Cuáles son los productos? ¿Cuáles son las luchas actuales? ¿Dónde puedes ayudar? ¿Y cómo encaja su equipo y los productos que está construyendo en ese esquema? Porque a esos niveles, con este enfoque en el producto, ya no se trata solo de la calidad del código. Los veteranos del equipo ya se están encargando de eso, y lo están haciendo perfectamente bien. Su función es asegurarse de que el producto entregado se ajuste y se amplíe. Y no puede hacer eso si no lo discute con otras personas en la empresa.

Nuevos desafios

Brian: Para los oyentes que no saben, Algolia es una potente API de búsqueda alojada. Parece una empresa bastante exitosa desde el exterior, pero estoy seguro de que hay muchos desafíos y cosas en mente. ¿Podrías darnos una idea de algunos de los grandes problemas en los que estás pensando o en los que estás trabajando?

“La idea es que, independientemente del camino que tome para buscar esos datos, obtenerlos y llegar a la página, aparecerán los datos correctos”.

Sarah: Como dijiste, Algolia es una API de búsqueda alojada. Esa es la API más grande que tenemos y es la más exitosa por ahora, pero también nos hemos expandido un poco. Actualmente, hay un producto llamado Algolia Recommend, que utiliza el mismo conjunto de datos que usa para la búsqueda, pero en función de un producto determinado, le brinda recomendaciones.

El objetivo de Algolia no es solo buscar, sino mostrar contenido. Tienes mucho contenido, pero no todo es relevante al mismo tiempo para las mismas personas. La idea es que, independientemente del camino que tome para buscar esos datos, obtenerlos y llegar a la página, obtendrá los datos correctos. Este es el punto de Algolia. Hay desafíos con eso. Somos expertos en búsquedas, pero el aspecto de recomendación y aprendizaje automático es una tecnología mucho más nueva, por lo que estamos aprendiendo con las últimas novedades. Tenemos mucho que aprender en comparación con la búsqueda. Este no es el mayor desafío, pero aún es un desafío asegurarnos de que podamos reiterar el mismo éxito que tuvimos con la búsqueda.

Ahora, hay cosas en las que Algolia no es buena. Es un motor de búsqueda, no una base de datos. Será rápido, eventualmente será consistente, pero no tiene la garantía de que tendrá todos sus datos, que sus datos siempre serán consistentes o que todos sus datos estarán allí. Esa es una elección de diseño en torno al motor de búsqueda, lo que lo hace muy diferente de una base de datos. Dicho esto, a mucha gente le gusta usar Algolia como base de datos porque es muy fácil enviar datos a Algolia, está ahí y es rápido. Tal vez hay algo que aprender sobre eso. Tal vez también podría ser una base de datos, y no digo que vaya a serlo, pero tal vez podría serlo. Tal vez hay algo más por ahí que tenemos que entender e investigar.

Hay muchos casos de uso con los que Algolia no puede trabajar. Uno de ellos es el caso de uso de reserva. Si desea reservar un Airbnb, cuando lo busca, aparece en sus resultados, lo que significa que está disponible. Pero tan pronto como llega a la página, ya no está disponible porque replica sus datos desde su base de datos a Algolia. Cuando guarde algo en su base de datos, enviará ese cambio a Algolia en un formato ligeramente diferente. Y debido a que existe ese retraso, esto no es en tiempo real, algo como el caso de uso de la reserva no puede funcionar. Cuando se trata de Airbnbs, es posible que algo disponible en este momento no esté disponible en 30 segundos, pero aún puede aparecer en su motor de búsqueda porque cuando guardó, necesita tal vez 10 segundos o algo así para que se propague a Algolia, y tal vez falló y necesitas hacerlo de nuevo. Esas son cosas a nivel de motor de búsqueda en las que estamos pensando. ¿Es algo que alguna vez podríamos apoyar? ¿Está fuera de discusión? ¿Cuál es el caso de negocio detrás de eso? Porque impulsa muchas cosas.

“Debería ser invisible; debe ser impecable. El hecho de que sean API separadas no es su problema. Ese es nuestro problema a resolver”

Ahora, con respecto al equipo de front-end, mencioné Algolia Recommend. Cuando eres un cliente, realmente no te importa que haya diferentes productos. No le importa tener Algolia Search con esas características y Algolia Recommend con esas subcaracterísticas. Usted se suscribe a Algolia y paga su tarifa mensual o anual por un conjunto de características que le dicen que funcionan bien juntas. No desea ni necesita comprender los límites artificiales que creamos internamente entre esta API y las API de datos.

Existe este dicho, "no envíes tu organigrama", y creo que este es uno de los próximos grandes temas para nosotros. ¿Cómo podemos asegurarnos de que, en el front-end, cuando usa la biblioteca front-end de Algolia, no tiene que preguntarse si necesita esto o aquello? ¿Que no sientes esos límites? Debería ser invisible; debe ser impecable. El hecho de que sean API separadas no es su problema. Ese es nuestro problema a resolver.

Creamos bibliotecas que estaban fuertemente acopladas a la API de búsqueda, y ahora tenemos que expandirnos a API más nuevas que puedan funcionar juntas y, a veces, es necesario llamar a una y luego llamar a otra para obtener la respuesta final. Todas esas cosas en este momento no son tan fluidas como nos gustaría que fueran. Todavía es un poco tosco en los bordes cuando desea conectar esas API juntas. Es posible, pero debe leer los tutoriales, seguirlos, hacer un pequeño cambio aquí y allá y escribir un código repetitivo. Esto no es delicioso, esto no es divertido y es demasiado trabajo. Si vamos a decirle, "use esa biblioteca", necesita hacer un trabajo que no quiere hacer. No hay justificación para usar la biblioteca si las primitivas de nivel inferior son tan fáciles de usar, ¿verdad?

En este momento, uno de los mayores desafíos es asegurarnos de aumentar el valor de las bibliotecas. Ya están haciendo muchas cosas que la mayoría de la gente no quiere hacer, pero en cierto punto, para ciertos clientes, no es tan sencillo y agradable como solía ser cuando solo teníamos búsqueda. Y este es el sentimiento que buscamos. Ese sentimiento de, "Wow, es mucho más simple de lo que pensé que sería".

Brian: Por último, ¿dónde pueden ir nuestros oyentes para mantenerse al día con usted?

Sarah: Puedes encontrarme principalmente en Twitter, soy frontstuff_io. Soy dolorosamente consciente de que este es el peor manejo en Twitter. También puedes encontrarme en sarahdayan.com y seguirme en GitHub si quieres; A veces cometo cosas. Pero sí, si quieres chatear, creo que mis DM están abiertos, así que envíame cualquier cosa.

Brian: Súper. Sarah, muchas gracias por acompañarme hoy.

Sara: Gracias por recibirme. Eso fue divertido.