GitLab'da çalışma deneyimi
(yorickpeterse.com)- Ekim 2015'te GitLab'ın 28. çalışanı olarak katılıp Aralık 2021'e kadar çalıştığım 6 yıl; tamamen uzaktan çalışma, hızlı büyüyen bir girişimin kaosu, performans·dağıtım·kurum kültürü sorunları ve tükenmişliğin iç içe geçtiği bir deneyimdi
- İlk dönem GitLab'da kullanıcıların en büyük şikayeti düşük performans ve sık kesintilerdi; ancak performans izleme altyapısı yetersizdi ve self-hosting müşterilerinin de kullanabileceği araçları birlikte geliştirmek gerekiyordu
- 2017~2018 döneminde Database ekibinde veritabanı yük dengeleyicisi geliştirdim; aynı dönemde production veritabanının silinmesi ve yedekleme hatalarının çakışması sonucu yaklaşık 6 saatlik veri kaybı ve yaklaşık 24 saatlik kurtarma süreci yaşandı
- 2019~2021 arasında Delivery ekibi, Community Edition ile Enterprise Edition'ın ayrı depo yapısını birleştirerek, commit sonrası GitLab.com dağıtımına kadar en kötü durumda 3 hafta süren akışı birkaç saat~bir gün seviyesine indirdi
- GitLab'dan çıkardığım dersler şunlardı: ölçeklenebilirlik bir kültür haline gelmeli, veri olmadan verilen “minimum viable” kararlar risklidir, SaaS ile self-hosting'i birlikte yürütmek gereksinim çatışmaları yaratır ve hızlı dağıtım ile role dayalı ücretlendirme önemlidir
GitLab'a katılmadan önce ve ilk rolüm
- GitLab'a katılmadan önce Amsterdam'da küçük bir startup'ta çalışıyordum; şirketin durumu o kadar zordu ki nakit yetersizliği nedeniyle ofisin bir bölümünü kiraya veriyordu
- Kişisel zamanımda Rubinius üzerinde çalışıyordum ve bunu production ortamında kullanılabilecek kadar kararlı hale getirmek istiyordum; bu yüzden ilgili bir iş yapabileceğim bir şirket aramaya başladım
- Ruby meetup'larında ve Rails Girls atölyelerinde Sytse ile tanıştıktan sonra GitLab'la ilgilenmeye başladım; 2015 yazında e-posta gönderdim ve Ekim 2015'te çalışan #28 olarak katıldım
- Sorumluluğum GitLab'ın performansını iyileştirmekti ve çalışma zamanımın %20'sini Rubinius'a ayırabiliyordum
- 6 yıl boyunca birçok ekipten geçtim, büyük ölçüde özerkliğe sahip oldum, 10 farklı yöneticiye rapor verdim ve GitLab'ın 30 kişiden yaklaşık 2000 kişiye büyüme sürecini deneyimledim
2015~2017: Uzaktan çalışma ve performans araçlarının kurulması
- Önceki işimdeki son çalışma günümün hemen ertesi günü GitLab'da işe başlayarak, haftada 5 gün ofis düzeninden haftada 5 gün uzaktan çalışma düzenine geçtim
- İlk dönem GitLab tamamen uzaktan bir şirketti ama sosyal yönü güçlüydü; Amsterdam ve Austin gibi yerlerde şirket buluşmaları ve etkinlikler sık yapılıyordu
- Bu dönemde GitLab ilk büyüme evresini yaşadı; yaklaşık 100 yeni çalışan alındı ve şirket büyüklüğü 30'lardan 130'lara çıkıp sonra 80'lere düştükten sonra yeniden büyüdü
- Aynı anda ciddi performans sorunları, neredeyse her hafta yaşanan kesintiler ve olgunlaşmamış yönetim gibi hızlı büyüyen startup sorunları da vardı
- “GitLab is slow” kullanıcıların en büyük şikayetiydi
- Hacker News'ta da GitLab'ın yavaşlığına dair şikayetler sıkça çıkıyordu
- Performans iyileştirmesi, araç eksikliği nedeniyle daha da zordu
- O dönemde performans izleme için yalnızca bir New Relic trial hesabı vardı ve toplam 15~20 sunucunun sadece 1~2 tanesi izlenebiliyordu
- Gelen veriler toplam durumu doğru biçimde temsil etmiyordu
- GitLab, kullandığı araçların self-hosting müşterilerine de sunulmasını ve mümkünse açık kaynak olmasını istiyordu
- Performansı iyileştirmek için önce araçları geliştirmek gerekiyordu; bunun sonucu olarak resmi özellik olan GitLab Performance Monitoring ortaya çıktı
- Geliştirme ortamı için ağır bir profiler olan Sherlock da bu dönemde geliştirildi
- GitLab, performans sorunlarını tek bir kişinin çözemeyeceğini fark etti; Performance ekibini kurdu, özel bir yönetici atadı ve küçük bir işe alım bütçesi verdi
- Rubinius'u GitLab'da çalışır hale getirmeye çalıştım ama başarılı olamadım; bakım yönü ve Ruby topluluğundaki tartışmalar da eklenince sonunda bu işi bıraktım
2017~2018: Database ekibi, yük dengeleyici, production veritabanı kazası
- İlk bir buçuk yılın kaosundan sonra performans büyük ölçüde iyileşti ve GitLab da performansı daha ciddiye almaya başladı
- Performance ekibinin kapsamı genel performans iyileştirmesinden veritabanı performansına kayınca ekip Database ekibine dönüştü
- İşe alım bütçesi de arttı ve yeni veritabanı yapılandırmaları gibi konularda yardımcı olacak bir altyapı mühendisi atandı
- Bu dönemde geliştirilen temel özellik GitLab database load balancer oldu
- İlgili sunum Scaling the GitLab database ile paylaşıldı
- Geliştiriciler her zamanki gibi DB sorguları yazıyor, yük dengeleyici ise bunları primary veya replica'ya yönlendiriyordu
- Yazma işleminden sonra, değişiklikler tüm replica'lara yansıyıncaya kadar primary'nin kullanılmasını sağlayan sticking uygulanıyordu
- Bunun performans üzerinde çok olumlu etkisi oldu ve şeffaf biçimde devreye alınmış olması benim için en gurur verici yanı olarak kaldı
- 31 Ocak 2017'de GitLab.com production veritabanının yanlışlıkla silindiği bir olay yaşandı
- Olay ayrıntıları GitLab.com database incident ile paylaşıldı
- Yedekleme sistemi uzun süredir düzgün çalışmıyordu ve yedekleme hatalarını bildirmesi gereken sistem de işlemiyordu
- Yaklaşık 6 saat önce production verisinin staging ortamına kopyalanmış olması sayesinde kurtarma mümkün oldu
- Kurtarma yaklaşık 24 saat sürdü ve yaklaşık 6 saatlik veri kaybı yaşandı
- Aynı dönemde GitLab veritabanı sharding'ini hâlâ istiyordu, ancak o zamanki veriler ve mühendislerin değerlendirmesine göre bu sorun için uygun bir çözüm değildi
- GitLab'da okuma istekleri yazma isteklerinden yaklaşık 10:1 oranında fazlaydı
- Saklanan veri miktarı da sharding'in karmaşıklığını haklı çıkaracak kadar büyük değildi
- Bir danışman da çok daha büyük yük ve depolama ölçeğine sahip müşteriler için bile sharding'in fazla olacağını söylemişti
2019~2021: Delivery ekibi ve dağıtım süresinin iyileştirilmesi
- 2018~2019 civarında performans ve güvenilirlik işlerinden yorulup yeni kurulan Delivery ekibine geçtim
- Delivery ekibinin hedefi GitLab'ın release sürecini ve araçlarını iyileştirmekti; o zamanki durum ise kaotikti
- Bir commit main branch'e girdikten sonra GitLab.com'a dağıtılması ortalama birkaç gün sürüyordu; en kötü durumda bu süre 3 haftaya kadar çıkıyordu
- En büyük darboğaz, GitLab Community Edition ile GitLab Enterprise Edition'ın ayrı Git depoları olarak tutulmasıydı
- Düzenli olarak manuel merge ve conflict resolution gerekiyordu
- Bu sorunu çözmek için iki projeyi birleştiren, aylar süren bir çalışma yapıldı
- İlgili çalışma Merging CE and EE codebases ile paylaşıldı
- Delivery ekibi release sürecini büyük ölçüde iyileştirerek değişikliklerin birkaç saat içinde dağıtılabildiği bir seviyeye getirdi
- En kötü durumda 3 haftadan, en kötü durumda yaklaşık 1 güne inmesi büyük bir iyileşmeydi
- Yine de bu hız ideal anlamda yeterince hızlı değildi
Kurum kültüründeki değişim ve ayrılışa giden süreç
- 2018, çalışan merkezli GitLab summit'in son yılıydı; 2019 sonrasında format, müşterilere yönelik daha geleneksel bir konferansa dönüştü
- 2000'den fazla kişinin katıldığı buluşmaların maliyeti çok yüksek olduğundan bu değişim finansal açıdan anlaşılırdı; ancak sosyal deneyim açısından önceki kadar eğlenceli değildi
- Dizüstü bilgisayar yönetimi sorunu da tekrar eden bir gerilim kaynağıydı
- GitLab, şirket Mac'i veya kişisel donanımıyla GitLab kaynaklarına erişen çalışanlardan uzaktan yönetim yazılımı kurmasını istiyor ya da bunu değerlendiriyordu
- Önerilen araçlar, kullanıcı etkinliğini kaydetmek gibi amaçlarla kullanılabilecek kadar müdahaleciydi ve kötüye kullanımı önleyecek güvencelerin yetersiz olduğunu düşünüyordum
- Çalışanların çok sayıdaki geri bildirimi, kilit çalışanlar baskı yapana kadar bazen görmezden geliniyordu
- GitLab sonunda SentinelOne tabanlı bir dizüstü bilgisayar yönetim çözümü seçti
- Kültürel değişimlerle kişisel değişimler üst üste gelince motivasyonum ve üretkenliğim azaldı, stresim arttı
- Hakkımda iyi değerlendirmeler yapan yöneticim başka bir role geçip ekibin başına yeni bir yönetici gelince çatışma yaşandı ve performance enablement plan uygulandı
- PEP, PIP'ten önce gelen; ilişkiyi ve işi yeniden rayına oturtmayı amaçlayan bir süreçti
- Başta bunun iki tarafın da iyileşmesine yönelik bir süreç olduğu söylenmişti, ancak pratikte yalnızca benden beklenen değişimlere odaklandığını hissettim
- Başlangıçta bir ay sürmesi planlanmıştı ama bir ay uzatıldı; iki ayın sonunda sonuç tatmin edici bulundu
- Bundan sonra GitLab ile benim farklı yönlere gittiğimizi düşünmeye başladım ve ayrılmayı değerlendirdim
- GitLab'ın halka arzı ve stock option kullanım zamanı nedeniyle Aralık 2021'de ayrılabildim
- O dönemde Hollanda'da, stock option kullanılırken kullanım fiyatı ile değerleme arasındaki fark üzerinden, likidite olup olmamasına bakılmaksızın %52 gelir vergisi ödenmesi gerekiyordu
- Vergi yükü çok yüksek olduğu için GitLab halka arz olmadan önce bunları kullanmak zordu
- Sonrasında yasa değişti ve verginin kullanım anında mı yoksa hisselerin likit hale geldiği anda mı ödeneceği seçilebilir hale geldi
- Aralık 2021'de GitLab'dan ayrıldım ve Inko'ya tam zamanlı odaklanmaya başladım
GitLab deneyiminden çıkardığım dersler
-
Ölçeklenebilirlik şirket kültürünün parçası olmalı
- GitLab ölçeklenebilirliğe yeterince öncelik vermedi ve ayrıldığım sırada da bu sorunun sürdüğünü düşünüyordum
- GitLab'ın ana geliri GitLab.com'dan değil, GitLab Enterprise Edition'ı self-hosting olarak kullanan müşterilerden geliyordu
- GitLab.com, kazandırdığından çok daha fazlasına mal oluyordu; bu yüzden odak self-hosting pazarına kayıyordu
- GitLab.com'daki birçok performans sorunu, çok sayıdaki self-hosting müşterisine doğrudan uygulanmıyordu
- Birçok geliştirici performansı iyileştirmek istiyordu ama buna ayıracak zaman ve kaynak verilmiyordu
-
Ekipler veri ve geliştirici odaklı hareket etmeli
- GitLab'da ürün yöneticisi odaklı bir yapı baskındı; hangi özelliklerin geliştirileceğine çoğunlukla product manager ve director karar veriyordu
- Bazı kararlar mantıklıydı, ancak bazıları sanki Hacker News'ta iyi fikir gibi görülen şeyleri üretmek gerekiyormuş gibi hissettiriyordu
- Daha basit bir hiyerarşi daha erken benimsenip team lead'lere daha fazla yetki verilse ve kullanıcılarla daha çok etkileşim kurulsa daha iyi sonuçlar elde edilebilirdi
- Bana göre product manager rolü, teknik olarak ürünün yapılmasına katkı sunarken ekip ile kullanıcılar arasında köprü kuran bir rol olmalı
-
Veri olmadan “minimal viable”ı değerlendirmek zor
- GitLab'ın temel ilkelerinden biri, her zaman minimal viable change ile başlamaktı
- Sorun şuydu: herkesin “minimal” tanımı farklıydı
- Bazı ekipler performansı ya da iyi kullanılabilirliği viable olmanın şartı sayarken, bazı ekipler bunlara önem vermiyordu
- Sonuç olarak kullanıcılar için faydalı olmayan özelliklerin geliştirildiğini düşünüyorum
- Talep edilmemiş ve sonunda kapatılmış bir serverless platform
- 3 hafta boyunca çalışmadığı halde kimsenin fark etmediği Kubernetes cluster yönetim desteği
- Mevcut bir çözüm yerine CI üstüne inşa edilmiş bir chatops çözümü
- Yalnızca oluşturma ve görüntüleme destekleyen, düzenleme ya da silme yapamayan requirements management özelliği
- GitLab üç ayda bir user survey yapıyordu ve bazı ekipler kullanıcı etkileşim verilerine erişebiliyordu; ancak hatırladığım kadarıyla ve eski iş arkadaşlarımla konuşmalarıma göre bu veriler ekip iş akışının merkezinde olmaktan çok ara sıra kullanılıyordu
-
SaaS ile self-hosting'i birlikte yürütmek zor
- GitLab hem self-hosting kurulumlar hem de SaaS sunuyordu
- Bu iki modelin gelir yapısı, gereksinimleri ve güncelleme uygulama biçimi farklıdır
- SaaS, hızlı dağıtım ile merkezi altyapıda büyük ölçekli veri ve iş yükü işlemeyi gerektirir
- Self-hosting instance'larının çoğu SaaS'ten çok daha küçüktür; bu yüzden SaaS sorunları ve çözümleri doğrudan aynı şekilde uygulanmaz
- Sonuç olarak platformun birçok bölümünde SaaS için ve self-hosting için iki ayrı kod yolu düşünmek gerekir
- Yalnızca SaaS'e ya da yalnızca self-hosting'e odaklanmak, tüm dikkati o işletim modeline uygun deneyime vermeyi sağlar
-
Daha çok insan, daha iyi sonuç anlamına gelmez
- GitLab yıllar içinde çok sayıda kişiyi işe aldı ve bugün 2000'den fazla çalışanı var
- Geliştirici sayısını tam bilmiyorum ama ekip sayfalarına bakınca en az birkaç yüz kişi olduğunu tahmin ediyorum
- Bir projeye daha fazla insan eklemek, üretkenlik ve sonucu mutlaka iyileştirmez; bu durum “The Mythical Man-Month” ile de ilişkilidir
- Elimde veri yok ama çoğu şirket için 20'den az geliştirici yeterlidir; bazıları için 20~50, çok azı içinse 50~100 gerekir diye düşünüyorum
- Geliştirici sayısı 100'ü aşıyorsa ürün kapsamının gereğinden fazla büyüyüp büyümediğini düşünmek gerekir
- Bu değerlendirme yazılım geliştiricileri içindir; özel donanım üretimi, sales, support gibi senkronizasyon maliyetinin farklı olduğu alanlar bunun dışındadır
-
Ruby on Rails hakkındaki değerlendirmem iki yönlü
- GitLab Ruby ve Ruby on Rails ile geliştirildi; bu kombinasyon GitLab'ın başarısına büyük katkı sağladı
- Ancak proje büyüyüp farklı deneyim seviyelerindeki katkıcıların sayısı arttıkça Rails, kötü performanslı kod yazmayı kolaylaştırabiliyor
- En tipik sorun N+1 query problem'dir
- Rails'in ActiveRecord'unda bunu çözmeye yardımcı özellikler var ama bunlar opt-in çalışıyor
- Geliştirici bunu unutursa satır bazında sorgular oluşur ve performans sorunları çıkar
- GitLab'ın ilk yıllarında çözülen performans sorunlarının büyük bölümü N+1 query kaynaklıydı
- Ruby'nin kendisi de harika bir dildi, ancak yoğun meta programming kullanımı büyük projelerde zorlayıcı olabiliyor
- Go, Rust, Node.js Ruby'den daha verimli olabilir, ancak Ruby on Rails kadar güçlü bir framework'e sahip olduklarını düşünmüyorum
- Python ve Django da seçenek olabilir, ancak Ruby ve Rails'teki bazı sorunların benzerlerini yaşatmaları muhtemeldir
-
Dağıtım süresi bir organizasyonun başarısı için kritiktir
- Koda, dağıtım yapılacak branch'e ya da tag'e push edildikten sonra en geç bir saat içinde production'a çıkabilme imkanı olmalıdır diye düşünüyorum
- GitLab'ın buna yaklaşması yaklaşık 4 yıl sürdü ve yine de gidilecek yol vardı
- Hızlı dağıtım, kesintilere müdahalede yardımcı olur
- Dağıtım saatler sürüyorsa hot-patch gerekebilir
- Hızlı dağıtım motivasyonu da etkiler
- Yapılan değişikliği gerçekten görmek ve kullanmak tatmin edicidir
- Haftalarca üzerinde çalışılan bir değişikliğin ancak 2 hafta sonra dağıtılması motivasyonu düşürür
- Organizasyonlar dağıtım süresini ve dağıtım sürecinde test suite'in aldığı zamanı azaltma konusunda çok agresif olmalıdır
- Esas nokta, tüm testlerin ve dağıtımların belirli bir sürenin altında olması değil; iş gereksinimlerinin izin verdiği ölçüde mümkün olan en hızlı dağıtımı öncelik haline getirmektir
-
Konuma dayalı maaş ayrımcıdır
- GitLab maaşları birçok değişkenden etkileniyordu ve bunlardan biri konumdu
- Fiziksel ofisi olan ve belirli bölgelerde işe alım yapması gereken şirketler için konuma dayalı düzeltme anlaşılabilir olabilir; ancak tamamen uzaktan çalışan bir şirkette, aynı deneyim ve sorumluluğa sahip iki kişiye yalnızca yaşadıkları yere göre farklı ücret vermek için haklı bir neden olmadığını düşünüyorum
- Ayrıldığım sırada Hollanda'da aldığım maaş vergi öncesi yıllık yaklaşık €120,000, aylık yaklaşık €8,500 idi
- Bay Area'da yaşasaydım en az iki katı, belki daha fazlasını almış olacağımı düşünüyorum
- Çözüm, adayın konumuna değil rolün gereksinimlerine göre ücretlendirme yapmaktır
- 0xide Computer Company, konuma göre değil herkese aynı tutarı ödeyen bir şirket olarak anılıyor
- İlgili tartışma Compensation as a Reflection of Values yazısında ele alınıyor
Sonuç
- GitLab'da geçirdiğim zaman, son derece olumlu ve olumsuz deneyimlerin karışımıydı
- Farklı ekiplerde elde ettiğimiz sonuçlarla ve birlikte çalıştığım insanlarla büyük gurur duyuyorum
- Son yaklaşık bir yılın tüm deneyime buruk bir tat bırakmış olması üzücü
- GitLab'da çalışmış olmaktan pişman değilim; yeniden yapma şansım olsa, geriye dönük bilgilerle bazı şeyleri biraz farklı yapardım
- Kusurları olsa da GitLab'ın birçok başka şirkete göre çok daha iyi olduğunu düşünüyorum ve hâlâ çalışılabilecek bir şirket olarak tavsiye ediyorum
1 yorum
Hacker News yorumları
Bir şirketin ücreti ten rengine veya cinsiyete göre düşürmesi büyük bir sorun olurken, bunu ikamet yerine göre yapmasının neden kabul edilebilir olduğu yönündeki karşılaştırma üzerinde daha fazla düşünmek gerekiyor.
Ten rengi·cinsiyet ile ikamet yeri, değiştirilebilir olup olmamaları ve işle gerçekten ilgili olup olmamaları bakımından farklıdır.
İkamet yeri, şirketin yerel tüzel kişilik kurma, hukuk ve vergi sistemlerini anlama, saat dilimi, seyahat masrafları gibi yükleri üstlenmesini gerektirdiği için işle ilgilidir.
Bölgeye göre ücretlendirmenin doğru olup olmadığı tartışılabilir; ancak bunu ırkçılık ve cinsiyet ayrımcılığıyla karşılaştırmak, GitLab’ı ırkçı ve cinsiyetçi bir örgüt gibi göstermeye varır ve tartışmayı hızla bitirir.
Bay Area’da yaşasaydı iki kattan fazla alacakken, sırf ikamet yeri farklı diye bunun adaletsiz olduğunu söylüyor; ama burada mağduriyet puanı kazanacak bir durum görünmüyor.
Ekonomiyi pek iyi anlamayan bir argümana daha yakın.
Şu anda ABD’de aldığım maaş, Birleşik Krallık’taki dönemimin yaklaşık iki katı; ama yaşam standardım benzer, bazı açılardan daha kötü, bazı açılardan daha iyi.
Orijinal yazının yazarı Bay Area’ya gitseydi, ücret daha yüksek olsa bile yaşam standardının aksine düşmüş olması kuvvetle muhtemeldi.
Yalnızca geliri değil, sosyal güvenceyi, vergileri ve kültürü de hesaba katmak gerekiyor; daha rahat yaşamak için Avrupa’ya geri dönerken büyük bir maaş kesintisini göze almayı da düşünebilirim.
GitLab’in bölgesel ücretlendirme motivasyonu https://handbook.gitlab.com/handbook/total-rewards/compensat... adresinde yer alıyor ve oldukça makul görünüyor.
Filipinler’e ya da Ukrayna’ya bile Bay Area maaşı verirseniz insanlar altın kelepçelere bağlanır; ayrılmaları gerektiğinde bile ayrılamayıp tükenmişlik yaşayabilirler.
Tersine, dünya medyanına göre maaş verirseniz Kaliforniya’da ya da Londra’da insan işe alamazsınız.
Ürün yöneticilerine gerek olmadığı ve tek bir üründe 100’den fazla geliştirici olmaması gerektiği iddiası da tartışmalı.
Orijinal yazının yazarı, yüksek özerkliğe sahip çok iyi bir mühendis gibi görünüyor; nispeten küçük bir startup’ta çok daha mutlu ve başarılı olabilecek biri.
Vergi düzenlemesi değişikliğini beklemek zorunda kalmasaydı daha erken ayrılıp iyi bir deneyim yazısı yazmış da olabilirdi.
Hisseye ek olarak Amsterdam’da $300k ücret de alsaydı, şirketten ayrılmanın ne kadar zor olacağını düşünmekte fayda var.
Dünya genelinde aynı ücreti zorunlu kılarsanız, şirketler offsite, aynı saat dilimi ve iletişim avantajları nedeniyle muhtemelen sadece yerelden işe alım yapmak ister.
Özellikle yüksek yaşam maliyetli bölgelerde de çalışmak isteyen adayların çok olduğu ekonomik koşullarda bu daha da geçerlidir.
Gelecekte değişebilir; ama gerçekçi teşvik yapısını görmek faydalı.
Başka ülkelerde işe alım yapan şirketlerin üstlendiği riskler de vardır; bunun yerelde bilgi ve gelecekteki şirketlerin tohumlarını bırakma etkisi de olur.
Ofise gitmek, o bölgenin yaşam maliyeti sayesinde çalışana ücret pazarlığında güç verir; ancak tamamen uzaktan çalışan bir şirket ve kültürde şirket her yerden işe alım yapabilir ve en düşük ortak paydaya yakın bir ücret verebilir.
Uzaktan çalışma herkesi dünya çapındaki yeteneklerle rekabet eden bağımsız yükleniciler gibi yapar; ofis çalışması ise sizi ağırlıklı olarak aynı bölgedeki insanlarla rekabet ettirir.
Oldukça standart bir akış ve büyük şirketlerde insanların büyük işleri iyi yapamamasının nedenlerinden biri olabilir
Şirket içinde bir proje başlatıp başarıya ulaştırsanız bile şirket üstünüze insanlar yerleştirir; sonunda kendi başlattığınız projede n'inci çalışan konumuna düşüp performans yetersizliğiyle suçlanabilirsiniz
Yalnızca eğlenceli ve ilginç işler yapmak ister, sonunda önemli olmayan konularda güçlü fikirler öne sürer; CEO'yla yakın olan bir bireysel katkı sağlayıcı yöneticinin tercihlerini kabul etmezse yönetmesi kâbusa döner
Kararların sorumluluğunu üstlenmeden oradan oraya hareket edip sorun çıkarabilir
Endpoint güvenliği ve kişisel cihaz kullanımı ipuçlarından biri
Bu tür izin verici kültür, uyumluluk ve geliştirme verimliliği maliyetleri nedeniyle ölçeklenmez
Tercih ettiği Linux dağıtımında ısrar eden eski usul bir geliştiriciyi bundan vazgeçirmek zordur; ama iş için iş bilgisayarı kullanmak ve güncellemeleri şirketin yönetmesine izin vermek daha doğrudur
Veritabanı yedekleri hikâyesi de aynı şekilde: veritabanı ekibiyseniz yedekler bir numaralı iştir
“Yedek yoktu” ifadesi edilgen çatıyla geçiştirilemez; gündelik olarak siteyi ayakta tutmaktansa sharding mimarisi tartışmalarıyla daha çok ilgileniyormuş gibi görünüyor
GitLab'ın barındırılan ürün performansına yeterince yatırım yapmadığı sonucu da, o ürün büyük zarar ediyorsa daha fazla kaynak koymamak doğal olabilir
Bunun eğlenceli mühendislik değil, gerçek iş gerekçeleriyle neden daha önemli olduğunu ve para kazandırdığını ikna edici şekilde anlatmak gerekir
Bir yöneticiyle birlikte başarılı bir proje başlattık, ancak yönetim açgözlü biçimde siyaseti ve sosyal ikilemleri işin içine çekip yönetim katmanları ekleyerek beni ve o yöneticiyi değiştirmeye çalışıyor
İşi gerçekten önemsememek gerektiğini öğrendim; bu yüzden proje bozulup dağıtılacakmış gibi hissediyorum
Burada o çalışanın gerçekten yüksek performanslı olduğu, yöneticiye gerek olmadığı ve PEP almayı hak etmediği varsayılıyormuş gibi bir hava var; ama bu güvenli bir varsayım değil
Erken aşama startup'larda şirket ve rol büyürken bu hıza ayak uyduramayan ya da uydurmak istemeyen ilk çalışanlar gördüm
Geçmiş katkılara duyulan saygı, yerine konması zor tarihsel bilgi, kurucularla ve lider olmuş ilk çalışanlarla ilişkiler nedeniyle bu kişilerin şirkette tutulması yaygındır
Ancak ilk çalışan olmak ve kritik erken projelerde yer almak, o işi sürdürmek için hâlâ en iyi ya da uygun kişi olduğunuz anlamına gelmez
Geçici çözümler, cron işleri ve manuel müdahalelerle bir şeyleri döndürmekte çok iyi olsanız bile, büyük bir şirkette bu operasyon biçimi hiç uygun olmayabilir
Uyum sağlayamazsanız ya da büyük şirket usulü çalışmak zorunda olmaktan rahatsız olursanız faydanızdan çok zararınız olur
Her erken aşama şirkette şirketle birlikte büyüyemeyen ilk çalışanlar olur; ama bu tek ya da en yaygın sonuç değildir
GitLab'da uzun süre çalışan çok kişi de var; ancak şikâyet dolu blog yazılarında onları duymadığımız için seçim yanlılığını dikkate almak gerekir
GitLab'ı uzun süredir kullanıyorum ve ürün gelişmeye devam ediyor; bu yüzden durgun bir ürün olduğu iddiasına katılmıyorum
Üç yıl sonra sürümlerin sürekli başarısız olduğunu gördüklerinde ancak sorun oldu; ama bunun benim etkilerimden çok birinin Google'da “sürüm başarısızlıkları nasıl önlenir” diye aramasının sonucu gibi geldi
Çözümünü bilmiyorum ve şimdi de başka bir konuda aynı şeyi yeniden yaşıyorum
Başta sadece yapılması gereken işi yapıyorduk; sonra her adım, yanlış şeyi yapmadığımızdan emin olmak gerekçesiyle yeni eklenmiş yönetici koltuklarından geçmek zorunda kaldı
Şirketin büyümesini sağlayan erken fikirler ve katkılarla ilgisi olmadan böyle oldu
GitLab CI ile ilgili yıllardır bekleyen sorunların arka planında bunun da olup olmadığını merak ediyorum
Dışarıdan bakınca GitLab harika şeyler üretme yeteneğini tamamen kaybetmiş gibi görünüyor; yıllardır var olan hatalar sürekli tekrarlansa bile düzeltmeye niyetli değilmiş izlenimi veriyor
Çalışanların kişisel bilgisayar kullanmasına izin verilmiş olması neredeyse şaşırtıcı.
Kuruluş ne kadar küçük olursa olsun şirkete ait ekipman sağlamalı ve tüm şirket işleri o ekipmanda yapılmalı.
Bu, şirket için fikri mülkiyet kontrolü açısından büyük avantaj sağlar; çalışan için de iş saatleriyle kişisel zamanı ayırmaya çok yardımcı olur, maliyeti de o kadar büyük değildir.
Nereye giderseniz gidin istediğiniz araç setini aynen kullanabilirsiniz; hızlıca silip yeniden oluşturabilmek de “benim bilgisayarımda çalışıyor/çalışmıyor” türü sorunları ayıklamak için iyidir.
Yelpazenin bir ucunda hafızaya dayanan yöntem var; diğer ucunda ise https://nixos.org/ ile her yerde tamamen yeniden üretilebilir build’ler oluşturma yöntemi var.
Arada da birçok seçenek var;
host: localhostile gerekenleri kuran bir Ansible dosyaları kümesini yöneten insanlar da gördüm.Ben en güncel Ubuntu sürümünü kullanıyor ve temiz kurulumda istediklerimin %80’ini kuran birkaç shell script [1] tutuyorum.
Bilimsel yaklaşmak isterseniz https://atuin.sh/ gibi bir şey kurup uzun vadeli shell geçmişinize göre gerçekte sık çalıştırdığınız programların istatistiğini çıkarabilirsiniz.
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
Kusursuz bir çözüm değil ama en azından şirket ekipmanı söz konusuysa, sızıntı ya kötü niyetli bir eylem ya da hassas veriyi onaylanmamış bir yoldan taşıyan bir beceriksizliğin sonucu olur.
Şirket dava edilirse kişisel cihazın içeriği bile her türlü celp kapsamına girebilir.
Ayrı cihaz istemenin kullanıcıya iş-yaşam dengesi açısından bir faydası yoktur; sadece zahmettir.
İş ve kişisel zamanı ayırma davranışı çoğunlukla kişinin kendi alışkanlıkları, becerileri ve nihayetinde kararları tarafından belirlenir.
Eskiden bölgeye göre maaşı ayrımcılık gibi hissederdim, ama artık büyük ölçüde bu düşünceden çıktım.
Sonuçta istenen şey SF maaşı oluyor; Hindistan’dakiler de Hollanda veya SF maaşı istemeye başlıyor.
Böyle olunca dibe doğru bir yarışın ortaya çıkması çok olası.
Basit gerçek şu: herkes kendi bölgesinde iyi yaşayacak kadar kazanıyordu.
Daha fazlasını istiyorsa taşınabilir; taşınmıyorsa bunun bir nedeni vardır.
Herkes SF maaşı ve Indiana ya da Hindistan yaşam maliyeti istiyor, ama bariz nedenlerle bunun yürümesi zor.
İşe alınırsanız San Francisco’da da olsanız, Polonya veya Endonezya’da da olsanız ABD düzeyinde maaş alırsınız.
Bu tür pozisyonlar son derece rekabetçidir.
Tüm dünyaya kapıyı açıp “elinizdekini gösterin” demiş oluyorsunuz; böylece çok daha büyük bir aday ve yetenek havuzuna bakabiliyorsunuz ve bunun içinde yoksul ülkelerden gelen çok zeki, güçlü motivasyona sahip istisnai yetenekler çoktur.
Arz ve talep böyle işler.
Daha fazla ödeyeceğinizi söylerseniz genellikle daha üst düzey adayları işe alırsınız.
ABD’nin çeşitli eyaletlerinde uzaktan çalışıp SF düzeyinde maaş alan epey insan tanıyorum.
Elbette bu mümkün.
SF de fazla kendini beğenmemeli.
Detroit de bir zamanlar Motor City ve Music City idi; dünya çapında bir kültür ve teknoloji merkeziydi, ama temel yetkinlikleri daha ucuz ve verimli başka bölgelerdeki emek tarafından sarsıldı.
Talep edilen şey eşit işe eşit ücret.
Ekip üyeleri aynı işi yaparken başkaları tam ücret alıyor ve sadece siz bir kısmını alıyorsanız bu ciddi biçimde yanlış demektir.
Ekibe katkı, şu anda nerede bulunduğunuza bağlı değildir.
İşe gidip gelmeye ne kadar zaman harcadığınız da çıktı beklentisini değiştirmez.
Ofis konumu aşırı pahalıysa şirket sorunu daha ucuz bir konum bularak çözmeli; çalışanların şirketin kötü ofis konumunu sübvanse etmesi için bir neden yok.
Çalışanın aldığı 100k ile şirketin maliyeti farklıdır.
Ülkeden ülkeye şirketin ek olarak üstlendiği vergiler, sosyal güvenlik, yan haklar değişir; çoğu durumda yerel tüzel kişilik ya da sanal bir işletme yapısı ve yerel mevzuata uyum için destek kaynakları gerekir.
Ben de çok uluslu bir şirkette küresel bir rolde çalışıp yerel ölçütlere göre maaş alan çalışan tarafındayım, ama dışarıdan göründüğünden daha fazla dikkate alınacak şey var.
Temel olarak işe alım maliyetini değil yaşam maliyetini yansıtacak şekilde ayarlıyor, ama eşit ücreti hedefliyor.
Berbat yöneticiler sektörün baş belası.
Buna karşılık birçok startup, kurucularının önceki işlerinde berbat yöneticilerle karşılaşması yüzünden ortaya çıkıyor.
traitorous eight ve Fairchild Semiconductors hikâyesi aklıma geliyor.
Kişisel olarak, önceki işimde teknik olmayan, politik ve intikamcı bir yöneticiyle karşılaşmasaydım kendi startup’ımı kurma motivasyonum olmazdı sanırım.
Geriye dönüp bakınca, kariyerimin başlarında böyle kötü bir yöneticiyle daha erken karşılaşsaydım iyi olurdu diye de düşünüyorum.
Becerilerime gerçekten ihtiyaç duyan şirketleri bulup İK süreçlerinin yükü olmadan daha kolay geçiş yapabilmek de iyi olurdu.
Ruby’nin tüm programlama modelinin, zamanın çoğunun G/Ç veya ağ beklemesiyle geçtiği ve bu yüzden dil hızının önemli olmadığı varsayımına dayandığı iddia ediliyor.
Ancak günümüzde Node.js ve JVM tarafında, G/Ç ve ağı beklerken başka işler yapabilen ya da daha fazla isteği işleyebilen modeller var.
2024’te Ruby/Rails kullanmak israf olabilir; ama kullanıcı sayısı sınırlı kurumsal uygulamalar, geliştirme hızının mutlak öncelik olduğu durumlar ve pazar doğrulaması için hızlı prototipler açısından iyi bir seçenek olabilir.
Rails harika bir framework ve üretkenliği çok yüksek; ancak 2-3 yıllık bir Rails projesinin bakımı her zaman zordur.
Rails projeleri Django veya Express projelerinden daha zor değil.
Herhangi bir codebase’de yabani otların büyümemesini istiyorsanız disiplin ve düzenli bahçe bakımı gerekir.
Ruby ve Rails’in bir zayıflığı varsa, bu hâlâ ham dil performansı ile daha yüksek bellek gereksinimi ve kullanımıdır; düşük gecikme veya küçük bellek ayak izi gerektiren işler için daha az caziptir.
Deneyimlerime göre asıl can yakan durumlar, trafiğin aniden büyük dalgalanmalar göstermesi veya websocket kullanan çok fazla aktif kullanıcı olması; websocket tarafı da çoğunlukla anycable ile çözülüyor.
Ancak bu sınırlara ulaşacak ürün sayısı çok az ve ulaşılsa bile çözülebilir.
Stripe, GitHub ve Shopify, Rails’in çeşitli şekillerde sorunsuz ölçeklendiğinin başlıca örnekleri.
Rails’i taşıyan büyük itici güç DHH’nin geliştirici mutluluğu hakkındaki düşüncesiydi; bu da geliştirme hızıyla yakından bağlantılı.
Rails topluluğunda G/Ç tartışmalarının olmasının nedeni bunun web sunucusu işletmek için önemli olması; yoksa dil veya framework kararının tek ya da ana odağı olması değil.
Amaç web sunucusunun CPU kullanımını azamiye çıkarmaksa, Rails’te de birden fazla process çalıştırarak bu mümkündü ve bu yaklaşım JVM’de birden fazla thread çalıştırmaya benzer şekilde uzun zamandır kullanılıyordu.
Daha az konforlu olabilir, ama 90’lardan beri kullanılan bir model; web istekleri genelde bağımsız çalıştığından process’ler arası iletişim de çoğu durumda büyük sorun olmaz.
Bunu genelleyerek “israf” demek fazla sert.
Rust ile uygulama yazmak da duruma göre israf olabilir; mesele baskının nerede olduğuna bağlı.
Erken aşamada piyasaya çıkamamak çok daha büyük bir endişedir; orta ve geç aşamalarda bile geliştirici hızı ölçeklenmesi en zor unsurlardan biridir.
Rails backend ve React frontend kullanan bir şirketin CTO’su olarak geliştirme hızı çok önemli ve Rails’in geliştirme hızı büyük bir avantaj olmaya devam ediyor.
Ölçekleme sorunları da var, ama bunların %99’u Rails değil veritabanı sorunu.
Bir şirketin mühendislere konuma göre maaş vermek istemesini başka bir ayrımcılık türü olarak görüyorum.
Çalışana bulunduğu yere göre değil, yetkinliğine göre ödeme yapılmalı.
Devlet kuralları cinsiyet, din, cinsel yönelim vb. üzerinden ayrımcılık yapmayın diyor; peki konuma göre maaş ayrımcılığı adil mi?
Europe’tan Asia’ya aynı rolle taşınan arkadaşlarımın, aynı kişi ve aynı rol olmalarına rağmen sırf konumları değişti diye daha az aldıklarını gördüm.
Daha az rekabetçi bir pazara taşınıp başka iş bulması zorlaşırsa, daha düşük maaşa rağmen işe gelme olasılığı artar.
Uzaktan çalışıyor olmak yerel pazara bağlı değilmiş gibi görünse de, hükümetler uluslararası işe alımın önüne çoğu zaman büyük engeller koyar; bu yüzden bazı ülkeler daha az rekabetçi pazarlar hâline gelebilir.
Aynı şirkette aynı işi yaparken başka bir ülkeye taşınıp maaşı düştüyse, neredeyse kesin olarak o kesintiyi bu nedenle kabul etmiştir.
Bence şirketler, çalışanlara herhangi bir evrensel değer ölçeğine göre değil, rahat ve sağlıklı yaşayabilme imkânlarına göre ödeme yapmalı.
Böyle evrensel bir değerin mümkün olmadığını düşünüyorum.
Yalnızca yetkinliği esas alalım argümanı, istemeden de olsa topluluğu parçalar; eşitsizlik yoluyla soylulaştırmayı ve toplumsal bağların çözülmesini kötüleştirir.
Konum önemlidir.
Aynı yaşam kalitesini, aynı tür konutu, aile geçindirme imkânını ve çocukları benzer okullara gönderme fırsatını sağlamak için ödeme yapılır.
Bunların maliyeti ülkeden ülkeye değiştiği için gereken gelir de değişir.
Şirketin belirli bir yetkinliğe ihtiyacı vardır ve piyasa o yetkinliğe ne değer biçiyorsa o kadarını, fazlasını değil, öder.
Konuma göre piyasa aynı yetkinliğe farklı fiyat biçer; dolayısıyla maaş da değişir.
Din biraz muğlak bir istisna; ama adil olsun ya da olmasın, bu ayrımcılık değil.
GitLab.com’un her zaman kazandığından çok daha fazlasına mal olduğu ve şirketin parayı çoğunlukla self-hosted GitLab Enterprise Edition müşterilerinden kazandığı doğruysa, ölçeklenebilirliğe yeterince yatırım yapmamanın gerçekten hata olup olmadığını merak ediyorum.
Öncelikle şirket, para kaybetmekten ziyade para kazandıran şeylere yatırım yapmalı.
Daha performanslı bir gitlab.com’un daha fazla müşteri ve itibar getirebileceği yönünde üst düzey bir değerlendirme yapılabilir; ancak gerçek iş self-hosted yazılım satışıysa geliştirme kaynaklarını oraya odaklamak makuldür.
Gerçekten GitLab lisansı satın aldık; barındırmayı GitLab’a bıraksak da kendimiz yapsak da koltuk maliyetinin aynı olduğunu fark edince, altyapı maliyetini neden biz üstlenelim diye düşündüm.
GitLab.com’u yarım yamalak yapacaksanız ya düzgün yapın ya da ürünü kaldırıp uzun vadede yalnızca GitLab Enterprise Edition gibi self-hosting müşterilerine odaklanın; bu daha iyi olabilir.
Ama yönetimden kimse böyle bir karar almak istemez.
Bu yüzden ürün yarım yamalak işletilir.
Ürünün kendisini önemseyen insanlar için bu durum sinir bozucu olabilir.
Her yeni geliştirici geldiğinde “ölçeklenebilirliğe daha çok dikkat etmeliyiz” der, kıdemliler de “evet evet, biliyoruz…” der.
Ekonomik açıdan, Amsterdam’daki bir geliştirici Bay Area’daki bir geliştiriciyle aynı değeri sağlıyorsa aynı maaşı vermek büyük olasılıkla doğrudur.
Amsterdam’daki geliştiricinin yerel piyasa değeri daha düşük olsa da, küresel bir şirket kuruyorsunuz ve başka küresel şirketlerle rekabet ediyorsunuz.
Şu anda Amsterdam’daki geliştiriciyi indirimli fiyata alabiliyor olsanız bile, sonunda rakipler değere daha yakın bir tutar teklif edecek ya da onlar kendi işlerini yapmak için ayrılacak.
En güçlü şirketlerin yeteneklere konumdan bağımsız ücretlendirme ödeyeceğini düşünüyorum.
Sonuçta önemli olan sağlanan değerdir.
GitLab gibi büyük bir Ruby kod tabanını taşıyan ve performans ile kararlılığa önem veren büyük şirketlere satış yapmak istiyorsanız, böyle bir kişiye yılda €120k’dan daha fazlasını vereceğinizi düşünüyorum.
Performans, tip güvenliği ve kararlılığa önem veren mühendislerin çoğu Ruby ile ilgilenmediği için, bu teknoloji kombinasyonunun piyasa değeri kesinlikle daha yüksek.
Bay Area’daki yıllık $500k seviyesinde mi bilmiyorum, ama en iyi yetenekleri isteyen güçlü şirketler ücretlendirmeyi konuma değil sağlanan değere bağlamazsa yeteneklerini kaybedecek.
Kodun dağıtıma alınmasının ne kadar sürdüğü, bir startup ölçeklenirken geliştirici hızını korumak için en önemli metriklerden biri, hatta belki de en önemlisi diye düşünüyorum.
Bağlam değiştirme, geliştiricinin günlük işlerinde en pahalı işlemlerden biri olmasına rağmen en kolay göz ardı edilenlerden biridir.
Yöneticiler ekip takvimini kendi takvimlerine göre düzenlemeyi sever, ancak bu bireysel katkı sağlayıcıların “maker schedule”ını sık sık böler.
Birçok organizasyon bunu fark edip takvim tarafındaki bağlam değiştirme maliyetine odaklanıyor, ancak geliştiriciler için derlemeden dağıtıma kadar geçen süre de en az bunun kadar, hatta daha önemlidir.