Algolia'dan Sarah Dayan, kıdemli bir mühendisi ayıran şey hakkında

İyi kodlama becerileri her zaman takdir edilirken, bir personel artı mühendis olmak, yalnızca teknik becerinizden çok daha fazlasını gerektirir. Oraya ulaşmak için ne gerekiyor ve daha da önemlisi, kuruluşunuz üzerinde en büyük etkiye nerede sahip olabilirsiniz?

Bir mühendislik parkurunda üst seviyeye ulaştığınızda, zorlu beceri setinizde optimal olmanız beklenir. Otonomsunuz, kodunuz kusursuz ve yazılım oluşturma ve gönderme konusunda derin bir anlayışa sahipsiniz. Ancak personel artı rollere girmek tamamen başka bir canavar. Proje yönetimi, mentorluk ve öğretim, karar verme, ilişki kurma var ve şirkete getirdiğiniz değer artık kodunuzun satırlarının kalitesiyle değil, mühendislik organizasyonunu ileriye taşıyarak ölçülmektedir.

Bugünün konuğu tam da bunu yaşadı. Sarah Dayan, geliştiricilerin bir API aracılığıyla kendi platformlarında dizin oluşturma ve arama yetenekleri oluşturmasına yardımcı olan bir "Hizmet Olarak Arama" platformu olan Algolia'da personel mühendisi ve iki teknoloji podcast'ine ev sahipliği yapıyor: Geliştirici Deneyimi ve Entre Devs. Kullanıcı deneyimi, tasarım ve bir şeyler inşa etme konusundaki yaşam boyu tutkusu göz önüne alındığında, kendisine mükemmel şekilde uyan bir rol olan ön uç kitaplıklar yaratıyor. Aslında, Sarah ailesi bodrumuna geniş bant internet kurduğundan beri web siteleri oluşturma konusunda takıntılıdır. İlk tıklamada aşktı. İlk phpBB forumunu 15 yaşında kurdu, bundan kısa bir süre sonra ilk HTML sayfasını yazdı ve o zamandan beri bir şeyler oluşturmayı bırakmadı.

Sarah, mühendislik alanında resmi bir eğitimi olmamasına rağmen, Fransız danışman Grand Manitou'da geliştirici olarak işe girdi. Ardından, dört yıl önce, 2018'de Algolia'da yazılım mühendisi olarak işe başladı. Sabırla saflarda yükseldi ve sonunda bir personel mühendisinin bireysel katkıda bulunan rolüne dönüştü. Ve aniden, son birkaç yıldır tek önemsediği şey - daha iyi bir mühendis olmak, daha iyi kod yazmak - yeni zorluklara yol açtı. Şirket için doğru teknik yönlendirmeyi nasıl sağlayacaktı? Darboğazların engeli kaldırılsın mı? Başkalarının onun için yaptığı gibi diğer mühendislere akıl hocalığı yapmak ve yardım etmek mi?

Bu bölümde Sarah ile oturduk ve bir personel artı mühendis rolünün birçok nüansları, yeterlilikleri ve beklentileri hakkında konuştuk.

İşte sohbetten en sevdiğimiz paketlerden bazıları:

• Geride kalmak istemiyorsan, öğrenmeye devam et. Fikirleri tartışın ve farklı bakış açılarına ve geçmişlere sahip diğer mühendislerden geri bildirim alın.
• Bir personel mühendisi olarak, enerjinizin çoğu, vizyon ve strateji için takımlar arası işbirliğine gidiyor. Şirket beş yıl sonra nerede olacak? Oraya nasıl gideceksin?
• Personel mühendislerine mentor olarak sahip olmak, daha genç kişilerin bu rollere ulaşmak için hangi adımları atması gerektiği konusunda netlik kazanmasını sağlar ve mühendislik liderleri oluşturma sürecini hızlandırırsınız.
• Popüler inanışın aksine, bir personel mühendisi yapısal bir sorun için hızlı bir çözüm değildir. Yeni bir işi kabul etmeden önce, yanlış anlamaları önlemek için sizden ne beklendiğini sorun.
• Personel mühendisleri, hedeflerine ulaşmasına yardımcı olabilmeleri için şirketin ihtiyaçlarını anlamalıdır. Gemiye binerken, mümkün olduğunca çok belge okuyun ve mümkün olduğunca çok kişiyle konuşun.

Tartışmamızdan hoşlanıyorsanız, podcast'imizin diğer bölümlerine göz atın. iTunes, Spotify, YouTube'da takip edebilir veya seçtiğiniz oynatıcıdaki RSS beslemesini alabilirsiniz. Aşağıda bölümün hafifçe düzenlenmiş bir transkripti var.

Öğrenmeyi asla bırakma

Brian Scanlan: Bugünkü programa katıldığınız için çok teşekkürler Sarah. Sizinle konuşma fırsatı bulduğum için çok mutluyum. Algolia'daki rolünüz ve işiniz hakkında konuşmadan önce, bu noktaya kadar olan yolculuğunuzu duymak isterim. Bugün bulunduğunuz yere yolculuğunuz nasıl başladı?

Sarah Dayan: Merhaba, beni kabul ettiğiniz için teşekkür ederim. Bu aslında komik bir hikaye. Şu anda 32 yaşındayım ve 15 yaşımdayken evde geniş bant ve sınırsız internetimiz vardı. Her zaman bir şeyler inşa etmeye meraklıydım ve web sitelerini ilk gördüğümde “Bunu nasıl yapacağımı bilmeliyim” dedim. Bir şey diğerine yol açtı ve ilk forumumu phpBB ile kurdum. PHP gerçekten çok büyüktü ve hala büyük, ama o zamanlar gerçekten web'in diliydi.

“Bunun benim işim olmadığına, belki de sevdiğim şeyi yapıyor olmam gerektiğine karar verdim. Bu yüzden sevdiğim şeye geri döndüm – web siteleri oluşturmaya”

O zamanlar, özellikle yazılım mühendisi olarak teknoloji alanında kariyer yapmak, bugünkü kadar havalı ve sıcak değildi. Ailem okulda dil ve edebiyatta iyi olduğum için gazeteci olmam gerektiğini düşündü. Ve bu yaptığım ilk şeydi. Gazetecilikte ilk yılımı geçirdim ve tamamen başarısız oldum ve sonra bunun benim işim olmadığına, belki de sevdiğim şeyi yapıyor olmam gerektiğine karar verdim. Bu yüzden sevdiğim şeye geri döndüm - web siteleri oluşturmaya. İlk işimi bir ajansta buldum ve orada altı yıl geçirdim. Bana iş hakkında, müşterilerle, ne istediklerini bilen ve ne istediğini bilmeyen insanlarla çalışmak hakkında çok şey öğretti. Daha sonra startup dünyasına geçtim. 15 yılı aşkın bir süredir kod yazıyorum ama profesyonel olarak 12 yıldır bu işi yapıyorum. Algolia'daki şu anki görevime beni getiren de bu oldu. Dört yıldır oradayım ve artmaya devam ediyorum.

Brian: Süper. Erken öğrendiğin ve kafana takılan ilginç derslerin var mı?

Sarah: Teknolojiye giden klasik bir yolum yok. Ben mühendislik okuluna gitmedim ve bunu yapmazsan teknoloji alanında harika bir kariyere sahip olman mümkün. Kesinlikle kendi kendini yetiştirebilirsin, başka insanlardan öğrenebilirsin ve bir diplomaya sahip olmak zorunda değilsin. Ancak diploma sahibi olmamak öğrenmemek için bir mazeret değildir. Google'da mühendislik yöneticisi olan Sarah Drasner'ın CSS-Tricks'te bununla ilgili harika bir blog yazısı var. Teknoloji alanında diplomasız bir kariyere sahip olsanız bile, bu sizi öğrenmekten ve bilgi aramaktan muaf tutmaz.

“Geri bildirim almadım, başka insanlarla, başka mühendislerle, başka bakış açılarıyla, başka geçmişlerle sohbet etmedim. Ve böylece geride kaldım”

Ve okulda gerçekten öğrendiğiniz bir şey de öğrenmeyi öğrenmektir ve bu gerçekten önemli bir beceridir. Kariyerimin başlarında, size bahsettiğim ajansta uzun süre tek çalışan bendim. Yalnızdım. Ve aynı zamanda kod yazan ama yaptığım şeylerden biraz uzak olan patronum vardı. Ve tek başına çalışmak özgürleştirici olabilse de – çok fazla güveniniz, çok özgürlüğünüz var – o kadar hızlı öğrenemiyorsunuz çünkü kendi bakış açınız dışında herhangi bir geri bildiriminiz veya başka bakış açınız yok. Ve eğer aktif bir öğrenme bile yapmazsanız, geride kalacaksınız.

Bu başıma gelen şeylerden biri. Geri bildirim almadım, diğer insanlarla sohbet etmedim: diğer mühendislerle, başka bakış açılarıyla, başka geçmişlerle. Ve böylece geride kaldım. Sahip olduğum bilgiye güveniyordum ve işe yaradığı için işleri farklı yapmak için hiçbir nedenim yoktu. Bu, kariyerimin başlarında aldığım en büyük derslerden biri olurdu. Özellikle teknoloji üzerine klasik bir yolculuğunuz yoksa, etrafınızı size geri bildirim ve bakış açıları getiren diğer insanlarla çevrelemek paha biçilmezdir ve bu, kariyerinize güç katacaktır.

Brian: Bence herhangi bir profesyonel rolde olan herkes için harika bir tavsiye ama senin için gerçekten işe yaramış gibi görünüyor. Bu günlerde PHP ile çalışmamakla ilgili bir şeyi özlüyor musunuz?

Sarah: Bence PHP harika bir dil. Modern JavaScript'te PHP'den pek çok ilham kaynağı bulabilirsiniz. Artık onunla çalışmıyorum çünkü JavaScript, PHP'yi kullanmak isteyebileceğiniz her yerde kullanabileceğiniz bir noktaya geldi. Ve özellikle bir ön uç mühendisi olarak, ortak paylaşım gibi, ön uçta ve arka uçta aynı dili kullanmanın birçok avantajı vardır. Ama bence PHP harika bir dil. Bir sürü kötü espri alıyor ve “Oh, PHP öldü” ama Laravel gibi bir şeyin başarısına baktığınızda, PHP'nin ölmekten çok uzak olduğunu hissediyorum.

PHP'ye girdiğimde, ciddi insanların kullandığı çerçeveye Zen çerçevesi deniyordu. Aslında, Zen'in PHP'nin arkasındaki şirket olduğuna inanıyorum ya da en azından geri aldı. Artık hiç kimse Zen çerçevesini kullanmıyor, en azından yeni projeler için değil, ancak PHP'nin şu anda nerede olduğunu görmek harika. Hala gelişiyor, insanlar PHP'de kodlamanın tadını çıkarıyor ve bence bu harika. Herkes için değil, ama sen yapıyorsun. Herkes istediği dilde masaya oturabilir.

Mühendislik merdivenini tırmanmak

Brian: Şu anda Algolia'da personel mühendisisiniz. Bana biraz bu rolden ve ne üzerinde çalıştığınızdan bahsedin, biz de personel mühendisinin ne olduğuna geçelim.

Sarah: Elbette. Ben bir personel mühendisiyim ve ön uçta çalışıyorum. Ben ön uç deneyimleri, kısaca FX adlı bir ekipteyim ve Algolia için ön uç kitaplıklar üzerinde çalışıyoruz. Algolia bir arama motorudur, bu yüzden uçtan uca. Verilerinizi aramaya göndermek için birden çok dilde motorunuz ve bazı API istemcileriniz var, ancak aynı zamanda ön uç kitaplıklarınız da var, çünkü kimin erişilebilir bir çalışan arama kutusu, bir isabet listesi, bir ayrıntılandırma listesi veya hiyerarşik menü?

Bütün bunları düzgün bir şekilde uygulamak zordur. Bunu müşteriler için yapıyoruz ve üzerinde çalıştığım ekip de bu. Ben bireysel bir katılımcıyım (IC) ve herhangi bir liderlik yolunda değilim. Ama gerçek şu ki, bir IC olarak daha yüksek rollere yükseldikçe, realiteniz liderlik rolünüzle biraz karışıyor. Herhangi bir raporum yok ve kimseyi yönetmiyorum, ancak yöneticimle daha çok şeylerin vizyon yönü olan konularda çok zaman harcıyorum. Ama yine de her gün kodluyorum ve herkes gibi incelemeler yapıp incelemeler alıyorum. Yani hala bir IC rolü. Algolia'da oldukça ileri bir seviyeye gelişebilir ve her gün kod yazan bireysel bir katılımcı olarak kalabilirsiniz.

"Üst düzey herhangi bir şey ve stratejiye çok fazla enerji harcamaya başlıyorsunuz - vizyon nedir, ürün beş yıl içinde nerede olacak ve bu konularda nasıl başarılı olacağız?"

Brian: İşin geri kalanına kıyasla nakliyeye ne kadar zaman harcadığınızı düşünüyorsunuz? İçeriği paylaşmak, strateji üzerinde çalışmak, bu tür şeyler.

Sarah: Bunu ölçmek zor. 50/50 diyebilirim. Çok kodladığım zamanlar oluyor ve kullandığınız enerjiyle aynı olduğu için kodlamaya incelemeleri de dahil ediyorum. Ancak aynı zamanda strateji oluşturmak için çok zaman, çok toplantı, çok vizyon belgesi, çok düşünme, geri bildirim toplamak için çok fazla konuşma var, örneğin PM'lerle, araştırmacılarla, tasarımcılarla çalışmak gibi… bunların hepsi işin bir parçası. . Algolia'da kıdemli personeliniz, müdürünüz vb. var. Üst düzey herhangi bir şey ve stratejiye çok fazla enerji harcamaya başlıyorsunuz - vizyon nedir, ürün beş yıl içinde nerede olacak ve bu konularda nasıl başarılı olacağız? Başarılı olmazsak bir yedek planımız olduğundan nasıl emin olabiliriz? Kıdemli bir mühendis olduğunuzda kodlama gibi bir projeye uygulamayı düşündüğünüz her şeyi ürünün stratejisine uygularsınız. Ürün üzerinde çok çalışıyorsunuz ve bir teknoloji girişiminde çalışmanın en sevdiğim yanlarından biri de bu.

Ben bir ajanstayken, herhangi bir strateji yapmadınız, ne düşündüğünüzü söylemediniz ve tavsiye vermeniz de beklenmiyordu. Sana söyleneni yaptın. Ancak bir startupta mühendis olduğunuzda, özellikle bu seviyelerde, sesiniz ve vizyonunuz çok önemlidir. Mühendisler için ürünler üretiyoruz. Ve kendimiz için bir şeyler inşa etmemek için çok dikkatli olmamız gerekse bile - bilginin lanetine sahibiz, ürünü biliyoruz, onu nasıl kullanacağımızı biliyoruz ve tüm uyarıları biliyoruz - hala mühendislerin neye önem verdiği konusunda hassasız. ne istedikleri ve hayatlarını neyin kolaylaştıracağı veya zorlaştıracağı hakkında. Bu nedenle ürüne, fikirleri masaya yatırmaya, zorlu fikirlere, kalıcı olacak en iyi şeyi inşa ettiğinizden emin olmaya büyük önem veriliyor.

“Nasıl daha iyi bir mühendis olunacağını düşünerek yıllarınızı harcadıktan sonra, başka şeyler düşünmeye başlamak için bir zihniyet değişikliğine ihtiyacınız olacak. Diğer insanlara nasıl yardım edebilirim? Durumların engelini nasıl kaldırabilirim?”

Brian: Kuruluşunuzun veya ekibinizin dışındaki diğer personel ve baş mühendislerle çalışmak için ne kadar zaman harcıyorsunuz? Bu, şirketinizde aktif bir topluluk mu? Bununla işbirliği içinde çok iş yapıyor musunuz? Gruplarınızda büyük ölçüde bağımsız mı çalışıyorsunuz? Veya birlikte çalıştığınız diğer kıdemli personel mühendislerinin bir alt kümesi var mı?

Sarah: İstediğim kadar değil. Herhangi bir organizasyonda, seviyeler yükseldikçe, daha az insanınız olur. Yani bir ton IC beş, IC altı, personel ve müdür yok gibi değil. Şu anda birçok kıdemli insanı işe alıyoruz, bu yüzden cevabım altı ay içinde farklı olabilir. Diğer personel ve hatta baş mühendislerle konuşmak için normal bir süre harcadım, ancak çok fazla olmadığımız için herhangi bir topluluk veya resmi bir şey yok gibi. Şimdi, yaşlılarla ve daha üstlerle tartışarak çok zaman harcadım çünkü bu benim görevimin bir parçası.

Rolümün bir kısmı, üst düzeydeki insanların büyümesine ve personel düzeyine terfi etmesine yardımcı olmak. Algolia büyüklüğündeki birçok şirkette kıdemli bir mühendis olarak, oraya ulaşmak için ne yapmanız gerektiğini biliyorsunuz. Daha çok bir kontrol listesi. Bundan sonra, daha karmaşık hale geliyor çünkü yoruma açık birçok şey var, kişiliğinize bağlı olarak başka bir kişiden çok farklı yapabileceğiniz şeyler. Ama fikir şu ki, üst seviyeye ulaştığınızda, zorlu beceri setinizde optimal olmanızı bekliyoruz. İyi olduğunuzu biliyoruz, belirli bir teknik seviyedesiniz ve bundan daha fazla büyümenizi beklemiyoruz, ancak sizden başka tür beceriler geliştirmeniz istenecek.

"İyi olduğun şeyi, yapmaktan hoşlandığın şeyi bulmalıyız ki parlamana yardım etsin ve onu geliştirsin. Çok fazla mentorluk var”

Daha iyi bir mühendis olmayı, daha iyi kod yazmayı, daha iyi incelemeler yapmayı veya bir inceleme aldığınızda daha az yorum yapmayı düşünerek yıllarınızı harcadıktan sonra, başka şeyler düşünmeye başlamak için bir zihniyet değişikliğine ihtiyacınız olacak. Diğer insanlara nasıl yardım edebilirim? Durumların engelini nasıl kaldırabilirim? Kendi iş yükümü nasıl oluşturabilirim? Bunlar, bu seviyelere ulaşmadan önce düşünmeniz gereken şeyler değildir. İnsanların konuya yaklaşmalarına, ne anlama geldiklerini anlamalarına ve oraya ulaşmak için kişiliklerinin hangi bölümünü kullanacaklarını anlamalarına yardımcı oluyorum.

Örneğin bazı insanlar sahnede olmayı ve sohbet etmeyi sever. Ve eğer bu onların hoşuna giden bir şeyse, kesinlikle daha iyi konferans anlaşmaları yapmalarına ve daha iyi bildiriler yazmalarına yardım etmeliyim. Ama bu senin işin değilse, buna yatırım yapmamız için hiçbir neden yok. Nelerde iyi olduğunuzu, neleri yapmaktan hoşlandığınızı bulmalı, bu da parlamanıza yardımcı olacak ve bunu geliştirecektir. Çok fazla mentorluk var. Bu, bu kıdem düzeyinde olmanın en sevdiğim yanlarından biri.

Bir şirket için, bir personele veya bir kıdemli mühendise sahip olmak gerçekten ilginç değil – 3, 5, 8, 16'ya sahip olmak istiyorsunuz. Ve bunu yapabilmenin tek yolu, zaten orada bir seviye daha düşük olan insanlara yardım ediyor. Mühendislik yöneticinizin bunu tüm ekiple tek başına yapmasını bekleyemezsiniz. Diğer mühendislerin bir veya iki yıl önce yaptıkları işi yapmalarına yardımcı olan mühendisleriniz olduğunda, bu çarpan etkisine sahip olursunuz. Ve bence bu insanlar için gerçekten heyecan verici çünkü başkalarından, aynı organizasyonda bu süreçten geçen insanlardan bir şeyler öğreniyorlar. Bu adımları takip ederlerse, dinlerlerse işe yarayabileceğine dair bir güven var. Oraya ulaşmak için ne yapmam gerektiğini anlamama yardımcı olabilecek baş mühendislerden bir şeyler öğrenmek istiyorum.

Öğreten kişi için özellikle ilginçtir çünkü gerçekte ne yaptıklarını inceleyebilirler. Sonrası bulanıklaşıyor ve siz "Evet, bundan biraz yaptım, biraz bundan" diyorsunuz. Hayır. Ne yaptın? Attığınız somut adımlar nelerdir? Evet dediğin şeyler neler? Hayır dediğin şeyler neler? Fikirlerinizi netleştirmenize, sürecinizi netleştirmenize ve sonrakiler için daha verimli olmanıza yardımcı olduğunu düşünüyorum.

İşe alım personeli artı mühendisler

Brian: Oldukça zor olabilecek bir organizasyona yeni personel ve baş mühendisler dahil etmekten bahsettiniz. Bu tecrübe ettiğin bir şey mi?

Sarah: Dürüst olmak gerekirse bu çok yaptığımız bir şey değil. Üç ya da dört baş mühendisimiz var ve hepsi benim ekibimde değil. Sahip olduğum deneyim çoğunlukla kıdemli mühendisleri getirmekle ilgili. Şimdi, herkes için ortak olan şeyler var ve bir de baş mühendisler için ilginç olabilecek şeyler var ve ben yine de deneyip deneyebilirim.

“Çok, çok kıdemli bir kişi size birçok konuda yardımcı olabilir, ancak şirketin veya ekibin yapısal sorunlarını çözemezler”

Netlik son derece önemlidir ve elbette, bir personel veya baş mühendisi işe alırken aynı tutuşu beklemezsiniz. Onların kendi kendine başlayanlar olmasını istiyorsun. Netlik, sizden ne beklendiğini, tüm görevleri vb. anlatmakla ilgili değildir, daha ziyade size görevinizle ilgili bir fikir vermekle ilgilidir. Buradaki amacın ne? Burada ne yapıyorsun? Ve bunun görüşme düzeyinde başladığını söyleyebilirim. Bir şirkete katılan bir personel veya baş mühendis için tavsiyem bunu sormak olacaktır, çünkü bazen insanlar sorunlarını çözmek için çok üst düzey roller almaya çalışırlar. "Oh, hadi çok, çok kıdemli birini işe alalım çünkü bizim bilmediğimiz şeyleri biliyorlar" gibiler. Ve bu doğru değil. Çok, çok kıdemli bir kişi size birçok konuda yardımcı olabilir, ancak şirketin veya ekibin yapısal sorunlarını çözmeyecektir.

Öte yandan, bir mühendislik yöneticisi neden o kişiye ihtiyaç duyduklarını düşündüklerini merak etmelidir. Çoğu zaman, kodlama harikası için bu seviyede birini işe almazsınız. Ekibinizde kıdemli bir mühendis varsa, bu Algolia'daki IC 4 olacaktır. Kodlama konusunda zaten mükemmel yetenekliler ya da en azından öyle olmalılar. Bir personel veya baş mühendis, yapmak istediğiniz bir şeyle ilgili deneyimle gelir ve örneğin, ekipte daha önce kimsenin ulaşamadığı bir ölçeğe ulaşmanız gerektiğini bildiğinizde onlara ihtiyacınız olabilir. Belki çözebilirsin, ama bir hızlandırıcı istiyorsun ve ekibinde çok kıdemli bir kişinin yapacağı şey bu.

Bu soruları önceden sormak, beklenen şeyde herhangi bir yanlış hizalama olmadığından emin olmanın iyi bir yoludur. Çok kıdemliyseniz ve bir yanlış hizalama olduğu için sizden üst düzey bir seviyede kodlamanız veya çalışmanız isteniyorsa, hayal kırıklığına uğrayacaksınız ve muhtemelen ayrılacaksınız. Bu seviyedeki bir kişiyi sırf ayrılmaları için işe almak için çok fazla zaman harcamak istemezsiniz çünkü bu son derece maliyetlidir.

Bundan sonra, bu kıdem seviyesindeki birinin çok okumasını ve çok sohbet etmesini beklerdim. Bu, genç bir mühendis olduğunuzda genellikle yapmadığınız bir şeydir. Kuruluşunuza geliyorsunuz, size ilk göreviniz veriliyor ve bu sadece akıyor – çalışmaya başlıyorsunuz, kodlamaya başlıyorsunuz ve yapmanız gereken şey bu çünkü sizi bir sonraki adıma götürecek olan şey bu.

"Göreviniz, teslim edilen ürünün sığacağından ve ölçekleneceğinden emin olmaktır. Ve bunu şirketteki diğer insanlarla tartışmazsanız yapamazsınız”

Ancak bu üst düzeylerde olduğunuzda, nerede olduğunuzu, neler olduğunu, kimin ne yaptığını anlamanız önemlidir. Yalnızca diğer mühendisler ve kıdemli kişilerle değil, aynı zamanda daha genç insanlarla, ürün yöneticileriyle, tasarımcılarla ve araştırmacılarla da ilişkiler kurmanız gerekir. Şirketin nasıl çalıştığını ve buna nasıl uyum sağlayabileceğinizi, neyi geliştirmeye yardımcı olabileceğinizi anlamanız gerekir. Herhangi bir yazılı dahili belge varsa, okuyun ve işiniz bittiğinde tekrar okuyun.

Ardından, görüşmeniz gereken kişilerin kimler olduğunu mühendislik yöneticinize sorun. Yeni biriyle her konuştuğunuzda, onlara kiminle konuşmanın ilginç olacağını düşündüklerini sorun. Bu size kanatlar verecek çünkü ilişkiler kuracak ve neler olduğunu anlayacaksınız. Ürünler nelerdir? Mevcut mücadeleler nelerdir? Nerede yardım edebilirsin? Ekibiniz ve oluşturduğunuz ürünler bu şemaya nasıl uyuyor? Çünkü bu seviyelerde, ürüne bu odaklanma ile, artık sadece kodun kalitesi ile ilgili değil. Takımdaki kıdemliler zaten bununla ilgileniyor ve bunu gayet iyi yapıyorlar. Göreviniz, teslim edilen ürünün sığacağından ve ölçekleneceğinden emin olmaktır. Ve bunu şirketteki diğer insanlarla tartışmazsanız yapamazsınız.

Yeni zorluklar

Brian: Bilmeyenler için Algolia, barındırılan güçlü bir arama API'sidir. Dışarıdan oldukça başarılı bir şirket gibi görünüyor ama eminim kafanızda bir çok zorluk ve konu vardır. Düşündüğünüz veya üzerinde çalıştığınız bazı büyük problemler hakkında bize bir fikir verebilir misiniz?

"Fikir şu ki, bu verileri aramak, elde etmek ve sayfaya ulaşmak için hangi yolu seçerseniz seçin, doğru verilerle karşı karşıya kalırsınız."

Sarah: Dediğiniz gibi, Algolia barındırılan bir arama API'sidir. Bu, sahip olduğumuz en büyük API ve şimdilik en başarılısı, ancak biraz daha genişlettik. Şu anda, arama için kullandığınız aynı veri kümesini kullanan, ancak belirli bir ürüne dayalı olarak size önerilerde bulunan Algolia Recommend adlı bir ürün var.

Algolia'nın amacı sadece arama yapmak değil, aynı zamanda içeriği ortaya çıkarmaktır. Çok fazla içeriğiniz var, ancak bunların hepsi aynı anda aynı kişiler için alakalı değil. Buradaki fikir, bu verileri aramak, elde etmek ve sayfaya ulaşmak için hangi yolu seçerseniz seçin, doğru verilerle karşı karşıya kalırsınız. Algolia'nın amacı budur. Bununla ilgili zorluklar var. Biz arama uzmanlarıyız, ancak öneri ve makine öğrenimi yönü çok daha yeni bir teknoloji, dolayısıyla en son şeylerle öğreniyoruz. Aramaya kıyasla öğreneceğimiz çok şey var. Bu en büyük zorluk değil, ancak aramada elde ettiğimiz başarının aynısını yineleyebileceğimizden emin olmak için yine de bir zorluk.

Şimdi, Algolia'nın pek iyi olmadığı şeyler var. Bu bir arama motoru, veritabanı değil. Hızlı olacak, eninde sonunda tutarlı olacak, ancak tüm verilerinize sahip olacağınızın, verilerinizin her zaman tutarlı olacağının veya tüm verilerinizin orada olacağının garantisi yok. Bu, arama motorunu bir veritabanından çok farklı kılan bir tasarım seçimidir. Bununla birlikte, birçok insan Algolia'yı veritabanı olarak kullanmayı sever çünkü Algolia'ya veri göndermek çok kolaydır ve oradadır ve hızlıdır. Belki bundan öğrenecek bir şeyler vardır. Belki bir veritabanı da olabilir ve öyle olacağını söylemiyorum ama belki olabilir. Belki de anlamamız ve araştırmamız gereken başka bir şey vardır.

Algolia'nın çalışamayacağı birçok kullanım durumu vardır. Bunlardan biri rezervasyon kullanım durumudur. Bir Airbnb rezervasyonu yapmak istiyorsanız, onu aradığınızda, arama sonuçlarınızdadır, yani müsaittir. Ancak sayfaya ulaşır ulaşmaz, verilerinizi veritabanınızdan Algolia'ya kopyaladığınız için artık mevcut değildir. Veritabanınıza bir şey kaydettiğinizde, bu değişikliği Algolia'ya biraz farklı bir biçimde göndereceksiniz. Ve bu gecikme olduğu için - bu gerçek zamanlı değil - rezervasyon kullanım durumu gibi bir şey çalışamaz. Airbnbs ile uğraşırken, şu anda mevcut olan bir şey 30 saniye içinde mevcut olmayabilir, ancak yine de arama motorunuzda görünebilir çünkü kaydettiğinizde, yayılması için 10 saniyeye veya buna benzer bir şeye ihtiyacınız vardır. Algolia ve belki de başarısız oldu ve tekrar yapmanız gerekiyor. Bunlar arama motoru düzeyinde düşündüğümüz şeyler. Destekleyebileceğimiz bir şey mi? Söz konusu değil mi? Bunun arkasındaki iş durumu nedir? Çünkü bir çok şeyi yönlendiriyor.

“Görünmez olmalı; sorunsuz olmalıdır. Bunların ayrı API'ler olması sizin sorununuz değil. Çözmemiz gereken sorun bu”

Şimdi, ön ekiple ilgili olarak, Algolia Recommend'ten bahsettim. Müşteri olduğunuzda, farklı ürünler olması gerçekten umurunuzda değil. Bu özelliklere sahip Algolia Search ve bu alt özelliklere sahip Algolia Recommend'e sahip olmanız umurunuzda değil. Algolia'ya abone oluyorsunuz ve birlikte iyi çalıştığı söylenen bir dizi özellik için aylık veya yıllık ücretinizi ödüyorsunuz. Bu API ile veri API'leri arasında dahili olarak oluşturduğumuz yapay sınırları anlamak istemezsiniz ve anlamanıza da gerek yoktur.

“Kuruluş şemanızı göndermeyin” diye bir söz var ve bence bu bizim için sonraki büyük konulardan biri. Ön uçta, Algolia ön uç kitaplığını kullanırken, buna mı yoksa buna mı ihtiyacınız olduğunu merak etmenize gerek kalmadığından nasıl emin olabiliriz? Bu sınırları hissetmiyor musun? Görünmez olmalı; sorunsuz olmalıdır. Bunların ayrı API'ler olması sizin sorununuz değil. Çözmemiz gereken sorun bu.

Arama API'sine gerçekten güçlü bir şekilde bağlı olan kitaplıklar oluşturduk ve şimdi birlikte çalışabilen daha yeni API'lere genişletmemiz gerekiyor ve bazen son yanıtı almak için birini, ardından diğerini aramanız gerekiyor. Şu anda tüm bu şeyler, olmasını istediğimiz kadar sorunsuz değil. Bu API'leri birbirine bağlamak istediğinizde, kenarlarda hala biraz pürüzlü. Bu mümkün, ancak öğreticileri okumalı, devam etmeli, burada ve orada küçük değişiklikler yapmalı ve bazı ortak kodlar yazmalısınız. Bu hoş değil, eğlenceli değil ve çok fazla iş. Size “o kütüphaneyi kullanın” diyeceksek, yapmak istemediğiniz bir işi yapması gerekiyor. Alt düzey ilkellerin kullanımı bu kadar kolaysa, kütüphaneyi kullanmanın hiçbir gerekçesi yoktur, değil mi?

Şu anda en büyük zorluklardan biri, kütüphanelerin değerini yükselttiğimizden emin olmaktır. Zaten çoğu insanın yapmak istemediği birçok şeyi yapıyorlar, ancak belirli bir noktada, belirli müşteriler için, yalnızca arama yaptığımız zamanki kadar sorunsuz ve keyifli değil. Ve bu, peşinde olduğumuz duygudur. "Vay canına, düşündüğümden çok daha basit" hissi.

Brian: Son olarak, dinleyicilerimiz size ayak uydurmak için nereye gidebilirler?

Sarah: Yani beni çoğunlukla Twitter'da bulabilirsiniz, ben frontstuff_io. Bunun Twitter'daki en kötü yol olduğunun acı bir şekilde farkındayım. Beni sarahdayan.com'dan da bulabilir, dilerseniz GitHub'dan da takip edebilirsiniz; Bazen bir şeyler taahhüt ederim. Ama evet, sohbet etmek istersen, DM'lerimin açık olduğunu düşünüyorum, bu yüzden bana bir şey gönder.

Brian: Süper. Sarah, bugün bana katıldığın için çok teşekkürler.

Sarah: Bana sahip olduğun için teşekkür ederim. Bu eğlenceliydi.