Sarah Dayan, da Algolia, sobre o que diferencia um engenheiro sênior

Embora boas habilidades de codificação sejam sempre apreciadas, ser uma equipe e um engenheiro exige muito mais do que apenas suas proezas técnicas. O que é preciso para chegar lá e, mais importante, onde você pode ter o maior impacto em sua organização?

Quando você alcança o nível sênior em uma trilha de engenharia, espera-se que você seja ótimo em seu conjunto de habilidades. Você é autônomo, seu código é imaculado e você tem um profundo conhecimento da construção e envio de software. Mas entrar na equipe e nos papéis é outra besta. Há gerenciamento de projetos, orientação e ensino, tomada de decisões, construção de relacionamentos, e o valor que você traz para a empresa não é mais medido pela qualidade das linhas do seu código, mas sim pelo avanço da organização de engenharia.

O convidado de hoje já passou por isso. Sarah Dayan é engenheira de equipe na Algolia, uma plataforma “Search-as-a-Service” que ajuda os desenvolvedores a criar recursos de índice e pesquisa em suas próprias plataformas por meio de uma API e hospeda dois podcasts de tecnologia: Developer Experience e Entre Devs. Ela cria bibliotecas de front-end, uma função que combina perfeitamente com ela, dada sua paixão ao longo da vida pela experiência do usuário, design e construção de coisas. Na verdade, Sarah é obcecada em criar sites desde que seus pais instalaram internet banda larga em seu porão. Foi amor ao primeiro clique. Ela montou seu primeiro fórum phpBB aos 15 anos, escreveu sua primeira página HTML pouco depois disso, e não parou de construir coisas desde então.

Apesar de não ter formação em engenharia, Sarah conseguiu um emprego como desenvolvedora na consultora francesa Grand Manitou. Então, há quatro anos, em 2018, ela conseguiu um emprego na Algolia como engenheira de software. Ela diligentemente subiu na hierarquia, finalmente crescendo na função de colaboradora individual de uma engenheira de equipe. E, de repente, tudo com que ela se importava nos últimos anos – tornar-se uma engenheira melhor, escrever código melhor – abriu caminho para novos desafios. Como ela forneceria a direção técnica certa para a empresa? Desbloquear gargalos? Orientar e ajudar outros engenheiros como outros haviam feito por ela?

Neste episódio, sentamos com Sarah para falar sobre as muitas nuances, proficiências e expectativas de uma função de equipe e engenheiro.

Aqui estão alguns dos nossos tópicos favoritos da conversa:

• Se você não quer ficar para trás, continue aprendendo. Discuta ideias e obtenha feedback de outros engenheiros com diferentes perspectivas e experiências.
• Como engenheiro de equipe, grande parte de sua energia vai para a colaboração entre equipes para a visão e a estratégia. Onde a empresa estará em cinco anos? Como você vai chegar lá?
• Ter engenheiros de equipe como mentores permite que mais pessoas juniores tenham clareza sobre quais etapas devem ser seguidas para alcançar essas funções e você agiliza o processo de criação de líderes de engenharia.
• Ao contrário da crença popular, um engenheiro de equipe não é uma solução rápida para um problema estrutural. Antes de aceitar um novo emprego, pergunte o que se espera de você para evitar mal-entendidos no futuro.
• Os engenheiros de equipe devem entender as necessidades da empresa para que possam ajudá-la a atingir seus objetivos. Durante a integração, leia o máximo de documentação e fale com o maior número de pessoas possível.

Se você gosta de nossa discussão, confira mais episódios do nosso podcast. Você pode seguir no iTunes, Spotify, YouTube ou pegar o feed RSS no player de sua escolha. O que se segue é uma transcrição levemente editada do episódio.

Nunca pare de aprender

Brian Scanlan: Muito obrigado, Sarah, por se juntar a nós no programa hoje. Estou muito feliz por ter a oportunidade de falar com você. Antes de falarmos sobre sua função e trabalho na Algolia, adoraria ouvir sobre sua jornada até aqui. Como começou sua jornada até onde você está hoje?

Sarah Dayan: Bem, olá, obrigada por me receber. Bem, isso é realmente uma história engraçada. Atualmente tenho 32 anos, e tínhamos banda larga e internet ilimitada em casa quando eu tinha 15 anos. Sempre gostei de construir coisas e, na primeira vez que vi sites, pensei: “Tenho que saber como fazer isso”. Uma coisa levou a outra, e eu construí meu primeiro fórum com phpBB. PHP era muito, muito grande, e ainda é grande, mas era realmente a linguagem para a web naquela época.

“Decidi que isso não era coisa minha, que talvez eu devesse fazer o que eu amava. Então, voltei para o que eu amava – construir sites”

Naquela época, ter uma carreira em tecnologia, especialmente como engenheiro de software, não era tão legal e quente como é hoje. Meus pais achavam que eu deveria me tornar jornalista porque eu era boa em línguas e literatura na escola. E foi a primeira coisa que fiz. Fiz meu primeiro ano de jornalismo, no qual falhei completamente, e então decidi que não era minha praia, que talvez eu devesse fazer o que eu amava. Então, voltei para o que eu amava – construir sites. Consegui meu primeiro emprego em uma agência e passei seis anos lá. Isso me ensinou muito sobre o trabalho, sobre como trabalhar com clientes, com pessoas que sabem o que querem e pessoas que não sabem o que querem. Então, eu me mudei para o mundo das startups. Codifico há mais de 15 anos, mas profissionalmente faço isso há 12. E foi isso que me levou ao meu cargo atual na Algolia. Estou lá há quatro anos e contando.

Brian: Super. Você tem alguma lição interessante que aprendeu no início que ficou com você?

Sarah: Eu não tenho um caminho clássico para a tecnologia. Não fiz faculdade de engenharia e é possível ter uma ótima carreira em tecnologia se você não fizer isso. Você pode definitivamente ser autodidata, pode aprender com outras pessoas e não precisa ter um diploma. Mas não ter um diploma não é desculpa para não aprender. Há uma ótima postagem no blog de Sarah Drasner, gerente de engenharia do Google, sobre CSS-Tricks sobre isso. Mesmo que você possa ter uma carreira em tecnologia sem um diploma, isso não o isenta de aprender e buscar conhecimento.

“Não recebi feedback, não entrei em conversas com outras pessoas: com outros engenheiros, com outras perspectivas, outras origens. E assim eu fiquei para trás”

E uma coisa que você realmente aprende na escola é aprender a aprender, e essa é uma habilidade muito importante. No início da minha carreira, na agência que te falei, fui o único funcionário por muito tempo. Eu estava sozinho. E eu tinha meu chefe, que também estava programando, mas estava um pouco afastado das coisas que eu fazia. E embora possa ser libertador trabalhar sozinho – você tem muita confiança, muita liberdade – você não aprende tão rápido porque não tem nenhum feedback ou outras perspectivas além da sua. E se você nem mesmo fizer nenhum aprendizado ativo, ficará para trás.

Essa é uma das coisas que aconteceu comigo. Não recebi feedback, não entrei em conversas com outras pessoas: com outros engenheiros, com outras perspectivas, outras origens. E assim fiquei para trás. Eu estava confiando no conhecimento que tinha e não tinha motivos para fazer as coisas de forma diferente porque funcionava. Essa seria uma das maiores lições que aprendi no início da minha carreira. Especialmente se você não tem uma jornada clássica na tecnologia, cercar-se de outras pessoas que lhe trazem feedback e suas perspectivas é inestimável e vai turbinar sua carreira.

Brian: Acho que é um ótimo conselho para qualquer pessoa em qualquer função profissional, mas parece que realmente funcionou para você. Você sente falta de não trabalhar com PHP hoje em dia?

Sarah: Eu acho que PHP é uma ótima linguagem. Você pode encontrar muita inspiração do PHP no JavaScript moderno. Eu não trabalho mais com isso porque o JavaScript evoluiu a um ponto em que você pode usá-lo onde quer que queira usar o PHP. E especialmente como engenheiro de front-end, há muitas vantagens em usar a mesma linguagem no front-end e no back-end, como o compartilhamento. Mas eu acho que PHP é uma ótima linguagem. Recebe muitas piadas ruins e “Oh, o PHP está morto”, mas quando você olha para o sucesso de algo como o Laravel, sinto que o PHP está longe de estar morto.

Quando entrei no PHP, o framework que as pessoas sérias usavam era chamado de framework Zen. Na verdade, acredito que a Zen é a empresa por trás do PHP, ou pelo menos foi isso que o levou de volta. Ninguém mais usa o framework Zen, pelo menos não para novos projetos, mas é ótimo ver onde o PHP está agora. Ainda está florescendo, as pessoas estão gostando de codificar em PHP, e eu acho isso ótimo. Não é para todos, mas você faz você. Todos podem se sentar à mesa com o idioma que quiserem.

Subindo a escada da engenharia

Brian: Você é atualmente um engenheiro da equipe da Algolia. Conte-me um pouco sobre esse papel e no que você trabalha, e passaremos para o que é um engenheiro de equipe.

Sara: Claro. Eu sou um engenheiro de equipe e trabalho no front-end. Estou em uma equipe chamada experiências de front-end, FX para abreviar, e trabalhamos em bibliotecas de front-end para Algolia. Algolia é um mecanismo de pesquisa, portanto, é de ponta a ponta. Você tem o mecanismo e alguns clientes de API em vários idiomas para enviar seus dados para pesquisa, mas também tem bibliotecas front-end, porque quem tem tempo para construir uma caixa de pesquisa funcional acessível, uma lista de hits, uma lista de refinamento ou um cardápio hierárquico?

Todas essas coisas são difíceis de implementar corretamente. Então, fazemos isso para os clientes, e essa é a equipe em que estou trabalhando. Sou um contribuinte individual (IC) e não estou em nenhuma trilha de liderança. Mas o fato é que, à medida que você cresce para cargos mais altos como IC, sua realidade se mistura um pouco com seu papel de liderança. Não tenho relatórios e não gerencio ninguém, mas passo muito tempo com meu gerente em tópicos que estão mais no aspecto da visão das coisas. Mas ainda codifico todos os dias e, como todo mundo, faço críticas e recebo críticas. Portanto, ainda é um papel do IC. Na Algolia, você pode crescer para um nível bastante avançado e continuar sendo um colaborador individual que consegue codificar todos os dias.

“Qualquer coisa acima do sênior e você começa a despejar muita energia na estratégia – qual é a visão, onde o produto estará em cinco anos e como teremos sucesso nessas coisas?”

Brian: Quanto tempo você acha que gasta entregando versus todo o resto do trabalho? Compartilhar contexto, trabalhar em estratégia, esse tipo de coisa.

Sarah: Isso é difícil de avaliar. Eu diria 50/50. Há momentos em que codifico muito e incluo revisões na codificação porque é a mesma energia que você usa. Mas também há muito tempo criando estratégias, muitas reuniões, muitos documentos de visão, muito pensamento, muita conversa para coletar feedback, como trabalhar com PMs, pesquisadores, designers… tudo isso faz parte do trabalho . Na Algolia você tem funcionários seniores, diretor, etc. Qualquer coisa acima do sênior e você começa a despejar muita energia na estratégia – qual é a visão, onde o produto estará em cinco anos e como teremos sucesso nessas coisas? Como podemos ter certeza de que, se não formos bem-sucedidos, temos um plano de backup? Qualquer coisa que você possa pensar para aplicar a um projeto como codificação quando você é um engenheiro sênior, você aplica isso à estratégia do produto. Você trabalha muito no produto, e isso é uma das coisas que eu mais amo em trabalhar em uma startup de tecnologia.

Quando eu estava em uma agência, você não fazia nenhuma estratégia, não dizia o que pensava e não era necessariamente esperado que você desse conselhos. Você fez o que lhe foi dito. Mas quando você é engenheiro em uma startup, especialmente nesses níveis, sua voz e sua visão importam muito. Estamos construindo produtos para engenheiros. E mesmo que tenhamos que ter muito cuidado para não construir coisas para nós mesmos – temos a maldição do conhecimento, conhecemos o produto, sabemos como usá-lo e conhecemos todas as ressalvas – ainda somos sensíveis ao que os engenheiros se importam sobre, o que eles querem e o que tornará sua vida fácil ou difícil. Portanto, há uma grande ênfase no produto, em trazer ideias para a mesa, em ideias desafiadoras, em garantir que você construa a melhor coisa que vai durar.

“Depois de passar anos pensando em como se tornar um engenheiro melhor, você precisará de uma mudança de mentalidade para começar a pensar em outras coisas. Como posso ajudar outras pessoas? Como posso desbloquear situações?”

Brian: Quanto tempo você gasta trabalhando com outros funcionários e engenheiros principais além de sua organização ou equipe? Essa é uma comunidade ativa em sua empresa? Você consegue fazer muito trabalho em colaboração com isso? Você trabalha em grande parte de forma independente em seus grupos? Ou há um subconjunto de outros engenheiros seniores com quem você está trabalhando?

Sarah: Não tanto quanto eu gostaria. Em qualquer organização, quanto mais alto você sobe nos níveis, menos pessoas você tem. Então não é como se houvesse uma tonelada de IC cinco, IC seis, funcionários e diretor. Estamos contratando muitos funcionários seniores agora, então minha resposta pode ser diferente em seis meses. Passei um tempo normal conversando com outros funcionários ou até engenheiros principais, mas não é como se houvesse alguma comunidade ou algo oficial só porque não somos muitos. Agora, passei muito tempo discutindo com os mais velhos e acima, porque isso faz parte do meu papel.

Parte do meu papel é ajudar as pessoas no nível sênior a crescer e a serem promovidas ao nível de equipe. Como engenheiro sênior em muitas empresas, especialmente do tamanho da Algolia, você sabe o que precisa fazer para chegar lá. É mais uma lista de verificação. Depois disso, fica mais complicado porque há muitas coisas que podem ser interpretadas, coisas que você pode fazer de maneira muito diferente de outra pessoa com base em sua personalidade. Mas a ideia é que, quando você atingir o nível sênior, esperamos que você seja ótimo em seu conjunto de habilidades. Sabemos que você é bom, está em um certo nível técnico e não esperamos que cresça muito mais do que isso, mas será solicitado que você desenvolva outros tipos de habilidades.

“Devemos descobrir em que você é bom, o que você gosta de fazer que o ajudará a brilhar e cultivar isso. Há muita orientação envolvida”

Depois de passar anos pensando em como se tornar um engenheiro melhor, escrever código melhor, fazer avaliações melhores ou ter menos comentários ao receber uma avaliação, você precisará de uma mudança de mentalidade para começar a pensar em outras coisas. Como posso ajudar outras pessoas? Como posso desbloquear situações? Como posso criar minha própria carga de trabalho? Estas não são necessariamente coisas que você tem que pensar antes de atingir esses níveis. Eu ajudo as pessoas a abordá-lo, entender o que eles significam e entender que parte de sua personalidade eles poderão usar para chegar lá.

Algumas pessoas adoram estar no palco e fazer palestras, por exemplo. E se isso é algo que eles gostam, sem dúvida, eu deveria ajudá-los a conseguir melhores compromissos para a conferência e escrever melhores chamadas para trabalhos. Mas se não é o seu caso, não há razão para investirmos nisso. Devemos descobrir em que você é bom, o que você gosta de fazer que o ajudará a brilhar e cultivá-lo. Há muita orientação envolvida. Esta é uma das minhas partes favoritas de estar neste nível de antiguidade.

Para uma empresa, não é realmente interessante ter uma equipe ou um engenheiro sênior – você quer ter 3, 5, 8, 16. E a única maneira de fazer isso é ter as pessoas que são já lá ajuda as pessoas que estão um nível abaixo. Você não pode esperar que seu gerente de engenharia faça isso sozinho com toda a equipe. Quando você tem engenheiros ajudando outros engenheiros a fazer o trabalho que fizeram um ou dois anos antes, você tem esse efeito multiplicador. E acho que isso é realmente emocionante para as pessoas, porque elas aprendem com outras, com pessoas que realmente passaram pelo processo na mesma organização. Há confiança de que, se eles seguirem esses passos, se ouvirem, pode funcionar. Quero aprender com os principais engenheiros que podem me ajudar a entender o que preciso fazer para chegar lá.

É particularmente interessante para a pessoa que ensina porque ela pode dissecar o que realmente fez. Fica confuso depois, e você fica tipo, “Sim, eu fiz um pouco disso, um pouco daquilo”. Não. O que você fez? Quais são os passos concretos que você deu? Quais são as coisas para as quais você disse sim? Quais são as coisas para as quais você disse não? Acho que te ajuda a esclarecer suas ideias, esclarecer seu processo e te deixa mais eficiente para os próximos.

Equipe de integração mais engenheiros

Brian: Você mencionou a integração de novos funcionários e engenheiros principais em uma organização, o que pode ser bem complicado. Isso é algo que você tem experiência?

Sarah: Isso não é algo que fizemos muito, para ser honesto. Temos três ou quatro engenheiros principais, e nem todos eles fazem parte da minha equipe. A experiência que tenho é principalmente trazendo engenheiros seniores. Agora, há coisas que são comuns a todos, e há coisas que podem ser interessantes para os engenheiros principais, e eu ainda posso tentar tentar.

“Uma pessoa muito, muito sênior pode ajudá-lo com muitas coisas, mas não vai resolver problemas estruturais da empresa ou de uma equipe”

A clareza é extremamente importante e, é claro, você não espera o mesmo apoio ao contratar uma equipe ou um engenheiro principal. Você quer que eles sejam auto-iniciantes. Clareza não é dizer o que se espera de você, todas as tarefas, etc., mas sim dar a você uma noção de sua missão. Qual é o seu propósito aqui? O que você está fazendo aqui? E eu diria que isso começa no nível da entrevista. Minha recomendação para uma equipe ou um engenheiro principal ingressando em uma empresa seria perguntar sobre isso porque, às vezes, as pessoas tentam contratar cargos muito altos para resolver seus problemas. Eles são como, “Oh, vamos apenas contratar alguém muito, muito sênior, porque eles sabem coisas que nós não sabemos”. E isso não é verdade. Uma pessoa muito, muito sênior pode ajudá-lo com muitas coisas, mas não resolverá problemas estruturais da empresa ou de uma equipe.

E, por outro lado, um gerente de engenharia deve se perguntar por que eles acham que precisam dessa pessoa. Na maioria das vezes, você não contrata alguém nesse nível para codificar a grandeza. Se você tem um engenheiro sênior em sua equipe, esse seria o IC quatro da Algolia. Eles já são perfeitamente capazes de codificação, ou pelo menos deveriam ser. Uma equipe ou engenheiro principal vem com experiência em algo que você deseja fazer e você pode precisar deles, por exemplo, quando souber que precisa atingir uma escala que ninguém na equipe alcançou antes. Talvez você possa descobrir, mas você quer um acelerador, e é isso que uma pessoa muito sênior vai fazer em sua equipe.

Fazer essas perguntas com antecedência é uma boa maneira de garantir que não haja desalinhamento em relação ao que é esperado. Se você for muito sênior e for solicitado a codificar ou trabalhar em um nível sênior apenas porque houve um desalinhamento, você ficará desapontado e provavelmente sairá. Você não quer gastar muito tempo contratando uma pessoa neste nível apenas para deixá-los sair porque é extremamente caro.

Depois disso, eu esperaria que alguém nesse nível de experiência lesse muito e tivesse muitas conversas. Isso é algo que você normalmente não faz quando é um engenheiro júnior. Você chega à sua organização, recebe sua primeira tarefa e ela simplesmente flui – você começa a trabalhar, começa a codificar, e é isso que você deve fazer, porque é isso que o levará ao próximo passo.

“Sua função é garantir que o produto entregue se encaixe e seja dimensionado. E você não pode fazer isso se não discutir com outras pessoas na empresa”

Mas quando você está nesses níveis seniores, é importante entender onde está, o que está acontecendo, quem faz o quê. Você precisa criar relacionamentos não apenas com outros engenheiros e pessoas seniores, mas com mais pessoas juniores, gerentes de produto, designers e pesquisadores. Você precisa entender como a empresa funciona e como você pode se encaixar nisso, o que você pode ajudar a melhorar. Se houver alguma documentação interna escrita, leia-a e, quando terminar, leia-a novamente.

Em seguida, pergunte ao seu gerente de engenharia quem são as pessoas com quem você deve se encontrar. Toda vez que você conversar com uma pessoa nova, pergunte a ela com quem ela acha que seria interessante conversar com você. Isso lhe dará asas porque você criará relacionamentos e entenderá o que está acontecendo. Quais são os produtos? Quais são as lutas atuais? Onde você pode ajudar? E como sua equipe e os produtos que você está construindo se encaixam nesse esquema? Porque nesses níveis, com esse foco no produto, não se trata mais apenas da qualidade do código. Os veteranos da equipe já estão cuidando disso e estão fazendo isso perfeitamente bem. Sua função é garantir que o produto entregue se encaixe e seja dimensionado. E você não pode fazer isso se não discutir com outras pessoas na empresa.

Novos desafios

Brian: Para ouvintes que não sabem, Algolia é uma poderosa API de pesquisa hospedada. Parece uma empresa bem-sucedida do lado de fora, mas tenho certeza de que há muitos desafios e coisas em sua mente. Você poderia nos dar uma idéia de alguns dos grandes problemas que você está pensando ou trabalhando?

“A ideia é que, não importa o caminho que você faça para pesquisar esses dados, obtê-los e chegar à página, você será exibido com os dados certos”

Sarah: Como você disse, Algolia é uma API de pesquisa hospedada. Essa é a maior API que temos e é a mais bem-sucedida por enquanto, mas também expandimos um pouco. Atualmente, existe um produto chamado Algolia Recommend, que usa o mesmo conjunto de dados que você usa para pesquisa, mas com base em um determinado produto, ele fornece recomendações.

O objetivo do Algolia não é apenas pesquisar, mas trazer à tona o conteúdo. Você tem muito conteúdo, mas nem tudo é relevante ao mesmo tempo para as mesmas pessoas. A ideia é que, independentemente do caminho que você siga para pesquisar esses dados, obtê-los e chegar à página, você será exibido com os dados certos. Este é o ponto de Algolia. Há desafios com isso. Somos especialistas em pesquisa, mas o aspecto de recomendação e aprendizado de máquina é uma tecnologia muito mais recente, por isso estamos aprendendo com as novidades. Há muito para aprendermos em comparação com a pesquisa. Este não é o maior desafio, mas ainda é um desafio garantir que possamos reiterar o mesmo sucesso que tivemos com a pesquisa.

Agora, há coisas em que Algolia não é muito boa. É um mecanismo de busca, não um banco de dados. Será rápido, eventualmente consistente, mas você não tem garantia de que terá todos os seus dados, que seus dados serão sempre consistentes ou que todos os seus dados estarão lá. Essa é uma escolha de design em torno do mecanismo de pesquisa, o que o torna muito diferente de um banco de dados. Dito isto, muitas pessoas gostam de usar Algolia como banco de dados porque é muito fácil enviar dados para Algolia, e está lá, e é rápido. Talvez haja algo a aprender sobre isso. Talvez também possa ser um banco de dados, e não estou dizendo que será, mas talvez possa. Talvez haja algo mais lá fora que temos que entender e pesquisar.

Existem muitos casos de uso com os quais Algolia não pode trabalhar. Um deles é o caso de uso de reserva. Se você deseja reservar um Airbnb, quando você o pesquisa, está nos seus resultados, ou seja, está disponível. Mas assim que você chega à página, ela não está mais disponível porque você replica seus dados do seu banco de dados para Algolia. Quando você salva algo em seu banco de dados, você envia essa alteração para Algolia em um formato ligeiramente diferente. E porque há esse atraso – isso não é em tempo real – algo como o caso de uso de reserva não pode funcionar. Quando você está lidando com Airbnbs, algo disponível agora pode não estar disponível em 30 segundos, mas ainda pode aparecer em seu mecanismo de pesquisa porque, quando você salvou, precisará de talvez 10 segundos ou algo assim para que seja propagado para Algolia, e talvez tenha falhado e você precise fazer tudo de novo. Essas são coisas no nível do mecanismo de pesquisa que estamos pensando. É algo que poderíamos apoiar? Está fora de questão? Qual é o caso de negócios por trás disso? Porque ele dirige um monte de coisas.

“Deve ser invisível; deve ser sem costura. O fato de serem APIs separadas não é problema seu. Esse é o nosso problema para resolver”

Agora, em relação à equipe de front-end, mencionei Algolia Recommend. Quando você é um cliente, você realmente não se importa que existam produtos diferentes. Você não se importa se você tem Algolia Search com esses recursos e Algolia Recommend com esses sub-recursos. Você se inscreve no Algolia e paga sua taxa mensal ou anual por um conjunto de recursos que, segundo você, funcionam bem juntos. Você não quer e não precisa entender os limites artificiais que criamos internamente entre esta API e as APIs de dados.

Existe um ditado: “não envie seu organograma”, e acho que esse é um dos próximos grandes tópicos para nós. Como podemos garantir que, no front-end, ao usar a biblioteca de front-end Algolia, você não precise se perguntar se precisa disso ou daquilo? Que você não sente esses limites? Deve ser invisível; deve ser sem costura. O fato de serem APIs separadas não é problema seu. Esse é o nosso problema para resolver.

Criamos bibliotecas que foram realmente fortemente acopladas à API de pesquisa, e agora temos que expandir para APIs mais novas que podem funcionar juntas e, às vezes, você precisa fazer uma chamada para uma e depois para outra para obter a resposta final. Todas essas coisas agora não são tão perfeitas quanto gostaríamos que fossem. Ainda é um pouco difícil quando você deseja conectar essas APIs. É possível, mas você tem que ler tutoriais, seguir, fazer uma pequena mudança aqui e ali e escrever algum código clichê. Isso não é delicioso, não é divertido e dá muito trabalho. Se for para dizer a você, “use essa biblioteca”, ela precisa fazer um trabalho que você não quer fazer. Não há justificativa para usar a biblioteca se as primitivas de nível inferior são tão fáceis de usar, certo?

Neste momento, um dos maiores desafios é garantir que aumentamos o valor das bibliotecas. Eles já estão fazendo muitas coisas que a maioria das pessoas não quer fazer, mas em um certo ponto, para certos clientes, não é tão fácil e agradável como costumava ser quando tínhamos apenas pesquisa. E este é o sentimento que buscamos. Aquela sensação de “Uau, é muito mais simples do que eu pensei que seria”.

Brian: Por último, onde nossos ouvintes podem ir para acompanhá-lo?

Sarah: Então você pode me encontrar principalmente no Twitter, eu sou frontstuff_io. Estou dolorosamente ciente de que este é o pior identificador no Twitter. Você também pode me encontrar no sarahdayan.com e me seguir no GitHub se quiser; Eu cometo coisas às vezes. Mas sim, se você quiser conversar, acredito que meus DMs estão abertos, então me envie qualquer coisa.

Brian: Super. Sarah, muito obrigado por se juntar a mim hoje.

Sarah: Obrigado por me receber. Foi divertido.