LinkedIn'den Ayrılırken
(corecursive.com)- Chris Krycho, LinkedIn'de yaklaşık 5 yıl boyunca masaüstü web uygulamasının frontend altyapısı ve geliştirici deneyiminden sorumlu oldu; bu süreçte büyük bir kod tabanını güvenle değiştirme işi ile ürünleri hızlı teslim etme baskısı arasındaki çatışmayı yaşadı
- LinkedIn masaüstü uygulaması, işe başladığında yaklaşık 2 milyon satır JavaScript iken zamanla yaklaşık 3,2 milyon satırlık bir monorepo'ya büyüdü; geçişler, otomasyon ve ürün ekiplerine yükü en aza indirme olmadan fiilen mümkün değildi
- Ember modernizasyonu ve TypeScript'in devreye alınması, hata azaltma ve geliştirme kalitesini artırmayı hedefliyordu; TypeScript'e geçişin uygulama loglarındaki hata hacmini en az %25 azaltabileceği analizi, şirket içinde ikna için kullanıldı
- Ember'den React'e geçiş planı, Chris'in ekibinin 3–5 yıllık kademeli otomasyon stratejisi ile, daha hızlı ürün denemeleri için mevcut yaklaşımı kökten yeniden tasarlama yönündeki yaklaşımın çarpışmasına dönüştü
- Büyük çaplı bir kesinti müdahalesi sırasında alarm, gözlemlenebilirlik, dayanıklılık ve code review sınırları ortaya çıktı; Chris, hızı en üst öncelik yapan organizasyon yönünün kendi değerleriyle uyuşmadığını düşünerek ayrıldı
5 yılda yaptığı iş ve kod tabanının ölçeği
- Chris Krycho, Ocak 2019'un sonunda LinkedIn'e katıldı ve yaklaşık 5 yıl çalıştı
- Sorumlu olduğu alan sunucu altyapısı değil, LinkedIn masaüstü web uygulamasının frontend altyapısı ve geliştirici deneyimini iyileştirmekti
- LinkedIn.com'un mobil olmayan tarayıcı deneyiminden sorumlu masaüstü uygulamasında büyük ölçekli JavaScript modernizasyon projelerine liderlik etti
- Önceki şirketindeki uygulama yaklaşık 150 bin satırdı, ancak LinkedIn frontend'i işe başladığında yaklaşık 2 milyon satır kod büyüklüğündeydi
- Aynı uygulamaya her çeyrekte 150–200 mühendis commit atıyordu ve onlarca ekip tek bir ürünü sürekli deploy ediyordu
- İşe başladığında uzaktan çalışan mühendis sayısı, toplam birkaç bin kişi içinde 100'den azdı ve Chris Colorado'dan uzaktan çalışan nadir örneklerden biriydi
2 milyon satır kodda migration nasıl yapılır
- İlk büyük işlerden biri, Ember tabanlı koda JavaScript'in modern class sözdizimini getirmekti
- Eski Ember sınıfları ile native JavaScript class'larının inheritance chain içinde karışması sorunu vardı ve içeride buna “Zebra Striping” deniyordu
- Bu ölçekteki bir migration mümkün olduğunca otomatik olmalıydı
- 2 milyon satırı elle düzeltmek aylar hatta daha uzun sürebilirdi
- Ürün ekiplerinden özellik geliştirmeyi durdurup sadece yeni sözdizimine geçmelerini istemek zordu
- LinkedIn'de ekipler arası yatay inisiyatifler (horizontal initiatives) süreci vardı ve ürün ekiplerinin katılımını %10'un altında tutmaya yönelik bir işletim ilkesi uygulanıyordu
- Chris'in ekibi, ürün ekiplerinin bizzat codemod çalıştırdığı bir model yerine, altyapı ekibinin otomasyonla PR oluşturduğu ve ürün ekiplerinin review ile smoke test yaptığı modelin daha kolay benimseneceğini düşündü
- Ember ile ilgili çalışmalar toplamda 18 ay sürdü; bunun büyük kısmı 6 ay içinde ilerledi, ancak bazı ekiplerdeki gecikmeler uzun bir kuyruk yarattı
TypeScript'i kabul ettiren hata azaltma mantığı
- Ember modernizasyonundan sonra Chris'in ekibi, frontend'de oluşan büyük hacimli JavaScript hatalarını bir sonraki hedef olarak seçti
- LinkedIn'de hata loglarının ölçeği çok büyük olduğu için harici servisler yerine şirket içi logging altyapısı kullanılıyordu
- LinkedIn bir önceki yıl 1 milyar üyeyi aşmıştı ve Chris ayrıldığında monorepo yaklaşık 3,2 milyon satıra ulaşmıştı
- Yarısı test koduydu
- Yarısı production koduydu
- Chris'in ekibi, TypeScript'in yakalayabileceği hata kategorilerini ayrı ayrı analiz etti
- Bazı hatalar TypeScript ile de yakalanamazdı, ancak tüm migration tamamlandığında günde milyonlar seviyesindeki JavaScript hataları içinde uygulama log hacminin en az %25 azaltılabileceği değerlendirildi
- Chris'in yazdığı TypeScript geçiş dokümanı mühendisler ve yöneticiler arasında tekrar tekrar paylaşıldı
- Çözülmek istenen problem
- Beklenen faydalar
- İşe alım rekabeti açısından karşılaştırma
- Diğer önceliklerle kıyaslama için karar zemini
- Sonrasında Chris, zor TypeScript type problemlerinde yardımcı olan şirket içi uzman rolünü üstlendi
Ember'den React'e: kademeli geçiş ve baştan tasarlama
- LinkedIn dünyadaki en büyük EmberJS kullanıcılarından biriydi, ancak Chris'in işi sonunda Ember'den React'e geçiş için plan hazırlama yönüne evrildi
- Üst düzey liderler, LinkedIn'deki migration maliyetinin fazla yüksek olduğunu ve ürün hızını yavaşlattığını düşünüyordu
- Chris'in ekibinin planı 3–5 yıllık kademeli bir otomasyon stratejisiydi
- Ürün ekiplerinin neredeyse hiç durmaması için otomasyon güçlendirilecekti
- Build pipeline, data layer, routing layer, reactivity system ve view layer sırayla ayrıştırılıp dönüştürülecekti
- Son aşamada Ember'in rendering ve reactivity sistemi React tarafına taşınacaktı
- Başka bir ekip hız sorununu daha doğrudan hedefliyordu
- Amaç, fikirden A/B testine kadar geçen süreyi aylardan haftalara indirmekti
- Masaüstü web, mobil web, iOS ve Android'deki farklı stack'ler ile uzun cycle time temel sorun olarak görülüyordu
- Chris, o ekibin yaklaşımını “finger guns mode”a yakın bir tavır olarak gördü
- Onlarca kişiyi destekleyen deneyimi yüzlerce mühendise ölçeklerken çıkacak sorunları yeterince ele almadıklarını düşündü
- Sorulara sık sık “sorun olmayacak” türü yanıtlar verildiğini hissetti
- Chris'in ekibinin 3–5 yıllık planı liderlikten güçlü bir karşılık görmedi
- Planın kendisi uzundu ve heyecan verici değildi
- Ekip de bunu “en az kötü seçenek” gibi sunduğu için ikna gücü zayıf kaldı
Kesinti müdahalesinde ortaya çıkan dayanıklılık sorunları
- Chris Noel tatilinden döndükten sonra, bazı LinkedIn kullanıcılarının LinkedIn.com sayfalarını en fazla yaklaşık 20 dakika boyunca göremediği bir sorun yaşandı
- Sorun, backend verilerini toplayıp hızlı iletmek için client kodunu Node.js üzerinde çalıştıran pre-rendering service ile ilgiliydi
- Serviste bir memory leak vardı ve container'lar memory limitini aşınca yeniden başlatılıyordu
- Kesintiyi büyüten birkaç etken üst üste geldi
- Memory kill için yeterli alarm yoktu
- Aynı anda yeniden başlayabilecek container sayısını belirleyen ayar bir YAML dosyasındaki bir key olarak duruyordu
- Bu değer type açısından geçerliydi ama bu sistem için yanlış bir değirdi
- Ayar, fiilen çalışan toplam servis sayısına neredeyse eşitti
- Deploy duraklaması uzun bir hafta sonu gibi uzadığında servisler benzer zamanlarda memory tüketti ve topluca restart olarak kullanıcı isteklerini işleyemez hale geldi
- Bazı sunucular düşünce kalanların yükü arttı ve bu sunucuların memory kullanımı da daha hızlı yükselerek veri merkezi ölçeğinde sunucu kayıplarına yol açtı
- Aynı dönemde filodaki CPU ve memory kullanımını azaltmaya yönelik resource rightsizing çalışması da sürdüğü için boş kapasite azalmıştı
- Chris ve diğer mühendisler daha iyi alarm, gözlemlenebilirlik ve dayanıklılık gerektiğini düşündü
- Tek bir Node sunucusu runaway duruma girse bile host process'i de öldürmemeliydi
- Sadece Node process'ini durdurup alarm üretmek ve sonra yeniden başlatmak daha güvenliydi
- Servis devre dışı kaldığında client-side fetch'e geçen bir fallback yol da değerlendirildi
Sadece code review ile önlenemeyecek çatışma
- Kesinti müdahale toplantıları haftada birkaç kez yapıldı; amaç ilerlemeyi paylaşmak ve yöneticilere rapor vermekti
- Başka bir ekibin yöneticisi kesinti müdahalesini üstlenerek ek kaynak getirdi ve Chris bunu, kendisine ve mevcut ekibin cevaplarına güvenilmediği yönünde algıladı
- Bu süreçte kıdemli bir mühendis “code review bunu neden çözemiyor?” diye sordu
- Chris'e göre sadece code review, aynı şeyin tekrar yaşanmayacağını garanti edemezdi
- İnsanlar hata yapar
- Junior bir mühendisin, çok kıdemli bir SRE'nin PR'ındaki bir ayarın mantıklı olup olmadığını sorgulaması zordur
- Sistemler, kıdemli mühendisin en iyi gününde değil, junior mühendisin kötü gününde de güvenli çalışacak şekilde tasarlanmalıdır
- Chris için yazılım mühendisliği, ürün çıktısı üreten mühendisleri destekleyen sistem tasarımını da kapsıyordu
- Teknik arızalar ile organizasyonel iletişim birbirinden ayrı değildi; Charity Majors'ın dediği gibi üst seviyede tamamen sosyal ya da tamamen teknik problemler diye bir şey yoktu
Liderlik, uzaktan çalışma kültürü ve değer çatışması
- Chris, kendi ekibinin ve yaklaşımının başka bir ekibin önerisi karşısında geri planda kaldığını düşündü
- Diğer ekibin planı masaüstü ve mobil uygulamaların tümünü yeniden düşünme yönünde büyüdü ve LinkedIn'in ürün geliştirme biçimini genel olarak yeniden ele alma karakteri kazandı
- Chris bu öneriyi daha iyi hale getirmek istedi, ancak kaygılarının ve sorularının yeterince dikkate alınmadığını hissetti
- Bir yöneticinin kendisine “fazla idealistsin, kârlılık ve maliyete yeterince dikkat etmiyorsun, değerlerini değiştirmen gerekiyor” dediğini aktardı
- Chris, uzaktan çalışmanın ilişki kurma üzerinde etkili olduğunu düşündü
- LinkedIn'de yüz yüze kültür güçlüydü ve birçok kişi ilişkileri kafeteryada ya da koridorda doğal biçimde kuruyordu
- Kıdemli mühendisler ve yöneticilerle tekrarlanan fiziksel temasın, çatışmalı durumlarda fark yaratabildiğini düşündü
- Chris, ilişki kurma konusunda kendisinin de zayıf kaldığı yönler olduğunu sonradan değerlendirdi
Sonunda neden ayrıldı
- Chris, mevcut kod tabanındaki birçok sorunun hızın abartılması ve yan yolların sorunlarını düzeltmemek ya da kaldırmamak yüzünden ortaya çıktığını düşündü
- Hız en üst değer haline geldiğinde başlangıçta hız kazanılabileceğini ama bunun zaman içinde sürdürülebilir olmadığını değerlendirdi
- Önceki işinde burnout yaşadığını; şiddetli migren, karın ağrısı, egzersiz yapamama, aniden ağlama ve panik atak geçirdiğini anlattı
- LinkedIn'de kalırsa her gün öfkelenmemeye çalışmak zorunda kalacağı bir durumda olacağını düşündü
- Bunu, devasa bir organizasyonun yönünü küçük bir kürek teknesiyle değiştirmeye çalışma durumuna benzetti ve inanmadığı bir iş yapma biçimine yıllarını vermemeye karar verdi
- Chris, LinkedIn'de 3 milyon satırlık bir uygulamayı, büyük şirkette TypeScript migration'ını ve büyük ölçekli mühendislik problemlerini öğrendi; ama kendi değerleriyle uyumlu bir iş bulmak için ayrıldı
1 yorum
Hacker News yorumları
Podcast’teki en ilginç noktanın, “fazla idealistsin, kâr-zarar tarafına yeterince dikkat etmiyorsun ve değerlerini değiştirmen gerekiyor” şeklindeki geri bildirim olduğunu düşünüyorum. Okumadan önce de böyle bir izlenim edinmiştim; yer yer değerli geri bildirimler aldığı ama bunları bilerek görmezden geldiği gibi geliyor
Bir senior staff engineer için zor olan şey “haklı olmak” değil, doğru çözüme doğru tüm organizasyonda hizalanma yaratabilmektir. 2019’da facebook.com’un React ile yeniden yazılması işinde yer aldığım için bu hikâye bana özellikle ilginç geldi
İletişimi bir ölçüde başardım ama LinkedIn’de bulunduğum süre boyunca bu hizalanmada pek başarılı olamadım. Bunun bir kısmı benim sorumluluğum, bir kısmı da LinkedIn’in sorumluluğu
Ancak bu durumda “fazla idealist” ifadesi gerçekten “kâr-zarara doğrudan katkı sağlamayan şeylerle ilgilenme” anlamına geliyordu; bunu iliklerime kadar reddediyorum. Kâr-zarar önemli, ama kullanıcı deneyimi, geliştirici deneyimi ve ne inşa ettiğimize dair temel etik de önemli
Bir organizasyonda, doğru olduğuna inandığın şeyi elinden geldiğince savunursun; sonra başka biri ya da bir karar grubu buna katılıp katılmayacağına karar verir. Sonucu kabullenip taviz mi vereceğim, yoksa ayrılacak mıyım, buna ben karar veririm; kariyerimde ikisini de yaptım
Tanınmış bir unicorn’da çok zeki, makul ve nazik bir senior staff engineer vardı. Yılda 50 milyon dolar ölçeğinde kullanılan bir framework’ü v2’den v3’e yükseltmeyi savunuyordu; Python 2’den 3’e geçişle kıyaslandığında çok küçük bir değişiklikti
Araştırma, temelde %10 performans iyileştirmesi beklenebileceğini göstermesine rağmen yönetim “sürüm yükseltmeye zaman harcamak” istemiyordu. Sonunda o mühendis tek başına bastırdı; bir aydan kısa sürede önizleme sürümünü hazırladı ve iki ay içinde büyük etki yaratan işlerin bir kısmını taşıyarak kendi maaşının birkaç katını tasarruf ettirdi
İlk politik ve mühendislik maliyetleri ödendikten sonra herkes taşınmak istedi; 1 yıl sonra dağıtım tamamlandığında yukarıdaki yönetim yapısının yaklaşık yarısı işten çıkarılma ve istifalarla dağılmıştı, ama o mühendis ve migration yerinde duruyordu. Bazen staff engineer inatçılık etmiyor olabilir; çılgın bir dünyada aklı başında kalan tek kişi olabilir
Böyle bir yerde bulundum ve katılmamayı seçebildim; ancak bunu her zaman yapmak mümkün değil
En iyi fikir ya da plana sahip olmadan da doğru bağlantılar, doğru öğle yemeği masası ve doğru sözlerle yönetimi ikna edenleri gördüm
“Sen fazla idealistsin ve kâr-zarara yeterince dikkat etmiyorsun” sözü de birini kenara itmek için kullanılan bir etiket olabilir. Özellikle de kendini ve fikirlerini üst yönetime bu şekilde pazarlamış biri söz konusuysa
Kişisel olarak Facebook’tan daha küçük olsa da yüzlerce mühendisi ve büyük bir kod tabanı olan bir organizasyonda Ruby, Rails ve Postgres ile ilgili birçok büyük ölçekli değişiklik ve yükseltme yaptım; Chris’in anlattığı metodoloji çok makul ve benim başarılı bulduğum yöntemlerle de örtüşüyor
Liderlik rollerinin etkili olabilmesi için güven ve saygı gerektiğine katılıyorum. Elbette bu güvenin işe yaraması için gerçekten haklı olmak da gerekir. Yanlış yönde ilerleme, ilerleme değildir
LinkedIn kod tabanını bilmiyorum, onunla çalışmışlığım da yok; ama ürkütücü derecede benzer görünen kod tabanlarını ve organizasyonel/siyasi yapıları birkaç kez gördüm. Bu yüzden genelde finger gun yöntemini savunurum
Finger gun tarzı yeniden yazım da iyi uygulanabilir. Aynı işi yapan birden fazla istemci varsa, bunlardan biri başka bir platformun temeli yapılabilir; sıfırdan başlansa bile temiz, hızlı ve sade yapılabilir
Başarının kilit noktası, yeni sistemi hem alan uzmanı hem de teknik uzman olan küçük bir kıdemli ekipe emanet etmektir. Tartışmalı olabilir ama sıradan operasyonel bakım sorunları dahil tüm başarının buradan geldiğini düşünüyorum. Geri kalan her şey sadece hızı düşürür
Çoğu teknoloji yöneticisinin tekrarladığı büyük sorun şu: Bir sonraki büyük sistemi en az deneyimli kişilere emanet ediyorlar. Finger gun tarafıyla simetrik bir röportaj da duymak isterim
Bunlar daha önce işe yaradığını gördükleri, kanıtlanmış şeyler olduğu için doğal; ama her zaman en iyisi olmuyor. Üstelik kıdemli ekip projeyi başlatsa bile sonuna kadar kalması nadir; sonuçları ya da artçı etkileri üstlenmek zorunda değillerse karar vermek fazla kolay oluyor
Planda engellerle başa çıkmak için gerçekçi seçenekler olmalı; bu yalnızca teknik seçenekleri değil, işi yapacak kişilerin zamanını ve kapasitesini de kapsar. Örneğin birden fazla ekibin sunucu işletmesini öngören bir plan teknik olarak mümkün olsa bile, ekibin zamanı ya da kapasitesi yoksa gerçekçi bir seçenek değildir
Öte yandan tüm engellerden kaçan incelikli bir rota planlamak da kötü. Vardığınızda engeller yer değiştirmiş olabilir ve yolda henüz bilmediğiniz engeller bulunabilir. Yalnızca tek bir yol planladıysanız orada takılıp kalırsınız
Ancak şu an gördüğümüz şey, karmaşık mimari tartışmasını karikatürize eden bir podcast açıklaması; bu yüzden LinkedIn’de gerçekte hangi saman adam argümanına daha yakın olduğunu bilemeyiz
Yönetim kurulunun tüm mühendisliğe, bundan sonra hiçbir projede hiç kimsenin ayrıntılar konusunda talimat veremeyeceğini söylediğini anlatmıştı
Chris’in birkaç talihsiz seçim yapmış olduğu izlenimi var. 5 yıllık plan önermiş; olayı liderlikten çok suçlama eksenine taşımış; sorunu çözmekten çok sorun hakkında konuşmuş; ilişki kurma tarafı da eksik kalmış gibi görünüyor
Chris’e empati duyuyorum; bir yandan da bu ortamda nasıl sonuç alınacağını bilmiyormuş gibi görünüyor. Yine de sorun değil. Herkesin bürokratik düğümler içinde çalışmayı öğrenmesi gerekmiyor; startup’lar bu açıdan daha basit
Büyük şirketlerin zamanla keskinliğini kaybetmesinin ve bir yöneticinin toplantı odasında yanında kendisine açıkça konuşacak tek bir VP olmadan yıllık bazda %-10 kayıpla yüzleşmesinin bir nedeni var
Böyle bir durumda kalınca insan psikolojik olarak yön duygusunu kaybediyor. Ben haklı gibiyim ama gerçekten haklı mıyım? Etrafımdaki insanlar gerçekten bu kadar beceriksiz ve iş arkadaşlarından öğrenmeye ilgisiz mi?
Birkaç yıl sonra ayrılıp geriye bakınca, o insanların işten çıkarıldığını ya da ayrıldığını, organizasyonun hâlâ X’i yapamadığını ve sonradan katılan ekiplerin çevikliği ile yetkinliğinin gerçekten var olduğunu görüyorsunuz
Bir yandan bu kibir, siyasi beceriksizlik ve patolojik bir çalışma kültürüne uyum sağlayamama olabilir. Diğer yandan doğru tepki de bu olabilir
Organizasyon patolojik bir kültür evresinden geçiyorsa, yetenekli, dikkatli ve tutkulu insanların bu yüzden delirmesi normal olabilir. Buna delirmeyen kişiler üretkenlik ve büyümeyle ilgisiz olabilir; hatta daha kötüsü net zarar bile olabilir
Bu yüzden böyle ortamlar bir psikodramaya dönüşür. Durum gerçekten bu kadar kötü mü, yoksa ben mi aşırı tepki veriyorum?
Ama yöneticilerin “bizim istediğimiz migrasyon olsa bile ürün iterasyon hızını hiç yavaşlatmayın” dediği bir durumda götürebileceğimizi hissettiğimiz tek plan da buydu
Olayı suçlama eksenine taşıdı kısmıyla ne kastedildiğini pek anlamıyorum. Aksine tersini yapmaya çalıştık; bellek eşiğini düşüren kişiyi ya da YAML’a yanlış değeri yazan kişiyi suçlamadık. Sadece, kök nedeni bir sonraki kişinin elinde tekrar patlayana kadar bırakmayıp gerçekten çözelim diye ısrar ettim
Sorunu çözmek yerine sadece konuştu kısmını da pek anlamıyorum. Yayında başardığım işleri uzun uzun övmedim sadece; orada çözdüğüm sorunları gayet iyi çözdük
İlişki kurma eksikliği, bölümde de söylediğim gibi en zayıf tarafımdı. Mühendislerle ilişkilerim iyiydi, ama özellikle üst yönetimle siyasi güven inşa etme konusunda ciddi şekilde başarısız oldum
Yine de bunun sadece o ortamda sonuç almayı bilmememden kaynaklandığını düşünmüyorum. Başarılı olabilecek bir yol görüyordum, ama inanmadığım bir şekilde davranmamayı da seçtim. Saygı duyduğum mühendislerin çoğu, inandıkları şeyler için siyasi dansı yapar; inanmadıkları şeyler içinse yapmaz
Şu anda LinkedIn’de çalışıyorum. Chris’in rolü ve podcast’i Ember ile frontend web geliştirmeyi kapsıyor gibi; bahsettiği kod satırı sayısı ve build büyük olasılıkla LinkedIn’in monolitik ana web uygulaması voyager-web olabilir.
LinkedIn’de milyonlarca satır koda ve uzun build sürelerine sahip başka sistemler de var. Orta katman, çevrimdışı veri stack’i, metrik sistemleri ve KafkaKafkaKafka gibi şeyler.
Ne yazık ki 17 dakikalık build oldukça iyi sayılır. Geçici bir altyapı arızası olmadan 17 dakikaysa çok iyi.
Şirket genelinde test kavramı neredeyse yok, QA da yok. Mühendisler terfi dosyalarına koymak için yarım yamalak projeleri içeri itip bir sonrakine geçiyor.
Dahili araçları günlük olarak kullanırken çok fazla sorunu bizzat çözmek zorunda kalıyordum; işini yapmaya çalışan mühendislerin fiilen QA olduğu bir yapı vardı.
Bunun yerine build’leri hızlandırmaya ya da build altyapısını daha hızlı ve ucuz hâle getirmeye yönelmek gerek.
En azından benim bulunduğum ekipte kod kalitesine ciddi vurgu vardı ve kültür de sürekli daha iyiye gidiyordu. Ancak bir kez voyager üzerinde çalışmıştım; onu kâbus olarak hatırlıyorum.
Büyük ölçekli yeniden yazımlar, yönetilebilir kod tabanlarında bile risklidir; geride kalan artıklar da sanki sonuna kadar kaybolmaz. Yıllar sonra köşede kalmış bir ayarlar sayfasını yeniden yazarak kim puan toplamak ister?
Böyle girişimleri o kadar çok gördük ki kod tabanı yeniden yazımları için bir framework olması beklenirdi, ama yok. Otomatik kod düzeltme araçları tutarlılık ister, fakat bu tutarlılığı koruyan yerler nadirdir. Kod kalıpları zaman içinde o kadar çok evrilir ki ağaç halkalarına bakıyormuşsunuz gibi olur.
Temelde kodu kutulara koyuyor, kutuları yeniden düzenliyor ve bazı düzenlerin daha verimli olduğunu makul biçimde söylüyoruz. Peki neden daha iyi bir yöntem bulamadık? Otomasyon kod düzeyinde çalışıyor, ama kutu düzeyinde çalışmıyor.
Bu, Conway Yasasının işlediği bir örnek. Organizasyon değişmediği için aynı kod çorbasını yeniden üretme ihtimali yüksek.
Aynı gemide bulunmuş biri olarak, olumlu mühendislik inisiyatiflerinin çok üst düzey bir sponsor aracılığıyla yukarıdan aşağıya gelmesi gerekir. Organizasyonu aşağıdan yukarıya değiştiremezsiniz; kod tabanını yaratan şey eninde sonunda organizasyondur.
Conway Yasası değişmez, ama mutlaka resmî organizasyon şemasına dayanmak zorunda değildir. Doğru teknik liderlerle yetkin yöneticiler arasında geçici iletişim yapıları kurarak yönetilebilir.
Ancak arada teknik açıdan zayıf ya da kendi krallığını kurmaya çalışan birkaç yönetici bile varsa her şey kolayca bozulur; şirketin yaşam döngüsüne bağlı olarak Pournelle’in Bürokrasi Demir Yasası nedeniyle zaten umut kalmamış olabilir.
Örneğin tüm geliştiriciler berbat durumdaysa onlara popüler bir framework vermek gibi. Bu, insan sorunlarıyla uğraşmamak için bir bahanedir; çocukların kreşi yönetmesine izin vermek gibidir.
Mükemmellik istiyorsanız hesap sorarak, sahiplik ile ödül ve sorumluluk yükleyen kurallarla yüksek standartlar koymalısınız. Karmaşık değil, ama tepeden itibaren kararlılık ve çatışmadan korkmamak gerekir.
Ancak Microsoft gibi bir şirketin bir şey yaptıktan sonra onu berbat etmeyeceğine dair tüm umudunuzu kaybedebilirsiniz.
LinkedIn’de 12 yıl geçirdim. Üzücü biçimde eski mühendislik organizasyonundan çok uzak. Kevin Scott’ın mühendisliği yönettiği dönem kıyaslandığında gerçekten iyiydi.
Milyonlarca satır JavaScript denince, bu başlı başına şişkinliğin vücut bulmuş hâli
LinkedIn gibi bir şeyi yeniden uygulamayı, daha doğrusu “Facebookvari” özellikleri olmayan kendi kişi veritabanımı yapmayı düşünüyordum
Sorun, kişilerimin topluca oraya nasıl taşınacağını sağlamak. Şişkinlikten bağımsız olarak Microsoft LinkedIn’in temel sorunu, kişi bilgilerini dışa aktarmaya izin vermemesi; bir kişi platformu için bu olmazsa olmaz bir özellik
https://queue.acm.org/detail.cfm?id=2567673
Özet: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn, 2010’un başlarında Node’a geçti
Ancak bu başlıktaki tepkilere bakınca, o sayı acaba yanlış mıydı diye de düşünüyorum
LinkedIn’de denemedim ama herkese açık bir web sitesindeki konferans katılımcı listesini dışa aktarırken kullandığım kirli yöntem bu. Duruma göre değişebilir
Chris Krycho’nun suçu başkalarına atma oyununa girmeden kendi zorluklarını dürüstçe anlatma biçimi etkileyiciydi. CoRecursive, kodun arkasındaki karmaşık bağlamları ele aldığı için sevdiğim podcast’lerden biri
Neredeyse her zaman zor olan bir yumuşak liderlik rolü gibi geliyor. Bir şeyden “sorumlusunuz” ama organizasyonun geri kalanı üzerinde çok az yetkiniz var ya da hiç yok
Gerçek teknik liderlik varsa bile ortalıkta yoktur; ya da uzun süredir oradadır ve “sistem uzmanı” olsa bile artık gerçek sorunlarla temas hâlinde değildir. Yaşadım, bir daha istemem