Programlama çoğunlukla düşünme sürecidir (2014)
(agileotter.blogspot.com)- Kod olarak görünen çıktı, bir günlük çalışmanın tamamı değil; okuma, araştırma, debug, doğrulama ve kararların sonunda kalan saf sonuça daha yakındır
- Yıllar boyunca programcılara yöneltilen gayriresmî bir soruda, 6 saatlik bir değişikliği yalnızca diff’e bakarak yeniden girmek için verilen en yaygın yanıt yaklaşık 30 dakika oldu
- Bu oran bilimsel bir araştırmadan değil, anketler ve diff gözlemlerinden geliyor; ancak programlamayı 1/12 eylem, 11/12 düşünme olarak görmeye yarayan pratik bir ölçüt sunuyor
- Yazılım geliştirme, fabrika tipi üretimden çok tasarım işine yakındır; ilk tasarımdan sonraki kopyalama ise makineler tarafından neredeyse sıfıra yakın marjinal maliyetle yapılır
- Yönetim ve süreçler yazma süresini artıracak şekilde optimize edilirse hedef şaşar; daha önemli olan, düşünmenin kalitesini yükselten ortam ve işbirliği biçimidir
6 saatlik işi yeniden girmek ne kadar sürer?
- Varsayım şu: toplantıların ve kesintilerin neredeyse olmadığı iyi bir günde, bir programcı 6 saatlik ciddi programlama yaptı
- İşten çıkmadan önce diff’i yazdırdı, ancak gece sürüm kontrol sistemi çöktü ve önceki günün yedeğine dönülünce gün boyu yapılan çalışma kayboldu
- Sorunun özü şu: diff verilen programcı, o 6 saatlik işi kod tabanına yeniden girmek için ne kadar süreye ihtiyaç duyar?
- Yıllar boyunca konferanslarda, müşteri şirketlerde, iş arkadaşlarına ve ilk kez tanışılan programcılara bu soru soruldu; en yaygın yanıt yaklaşık 30 dakika oldu
- 6 saatin içinde 30 dakikadan 12 tane bulunduğu için, bu gözlem programlamanın 1/12 eylem, 11/12 düşünme olduğu ifadesine dönüşüyor
Oranın niteliği ve sınırları
- Bu sayı titiz bir bilimsel araştırmadan çıkmış bir değer değil, iyi kayıt tutulmuş resmî bir anketin sonucu da değil
- Amaç, programlama etkinliğinin istatistiksel ya da matematiksel bir yasasını bulmak değil; makul bir soruya makul bir cevap bulmaktı
- Hiçbir şirket, günlük çalışmanın tamamını gerçekten silip bu deneyi doğrulamaya ya da çürütmeye kalkışmadığı için, dayanak tahminler ve günlük diff gözlemleriyle sınırlı kaldı
- Pek çok changelog ve diff incelendiğinde, iyi bir gündeki saf değişim miktarı genelde 30 dakika ± 10 dakika gibi görünüyordu
Yazmak darboğaz değildir
- “Yazmak darboğaz değildir” sözü uzun zamandır çıkartmalarda ve sosyal medyada tekrar ediliyor
- Bazı programcılar için yazmanın kendisi darboğaz olabilir, ancak hızlı kod üretiminin anahtarı genelde yazma hızı ya da araç ustalığı değildir
- Quora’daki “How do programmers code so quickly?” başlıklı uzun yazıda bir yanıtlayıcı; kas hafızası, araç ustalığı, debug yeteneği, yazma becerisi ve bilgi arama becerisinden söz etti
- Ancak hızlı kod üretiminde yazmak ve araçlar daha çok yardımcı araçlardır; ne yapılacağına karar vermek için harcanan zaman daha büyük paya sahiptir
Yazılım fabrikası ile tasarım işi arasındaki fark
- Fiziksel ürün üretiminde görünür işin büyük kısmı harekettir; çeliğin yuvarlanması, damgalanması, preslenmesi, frezelenmesi, yerleştirilmesi ve birleştirilmesi iş gibi görünür
- Modern fabrikalar, CNC makinelerinde olduğu gibi soyut bir model yani veri temelinde hassas hareketler yapar; insanlar makineleri doğrudan elle çalıştırmak yerine onları yönetir
- Yazılım tarafındaki fabrika ise zaten tamamlanmıştır; kullanıcı “copy” ya da “download” düğmesine basarak bit-perfect copy elde eder
- İlk model bir kez var olduğunda, sonrasındaki kopyalamanın marjinal maliyeti fiilen sıfıra yakındır ve yazılım entelektüel bir üründür
- Uncle Bob Martin, yazılım geliştirmenin üretim işi değil tasarım işi olduğunu ve ilk tasarımdan sonraki kopyalamanın makineler tarafından neredeyse sıfır maliyetle yapıldığını uzun zamandır söylüyor
- Programcılar, tester’lar, PO’lar, Scrum Master’lar ve yazılım yöneticileri; müşterilerin ve topluluğun kullanacağı kopyaların temelini oluşturan veri modelini tasarlar
Entelektüel işi gözlemlemek zordur
- Sanayi çağına özgü düşünce biçimi, yazılım geliştirmeyi fabrika gibi görmeye çalışır ve geliştiricilerden gerçek sürece zarar verse bile fiziksel emek veriyormuş gibi görünmeleri beklenir
- Entelektüel faaliyetleri gözlemlemek ve ölçmek zordur; %80 tamamlanmış bir fikrin fiziksel bir biçimi yoktur
- Deneyler, proof-of-concept kodları ve notlar olabilir; ancak bunlar fiziksel işlerdeki gibi kesin bir tamamlanma oranı göstermez
- Üretim aşamasındaki bir sandalye, %50 noktasında kabaca %50 tamamlanmış görünür ve bittiğinde bitmiş ürün gibi görünür
- Bir sandalye tasarımı, %70’ten fazla ilerleyene kadar kâğıda bile dökülmemiş olabilir; ayrıca tasarım bitmeden gerçekten %70 tamam olup olmadığını bilmek de zordur
30 dakikalık değişiklik neden 6 saatlik iş anlamına gelir?
- 30 dakika, gün boyunca yazılıp silinmiş, düzenlenmiş ve yeniden oluşturulmuş kodun saf sonucunu yeniden üretme süresidir; harcanan toplam emeğin kendisi değildir
- Programcı, kusurlardan ve güvenlik açıklarından kaçınmak için kod yazarken sürekli değerlendirme yapar ve hipotezler kurar
- Kod metni, programın çalışırken ne yapması gerektiğini içerir; neden bu yaklaşımın seçildiğini, sistemin diğer bölümlerini nasıl etkilediğini ya da hangi hataların eklenip sonra çıkarıldığını ise çoğunlukla taşımaz
- Gerçek işin büyük kısmı değişikliğin kendisinde değil, değişikliğin nasıl yapılacağına karar vermekte yatar; mevcut kodun anlaşılması gerektiğinden, dağınık kod veya zayıf tasarım kaynakta görünmese bile daha çok zaman alır
- Programcının çıktısı ortak kod tabanına entegre edildiği için sosyal bir bağlama sahiptir; diğer programcıların, tester’ların ve operasyon ekiplerinin işi anlamasına yardımcı olmak da kodda görünmeyen maliyetler ve faydalar üretir
Kod satırı sayısı ilerlemenin ölçüsü değildir
- 6 saatlik entelektüel çalışma; okuma, araştırma, karar verme, kontrol, doğrulama ve gözden geçirme süreçlerinden geçerek kod tabanında 30 dakikalık saf değişime dönüşebilir
- Bu, eklenen kod satırı sayısı anlamına gelmez; hata düzeltmeleri ve özellik eklemeleri yapılmış olsa bile hafta sonundaki kod satırı sayısı hafta başına göre daha az olabilir
- Takımın üst düzey yöneticisinin SLOC’u ilerleme göstergesi gibi raporladığını bilmeden, birkaç hafta boyunca negatif kod satırı sayısı kaydedildiği için sorun yaşanmıştı
- Programcının gerçekte yaptığı iş; okumaya, öğrenmeye, anlamaya, tahmin etmeye, araştırmaya, debug etmeye, test etmeye, derlemeye, çalıştırmaya, hipotez kurmaya ve çürütmeye daha yakındır
- Yapılan işin büyük kısmı sonuçta düşünmek ve karar vermek olarak kalır
Daha az yazmak daha hızlı geliştirme olabilir
- Quora yanıtlarından biri, klavye üzerinde hareket eden parmakların görülebildiğini; ama kullanıcılarla konuşmak, ekip arkadaşlarıyla problemi tartışmak, araştırmak ve düşünmek için geçen zamanın görünmediğini söyledi
- Başka bir yanıtlayıcı, müşterinin “requirements” ya da “must have” dediği gereksiz fikirleri ayıklamasına yardımcı olmanın, çözüm teslimini en çok hızlandıran şey olduğunu belirtti
- Bir başka yanıt ise, üstün geliştiricilerin klavyeye dokunmadan önce gereksinimleri anlayıp uygun çözümü tasarlayarak işin %90’ından fazlasını yaptığını söyledi
- “Ne yazmayacağını bilmek”, “daha az yapmak”, “daha küçük adımlarla ilerlemek”, “önce ne yapılacağını anlamak” tekrar tekrar ortaya çıkan yanıtlardır
- Daha çok yazan veya daha çok copy-paste yapan kişiler, düşünme ve anlama konusunda daha zayıf olabilir; bunun sonucu olarak hata sayısı ve diğer programcıların anlama/düzeltme yükü artabilir
Süreçler düşünmek için tasarlanmalı
- Eğer programlama 1/12 eylem ve 11/12 düşünmeyse, insanlara zamanlarının 11/12’sinde yazı yazmaları için baskı yapılmamalıdır
- Gerekli olan şey, düşünmenin kalitesini yükselten malzemeler, ortam ve süreçlerdir
- Tersi yapılırsa sistem yanlış etkilere göre optimize edilir
- Yazılım hakkında birlikte düşünmeyi ve kararları daha kolay vermeyi sağlayan sistemler bilinçli olarak kurulduğunda üretkenlik artabilir
- İş içinde öğrenmeyi deneyerek, düşünmenin optimize edildiği sistemlerin nasıl kurulacağı üzerine kafa yorulmalıdır
1 yorum
Hacker News yorumları
Yazıdaki “gerçekten üstün bir geliştirici, klavyeye dokunmadan önce işin %90’ından fazlasını bitirir” sözü bazen doğru olsa da, insanların kafasında aynı anda çok sayıda kısıt ve kavram tutamayacağı gerçeğini gözden kaçırdığını düşünüyorum.
Hiçbir şey yazmadan, yalnızca düşünerek ilerleyebileceğim alan çok sınırlı; bu yüzden olası bir yaklaşım aklıma gelir gelmez, onu tamamen tanımlanmış bir tasarıma dönüştürmeden neredeyse hemen klavyeye sarılırım.
Gerçek kod yazarak farklı yaklaşımları denediğimde, başta en iyi sandığım çözümün daha az umut verici görünen çözümden çok daha kötü çıktığı sık oldu; problemi çalışan somut kod kadar iyi ortaya koyan bir şey yok.
Sonuçta kodlama, fikirleri koda maddeleştirip doğrulama sürecidir; prototiplemedeki ilk iterasyonu çöpe atma bakışı gibi, kod yazmayı da düşünme sürecinin bir parçası olarak görmek gerekir.
Efsaneye göre Git’i bir ay kadar düşündükten sonra 6 günde tamamlamış, 7. gün de dinlenmiş gibi anlatılır; ama sıradan insanlar, özellikle de benim için süreç daha çok ne yazacağını düşünmek, yazmak, test etmek, tekrar düşünmek ve bazı kısımları düzeltmek şeklinde bir etkileşimdir.
Nihai çalışan sürüme ulaşma süreci sonuçta bir ölçüde sanata yakındır.
Kabaca bir fikre vardıktan sonra, sorun çıkarma olasılığı en yüksek görünen “yapışkan” kısımdan kod yazmaya başlarım.
Tüm sorunları önceden öngöremediğim için gerçekten çarpışıp görmem gerekir; bu yöntem çoğu zaman çok işi çöpe atmama yol açar.
Doğru yolda olduğumdan emin olana kadar neredeyse hiç dokümantasyon yazmam[0]; böylece Concrete Galoshes[1] dediğim durumu azaltabilirim.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
Bunu öğrenmenin tek yolu bol miktarda pratik kodlama ve aktif öğrenmedir; bu aynı zamanda aynı teknoloji yığınını tekrar tekrar kullanmak anlamına da gelir.
Aynı yığında kalıp problemin kendisine odaklanmayı tercih ederim, ama burada sözü edilen “harika geliştirici”nin araç seçimi konusunda epey tek boyutlu olma ihtimali yüksek.
Yaş aldıkça mimarinin mikro kararlardan daha önemli olduğu fazlasıyla netleşiyor.
Mikro şeyler optimize edilebilir, ama makro kararlar çoğu zaman kalıcıdır.
Çoğu zaman kodu testlerin içinde tasarlar ve uygulamanın bir ölçüde yönlendirilmesine izin veririm.
Nihai sonucu zihnimde canlandırdıktan sonra, sisteme iyi bir API olacağını düşündüğüm biçimde test yazar ve oradan başlarım.
Sonuç olarak kod temelde test edilebilir hale gelir; Red → Green → Refactor döngüsünü birkaç kez çevirerek tatmin edici bir duruma ulaşırım.
Başkaları da böyle mi çalışıyor merak ediyorum.
Jonathan E. Steinhart’ın “The Secret Life of Programs” kitabındaki açıklama en hoşuma gideniydi.
Bilgisayar programlamanın iki aşaması olduğunu söylüyor: 1. Evreni anla 2. Üç yaşındaki bir çocuğa anlat.
Anlamadığınız bir işi yapan program yazamazsınız; yazım kurallarını bilmiyorsanız yazım denetleyicisi yapamazsınız, fiziği bilmiyorsanız iyi bir aksiyon video oyunu yapmak zordur demek istiyor.
İyi bir programcı olmak için diğer her şey hakkında mümkün olduğunca çok şey öğrenmek gerekir; bir problemin çözümü sık sık beklenmedik yerlerden geldiği için şu an alakasız görünüyor diye göz ardı etmemek gerekir.
İkinci aşama, bildiklerinizi dünyayı üç yaşındaki bir çocuk gibi çok katı biçimde gören bir makineye anlatmaktır.
Bir çocuğa “ayakkabın nerede?” diye sorarsanız “orada” diye cevap verebilir; soruya cevap vermiştir ama aslında ayakkabısını giyip dışarı çıkma niyetinizi çıkaramamıştır.
Çocuklar büyüdükçe esneklik ve çıkarım yapma becerisi öğrenir, ama bilgisayarlar Peter Pan gibi asla büyümez.
Kişiye ve probleme göre uygun düşünme biçimi değişir; farklı biçimlerde düşünmeyi ve programlamayı öğrenirseniz seçebileceğiniz araçlar artar.
Bu yüzden programlamanın mutlaka tek bir doğru şekilde gerçekleşmesi gerektiği türünden iddiaları sevmiyorum.
“Anlamadığınız şeyi program olarak yazamazsınız” sözü de doğru değil; bir şeyin gerçekte nasıl çalıştığını anlamak için çoğu zaman yazılım kullanırız.
Fizik modelleme de çoğu zaman gerçeğe tam sadakat hedefi değil, oyunun kullanıcı deneyimi ve zorluğu arasında denge bulmaya yönelik bir keşiftir.
Programlama keşifçi bir bilişsel araç olabilir; bu, düşünmenin büyük kısmının her zaman önce gelmesi gerektiği anlamına gelmez.
Genel kültürlü kişileri ya da kendi kendini yetiştirenleri severim, ama bu iyi bir programcı olmanın zorunlu ilk adımı değildir.
Çocukların “katı bir dünya görüşüne” sahip olmasından ziyade, sosyal imaları her zaman çıkaramaması söz konusudur; bilgisayarlar da bilinen olgulardan mantıksal sonuçlar çıkaracak şekilde programlanabilir.
Farklı yaşlardaki çocuklara, üç yaşındaki bir çocuğa da bir şeyler açıklamışlığım var; ama bu deneyim bilgisayar programlamaya hiç benzemiyordu.
Bu rakamın fiilen doğru olduğundan oldukça eminim, ama henüz hiçbir şirket bu deneyi kanıtlamak ya da çürütmek için bir günlük işi komple silmeyi kabul etmedi
Eskiden çok daha sabırlı olduğum zamanlarda, her gece tüm kod değişikliklerini gözden geçirip beğenmediklerini silen bir patronum vardı
O patron sürüm kontrolünün gereğinden fazla karmaşık olduğuna inanıyordu; şirket standardı olarak kendi evindeki ağ sürücüsüne uzaktan bağlanmayı benimsetmeye çalışıyordu
Bu yüzden bazen ertesi gün işe geldiğimde önceki günkü iş silinmiş oluyordu; sonunda gizlice SVN kurana kadar önceki günkü işi yeniden oluşturmada epey ustalaştım
Edge case testleri dahil bile olsa bir saatten fazla sürdüğü nadirdi
İlk işimde bir tür travma yaşadığım için ikinci işimde hemen bir Git deposu olup olmadığını sordum; patronum Git'i Github ile aynı şey sanıp kodu herkese açmak istemediğini söyledi
Daha sonra daha büyük bir şirket tarafından satın alınınca intranet erişimi kazandım; içeride bir GitLab instance'ı bulup çoğunlukla tek başıma çalıştığım kodu orada sürümledim ve belgelendirdim, hatta GitLab Runner bile kurdum
Kodu nasıl çalıştıracaklarını da adım adım belgelemiştim; işten çıkarıldığımda kodu devretmemi istediler, ben de hepsini gösterip nasıl yeniden üreteceklerini anlattım, patronum epey etkilenip teşekkür etti
Berbat bir iş yerinde doğru olduğunu düşündüğüm şekilde ısrar etmem sayesinde belki küçük de olsa iyi bir etki bırakmışımdır
O GitLab'ı bulmadan önce ağ paylaşımında bare bir Git deposu oluşturup oraya push ediyordum
İyi niyetli olsa bile bir yönetici koda ya da review sürecine karıştığında bu neredeyse her zaman ekip için net kayıp olur
Programcı olmayanlara göndermek için iyi bir yazı
Programcıların domain bilgisine ihtiyacı olduğu gibi, programcılardan bir şey elde etmek isteyenlerin de programlamayı biraz anlaması gerekir
Çok küçük bir diff bile hata ayıklama, tasarım ve öğrenme yüzünden saatler sürebilir
Sadece çıktının miktarına bakıp etkilenmemek kolaydır; ama birinden açıklama dinlemek ile saatlerce kendi başına duvara kafa ata ata anlamaya çalışmak tamamen farklı şeylerdir
Performansı 100 kat iyileştiren tek satırlık commit'i bulmanın günler sürdüğü, aynı anda senkronizasyon toplantısında neden ticket'ın ilerlemediğini açıklamak zorunda kaldığınız türden işler
Bu yüzden domain bilgisi kilit nokta
Finans alanında çalışırken trading desk'te oturup çeşitli borsaları izledim ve türlü stratejileri uygulayan kodlar yazdım
İşin ne yapması gerektiğini bilmiyorsanız bilgisayarın ne yapması gerektiğini de düşünemezsiniz
Bu açıdan kodlayıcıları çevirmen gibi eğitmek mantıklı olabilir
Çevirmen bir arkadaşım birkaç dilin gramerini ve deyimlerini iyi biliyor, yeni dilleri de bizim yeni programlama dilleri öğrenmemiz gibi öğreniyor; ama ilaç sektörü hakkında da ciddi zaman harcadı ve artık tıbbi belgeler çeviriyor
Avukatlık ve muhasebecilik de dil bariyeri olan meslekler
Uzman olduğunuzda hukuk, muhasebe ve yazılımın dilini öğrenirsiniz; ama iyi bir uzman, uzmanlık diliyle değil işin diliyle yanıt verir
Daha zayıf bir avukat, hukuk terimleriyle olası tüm sonuçları anlatıp kararı size bırakır; iyi bir avukat ise önemsiz olasılıklar çok olsa da pratikte aynı konumdaki müşterilerin bu iş hedefi nedeniyle hepsinin X yaptığını söyler
İlk trading işimde bir trader, enstrümanları tarayıp işlem yapılacak hedefleri bulma sürecini çalıştıran bir Excel VBA modülü yapmıştı
Sürüm kontrolü olmadan diskte duran dosyalardan ibaretti; işe yeni gelen biri birkaç hafta içinde o VBA modülünün tamamını silmiş halde kaydetti, yedek de yoktu, IT'den yardım da yoktu
Trader'ın yüzü kızardı, sonra sakinleşti; zaten yedek olması gerektiğini ve VBA ile ne yaptığının gerçekliğini kabullenip oturdu ve 80'ler terminal ekranında karakterler tek tek yazılıyormuş gibi her şeyi baştan yazdı
İyi bir çözüm üretmek için önce o domainde deneyim sahibi olmak gerektiği benim temel inancım
Şu anda zamanımın çoğunu yeni domain deneyimi kazanmak için harcıyorum ve gerekli bilgiyi hızla edinmek için domain uzmanlarının yanında oturuyorum
Benim gibi bir geçmişe sahip birindense muhasebe ile ilgili yazılımları 15 yıl geliştirmiş bir yazılım mühendisini tercih ediyor, o kişiyi bir muhasebeciyle 30 dakika konuşturmayı seçiyorlar
Programlamanın mutlaka belirli tek bir şekilde işlemesi gerektiğini söyleyen reçeteler tekrar tekrar karşımıza çıkıyor, ama alt alanlara göre iş türleri çok büyük farklılık gösteriyor
Her alana uyan kusursuz tek bir metodolojiyi öğrenmeye ya da öğretmeye çalışmaktansa, çeşitli yaklaşımlar ve metodolojilerden oluşan bir alet çantasına ve her birinin hangi durumlara iyi uyduğunu anlamaya sahip olmak daha iyi bence
Bu da insanı sektörler arasında taşınabilir genel programlama becerilerine odaklanmaya itiyor
Bjarne’in PPP kitabının[0] başlarında da benzer bir şey geçiyor
“En iyi programcılar bile, özellikle de en iyi programcılar, zamanlarının çoğunu kod yazmaya değil problemi anlamaya harcar. Problemi anlamak ciddi zaman alır ve çoğu zaman kayda değer zihinsel çaba gerektirir. Pek çok programcının programlamanın ilginç olduğunu söylerken kastettiği entelektüel meydan okuma da tam olarak budur” anlamında
Yakın zamanda ilk sayfaya çıkan[2] yeni baskıyı[1] da aldım
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
Hangi veritabanını kullanacağız, hangi dil en iyisi, kodda ve veritabanında null’a izin verilecek mi, API biçimi, log biçimi gibi şeyler
Özellikle ilginç değiller ve arada bir yeniden değerlendirmek gerekebilir, ama son üç şirkette bu tür zaman kayıplarının çoğu artık çözülmüş olması gereken problemler gibi geldi
Aslında bir şirketin güçlü bir düşünce biçimi varsa, şüpheli olsa bile çok daha üretken olabilir
Perl, MongoDB, CGI kullanılacağı kesin olarak belirlenmiş olsaydı, o stack’e rağmen son zamanlardakinden daha üretken olurdum gibi geliyor
“Programlama çoğunlukla düşünmektir” insanın kendine derin bir hakikatmiş gibi söylediği cümlelerden biri, ama bir gözlem olarak pek verimli değil
Programlamanın düşünmek olması, tüm bilgi işlerinin düşünmek olmasıyla tam olarak aynı anlamda doğru
Tasarım da çoğunlukla düşünmektir, muhasebe de çoğunlukla düşünmektir, yönetim de büyük ölçüde düşünmektir
Anlamlı fark düşünmenin kendisi değil, ne hakkında düşündüğünüzdür
Yöneticiler insan problemlerini debug etmek zorunda oldukları için insanlarla çok zamana, yani toplantılara ihtiyaç duyar
Geliştiriciler bilgisayar problemlerini debug ettiği için bilgisayarla çok zamana ihtiyaç duyar
Burada açık bir gerilim var ve iki uç da işe yaramıyor; bu yüzden birbirimizin işini daha az bölmek için bir denge bulmak gerekiyor
Bahsettiğim anlaşılmaz code golf tarzı kod değil; ürettiğiniz her şeyi bakımını yapmak zorunda olmanız açısından söylüyorum
Bakımla pek ilgilenmeyip metnin yarattığı duyguya daha çok önem verecek bir romancıdan açıkça farklı
“İş başında öğrenmeyi deneyerek düşüncenin optimize edildiği bir sistem kurmak için?” sorusuna verilecek en iyi optimizasyon kesintileri azaltmaktır
Araştırmalara göre kesintiler programlama üzerinde yıkıcı etki yaratır
Bir kesintiden sonra işe dönmek 10-15 dakika sürer, bir programcının günde elde ettiği kesintisiz 2 saatlik oturumun muhtemelen yalnızca bir tane olması muhtemeldir ve düzenleme, arama ya da anlama sırasında bölmek en kötü zamandır
Bu kesintileri takip edip gösterecek bir yol olup olmadığını merak ediyorum
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
Ama geliştiricilerden bitmek bilmeyen toplantılar, Slack/Zoom’daki kısa ping’ler ve senkronizasyonlar arasında saatler süren kodlama işlerini bitirmeleri bekleniyor
Bazen hafta sonu evden çalışmak zorunda kaldığımda, kesintisiz bir hafta sonunun iş kalitesinin telaşlı bir hafta içine göre çok daha iyi olduğunu gördüm
Herkese uymaz, her duruma da uymaz; kalan %20 gündüz çalışan insanlarla koordinasyon, ama saatlerce süren iyi kesintisiz oturumlardan çıkan üretkenlik kıyas kabul etmez
Tekrar söyleyeyim: herkes için, muhtemelen çoğunluk için uygun bir yöntem değil
Evde kimse beni bölmüyor; bir kesinti gelse bile ne zaman yanıt vereceğime ben karar verebiliyorum
Özellikle zor bir problemle uğraşırken her 10-20 dakikada bir kesinti geliyorsa bırakmak daha iyi; aksi halde muhtemelen sonradan baş ağrısı yaratacak berbat kod üretirsiniz
Gizliliğe saygı gösterecek şekilde tasarladık: web tarayıcısı kullanıldığı bilgisini kaydediyordu ama şirket içi intranet mi yoksa fb.com mu gibi belirli URL’leri kaydetmiyordu
Ara sıra bir açılır pencereyle kullanıcının kendi üretkenliğini değerlendirmesini ve serbest metin yorum bırakmasını istiyordu; insanların süper insan gibi görünmek için yalan söylememesi adına bunu kullanıcı ID’siyle ilişkilendirmedik
Windows frontend’i ve Scala backend’i geliştirip geliştiriciler, avukatlar ve finans çalışanlarının da olduğu gönüllü bir gruba dağıttık; ancak ilk veri analizinden sonra işler ilginçleşmeye başladığında zaman ve bütçe bittiği için makale olarak yayımlayamadık
Rescue Time( https://www.rescuetime.com/
) gibi mevcut araçlara da baktık ama kurum içi üretkenlik verilerini harici bir bulutta saklamayı kabul edilemez bulduk
İyi programlama bazen çoğunlukla düşünmektir, ama “Hiçbir plan düşmanla ilk temastan sonra sağ kalmaz” sözü doğru
Pratik programlama, planlama ile kodu IDE’de denemenin dikkatli bir bileşimidir ve bu denge kullanım senaryosuna göre değişmelidir
Günlerce kod yazmıyorsanız ya problem yüzeyini tamamen biliyorsunuzdur ya da sadece tahmin yürütüyorsunuzdur
İkincisiyse üzerinde düşünecek pek de fazla şey yoktur
İkincisi daha hızlı olur
Düşünmeyi “araç destekli düşünme” olarak genişletebileceğimize katılıyorum
Peter Naur’un Programming as Theory Building ifadesinin yinelenmiş bir biçimi ve programlamanın özünü anlamamda belirleyici oldu
Programlama, programın kendisini üretme işi değil; dünyadaki işler hakkında belirli bir içgörü oluşturma işidir ve sonunda ortaya çıkan kod, kişinin inşa ettiği teorinin yalnızca basit bir ifadesidir