Sarah Dayan di Algolia su ciò che distingue un ingegnere senior

Sebbene le buone capacità di programmazione siano sempre apprezzate, essere uno staff più un ingegnere richiede molto di più della semplice abilità tecnica. Cosa serve per arrivarci e, soprattutto, dove puoi avere il maggiore impatto sulla tua organizzazione?

Quando raggiungi il livello senior su una pista di ingegneria, dovresti essere ottimale nel tuo set di abilità difficili. Sei autonomo, il tuo codice è immacolato e hai una profonda conoscenza della creazione e della spedizione di software. Ma entrare nello staff più i ruoli è completamente un'altra bestia. C'è gestione del progetto, tutoraggio e insegnamento, processo decisionale, costruzione di relazioni e il valore che porti all'azienda non è più misurato dalla qualità delle linee del tuo codice, ma piuttosto dal portare avanti l'organizzazione ingegneristica.

L'ospite di oggi ha passato proprio questo. Sarah Dayan è un ingegnere del personale di Algolia, una piattaforma "Search-as-a-Service" che aiuta gli sviluppatori a creare indici e capacità di ricerca nelle proprie piattaforme tramite un'API e l'host di due podcast tecnologici: Developer Experience ed Entre Devs. Crea librerie front-end, un ruolo che le si addice perfettamente data la sua passione di una vita per l'esperienza utente, il design e la costruzione di oggetti. In effetti, Sarah è ossessionata dalla creazione di siti Web da quando i suoi genitori hanno installato Internet a banda larga nel suo seminterrato. È stato amore al primo clic. Ha messo insieme il suo primo forum phpBB a 15 anni, ha scritto la sua prima pagina HTML non molto tempo dopo e da allora non ha smesso di costruire cose.

Nonostante non avesse un'istruzione formale in ingegneria, Sarah ha ottenuto un lavoro come sviluppatore presso il consulente francese Grand Manitou. Poi, quattro anni fa, nel 2018, ha ottenuto un lavoro in Algolia come ingegnere del software. Ha diligentemente scalato i ranghi, diventando infine il ruolo di collaboratore individuale di un ingegnere del personale. E all'improvviso, tutto ciò che le è importato negli ultimi anni - diventare un ingegnere migliore, scrivere codice migliore - ha lasciato il posto a nuove sfide. Come fornirebbe la giusta direzione tecnica per l'azienda? Sbloccare i colli di bottiglia? Fare da mentore e aiutare altri ingegneri come altri avevano fatto per lei?

In questo episodio, ci siamo seduti con Sarah per parlare delle molte sfumature, competenze e aspettative di un ruolo di staff più ingegnere.

Ecco alcuni dei nostri asporto preferiti dalla conversazione:

• Se non vuoi restare indietro, continua ad imparare. Discuti le idee e ottieni feedback da altri ingegneri con prospettive e background diversi.
• In qualità di ingegnere del personale, gran parte della tua energia va nella collaborazione tra i team per la visione e la strategia. Dove sarà l'azienda tra cinque anni? Come hai intenzione di arrivarci?
• Avere ingegneri del personale come mentori consente a più giovani di ottenere chiarezza su quali passi intraprendere per raggiungere quei ruoli e accelerare il processo di creazione di leader ingegneristici.
• Contrariamente alla credenza popolare, un ingegnere del personale non è una soluzione rapida per un problema strutturale. Prima di accettare un nuovo lavoro, chiedi cosa ci si aspetta da te per evitare incomprensioni lungo la linea.
• Gli ingegneri del personale devono comprendere le esigenze dell'azienda in modo da poterla aiutare a raggiungere i suoi obiettivi. Durante l'onboarding, leggi quanta più documentazione e parla con quante più persone possibile.

Se ti piace la nostra discussione, dai un'occhiata ad altri episodi del nostro podcast. Puoi seguire su iTunes, Spotify, YouTube o prendere il feed RSS nel tuo lettore preferito. Quella che segue è una trascrizione leggermente modificata dell'episodio.

Mai smettere di imparare

Brian Scanlan: Grazie mille, Sarah, per esserti unito a noi nello show oggi. Sono felice di avere l'opportunità di parlare con te. Prima di parlare del tuo ruolo e del tuo lavoro in Algolia, mi piacerebbe conoscere il tuo viaggio fino a questo punto. Come è iniziato il tuo viaggio dove sei oggi?

Sarah Dayan: Bene, ciao, grazie per avermi ospitato. Be', in realtà è una storia divertente. Al momento ho 32 anni e abbiamo avuto la banda larga e Internet illimitato a casa quando ne avevo 15. Mi sono sempre occupato di creare cose e la prima volta che ho visto i siti Web, ho pensato: "Devo sapere come farlo". Una cosa tira l'altra e ho creato il mio primo forum con phpBB. PHP era davvero, davvero grande, ed è ancora grande, ma all'epoca era davvero il linguaggio per il web.

“Ho deciso che non era il mio genere, che forse avrei dovuto fare ciò che amavo. Quindi, sono tornato a ciò che amavo: creare siti Web"

A quei tempi, avere una carriera nella tecnologia, soprattutto come ingegnere del software, non era così bello e interessante come lo è oggi. I miei genitori pensavano che dovessi fare il giornalista perché a scuola ero bravo in lingue e letteratura. E questa è stata la prima cosa che ho fatto. Ho fatto il mio primo anno in giornalismo, cosa che ho completamente fallito, e poi ho deciso che non era il mio genere, che forse avrei dovuto fare ciò che amavo. Quindi, sono tornato a ciò che amavo: creare siti Web. Ho ottenuto il mio primo lavoro in un'agenzia e ho trascorso sei anni lì. Mi ha insegnato molto sul lavoro, sul lavoro con i clienti, con persone che sanno cosa vogliono e persone che non sanno cosa vogliono. Poi sono passato al mondo delle startup. Sono stato programmatore per oltre 15 anni, ma professionalmente lo faccio da 12. E questo è ciò che mi ha portato al mio attuale ruolo in Algolia. Sono lì da quattro anni e oltre.

Brian: Super. Hai qualche lezione interessante che hai imparato all'inizio che ti è rimasta impressa?

Sarah: Non ho un percorso classico verso la tecnologia. Non ho frequentato la scuola di ingegneria ed è possibile avere una grande carriera nella tecnologia se non lo fai. Puoi sicuramente essere autodidatta, puoi imparare da altre persone e non devi avere una laurea. Ma non avere una laurea non è una scusa per non imparare. C'è un ottimo post sul blog di Sarah Drasner, un responsabile tecnico di Google, su CSS-Tricks a riguardo. Anche se puoi avere una carriera in tecnologia senza una laurea, ciò non ti esonera dall'apprendimento e dalla ricerca della conoscenza.

“Non ho ricevuto feedback, non ho avuto conversazioni con altre persone: con altri ingegneri, con altre prospettive, altri background. E così sono rimasto indietro”

E una cosa che impari davvero a scuola è imparare a imparare, e questa è un'abilità davvero importante. All'inizio della mia carriera, presso l'agenzia di cui ti ho parlato, sono stato l'unico dipendente per molto tempo. Ero tutto solo. E avevo il mio capo, che stava anche programmando ma era un po' distaccato dalle cose che stavo facendo. E sebbene possa essere liberatorio lavorare da solo – hai molta fiducia, molta libertà – non impari così velocemente perché non hai feedback o altre prospettive a parte la tua. E se non fai nemmeno alcun apprendimento attivo, rimarrai indietro.

Questa è una delle cose che mi è successa. Non ho ricevuto feedback, non ho avuto conversazioni con altre persone: con altri ingegneri, con altre prospettive, altri background. E così sono rimasto indietro. Facevo affidamento sulle conoscenze che avevo e non avevo motivo di fare le cose diversamente perché funzionava. Sarebbe una delle lezioni più importanti che ho ricevuto all'inizio della mia carriera. Soprattutto se non hai un classico viaggio nella tecnologia, circondarti di altre persone che ti forniscono feedback e le loro prospettive è inestimabile e aumenterà la tua carriera.

Brian: Penso che sia un ottimo consiglio per chiunque ricopra un ruolo professionale, ma sembra che abbia funzionato davvero per te. Ti manca qualcosa del non lavorare con PHP in questi giorni?

Sarah: Penso che PHP sia un ottimo linguaggio. Puoi trovare molta ispirazione da PHP nel moderno JavaScript. Non ci lavoro più perché JavaScript si è evoluto al punto in cui puoi usarlo ovunque tu voglia usare PHP. E soprattutto come ingegnere front-end, ci sono molti vantaggi nell'usare la stessa lingua sul front-end e sul back-end, come la condivisione condivisa. Ma penso che PHP sia un ottimo linguaggio. Ricevono molte battute negative e il "Oh, PHP è morto", ma quando guardi al successo di qualcosa come Laravel, mi sembra che PHP sia tutt'altro che morto.

Quando sono entrato in PHP, il framework utilizzato dalle persone serie era chiamato framework Zen. In realtà, credo che Zen sia l'azienda dietro PHP, o almeno questo l'ha ripreso. Nessuno usa più il framework Zen, almeno non per nuovi progetti, ma è bello vedere dove si trova PHP in questo momento. È ancora fiorente, le persone si divertono a programmare in PHP e penso che sia fantastico. Non è per tutti, ma tu lo fai. Ognuno può sedersi a tavola con la lingua che preferisce.

Salire la scala dell'ingegneria

Brian: Attualmente sei un ingegnere del personale in Algolia. Parlami un po' di quel ruolo e su cosa lavori, e passeremo a cos'è un ingegnere del personale.

Sara: Certo. Sono un ingegnere del personale e lavoro sul front end. Faccio parte di un team chiamato esperienze front-end, in breve FX, e lavoriamo su librerie front-end per Algolia. Algolia è un motore di ricerca, quindi è end-to-end. Hai il motore e alcuni client API in più lingue per inviare i tuoi dati alla ricerca, ma hai anche librerie front-end, perché chi ha tempo per creare una casella di ricerca funzionante accessibile, un elenco di risultati, un elenco di perfezionamento o un menu gerarchico?

Tutte queste cose sono difficili da implementare correttamente. Quindi lo facciamo per i clienti, e questa è la squadra su cui sto lavorando. Sono un contributore individuale (IC) e non sono su alcun percorso di leadership. Ma il fatto è che, man mano che cresci a ruoli più alti come IC, la tua realtà si fonde un po' con il tuo ruolo di leadership. Non ho rapporti e non gestisco nessuno, ma passo molto tempo con il mio manager su argomenti che riguardano più l'aspetto visivo delle cose. Ma continuo a programmare ogni giorno e, come tutti, do recensioni e ricevo recensioni. Quindi è ancora un ruolo IC. In Algolia, puoi crescere fino a un livello piuttosto avanzato e rimanere un contributore individuale che può programmare ogni giorno.

"Qualcosa di sopra senior e inizi a riversare molta energia nella strategia: qual è la visione, dove sarà il prodotto tra cinque anni e come avremo successo su queste cose?"

Brian: Quanto tempo pensi di dedicare alla spedizione rispetto a tutto il resto del lavoro? Condividere il contesto, lavorare sulla strategia, quel genere di cose.

Sarah: È difficile da valutare. Direi 50/50. Ci sono momenti in cui codifico molto e includo recensioni nella codifica perché è la stessa energia che usi. Ma c'è anche molto tempo per elaborare strategie, molte riunioni, molti documenti di visione, molte riflessioni, molte conversazioni per raccogliere feedback, come lavorare con PM, ricercatori, designer... tutto questo fa parte del lavoro . In Algolia hai personale senior, preside, ecc. Qualsiasi cosa al di sopra del senior e inizi a riversare molta energia nella strategia: qual è la visione, dove sarà il prodotto tra cinque anni e come avremo successo su queste cose? Come possiamo assicurarci che, se non abbiamo successo, abbiamo un piano di backup? Qualsiasi cosa tu possa pensare di applicare a un progetto come la programmazione quando sei un ingegnere senior, lo applichi alla strategia del prodotto. Lavori molto sul prodotto, ed è una delle cose che amo di più del lavoro in una startup tecnologica.

Quando ero in un'agenzia, non facevi nessuna strategia, non dicevi quello che pensavi e non dovevi necessariamente dare consigli. Hai fatto quello che ti è stato detto. Ma quando sei un ingegnere in una startup, specialmente a quei livelli, la tua voce e la tua visione contano molto. Stiamo costruendo prodotti per ingegneri. E anche se dobbiamo stare molto attenti a non costruire cose per noi stessi – abbiamo la maledizione della conoscenza, conosciamo il prodotto, sappiamo come usarlo e conosciamo tutti gli avvertimenti – siamo comunque sensibili a ciò che interessa agli ingegneri su cosa vogliono e cosa renderà la loro vita facile o difficile. Quindi c'è un'enorme enfasi sul prodotto, sul portare idee in tavola, sulle idee stimolanti, sull'assicurarsi di costruire la cosa migliore che duri.

“Dopo aver passato anni a pensare a come diventare un ingegnere migliore, avrai bisogno di un cambiamento di mentalità per iniziare a pensare ad altre cose. Come posso aiutare altre persone? Come posso sbloccare le situazioni?"

Brian: Quanto tempo dedichi a lavorare con altro personale e ingegneri principali al di fuori della tua organizzazione o team? È una comunità attiva nella tua azienda? Puoi fare molto lavoro in collaborazione con quello? Lavori in gran parte in modo indipendente nei tuoi gruppi? O c'è un sottoinsieme di altri ingegneri del personale senior con cui stai lavorando?

Sarah: Non quanto vorrei. In qualsiasi organizzazione, più alti si sale di livello, meno persone hai. Quindi non è che ci siano un sacco di IC cinque, IC sei, personale e preside. Stiamo assumendo molte persone anziane in questo momento, quindi la mia risposta potrebbe essere diversa tra sei mesi. Ho passato una normale quantità di tempo a parlare con altro personale o anche con i principali ingegneri, ma non è che ci sia una community o qualcosa di ufficiale solo perché non siamo così tanti. Ora, ho passato molto tempo a discutere con gli anziani e oltre, perché fa parte del mio ruolo.

Parte del mio ruolo consiste nell'aiutare le persone a livello senior a crescere e ad essere promosse a livello di staff. In qualità di ingegnere senior in molte aziende, in particolare le dimensioni di Algolia, sai cosa devi fare per arrivarci. È più una lista di controllo. Dopodiché, diventa più complicato perché ci sono molte cose che potrebbero dipendere dall'interpretazione, cose che puoi fare in modo molto diverso da un'altra persona in base alla tua personalità. Ma l'idea è che, quando raggiungi il livello senior, ci aspettiamo che tu sia ottimale nel tuo set di abilità difficili. Sappiamo che sei bravo, sei a un certo livello tecnico e non ci aspettiamo che tu cresca molto più in alto, ma ti verrà chiesto di sviluppare altri tipi di abilità.

“Dovremmo trovare ciò in cui sei bravo, ciò che ti piace fare che ti aiuterà a brillare e coltivarlo. C'è un sacco di tutoraggio coinvolto"

Dopo aver passato anni a pensare a come diventare un ingegnere migliore, scrivere codice migliore, fare recensioni migliori o avere meno commenti quando ricevi una recensione, avrai bisogno di un cambiamento di mentalità per iniziare a pensare ad altre cose. Come posso aiutare altre persone? Come posso sbloccare le situazioni? Come posso creare il mio carico di lavoro? Queste non sono necessariamente cose a cui devi pensare prima di raggiungere quei livelli. Aiuto le persone ad avvicinarsi, a capire cosa significano e a capire quale parte della loro personalità potranno usare per arrivarci.

Ad alcune persone piace stare sul palco e fare discorsi, per esempio. E se questo è qualcosa che gli piace, con tutti i mezzi, dovrei aiutarli a ottenere migliori impegni per conferenze e scrivere migliori call for papers. Ma se questo non fa per te, non c'è motivo per cui dovremmo investire in quello. Dovremmo trovare ciò in cui sei bravo, cosa ti piace fare che ti aiuterà a brillare e coltivarlo. C'è un sacco di tutoraggio coinvolto. Questa è una delle parti che preferisco dell'essere a questo livello di anzianità.

Per un'azienda, non è davvero interessante avere uno staff o un ingegnere senior: vuoi averne 3, 5, 8, 16. E l'unico modo per farlo è avere le persone che sono già lì aiuta le persone che sono un livello più basso. Non puoi aspettarti che il tuo responsabile tecnico lo faccia da solo con l'intero team. Quando hai ingegneri che aiutano altri ingegneri a fare il lavoro che hanno fatto un anno o due anni prima, hai questo effetto moltiplicatore. E penso che questo sia davvero elettrizzante per le persone perché imparano dagli altri, dalle persone che hanno effettivamente affrontato il processo nella stessa organizzazione. C'è la certezza che, se seguono questi passaggi, se ascoltano, potrebbe funzionare. Voglio imparare dai principali ingegneri che possono aiutarmi a capire cosa devo fare per arrivarci.

È particolarmente interessante per la persona che insegna perché può analizzare ciò che ha effettivamente fatto. Dopo diventa confuso e tu dici: "Sì, ho appena fatto un po' di questo, un po' di quello". No. Cosa hai fatto? Quali sono i passi concreti che hai fatto? Quali sono le cose a cui hai detto di sì? Quali sono le cose a cui hai detto di no? Penso che ti aiuti a chiarire le tue idee, a chiarire il tuo processo e ti renda più efficiente per i prossimi.

Personale di bordo più ingegneri

Brian: Hai menzionato l'inserimento di nuovo personale e ingegneri principali in un'organizzazione, il che può essere piuttosto complicato. È qualcosa con cui hai esperienza?

Sarah: Questo non è qualcosa che abbiamo fatto molto, ad essere onesti. Abbiamo tre o quattro ingegneri principali e tutti non fanno parte della mia squadra. L'esperienza che ho riguarda principalmente il portare ingegneri senior. Ora, ci sono cose che sono comuni a tutti, e poi ci sono cose che potrebbero essere interessanti per i principali ingegneri, e posso ancora provare a provarci.

"Una persona molto, molto anziana può aiutarti in molte cose, ma non risolverà problemi strutturali dell'azienda o di un team"

La chiarezza è estremamente importante e, naturalmente, non ti aspetti lo stesso comportamento quando assumi uno staff o un ingegnere principale. Vuoi che siano auto-iniziatori. La chiarezza non consiste nel dirti cosa ci si aspetta da te, tutti i compiti, eccetera, ma piuttosto nel darti un'idea della tua missione. Qual è il tuo scopo qui? Cosa stai facendo qui? E direi che questo inizia a livello di intervista. La mia raccomandazione per uno staff o un ingegnere principale che entra a far parte di un'azienda sarebbe di chiedere in merito perché a volte le persone cercano di assumere ruoli molto senior per risolvere i loro problemi. Dicono: "Oh, assumiamo qualcuno molto, molto anziano perché sa cose che noi non sappiamo". E non è vero. Una persona molto, molto anziana può aiutarti in molte cose, ma non risolverà problemi strutturali dell'azienda o di un team.

E dall'altra parte, un manager di ingegneria dovrebbe chiedersi perché pensano di aver bisogno di quella persona. La maggior parte delle volte, non assumi qualcuno a questo livello per codificare la grandezza. Se hai un ingegnere senior nella tua squadra, quello sarebbe IC quattro in Algolia. Sono già perfettamente in grado di codificare, o almeno dovrebbero esserlo. Uno staff o un ingegnere principale viene fornito con esperienza in qualcosa che vuoi fare e potresti averne bisogno, ad esempio, quando sai che devi raggiungere una scala che nessuno nel team ha mai raggiunto prima. Forse potresti capirlo, ma vuoi un acceleratore, e questo è ciò che farà una persona molto anziana nella tua squadra.

Fare queste domande in anticipo è un buon modo per assicurarsi che non vi siano disallineamenti su ciò che ci si aspetta. Se sei molto anziano e ti viene chiesto di programmare o lavorare a livello senior solo perché c'era un disallineamento, rimarrai deluso e probabilmente te ne andrai. Non vuoi passare molto tempo ad assumere una persona a questo livello solo per farla partire perché è estremamente costoso.

Dopodiché, mi aspetterei che qualcuno a questo livello di anzianità leggesse molto e conversasse. Questo è qualcosa che di solito non fai quando sei un ingegnere junior. Vieni nella tua organizzazione, ti viene assegnato il tuo primo compito e tutto scorre: inizi a lavorare, inizi a programmare, e questo è ciò che dovresti fare perché questo è ciò che ti porterà al passaggio successivo.

“Il tuo ruolo è assicurarti che il prodotto consegnato si adatti e si adatti alle dimensioni. E non puoi farlo se non ne parli con altre persone in azienda”

Ma quando sei a quei livelli senior, è importante che tu capisca dove sei, cosa sta succedendo, chi fa cosa. È necessario creare relazioni non solo con altri ingegneri e persone senior, ma anche con persone più giovani, product manager, designer e ricercatori. Devi capire il modo in cui funziona l'azienda e come puoi inserirti in questo, cosa puoi aiutare a migliorare. Se c'è della documentazione interna scritta, leggila e, quando hai finito, leggila di nuovo.

Quindi, chiedi al tuo responsabile tecnico chi sono le persone con cui dovresti incontrare. Ogni volta che parli con una nuova persona, chiedile con chi, secondo loro, sarebbe interessante per te parlare. Questo ti darà le ali perché creerai relazioni e capirai cosa sta succedendo. Quali sono i prodotti? Quali sono le lotte attuali? Dove puoi aiutare? E in che modo il tuo team e i prodotti che stai costruendo si adattano a questo schema? Perché a quei livelli, con questa attenzione al prodotto, non si tratta più solo della qualità del codice. Gli anziani della squadra se ne stanno già occupando e lo stanno facendo perfettamente. Il tuo ruolo è assicurarti che il prodotto consegnato si adatti e si adatti alle dimensioni. E non puoi farlo se non ne parli con altre persone in azienda.

Nuove sfide

Brian: Per gli ascoltatori che non lo sanno, Algolia è una potente API di ricerca ospitata. Dall'esterno sembra un'azienda piuttosto di successo, ma sono sicuro che ci sono molte sfide e cose nella tua mente. Potresti darci un'idea di alcuni dei grandi problemi a cui stai pensando o su cui stai lavorando?

"L'idea è che, indipendentemente dal percorso che prendi per cercare quei dati, ottenerli e atterrare sulla pagina, vieni in superficie con i dati giusti"

Sarah: Come hai detto, Algolia è un'API di ricerca ospitata. Questa è l'API più grande che abbiamo e per ora è quella di maggior successo, ma l'abbiamo anche ampliata un po'. Attualmente, esiste un prodotto chiamato Algolia Recommend, che utilizza lo stesso set di dati che utilizzi per la ricerca, ma in base a un determinato prodotto, ti fornisce consigli.

Lo scopo di Algolia non è solo cercare ma far emergere contenuti. Hai molti contenuti, ma non tutti sono rilevanti allo stesso tempo per le stesse persone. L'idea è che, indipendentemente dal percorso che si intraprende per cercare quei dati, ottenerli e atterrare sulla pagina, vengono visualizzati i dati giusti. Questo è il punto dell'Algolia. Ci sono sfide con quello. Siamo esperti di ricerca, ma l'aspetto dei consigli e dell'apprendimento automatico è una tecnologia molto più recente, quindi stiamo imparando con le ultime novità. C'è molto da imparare rispetto alla ricerca. Questa non è la sfida più grande, ma è comunque una sfida per assicurarci di poter reiterare lo stesso successo che abbiamo avuto con la ricerca.

Ora, ci sono cose in cui l'Algolia non è eccezionale. È un motore di ricerca, non un database. Sarà veloce, alla fine sarà coerente, ma non hai la garanzia che avrai tutti i tuoi dati, che i tuoi dati siano sempre coerenti o che tutti i tuoi dati saranno lì. Questa è una scelta di design attorno al motore di ricerca, che lo rende molto diverso da un database. Detto questo, a molte persone piace usare Algolia come database perché è molto facile inviare dati ad Algolia, ed è lì, ed è veloce. Forse c'è qualcosa da imparare a riguardo. Forse potrebbe anche essere un database, e non sto dicendo che lo sarà, ma forse potrebbe. Forse c'è qualcos'altro là fuori che dobbiamo capire e ricercare.

Ci sono molti casi d'uso con cui Algolia non può funzionare. Uno di questi è il caso d'uso della prenotazione. Se vuoi prenotare un Airbnb, quando lo cerchi è nei tuoi risultati, il che significa che è disponibile. Ma non appena raggiungi la pagina, non è più disponibile perché replichi i tuoi dati dal tuo database ad Algolia. Quando salvi qualcosa nel tuo database, invierai la modifica ad Algolia in un formato leggermente diverso. E poiché c'è quel ritardo - questo non è in tempo reale - qualcosa come il caso d'uso della prenotazione non può funzionare. Quando hai a che fare con Airbnbs, qualcosa disponibile in questo momento potrebbe non essere disponibile in 30 secondi, ma potrebbe comunque essere visualizzato nel tuo motore di ricerca perché quando hai salvato, hai bisogno di forse 10 secondi o qualcosa del genere per propagarlo a Algolia, e forse ha fallito e devi rifarlo da capo. Sono cose a cui stiamo pensando a livello di motore di ricerca. È qualcosa che potremmo mai sostenere? È fuori questione? Qual è il business case dietro questo? Perché guida molte cose.

“Dovrebbe essere invisibile; dovrebbe essere senza soluzione di continuità. Il fatto che si tratti di API separate non è un tuo problema. Questo è il nostro problema da risolvere”

Ora, per quanto riguarda il team di front-end, ho menzionato Algolia Recommend. Quando sei un cliente, non ti interessa davvero che ci siano prodotti diversi. Non ti interessa avere Algolia Search con quelle funzioni e Algolia Recommend con quelle sottocaratteristiche. Ti abboni ad Algolia e paghi la tua quota mensile o annuale per una serie di funzionalità che ti è stato detto funzionano bene insieme. Non si desidera e non è necessario comprendere i confini artificiali che abbiamo creato internamente tra questa API e le API di dati.

C'è questo detto "non spedire il tuo organigramma" e penso che questo sia uno dei prossimi grandi argomenti per noi. Come possiamo assicurarci che, sul front-end, quando utilizzi la libreria front-end di Algolia, non devi chiederti se hai bisogno di questo o quello? Che non senti quei confini? Dovrebbe essere invisibile; dovrebbe essere senza soluzione di continuità. Il fatto che si tratti di API separate non è un tuo problema. Questo è il nostro problema da risolvere.

Abbiamo creato librerie che erano davvero fortemente accoppiate all'API di ricerca, e ora dobbiamo espanderci a nuove API che possono lavorare insieme e, a volte, è necessario eseguire una chiamata a una, quindi una chiamata a un'altra per ottenere la risposta finale. Tutte queste cose in questo momento non sono così fluide come vorremmo che fossero. È ancora un po' agitato quando vuoi connettere queste API insieme. È possibile, ma devi leggere i tutorial, seguire, apportare piccole modifiche qua e là e scrivere del codice standard. Questo non è delizioso, non è divertente ed è troppo lavoro. Se dobbiamo dirti "usa quella libreria", ha bisogno di fare un lavoro che non vuoi fare. Non c'è giustificazione per usare la libreria se le primitive di livello inferiore sono facili da usare, giusto?

In questo momento, una delle maggiori sfide è assicurarsi di aumentare il valore delle biblioteche. Stanno già facendo molto che la maggior parte delle persone non vuole fare, ma a un certo punto, per alcuni clienti, non è così semplice e piacevole come una volta quando avevamo solo la ricerca. E questa è la sensazione che stiamo cercando. Quella sensazione di "Wow, è molto più semplice di quanto pensassi".

Brian: Infine, dove possono andare i nostri ascoltatori per tenerti al passo?

Sarah: Quindi puoi trovarmi principalmente su Twitter, sono frontstuff_io. Sono dolorosamente consapevole che questo è il peggior handle su Twitter. Puoi anche trovarmi su sarahdayan.com e seguirmi su GitHub se vuoi; A volte impegno le cose. Ma sì, se vuoi chattare, credo che i miei DM siano aperti, quindi inviami qualsiasi cosa.

Brian: Super. Sarah, grazie mille per esserti unito a me oggi.

Sarah: Grazie per avermi. È stato divertente.