Geliştiricileri üretken yapan şey nedir

xguru · 2023-08-07T11:09:02+09:00

Geliştirici üretkenliğini birçok unsur etkiler Bazıları açıktır ve ölçmesi kolaydır, ancak diğerlerini ölçmek zordur ve bu yüzden gözden kaçma eğilimindedir Ne inşa edileceğini bilmek (Knowing what to build) Yanlış şeyi hızlı yapmak hiç de üretken değildir müşterinin ne istediğini bilmek, diğer ekiplerin neyi kabul edilebilir bulduğunu bilmek (DB tablosunda kaç indeks olabilir, yasal olarak izin verilmeyen hangi bilgiler paylaşılabilir?), daha önce denenip işe yaramayan şeylerin ne olduğunu bilmek gerekir Daha az iş yapmak İşi hızlı tamamlamak iyidir, ama hiç "yapmak zorunda olmamak" daha da iyidir Şirket süreçleri, üretkenliği düşüren "meşguliyet işleri" ekleyebilir Bazen aynı değeri çok daha az işle sunmak için süreci kolayca ayarlamanın yolları vardır "Işıkları açık tutmak (Keep the lights on, KTLO)" için belli ölçüde çaba gerekebilir Bu, sürekli yapılması gereken (ör. destek taleplerine yanıt vermek) ama projeyi ileri götürmeyen işlerdir Bu tür işler çeşitli metriklerde (tamamlanan bilet sayısı, merge edilen commit sayısı) üretken görünebilir, ama şirketi daha iyi bir yere taşımaz Hızlı yanıt veren araçlar Geliştiriciler sürekli araç kullanır: editör, git, build sistemi Bu araçların eklediği süre, ne kadar sık kullanıldıklarına bağlı olarak oldukça büyük bir maliyet yaratır Sadece saat başına maliyet oluşturmakla kalmaz, geliştiricinin odağını da bozar Geliştiricinin kafasındaki bilgi Ölçmesi zordur Diğer tüm koşullar eşitse, ilgili bilgiye daha çok sahip olan geliştirici daha üretkendir çünkü kodun nasıl çalıştığını bilir ve koda derinlemesine bakması gerekmez, araçları nasıl kullanacağını ve hangi tuzaklardan kaçınacağını bilir doğru soruları sorar 10x geliştiriciler vardır ve onlar "kod tabanını çok iyi bilen kişiler"dir Bu, bir ekibin topluca zihinlerinde tutabileceğinden daha fazlasına sahip olmaması gerektiği anlamına gelir. (Bus Factor teorisine göre bus number'ın 1'den büyük olması idealdir) Ayrıca sahipliğin ne kadar sık değiştiğini en aza indirmenin avantajlı olduğunu da gösterir Hiç kimse, onu yapan kişiden daha fazlasını bilemez İdeal olarak bir sistemi ilk kez kullanan kişilerin, o sisteme zaten hakim olan kişilerle birlikte çalışıp öğrenmesi iyidir Sistemler arasında net sınırlar gerekir Basit semantiğe sahip temiz arayüzler, arayüzün arkasındaki tüm sistemi bilmeden yalnızca arayüzün özellikleri üzerine düşünebileceğiniz anlamına gelir Dokümantasyon bilgiyi aktarmanın iyi bir yoludur Özellikle geliştiricinin aşina olmadığı belirli bir işi yapması gerektiğinde önemlidir Dokümantasyon eksikse geliştirici işin nasıl yapılacağını kendi başına araştırmak, hata yapmak ve işi yeniden yapmak ya da başka bir ekibin soruları yanıtlamasını beklemek zorunda kalabilir; bu da işi yavaşlatır Bu, 1 saatlik bir işi kolayca 2 günlük bir işe dönüştürebilir Bunu 100 geliştirici yapmak zorundaysa, eksik bir dokümantasyon sayfasının maliyeti bir geliştiricinin yıllık maaşına eşdeğer olabilir Bu aynı zamanda uzmanlaşmanın (Specialization) artması gerektiği anlamına da gelir Her geliştiriciden çok geniş bir iş yelpazesi yapmasını istemek üretken değildir Bazı güvenlik sistemlerini ya da kapasite planlamasını yazma sürecine harcanan bir saat, sorunu çözmek için alanı anlamaya harcanan bir saatten farklıdır Faydalı altyapı Altyapı engel değil, yardımcı olmalıdır Yapılması gereken tüm işlerle makul ölçüde yakın hizalanmış olmalıdır Altyapının her parçası belirli kullanım senaryoları düşünülerek tasarlanır, ancak projelerde bazen bu senaryoların dışına çıkılır Böyle durumlarda "sadece bizim altyapımızı kullanmalısınız" ya da "bizim altyapımızda bunu yapamazsınız" denmesi sinir bozucudur Bu durumda ya altyapının etrafından dolanarak çalışmak ya da gereksinimleri altyapı sahiplerine anlatmaya çalıştığınız toplantılarda zaman harcamak zorunda kalırsınız Az teknik borç Mevcut kod, yapmak istediğiniz işe hiçbir zaman tam olarak uymaz Kodun ilk yazarı, sizin hangi değişikliği yapacağınızı görebilecek bir "sihirli küre"ye sahip değildi Ama bazı kodları değiştirmek diğerlerine göre çok daha kolaydır "X nasıl yapılır?" sorusunun cevabı "bunların hepsini yeniden tasarlamamız gerekiyor" olmamalıdır Teknik borç fazlaysa, bir özelliği biraz değiştirmek için bile sistemi daha büyük ölçüde değiştirmek gerekir Teknik borcu azaltmak, (a) anlaşılması ve (b) değiştirilmesi gereken yüzey alanını en aza indirmeyi sağlar Teknik borcu ödemeye yönelik projeler tamamlanmalıdır Ortada bırakılırsa ya da önceliği düşürülürse, sistem başlangıçtakinden daha kötü hale gelebilir Düşük hata oranı Araç çalıştırma hataları, build hataları, dağıtım hataları ya da production hatalarından kaynaklanan regresyonlar yaşanıyorsa, bu zaman kaybıdır Bu tür hataların olasılığını düşürmek üretkenliği artırır Bu hataları yaşayan mühendisin yanı sıra, hata veren sistemin sahibi olan ekibin de zamanını boşa harcama eğilimi vardır (çünkü birlikte analiz edip düzeltmeleri gerekir) Üretken pratikler pratiktir (Productive practices are practical) Belirli bir problemi nasıl çözeceğini öğrenmenin en iyi yolu bir prototip yazmaktır Eğer ortam prototiplemeyi engelliyorsa, en üretken yaklaşım bile engellenebilir Monitoring araçlarını kullanmak zorsa, geliştiriciler daha az dashboard oluşturur, daha az şeyi ölçer ve kararlar daha az veri odaklı olur Tersine, büyük değişiklikleri daha küçük code review'lara bölmek, kodu incelemeyi ve dağıtmayı kolaylaştırabilir Mühendisin ne kadar odaklanabildiği Mühendisler bir üretim takvimine göre çalışır ve odaklanabilmelidir Bu odak, toplantılar ve kesintilerle çalınabilir Kesintilere yavaş CLI komutları, yavaş testler ve nasıl yapılacağı bilinmediği için araştırma gerektiren işler de dahildir Bir haftada çok fazla iş hakkında düşünmek de odaklanma becerisine zarar verir Yaklaşan deadline'lar ya da yöneticiden yanıt alınmamış sorular, başka şeylere odaklanmaya çalışırken bile zihinsel RAM'i işgal eder İşi bitirmek Bir şeyin %50'sini yapmak, %50 üretkenlik değil %0 üretkenliktir Boşa giden iş kadar üretken olmayan başka bir şey yoktur Bazen projeyi yarıda bırakmak doğru karar olabilir Batık maliyet yanılgısıyla mücadele etmek bazen doğrudur Ama proje tamamlanmadan önce önceliği değiştirme yönünde tutarlı bir örüntü olmamalıdır Böyle olursa ekibin üretkenliği 0'a düşebilir Sonuç Bu kadar çeşitli unsurları ölçmek için her zaman dashboard kuramasak da, yukarıdakilerin üretkenliği nasıl etkilediğini anlayabiliriz Bu sorunları çözmek, yapılan iş miktarını büyük ölçüde artırabilir Bazı sorunları düzeltmek şaşırtıcı derecede kolay olabilir Dokümantasyon yazmaya birkaç saat ayırmak, şirkete binlerce saat kazandırabilir Ağacı hızlı kesmek istiyorsanız, işe testereyi bileyleyerek başlayın

(jeremymikkola.com)

86 puan yazan xguru 2023-08-07 | 7 yorum | WhatsApp'ta paylaş

Geliştirici üretkenliğini birçok unsur etkiler
Bazıları açıktır ve ölçmesi kolaydır, ancak diğerlerini ölçmek zordur ve bu yüzden gözden kaçma eğilimindedir

Ne inşa edileceğini bilmek (Knowing what to build)

Yanlış şeyi hızlı yapmak hiç de üretken değildir
- müşterinin ne istediğini bilmek,
- diğer ekiplerin neyi kabul edilebilir bulduğunu bilmek (DB tablosunda kaç indeks olabilir, yasal olarak izin verilmeyen hangi bilgiler paylaşılabilir?),
- daha önce denenip işe yaramayan şeylerin ne olduğunu bilmek gerekir

Daha az iş yapmak

İşi hızlı tamamlamak iyidir, ama hiç "yapmak zorunda olmamak" daha da iyidir
Şirket süreçleri, üretkenliği düşüren "meşguliyet işleri" ekleyebilir
- Bazen aynı değeri çok daha az işle sunmak için süreci kolayca ayarlamanın yolları vardır
"Işıkları açık tutmak (Keep the lights on, KTLO)" için belli ölçüde çaba gerekebilir
Bu, sürekli yapılması gereken (ör. destek taleplerine yanıt vermek) ama projeyi ileri götürmeyen işlerdir
Bu tür işler çeşitli metriklerde (tamamlanan bilet sayısı, merge edilen commit sayısı) üretken görünebilir, ama şirketi daha iyi bir yere taşımaz

Hızlı yanıt veren araçlar

Geliştiriciler sürekli araç kullanır: editör, git, build sistemi
Bu araçların eklediği süre, ne kadar sık kullanıldıklarına bağlı olarak oldukça büyük bir maliyet yaratır
Sadece saat başına maliyet oluşturmakla kalmaz, geliştiricinin odağını da bozar

Geliştiricinin kafasındaki bilgi

Ölçmesi zordur
Diğer tüm koşullar eşitse, ilgili bilgiye daha çok sahip olan geliştirici daha üretkendir
- çünkü kodun nasıl çalıştığını bilir ve koda derinlemesine bakması gerekmez,
- araçları nasıl kullanacağını ve hangi tuzaklardan kaçınacağını bilir
- doğru soruları sorar
- 10x geliştiriciler vardır ve onlar "kod tabanını çok iyi bilen kişiler"dir
Bu, bir ekibin topluca zihinlerinde tutabileceğinden daha fazlasına sahip olmaması gerektiği anlamına gelir. (Bus Factor teorisine göre bus number'ın 1'den büyük olması idealdir)
- Ayrıca sahipliğin ne kadar sık değiştiğini en aza indirmenin avantajlı olduğunu da gösterir
- Hiç kimse, onu yapan kişiden daha fazlasını bilemez
- İdeal olarak bir sistemi ilk kez kullanan kişilerin, o sisteme zaten hakim olan kişilerle birlikte çalışıp öğrenmesi iyidir
Sistemler arasında net sınırlar gerekir
- Basit semantiğe sahip temiz arayüzler, arayüzün arkasındaki tüm sistemi bilmeden yalnızca arayüzün özellikleri üzerine düşünebileceğiniz anlamına gelir
Dokümantasyon bilgiyi aktarmanın iyi bir yoludur
- Özellikle geliştiricinin aşina olmadığı belirli bir işi yapması gerektiğinde önemlidir
- Dokümantasyon eksikse geliştirici işin nasıl yapılacağını kendi başına araştırmak, hata yapmak ve işi yeniden yapmak ya da başka bir ekibin soruları yanıtlamasını beklemek zorunda kalabilir; bu da işi yavaşlatır
- Bu, 1 saatlik bir işi kolayca 2 günlük bir işe dönüştürebilir
- Bunu 100 geliştirici yapmak zorundaysa, eksik bir dokümantasyon sayfasının maliyeti bir geliştiricinin yıllık maaşına eşdeğer olabilir
Bu aynı zamanda uzmanlaşmanın (Specialization) artması gerektiği anlamına da gelir
- Her geliştiriciden çok geniş bir iş yelpazesi yapmasını istemek üretken değildir
- Bazı güvenlik sistemlerini ya da kapasite planlamasını yazma sürecine harcanan bir saat, sorunu çözmek için alanı anlamaya harcanan bir saatten farklıdır

Faydalı altyapı

Altyapı engel değil, yardımcı olmalıdır
Yapılması gereken tüm işlerle makul ölçüde yakın hizalanmış olmalıdır
Altyapının her parçası belirli kullanım senaryoları düşünülerek tasarlanır, ancak projelerde bazen bu senaryoların dışına çıkılır
- Böyle durumlarda "sadece bizim altyapımızı kullanmalısınız" ya da "bizim altyapımızda bunu yapamazsınız" denmesi sinir bozucudur
- Bu durumda ya altyapının etrafından dolanarak çalışmak ya da gereksinimleri altyapı sahiplerine anlatmaya çalıştığınız toplantılarda zaman harcamak zorunda kalırsınız

Az teknik borç

Mevcut kod, yapmak istediğiniz işe hiçbir zaman tam olarak uymaz
- Kodun ilk yazarı, sizin hangi değişikliği yapacağınızı görebilecek bir "sihirli küre"ye sahip değildi
- Ama bazı kodları değiştirmek diğerlerine göre çok daha kolaydır
"X nasıl yapılır?" sorusunun cevabı "bunların hepsini yeniden tasarlamamız gerekiyor" olmamalıdır
Teknik borç fazlaysa, bir özelliği biraz değiştirmek için bile sistemi daha büyük ölçüde değiştirmek gerekir
Teknik borcu azaltmak, (a) anlaşılması ve (b) değiştirilmesi gereken yüzey alanını en aza indirmeyi sağlar
Teknik borcu ödemeye yönelik projeler tamamlanmalıdır
- Ortada bırakılırsa ya da önceliği düşürülürse, sistem başlangıçtakinden daha kötü hale gelebilir

Düşük hata oranı

Araç çalıştırma hataları, build hataları, dağıtım hataları ya da production hatalarından kaynaklanan regresyonlar yaşanıyorsa, bu zaman kaybıdır
Bu tür hataların olasılığını düşürmek üretkenliği artırır
Bu hataları yaşayan mühendisin yanı sıra, hata veren sistemin sahibi olan ekibin de zamanını boşa harcama eğilimi vardır (çünkü birlikte analiz edip düzeltmeleri gerekir)

Üretken pratikler pratiktir (Productive practices are practical)

Belirli bir problemi nasıl çözeceğini öğrenmenin en iyi yolu bir prototip yazmaktır
Eğer ortam prototiplemeyi engelliyorsa, en üretken yaklaşım bile engellenebilir
Monitoring araçlarını kullanmak zorsa, geliştiriciler daha az dashboard oluşturur, daha az şeyi ölçer ve kararlar daha az veri odaklı olur
Tersine, büyük değişiklikleri daha küçük code review'lara bölmek, kodu incelemeyi ve dağıtmayı kolaylaştırabilir

Mühendisin ne kadar odaklanabildiği

Mühendisler bir üretim takvimine göre çalışır ve odaklanabilmelidir
Bu odak, toplantılar ve kesintilerle çalınabilir
Kesintilere yavaş CLI komutları, yavaş testler ve nasıl yapılacağı bilinmediği için araştırma gerektiren işler de dahildir
Bir haftada çok fazla iş hakkında düşünmek de odaklanma becerisine zarar verir
Yaklaşan deadline'lar ya da yöneticiden yanıt alınmamış sorular, başka şeylere odaklanmaya çalışırken bile zihinsel RAM'i işgal eder

İşi bitirmek

Bir şeyin %50'sini yapmak, %50 üretkenlik değil %0 üretkenliktir
Boşa giden iş kadar üretken olmayan başka bir şey yoktur
Bazen projeyi yarıda bırakmak doğru karar olabilir
- Batık maliyet yanılgısıyla mücadele etmek bazen doğrudur
- Ama proje tamamlanmadan önce önceliği değiştirme yönünde tutarlı bir örüntü olmamalıdır
- Böyle olursa ekibin üretkenliği 0'a düşebilir

Sonuç

Bu kadar çeşitli unsurları ölçmek için her zaman dashboard kuramasak da, yukarıdakilerin üretkenliği nasıl etkilediğini anlayabiliriz
Bu sorunları çözmek, yapılan iş miktarını büyük ölçüde artırabilir
Bazı sorunları düzeltmek şaşırtıcı derecede kolay olabilir
- Dokümantasyon yazmaya birkaç saat ayırmak, şirkete binlerce saat kazandırabilir
Ağacı hızlı kesmek istiyorsanız, işe testereyi bileyleyerek başlayın

7 yorum

kofmania 2023-08-07

Ve çok fazla kapanış bölümü olan bir yazı.

laeyoung 2023-08-07

"Belgelendirme yetersizse, geliştiricinin işi nasıl yapacağını kendi başına araştırması, hatalar yapması ve işi yeniden yapması ya da başka bir ekibin soruları yanıtlamasını beklemesi gerekebilir; bu da işin yavaşlamasına neden olabilir."

Geliştirme dokümantasyonu değil ama şirketteki onboarding belgeleri için, onboarding alan kişilerden bir hafta sonra bunları güncellemelerini istemek dokümantasyonu gerçekten iyileştiriyor. Çünkü şirkete girip hiçbir bilgiye sahip olmadığınızda neye ihtiyaç duyulduğunu o anda en iyi onlar biliyor.

GitHub'daki açık kaynak projelerin README.md dosyalarının da çoğunlukla iyi yazılmış olmasının nedeni, çok sayıda ilk kullanıcının gelip geri bildirim vermesi olabilir diye düşünüyorum.

2023-08-07

[Bu yorum gizlendi.]

devsepnine 2023-08-07

Bu aralar üst üste çok fazla iş geldiği için aklım başımdan gidiyor ağlamaklı yüz

ahwjdekf 2023-08-07

Altyapı bir engel değil, bir yardımcı olmalı --> ancak şu anda Kore'deki şirketler güvenliği bahane ederek buna hiç uymuyor.

hero512 2023-08-07

Duygunuzu anlıyorum ama bu yazı İngilizce yazılmış. İngilizce konuşulan ülkelerdeki şirketlerde de durum benzer görünüyor.

kuroneko 2023-08-07

Bu bir özetten çok çeviri düzeyi gibi görünüyor... Ayrıntılı derleme için teşekkürler.