LinkedIn'den ayrılırken

• İşi doğru yapmakla şirketin hızlı temposu çatıştığında sizin seçiminiz ne olur?
• İnançlarını koruyup uzlaşmak mı, yoksa ilkelerine uyan işi bulmak için ayrılmak mı sorusunda, mühendis Chris Krycho ikincisini seçti.
• Chris, sonunda kendi ilkeleriyle örtüşen işi sürdürmek için LinkedIn'den ayrıldı.
• Podcaste anlattıklarının derlenmiş hali.
• Onun hikâyesi, "yenilik ihtiyacı" ile "proje sağlığının önemi" arasındaki gerilimi vurguluyor.

Chris Krycho'nun LinkedIn'deki ilk günü

• Chris, 2019 Ocak ayının sonunda LinkedIn'e katıldı. Büyük şirketlerde veya sağlıklı küçük şirketlerde sık görülen çeşitli onboarding süreçlerinden geçti.
• Chris, Colorado'dan uzaktan çalışacaktı; ancak ilk iki haftasını onboarding ve ekiple vakit geçirerek geçirdi.

Milyonlarca satır kod

• Önceki şirketindeki deneyimiyle kıyaslandığında, LinkedIn'in frontend istemci uygulaması ve backend servislerinin ölçeği onu ciddi biçimde şaşırttı.
• LinkedIn'in frontend'i 2 milyon satıra ulaşıyordu; bu, önceki şirketinin tüm kodundan çok daha fazlaydı.

Altyapı ekibi

• Chris'in rolü altyapı ekibindeydi; sunucu kurmaktan çok mühendislik desteği veya geliştirici deneyimini iyileştirmeye odaklanıyordu.
• Amaç, LinkedIn'in büyük ölçekli masaüstü uygulaması üzerinde çalışmayı daha kolay hale getirmekti.

JavaScript modernizasyonu

• JavaScript class'larının kullanıma alınması yoluyla kodu modernleştirme çalışmalarına katıldı. Ember framework'ünü kullanırken ortaya çıkan sorunları çözme sürecinde çok şey öğrendi.
• Büyük bir codebase'te migration çalışmalarının mümkün olduğunca otomatikleştirilmesi gerektiğini, çünkü iş yükünün elle yönetilemeyecek kadar büyük olduğunu fark etti.

TypeScript'e geçiş

• Frontend'de ortaya çıkan hataları azaltmak için TypeScript'e geçme kararı alındı.
• TypeScript kademeli olarak devreye alınabiliyordu ve bu da LinkedIn'in ihtiyaç duyduğu ölçeklenebilirliği sağlıyordu.

Yavaş migration planı ve 'Finger Gun's Plan'

• Chris ve ekibi, Ember kodunu React'e taşımak için 3-5 yıllık bir plan önerdi; ancak başka bir ekip, kapsamlı bir yeniden değerlendirme ve yüksek hız vaat eden 'Finger Gun's Plan'ı sundu.
• Bu yaklaşım farkı, Chris ve ekibinin yaşadığı sorunlarla şirketin hızı önceleyen kültürü arasındaki çatışmayı yansıtıyordu.

Chris'in deneyimleri ve öğrendikleri

• Yetersiz alarm sorununu fark etti.
• Bellek kullanımındaki artış ve sunucu yeniden başlatmalarının zincirleme etkisi nedeniyle tüm veri merkezindeki sunucular devre dışı kaldı.
• Sistemi sıfırlayarak ve yetkileri ayarlayarak sorunu çözmeye çalıştı.
• Başarısızlık kaçınılmazdır ve yazılım mühendisliği, mühendislerin ürün çıktıları üretme sürecini destekleyen sistemleri tasarlamaktır.
• Çok katmanlı dayanıklılığa sahip sistemlerin gerekliliğini vurguladı.

Olaya karşı tepki

• Sorun çözme sürecinde, yönetimin güven eksikliğinden kaynaklanan memnuniyetsizlik ortaya çıktı.
• Kıdemli mühendislerle görüş ayrılıkları ve iletişim sorunları yaşandı.
• Sistemin yalnızca en iyi koşullarda değil, her durumda destek sağlayabilmesi gerektiğini vurguladı.

Artan baskı

• Teknik borcu azaltma ve dayanıklılığı artırma çabalarına rağmen yöneticilerin memnuniyetsizliği arttı.
• Karmaşık sorunlara basit çözümler talep eden yönetimle çatışmalar yaşandı.

Organizasyonel yeniden yapılanma

• 'Finger Guns' ekibi nedeniyle organizasyonel yeniden yapılanma ve rol değişiklikleri yaşandı.
• Farklı rollerde yeni deneyimler ve öğrenme fırsatları olduğunu fark etti.

Düşünme ve farkındalık

• Geçmiş deneyimleri ve mevcut durumu üzerinden öz değerlendirme yaptı.
• İnsan ilişkileri kurmanın ve iletişimin önemini fark etti.
• Teknik sorunlarla sosyal sorunların birbiriyle bağlantılı olduğunu anladı.

Sonuç ve çıkarımlar

• Chris, hızı en yüksek değer sayan kültüre karşı eleştirel bakışını korudu.
• Kariyeri ve kişisel değerleri üzerine düşünerek yeni fırsatlar aradı.
• Mühendislik mükemmeliyetini hedefleyen bir rol bulma yolculuğu Chris için sürüyor.

GN⁺ görüşü

• Chris Krycho'nun deneyimi, teknik ilkeler ile iş gereksinimleri arasındaki çatışmayı iyi gösteriyor.
• Onun kararı, kişisel değerlerle mesleki seçimler arasında denge kurmanın önemini vurguluyor.
• LinkedIn gibi büyük ölçekli teknoloji ortamlarında değişim yönetimi karmaşıktır ve bu, diğer şirketler için de önemli dersler sunar.
• TypeScript gibi teknolojilerin kullanıma alınması kod kalitesini artırıp hataları azaltmaya yardımcı olabilir; ancak büyük codebase'lerde kademeli bir yaklaşım gerekir.
• Bu tür teknik değişimleri ilerletirken geliştirici deneyimi ile ürün yayınlama hızı arasındaki denge dikkate alınmalıdır.

[GN⁺]

Hacker News görüşleri

• Bir yöneticiyle yaptığı konuşmada kendisine, "fazla idealist olduğu, kâra yeterince önem vermediği ve değerlerini değiştirmesi gerektiği" söylendiğini anlatıyor. Buna karşı rahatsızlığını dile getirip kendi değerlerine bağlı kalma kararlılığını ortaya koydu. Bunun podcast'teki en ilginç kısım olduğu, yazarın da buradan önemli geri bildirimi kasıtlı olarak görmezden geldiği izlenimini edindiği belirtiliyor. Kariyerinden çıkardığı ders ise doğru olanı bilmenin zor olmadığı, asıl zor olanın doğru çözüm konusunda tüm organizasyonu aynı çizgide buluşturmak olduğu.

  • Yöneticiyle konuşmada yaşanan değer çatışması örneği
  • Önemli geri bildirimin bilerek göz ardı edildiği izlenimi
  • Doğru çözüm etrafında organizasyon genelinde uzlaşının önemli bir ders olması

• 2019'da facebook.com'un React ile yeniden yazılması çalışmasına katıldım. LinkedIn'in kod tabanı ya da organizasyonu hakkında doğrudan bilgim yok ama benzer kod tabanları ve organizasyon yapıları olan şirketler gördüm. "Finger gun" yaklaşımını destekliyorum; iyi uygulandığında olumlu sonuçlar verebilir. Birden fazla istemci aynı işi yapmaya çalışıyorsa, birini temel alarak diğer platformlara hizmet verebilirsiniz. Ya da sıfırdan başlıyorsanız, bunu temiz, hızlı ve sade bir şekilde yapabilirsiniz. Başarının yaygın unsuru, yeni sistemi kuran küçük ve tecrübeli bir ekip olmasıdır; alan uzmanları ile teknik uzmanların bir araya geldiği küçük mühendislik ekiplerinden başarı çıktığına inanıyorum. Teknik yönetimde tekrar eden büyük sorunlardan biri, bir sonraki büyük sistemi en az deneyimli kişilerin inşa etmesidir.

  • React ile yeniden yazım deneyiminin paylaşılması
  • "Finger gun" yaklaşımı ve küçük, deneyimli ekiplerin öneminin vurgulanması
  • Az deneyimli kişilerin büyük sistemler kurmasının sorun olarak gösterilmesi

• Büyük yeniden yazımlar, yönetilebilir kod tabanlarında bile risklidir ve elde kalan sorunlar tamamen ortadan kalkmaz. Yıllar sonra gizli bir ayar sayfasını yeniden yazmak isteyecek kişi kim olur ki? Keşke kod tabanlarını yeniden yazmaya yarayan bir framework olsaydı, ama gerçekte yok. Otomatik codemod'lar tutarlılık ister, ama buna uyulan durumlar nadirdir. Zaman içinde kod kalıpları o kadar çok değişir ki, bu neredeyse ağacın yaş halkalarına bakmak gibidir. Yapılan şey kodu kutulara koyup yeniden düzenlemektir, fakat kutu seviyesinde otomasyon yoktur.

  • Kod tabanı yeniden yazımının riskleri ve kalan sorunlar
  • Kod yeniden yazımı için bir framework bulunmaması
  • Kod seviyesindeki otomasyon ile kutu seviyesindeki otomasyon arasındaki boşluk

• Şu anda LinkedIn'de çalışıyorum ve podcast'te bahsedilen Chris'in rolünün ve frontend web geliştirme kısmının ember ile ilgili olduğunu düşünüyorum. Sanırım LinkedIn'in monolitik amiral gemisi web uygulaması voyager-web'den söz ediyor. LinkedIn'de voyager-web dışında da milyonlarca satır kodu ve uzun build süreleri olan pek çok sistem var. Örneğin middle-tier, offline data stack, metric sistemleri, Kafka vb. 17 dakikalık build süresi aslında oldukça iyi; geçici altyapı arızaları olmadan 17 dakikaysa bu gerçekten çok iyi demektir.

  • LinkedIn'deki güncel çalışma deneyiminin paylaşılması
  • Çeşitli sistemler ve build süreleri hakkında açıklama
  • 17 dakikalık build süresine dair değerlendirme

• Milyonlarca satır JavaScript kodu aşırı bir şişkinliğe işaret ediyor. LinkedIn gibi bir hizmeti yeniden uygulama ya da kendi kişi veritabanımı kurma fikri aklıma geldi. Sorun, kişileri toplu halde nasıl taşıyacağınız. Microsoft LinkedIn'in temel sorunlarından biri kişi bilgilerini dışa aktaramamanız; oysa bu, bir kişi platformunda mutlaka olması gereken bir özellik.

  • JavaScript kodunun aşırı hacmine dikkat çekilmesi
  • Kişi bilgilerinin taşınmasındaki zorluk
  • Kişi bilgilerini dışa aktarma özelliğinin önemi

• LinkedIn'de 12 yıl geçirdim ama artık geçmişteki mühendislik organizasyonundan çok uzağız. Mühendisliğin başında Kevin Scott varken dönem çok daha iyiydi.

  • LinkedIn'de uzun süre çalışma deneyimi
  • Geçmişteki mühendislik organizasyonu ile bugünkü durum arasındaki fark

• Bu, Conway yasasının iş başında olduğu bir durum. Organizasyon değişmediği sürece aynı kod karmaşasını yeniden üretecektir. Olumlu mühendislik inisiyatifleri yukarıdan gelmeli ve çok üst düzey destek gerektirir. Organizasyonu aşağıdan yukarıya değiştirmek imkânsızdır; organizasyon kod tabanını üretir.

  • Organizasyon değişmeden kod karmaşasının yeniden ortaya çıkma ihtimali
  • Yukarıdan gelen olumlu mühendislik inisiyatiflerine duyulan ihtiyaç

• Chris Krycho'nun yaşadığı zorluklar hakkında dürüstçe konuşurken bunu suçlama oyununa çevirmemesi beni derinden etkiledi. CoRecursive, kodun arkasındaki karmaşık bağlamı araştırdığı için sevdiğim podcast'lerden biri.

  • Chris Krycho'nun dürüst tavrı ve suçlayıcı olmaktan kaçınması
  • CoRecursive podcast'ine yönelik olumlu değerlendirme

• Ember'dan React'e geçiş, daha önce çalıştığım bir müşterinin geliştirdiği teknolojiye uygun bir örnek gibi görünüyor. "Unhack" adında bir dil oluşturmuştu; bu sayede AST seviyesinde arama ve değiştirme yapılabiliyordu. Orijinal kodda bir kalıp tanımlayıp, onun yerine geçecek başka bir kalıp belirlediğiniz bir dil kullanıyordu. O müşteriyle çalışmayı birkaç yıl önce bıraktığım için bunun hâlâ var olup olmadığını bilmiyorum.

  • Ember'dan React'e teknik geçiş örneği
  • AST seviyesinde arama ve değiştirmeyi mümkün kılan "Unhack" dili

• LinkedIn'in kod tabanının dağınık olması, siteyi kullanınca hiç de şaşırtıcı gelmiyor. İlginizi çeken bir gönderiye tıklayıp, sonra yazarı hakkında daha fazla bilgi edinmek isteyip geri tuşuna bastığınızda akış yenileniyor ve gönderiyi kaybediyorsunuz. Aldığınız mesajlarda aşağı kaydırmaya çalıştığınızda tüm web sayfası yavaşlıyor ve girdiyi algılaması 10-15 saniye sürüyor. Neden 30 tane sahte bildirim alıyorsunuz? Bunlar insanları etkileşime zorlamak için üretilmiş sahte bildirimler. Öneri algoritması da bütünüyle berbat.

  • LinkedIn web sitesini kullanmanın zorlukları
  • Sahte bildirimler ve yavaş web sayfası tepkileri
  • Öneri algoritmasının sorunlu olduğunun vurgulanması