‘Can’t be fucked’: Teknik borcun hafife alınan bir nedeni
(jesseduffield.com)- Geliştiricilik becerisi yalnızca bilgiyle belirlenmez; yapılması gerekeni bilirken bile motivasyon eksikliği yüzünden testleri, refactoring’i ve yeniden üretim örnekleri hazırlamayı ertelemek teknik borç biriktirir
- İyi geliştiriciler flaky testleri araştırıp düzeltir, buldukları hatalar için ticket açar ya da hemen düzeltir; yeni bir özellik mevcut kodla uyuşmuyorsa önce refactoring yapar
- “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” gibi özlü sözler gerçek kısıtlarla uğraşırken yararlıdır; ancak sadece canı istememeyi gizlemek için de kullanılabilir
- Lazygit’te aylar boyunca end-to-end test sistemi kurulup etkisi hissedildi, ancak Lazydocker’a aynı testler eklenmedi; minimum yeniden üretim deposu isteği ve God Struct refactoring’i de ertelendi
- Kusursuz kod yazacak enerji olmadığında bile eksikleri dürüstçe ortaya koymak, bakım standartlarını ve sonraki işlerin önceliğini değerlendirmeyi kolaylaştırır
Teknik borç yaratan motivasyon eksikliği
- “Can’t Be Fucked”, bir şeyi yapmak istememeyi ya da yapacak enerji ve motivasyona sahip olmamayı ifade eden Avustralya argosudur
- Çok fazla geliştirme bilgisi öğrenmenin insanı daha iyi bir programcı yapacağını düşünmüştüm; ancak gerçekte saygı duyulan geliştiriciler yalnızca bilgiye değil, sürekli bir özen ve çalışkanlığa da sahip olan kişiler
- İyi geliştiriciler, sorunları küçükken doğru şekilde ele almanın uzun vadede zaman kazandırdığını bilir ve buna göre davranır
- Flaky test varsa araştırır ve düzeltir
- Gerçek kullanımda bir hata bulursa ticket açar ya da hemen düzeltir
- Yeni bir özellik mevcut kodla uyuşmuyorsa zorla araya sıkıştırmak yerine önce refactoring yapar
- Gerekirse nedenini anlamak için stack’in alt katmanlarına kadar iner
- Bu geliştiriciler de “good enough”ın doğru olduğu durumları, kapsamın daraltılması gereken anları ve mimariyi değiştirmeden önce domain’i daha iyi öğrenmenin daha iyi olacağı halleri ayırt eder
- Sorun şu ki bu tür değerlendirmelerden bağımsız olarak, bazı anlarda projenin dış kısıtlarından daha güçlü kısıt motivasyon eksikliği olur
Özlü sözlerin arkasına saklanmadan dürüst olmak
- Lazygit’in end-to-end test sistemi birkaç ay boyunca part-time geliştirildi; sonrasında çok sayıda regression’ı engelledi ve bugün eklenmeye çalışılsa çok daha zor olacağına dair güçlü bir kanaat var
- Buna rağmen Lazydocker’a end-to-end test eklenmemesinin nedeni basitçe CBF idi
- Başka bir açık kaynak depoya issue açtıktan sonra minimum yeniden üretim Git deposu istendi, ancak hâlâ hazırlanmadı; bir yıldan uzun süre önce başlanan büyük refactoring de bitirilemediği için kod hâlâ büyük ölçüde God Struct içinde kalıyor
- Bunun burnout mı, growth mindset eksikliği mi, yoksa karakter meselesi mi olduğu konusunda kesin bir yargıya varılmıyor
- Teknik borcun uzun vadeli acısını bilmek kaçınma motivasyonu sağlayabilir; ancak bilmek ile gerçekten doğru davranmak farklı şeylerdir
- “Çok fazla test bakım yükü oluşturur”, “diğer özelliklerin nasıl etki edeceğini görüp refactoring yapacağım”, “premature optimisation”, “cut scope aggressively” gibi ifadeler iyi muhakeme için de kullanılabilir, bahane olarak da
- Kodun ya da pull request’in bir kısmının yetersiz olmasının nedeni tembellikse bunu kabul etmek, reviewer’ın bu eksikliğin standardı aşıp aşmadığını veya zamanı bir sonraki işe harcamanın daha iyi olup olmadığını doğrudan değerlendirmesini sağlar
- CBF hâli geldiğinde moral bozmak yerine dürüst olmak gerekir; çok uzun süredir %100 tempoyla koşuluyorsa tatil gerekebilir
1 yorum
Hacker News yorumları
CBF’nin önemli bir kısmı yalnızca ücret ve teşviklerle açıklanabilir
Bu şirkete ilk girdiğimde enerjim yüksekti; bozuk build’leri düzelttim, ihmal edilmiş testleri geçer hâle getirdim, dağıtım pipeline’ını refactor ettim, hataların kök nedenini bulup giderdim
Ama zaman geçtikçe insanlar beni örnek almak bir yana, “nasıl olsa o kişi düzeltir” noktasına geldi; angarya işleri yaptıkça karşıma sadece daha fazla angarya çıktığını öğrendim
Buna karşılık, işleri kabaca hack’leyerek yapan kişiler sonuçları iyi paketleyip daha önce terfi aldı; operasyonda sorunlar patlak verdiğinde de çoktan başka projeye geçmiş oluyorlardı
Her hafta saatlerce yardım ettiğim junior, 2022’de alelacele işe alındığı için benden fazla kazanıyor; ben ise 2023’te “beklentilerin üzerinde” değerlendirmesi aldım ama zor zamanlar denerek zam bile alamadım
Sonuçta maaş karşılığı çalışan biri açısından, emek ödüllendirilmiyor hatta cezalandırılıyorsa motivasyonun kaybolması şaşırtıcı değil
Ayrılıp, bulunman gereken yeri ve kendi insanlarını bulman gerekir
Takdir görmek motivasyon maliyetini ciddi biçimde düşürür ve insanlar ödüllendirilmekten hoşlanır
İnsanların oyunlara binlerce saat harcamasının nedeni de motivasyon maliyetinin çok düşük olmasıdır
İş yerini oyunlaştırmak gerektiğini söylemiyorum ama insan kendini savununca küçük hesapçı göründüğü için, çalışma arkadaşlarının birbirini takdir etmesi gerekir
Teknik borcun da farklı faiz oranları vardır; beceri, %0 borcu bırakıp yüksek faizli borcu önce ödemektedir
Bodrumdaki dolabın zeminini döşerken malzeme yetmediği için arka tarafı tamamen kaplayamadım; görüntü olarak biraz çirkin ama her zaman kutularla kapanıyor ve on yıllarca yaşasanız da etkisi yok. Bu %0 teknik borçtur
Buna karşılık drenaj kanalı tıkanırsa zaman geçtikçe bodrum su alması veya drenajın yerinden çıkması gibi nedenlerle maliyet artar; bu faiz işleyen bir borçtur. Giriş merdivenlerinin bozulup sürekli takılıp düşmeye yol açması da hızlıca düzeltilmesi gereken yüksek faizli bir borçtur
Mühendislikte, tüm özellik geliştirmeyi yavaşlatan mimari sorunlar yüksek faizli borç olabilir; neredeyse hiç dokunulmayan bir dosyadaki dağınık kod veya TODO’lar ise gerçekte düşük faizli borç olabilir
Mühendisler bir yandan %0 borcu düzeltmeye çalışırken daha önemli işleri kaçırır; diğer yandan “ürün/liderlik teknik borcun giderilmesini desteklemiyor” derler ama gerçek maliyeti ve faiz oranını çoğu zaman iyi açıklayamazlar
En tepeden en alta kadar herkesin ilgisini yeni ve parlak şeyler çekiyor; mevcut olanı sürdürme işine ilgi yok
Önemini ikna edici biçimde anlatsan bile, yönetim o işin gerekli olduğuna katılmakla yetinir; performans değerlendirmesine hiçbir olumlu etkisi olmaz. Yanlış giderse yalnızca azar işiteceğim işi ben üstlenmiş olurum
Kod tabanı dağınık ve tutarsızsa, gizli kalmış bir dosya bile olsa geliştiricilerin yeni özellikleri tutarlı ve kaliteli biçimde uygulama isteği azalır
“Nasıl olsa bu modülün tamamını yeniden yazmak gerekecek; şimdilik buraya gelişi güzel ekleyelim, sonra temizleriz” noktasına gelinir
https://en.wikipedia.org/wiki/Broken_windows_theory
Teknik borç ifadesinin doğal bir uzantısı ve ana fikri kısa ve net aktarıyor; şirkette de kullanmak isterim
Bu yüzden “geliştirici gerçek maliyeti açıklayamadı” diye suçlamak biraz kolaycı bir bahane
Müşteriye görünen bir sorun ortaya çıkarsa çözülme ihtimali var, ama yalnızca iç sorun olarak kalıyorsa bu ihtimal çok daha düşük
“%0 teknik borç” gibi bir ifadeyi ciddi ciddi kullanırken, kavramı yanlış kurup kurmadığımıza dönüp bakmak gerekir
Borç ya ödenir ya da faizi ödenir; böyle bir şey yoksa borç da değildir
Bir sonraki adımda henüz uygulanmamış özelliklere de %0 teknik borç mu diyeceğiz diye düşünüyorum
Steve Jobs hayranı değilim ama zanaatkârlık ve ayrıntılara önem verme tavrı üzerine söylediği şu sözü hep sevmişimdir:
“Güzel bir şifonyer yapan bir marangozsanız, sırf duvara bakıyor ve kimse görmeyecek diye arka tarafında kontrplak kullanmazsınız. Orada olduğunu siz bilirsiniz; bu yüzden arka tarafta da güzel ahşap kullanırsınız. Geceleri rahat uyuyabilmek için estetik ve kalite en sona kadar sürmelidir.”
Yazılımın genelinde, “gereksinimleri teknik olarak zar zor karşıladım, benim işim bitti” tavrından çok çektiğini düşünüyorum.
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Standartların altında kalan donanım ve yazılımların yayımlanmasını reddettiği, doğru spesifikasyonlarda üretemeyen kişileri işten çıkardığına dair çok anlatı var.
Buna karşılık çoğu insan tam tersi bir liderlik altında çalışıyor: “Mümkün olduğunca çabuk bitirip daha çok sat; kalite testlerinden sorunsuz geçecek kadarını da kabaca yerine getir.”
Gerçek bir marangozun piyasada rekabet edebilmesi için pratik ve maliyet açısından verimli olması gerekir.
Kimsenin görmediği yerlere pahalı ahşap kullanır ya da zaman harcarsa üretim hacmi düşer, müşterinin maliyeti gereksiz yere artar.
Zanaatkâr için de zaman ve para sınırlıdır; görünmeyen işe harcanan zaman, daha görünür bir işe harcanamayan zamandır.
Aynı beceriye sahip marangozların daha düşük maliyetle daha fazla üretim yaptığı bir pazarda böyle bir marangoz geride kalır.
Yazılım sorununun tavırdan çok teşvik sorunu olduğunu düşünüyorum. İyi iş yapmayı ve iyi yazılım kullanmayı severim ama gün içinde zaman sınırlı; benim fayda sağlamayacağım bir ticari kazanç uğruna kişisel zamanımdan vazgeçecek kadar da değil.
Üstelik refaktör etmeye başladığınızda, bir gün aniden bugün bitmesi gereken zorunlu bir özellik çıkacağını makul biçimde öngörebilirsiniz.
Yönetim teknik borcu çözmeyi kabul etse bile, sonuçta tahminleri şişirip size atanan iş yerine refaktör yapmadıkça çözülmez.
Bir kitapta bir demirci karakteri, bir araba parçasını onarırken “Her zaman yapabileceğinin en iyisini yap” der.
“Ama o altta kalan bir parça, kimse görmeyecek ki” denince, “Ama ben orada olduğunu biliyorum. Yapabileceğim kadar iyi yapmazsam o araba her geçtiğinde utanırım. Üstelik o arabayı her gün göreceğim” diye yanıtlar.
https://news.ycombinator.com/item?id=28086786
Düzgün birim/entegrasyon/uçtan uca testleri yazarsanız, berbat kod gördüğünüzde onun üstüne bir kat daha koymak yerine refaktör ederseniz, kâğıt üzerinde sürekli ticket “çözen” ekip arkadaşınızdan daha az üretken görünürsünüz.
Bu, özellikle refaktör etmeyi veya kod kalitesi temizliğini hiç hesaba katmayan “tam Agile” organizasyonlarda daha da belirgin.
Apple en azından bir dönem istisnaydı. Ürün fiyatları yüksekti, müşteriler kalite bekliyordu; şirketin bunu mümkün kılacak kâr marjı vardı ve en önemlisi deneyimi görebilen Steve Jobs vardı.
Bunun karşı ucunda ise Juicero gibi, meyve suyu paketini sıkmak için havacılık-uzay düzeyi mühendislikle makine yapan örnekler var.
Kariyerimin büyük bölümünde, bana söylenmeden fırsat gördüğümde teknik borcu temizledim. Çünkü bağlılık ve sahiplenme hissim vardı.
Şimdi ise Jira tabanlı mikro yönetim ve özerkliğin olmadığı bir iş yerindeyim; mutlaka yapmam gerekenler dışında hiçbir şey yapmıyorum.
Eskiden gönüllü çaba kariyerimin merkezindeydi; artık herhangi bir değişikliğin bürokratik ve sosyal proje yönetimi maliyeti o kadar yüksek ki uğraşmaya değmiyor.
Ürünün uzun vadede iyi gidip gitmemesi ya da şirketin başarılı olup olmaması umurumda değil; bir sonraki işimi bulana kadar sadece ticket kapatıyorum.
Tersine, “Refaktör için izin istemeyin, yapın” yaklaşımıyla ilerlerseniz, depodaki mevcut kalıpları izlemeyen bir PR açtığınız için azar işitirsiniz.
Sonra iş “Güzel ama bunu tüm ekiple konuşmamız lazım”a döner.
Böylece teknik borç büyümeye devam eder, tek bir PR’ı merge etmek aylar sürer ve testler o kadar kararsızdır ki build alınana kadar yeniden başlat düğmesine basmak bir kumarhane slot makinesi gibi olur. Agile gerçekten harika.
Sadece tepkisel hareket eden bir iş yerinde proaktif davranmak, deneyimlerime göre asla ödüllendirilmez.
Bir sorun fark ettiğiniz anda o artık sizin sorununuz olur; daha sonra yeniden patlarsa da onu sizin bozduğunuz düşünülür.
PM’ler ve yönetim katmanı her zaman olumsuz varsayımlarla hareket eder; buna değmez.
Özellikle bazı insanlar iyi koda giden aydınlanmış yolu bildiklerini sanıyor; ama gerçekte çoğu zaman mevcut kodu okuyup anlamaktan daha kolay olan yolu seçiyorlar.
Buradaki yorumlarda biraz yanlış anlama var.
Bireysel programcı için motivasyon, çaba, enerji, irade gücü—adına ne derseniz deyin—sınırlı bir kaynaktır ve bu tamamen normaldir.
Organizasyonun avantajı, bireysel bir programcıdan daha fazla iş çıkarabilmesidir; ancak birden çok bileşeni bir araya getirirken aralarda boşluklar oluşur ve işler bu boşluklardan düşer.
COO, İK, ürün yöneticisi gibi teknik iş için değil, organizasyonu işletmek için maaş alan kişilerin bu boşlukları ele alacak süreçler oluşturması gerekir.
Ne var ki giderek daha fazla şirket bu işi tek tek mühendislere ve tasarımcılara yüklüyor; çünkü bunu kâr-zarar veya OKR’lerle ölçmek zor.
Şirket acı çekiyor, mühendisler tükenmişlik yaşıyor. Ek bir karşılık olmadan aralardan düşen küçük ticket’ları ve işleri sürekli sahiplenmenin bir sınırı var.
Buradaki olumsuz hava çok yoğun ama bu yazının günlük duygularımı tam olarak anlatmasına sevindim
Açık kaynak projelerdeki mükemmel test kapsamını ve ilkeli refactoring’i görünce ben de bazı günler “doğru düzgün yapalım” moduna girip iyi yapılmış birçok şey çıkarıyorum
Sonra bir gün o enerji kaybolunca, yazar gibi ben de CBF oluyorum. Testleri atlıyorum, iyi olmadığını bildiğim bir yere kod ekliyorum ve gelecekteki kendimin teşekkür etmeyeceği bir yol döşüyorum
Bunun gerçek zamanlı olarak olduğunu görüyorum ama yeniden ilhamlı “doğru düzgün yapalım” moduna dönecek enerjim ya da motivasyonum olmuyor
Bunların hepsi bizzat yapıp sattığım yazılımda da oluyor
Yazarın Lazygit’i yapan kişi olduğunu görünce etkilendim; lazygit’i gerçekten seviyorum. Kafamda hep işini doğru yapan açık kaynak bakımcıları kategorisinde yer alıyor
İkimizin de motivasyon konusunda benzer deneyimler yaşadığını düşünüyorum
lazygit’i sevdiğine sevindim; umarım ileride de bu iyi izlenimi koruyabilirim
Kararların çoğu aslında bilinçdışıdır
“Hiç uğraşamam” hâli, beynin bazı devrelerinin refactoring ya da test gibi işlerin uğraşmaya değmediğine karar verdiği anlamına gelir
O devre haklı da olabilir. Çünkü nesnel ve bütünsel bakıldığında, çoğu zaman emeğe karşılık gelen ödül gerçekten yeterli değildir
Örneğin iki ay boyunca uçtan uca testler yazdıysanız ve sonraki 6 ayda debug vb. işlerde 3 hafta tasarruf ettiyseniz hesap tutmaz
Yaygın iki uç var. Bir tarafta iş tarafı, mühendislere gerçekten kötü bir ödün olan teknik borcu dayatıyor; diğer tarafta ise mühendisler sonunda karşılığı verilmeyecek ideal bir yapısallaştırmaya ve dev test paketlerine zaman harcayabiliyor
Bunun bir kısmı da birinin daha iyi bir kod yapısı ya da ek testler bulup kendilerini değerlendireceğinden kaygılanmalarından kaynaklanıyor
Kendi standardımın altında bir şey ortaya koyduğumu hissedersem, o standart gerçek ihtiyaçtan yüksek olsa bile moral ve motivasyon ciddi şekilde zarar görür
Teknik borcun en büyük sorununun aslında morali bozması olduğunu düşünüyorum
Lazygit’te uçtan uca test sistemini birkaç ay boyunca kısmen geliştirdim ve her gün o sistemin engellediği regresyonları, ayrıca şimdi eklemeye kalksam bunun ne kadar daha zor olacağını düşünüyorum
Değerli olduğunu kesin olarak bilmeme rağmen Lazydocker’a neden uçtan uca test eklemedim? Çünkü basitçe CBF
Uçtan uca testler, araçlar düzgün değilse cehennem gibi zahmetli ve devasa bir iştir. Kolayca takılabilecek temel framework’lerin daha iyi hâle gelmesi gerekiyor
Şanslıysanız o kişinin entegrasyon testlerine bakacak zamanı da kalır
Bu toplumda ve bu dünyada insanların tembel olduğu yönündeki bakış açısının genel olarak saçma olduğunu düşünüyorum
Onlarca yıl haftada 40 saat çalışıp ancak yeniden doğduktan sonra dinlenmemiz bekleniyor; burada tembellikten mi söz edeceğiz?
Zihinsel enerji başkalarının servetini yaratmak için çekilip alınıyor, sonra hiçbir şey yapamayacak kadar yaşlanınca bir kenara atılıyoruz
Her hafta dün bitmiş olması gereken bir özellik daha çıkıyor; teknik borcu ne zaman düzelteceğiz bilmiyorum. Boş zamanımızda mı? Zaten neden var olmaya devam etmemiz gerektiğini de bilmiyorum
Küçük bir ekipteki olgun bir projede geriye kalan ticket’ların hepsi kimsenin istemediği zor bug’lardı
Günler harcasanız da şüphe listesinden birkaç maddeyi silmek dışında gösterecek bir şeyiniz olmuyor; yanlışlıkla elediğiniz bir şey bir hafta sonra yeniden karşınıza çıkıyor
Her gün tüm zihinsel enerjinizi böyle ticket’lara dökmeniz gerekiyor; kahveye ya da uyarıcılara dayanıp bir bug’ı zar zor çözünce kodu gönderiyor, ticket’ı kapatıyor ve hemen bir sonrakine geçiyorsunuz
Gerçek bir dinlenme yok; yalnızca bir sonraki ticket’ın başında, kimse anında sonuç beklemezken kısa süreliğine kafanızı dinlendirebiliyorsunuz
Ama birkaç gün geçince insanlar şimdiye kadar ne yaptığınızı soruyor, takılıp takılmadığınızı soruyor; aslında neredeyse başlamamışken neden geride kaldığınızı küçük yalanlarla uydurmak zorunda kalıyorsunuz
En çok dinlenmeniz gereken anda zaten en çok geride kalmış oluyorsunuz ve insanlar bunu fark etmiş oluyor; bu yüzden izin almak bile bir seçenek gibi hissettirmiyor
Şimdi bir mühendislik kâr amacı gütmeyen kuruluşunda haftada 20–30 saat, bazen daha az çalışıyorum; para sıkışık ama daha fazla çalışmam kesinlikle mümkün değil
Yan projelere ve bisiklete binmeye biraz zamanım var; hafta sonları asla çalışmıyorum. Özel bir durum yoksa salı günleri de çalışmıyorum
Şu anki işimi gerçekten seviyorum ve hayalimdeki iş ama kendimi öldürecek kadar yapmaya değmez. Hayat bir kez yaşanıyor; doğru düzgün sevgiyle yaşayacağım
Bugün şirket cihazının firmware’ini neredeyse baştan yazdığım 1 aylık bir işi bitirdim; başlangıçta bu, iletişim modülünün bir kısmındaki küçük bir bug’ı düzeltmek için 1 haftalık bir iş olarak planlanmıştı
Neyse ki rahat bir PM’im ve ekip arkadaşlarım var; artık o koddaki 8 yıllık legacy bug’ları gerçekten düzeltebilir hâle geldiğimizi kabul ettiler
Hâlâ edge case testleri ve ek düzeltmeler kaldı ama uzaktan kod güncellemesi çalıştığı için cihazları sevk edebiliyoruz
Buradaki “yalan” daha çok bir davranış önerisi gibi. Aslında yoruma “yalan söyleyin” diye başlamıştım ama yanlış anlaşılma oldu
İş arkadaşlarımıza, işin daha geniş sonuçlarını düşünmek için zaman ayırmanın önemli olduğunu anlatmak için de var olmalıyız
Böyle topluluklara kendi düşüncelerimizi katmak, çikolata yemek, mümkünse köpeği gezdirmek ve YouTube’da Alan Watts dersleri dinlemek için de var olmalıyız
Doğru yapmaya çalışan biri olarak teknik borçta önemli olan şeyin takip olduğunu düşünüyorum
Gördüğünüz bir sorunu iş olarak açmak birkaç dakika sürer ve o iş teknik borç hâline gelir
Liderliğin teknik borcu önceliklendirme ve belirli bir miktarını sürekli azaltma sorumluluğu vardır
Bazen bir şeyi yapmamaya karar vererek de teknik borcu azaltırsınız; bu da tamamen sorun değildir
Kaydetme, gözden geçirme ve ele alma sürecinin amacı, “şimdi değil” denen sorunlara ikinci kez bakma fırsatı vermektir
İlk sezgi yanlış olup X’e gerek olmayabilir; ya da tam tersine, o sırada akla gelmeyen bir nedenle doğru olabilir
En önemlisi, “şimdi yapamayız” denen işlerin bir kısmı gerçekten önemlidir. Zaman ayırıp bakmazsanız bunları bulamazsınız