“Kötü kod” konusunda birkaç deneyimim var. Çoğu zaman tek başıma çalıştım, ama ekip içinde sadece çalışan, fakat en iyi olmayan kod yazdığım da oldu. Yeni işle birlikte eski kodu refactor etmeye çalıştığımda sık sık reddedildim; gerekli refactor veya düzeltmeleri ticket olarak bıraksam da genelde önceliği düşürüldü ya da görmezden gelindi.
Tek başınaysanız gerekli işi önceliklendirebilirsiniz, ama ekipte ikinci en iyi kararlar sonsuza kadar kalır ya da “sistem çöktü” anına kadar bekletilir. Sonrasında postmortem’de, aylar önce bu bombayı düzeltmeyi istediğiniz ticket’ı gösterdiğinizde bu “suçlama” ya da “saldırganlık” olarak algılandı; sonuçta çözüm, sanki asla ikinci en iyi kod yazmamakmış gibi oldu ve kod yazarken hayal kırıklığı ile kaygı arttı.
2017’de, 2003/2004’te yazdığım kodu düzeltmem için de benimle iletişime geçildi; o kod hâlâ production’da çalışıyordu. Bozuk kodu ve yaptığım tavizleri yeniden görüp sorumlusunun bizzat ben olduğumu fark etmek epey alçakgönüllü kılan bir deneyim; bundan sonra bakımı yapılabilir kod ve dokümantasyon konusundaki bakış açım ciddi biçimde değişti.
Bu, ekibe ve şirkete göre değişir. Geliştiricilerin kod bakımı ve refactor için zaman harcamaya teşvik edildiği, hatta bazen sadece bunu yapmaya zorlandığı; rastgele ürün taleplerinin önüne mühendislik odaklı işlerin konduğu ve işi düzgün bitirmek için takvimlerin de ayarlandığı pek çok ekip gördüm.
S&P 500 büyük şirketlerinden, 100 milyon–1 milyar dolar ölçeğindeki şirketlere ve startup’lara kadar bu deneyim bende oldukça olağandı. Bu tür durumlarda makul ödünler verebilen ve iş ihtiyaçlarını da gözetebilen deneyimli yazılım mühendisleri ve yöneticiler vardı; mühendislerin müşterilerle doğrudan etkileşime girmesi de sık görülüyordu.
Esas mesele denge; bu denge de genellikle dengeli yargıda bulunabilen insanlar sayesinde oluşuyor. Sadece “mükemmeli” kovalarsanız sonu gelmeyen refactor ve hiç yayınlanmayan ürünlere gidersiniz; teknik borcu ya da çöp kaliteyi yok sayarsanız zamanla işiniz çökebilir. Nerede durulacağı ürün, sektör, müşteri ve işe göre değişir.
Ya kahraman olarak ölürsünüz ya da 10 yıllık bir git blame’de kendi adınızı görecek kadar uzun yaşarsınız.
“Çalışıyor ama optimal değil”, zaman az ve yapılacak iş çokken çoğu zaman kabul edilebilir bir ödündür. “Mükemmel, iyinin düşmanıdır” gibi MBA tarzı sloganlar da bir şey eksik kaldığında kullanılabilecek sözlerdir.
2017’de, 2003/2004’te yazdığınız kodu düzeltmeye çağrılmış olmanız, hepimizin zaman yolcusu olduğu anlamına da geliyor. Geçmişteki kendime karşı hoşgörülüyüm, gelecekteki kendime karşı ise biraz kabayım.
Geçmişteki ben genç ve saftı ama üretkendi; çok da yol katetti. Kodu anlamam iki gün sürdü ama nihayetinde oldukça zekiceydi; şu anki benim her şeyi unutmuş olması belki de hafızamın kötü olmasındandır.
Gelecekteki ben bütün yanlışları düzeltecek. Daha yaşlı ve daha bilge; XXX ve TBD’yi akıllı koda çevirmek, iyi fikirleri uygulamak ve vasat fikirleri yeniden uygulamak için sonsuz zamanı olduğuna inanıyorum. Daha iyi yorumlar olursa belki bu üçü bir olur.
Bu kendini haklı gören “o tek kişi” tavrının zararlı olduğunu düşünüyorum. Kıdemli geliştiricilerin yaptıkları hataları ve batırdıkları işleri anlatabilmesi son derece özgürleştirici ve sağlıklı.
Bu sadece bir öğrenme fırsatı değil; aynı zamanda açık bir kültürü gösterir ve impostor sendromuna karşı da etkilidir. Mükemmeliyetçi tavır bunun tam tersine “daha çok çalış ve hata yapma” demekten ibarettir; öğrenilecek bir şey sunmaz, sadece bireysel çabayı artırmayı ister.
En az iki kez “o tek kişi”nin büyük bir hatayı kabul etmediğini; iyi bir müşteriyi kaybetmek pahasına bile bundan kaçındığını ve arkadan konuşmuş olacağını tahmin ediyorum.
Bir defasında, bir junior’ın rapora yanlış yazılım sürümünü koyduğu küçük bir hatayı ben üstlendim. Müşteriye “bir hata oldu, düzeltilmiş rapor burada” demek yeterliyken yöneticim sadece “bunu saklayıp kusursuz olduğumuz imajını koruyabilir miyiz?” diye düşünüyordu. Aynı kişi, başkalarının hatalarını indirim, tazminat ya da ücretsiz hizmet istemek için fırsat olarak kullanıyordu.
Çoğu insanın işini yapıp geliştiğini düşünüyorum. Konfigürasyon yönetimimizde benim yazdığım ve işlevsel olarak gayet iyi çalışan epey şey var; ama araçlarla 1–2 yıl uğraştıktan sonra çeşitli nedenlerle kalitesinin epey kötü olduğunu söylemeye başladım.
Yine de sorun değil. Değiştirmek için bir neden doğarsa toparlarız; o zamana kadar kötü pratiklere ve daha iyi yaklaşımlara örnek olarak duruyorlar.
Kendinizde eleştirecek bir şey bulamıyorsanız gelişmiyorsunuz demektir. Bu tür öz eleştiriyi paylaştığınızda başkaları da benim hatalarımdan öğrenir ve kendi hatalarından öğrenmenin de sorun olmadığını görür.
Kod incelemelerinde sık sık “neden o hatayı yapmasan olmuyor?” ya da “neden sadece şöyle yapmıyorsun?” gibi sözler duyuyorum.
Şimdilerde “Muhtemelen IQ’nuz benimkinden yüksek olduğu içindir. Benim IQ’m düşük, o yüzden daha aptalca ve basit işler yapmam gerekiyor” diye cevap veriyorum. Bazen karşı taraf, ne kadar düşünmeden küçümseyen küçük bir tuhaf gibi davrandığını fark edip kızarıyor.
“Neden sadece … yapmıyorsunuz?” diye başlayan sorulara karşı biraz alerjim var. O üç kelimeyi duyar duymaz genelde arkasından gelecek öneriyi tahmin edebiliyorum; çok karmaşık olduğu için değil, çoğunlukla akla ilk gelen bariz yöntem olduğu ve zaten dikkatlice değerlendirilmiş ya da denenmiş olduğu için.
Sorunun kendisi kötü değil, ama “benim fikrim çok kolay” ve “sen bu açık ve kolay düşünceyi akıl edemedin” varsayımları can sıkıcı ya da aşağılayıcı gelebiliyor. Buna karşılık ben başkalarına sorarken “neden sadece” demekten kaçınmaya çalışıyorum; “X’i yapmamanızın bir nedeni olduğunu mu anlamalıyım?” gibi sormak ya da sadece nazikçe nedenini sormak daha iyi olabilir.
Soru bağlam eksikliğinden kaynaklanıyorsa, yaptığım işi açıklamadan önce en bariz yöntemlerin neden işe yaramadığını ya da zorlayıcı gereksinimleri ve problem girdilerini baştan belirtmek bunu önleyebilir. Kod zaten commit’lenmişse amaç, commit ya da merge request yorumlarıyla sonradan gelen geç kalmış itirazları azaltmaktır. Bazen de karşı çıkmadan o yöntemi denediğimi ama neden işe yaramadığını doğrudan açıklamak ve gerçekten başka fikirleri olup olmadığını sormak da faydalı olur.
Eğer gerçekten benim düşünemediğim ve sorunu çözebilecek bir öneriyse bunun iyi bir fikir olduğunu söyleyip uygulamaya yardım etmelerini isterim. Böyle durumlarda karşı tarafın varsayımına ya da üslubuna karşı çıkma dürtüsü olsa da, kabul edip kısa süreliğine utanmayı seçmeye çalışıyorum.
grug brain’in çok iyi uygulanmış bir örneği: https://grugbrain.dev/
“Karmaşıklıkla mı yoksa bir tiranozorla bire bir dövüşmek mi diye seçmek gerekse, grug tiranozoru seçer. En azından grug tiranozoru görebilir.”
Şaka değilse, ilk soru yardımcı değil ve neredeyse kaba bir davranış. Herkes ara sıra hata yapar.
İkinci soru genelde makul bir geri bildirim olabilir. İnsanların beceri ve bilgi alanları her zaman örtüşmez. A için akıl almaz derecede karmaşık olan bir şey B için öyle olmayabilir; tersi de mümkündür ve bu mutlaka birinin daha zeki olduğu anlamına gelmez. A SQL bilmiyor olabilir, B de pandas bilmiyor olabilir
Teknoloji yığınınızda zaten hem SQL hem de pandas olduğunu varsayarsak, bazı kodları SQL’den pandas’a ya da tersine taşımak mantıklı olabilir. Bazı insanlar nesne yönelimli stili daha kolay bulur, bazıları fonksiyonel stili. Hangisinin daha anlamlı olduğu her zaman apaçık değildir; bu yüzden soru iyi bir soru olabilir. Öneri kötüyse neden kötü olduğunu açıklarsınız; iyiyse şu anda yapmaya değip değmeyeceğini değerlendirirsiniz. Ortadaysa ya da vaktiniz yoksa bunu kabul edip geçebilirsiniz
Diğer seçenek de açıkça katılmaktır. “Evet, aptalcaydı, değil mi?” ya da “Evet, belki de öyle yapmamalıydım”, veya “Bunu düşüneceğim” diye yanıt verebilirsiniz
Böylece karşı tarafın, en iyi olmayan bir şey yaptınız diye sizi utandırması ya da suçlu hissettirmesi zorlaşır. Bu tür sözlerin amacının çoğu zaman utandırarak üstünlük kurmak olduğunu düşünüyorum. Oyuna katılmamayı seçmektir ve genelde kazandıran hamle de budur
Bilgisizlikten söylenmişse, bunu saldırı olarak alıp karşı tarafı utandırarak bedel ödetmeye gerek yok
Daha önce gördüğüm blogu ya da yazıyı bulamıyorum ama mesajı şuydu: “Kodda en iyi olmayan bir şey gördünüz diye yetersizlik varsaymayın.” O kodu yazan kişinin sıkışık teslim tarihi, başka öncelikler veya başka etkenler nedeniyle hemen “doğru şeyi” yapamamasının bir nedeni olabilir
Yazıldığı anda kod mükemmel olsa bile kod tabanının büyümesi ve gereksinimlerin değişmesi onu kötü hâle getirebilir
Örneğin saklanacak 10 öğe varsa basit bir dosya pratik bir seçim olabilir; ama 10.000’e çıktığında bir veritabanına ihtiyaç duyulabilir. Oysa en baştan 10 öğe için veritabanı kullansaydı, aşırı mühendislik diye şikâyet ederdiniz
2 sınıf varsa if/else yeterli olabilir; 20 sınıf olduğunda Factory deseni gerekebilir, ama en baştan yapılsaydı mimari astronotluk gibi görünürdü. Bu büyümeyi tahmin etmeye çalışıp yanılırsanız karmaşık kod üretirsiniz. Sürekli geliştirilen projeler sistematik olarak kendi boylarını aşar
Chesterton’ın çiti de var. Koddaki aptalca görünen bir şey geçmişte gerçekten önemli olmuş olabilir. Daha kötüsü, bugün de nadir bir uç durum için önemli olabilir ama siz henüz nedenini görmüyor olabilirsiniz
Blog yazıları hakkında burada ve reddit’te birkaç kez kötü niyetli yorum aldım. Böyle olduğunda, yargılamadan o kötü niyetli yoruma giden bağlantıyı yazıya ekleyerek ışık tutma yöntemini kullanıyorum. Genelde hiçbir şey olmuyor ama bazen tartışmayı daha sağlıklı bir yöne çeviriyor
Ben de epey aldım. Bazıları muhtemelen hak edilmişti ama çoğu büyük olasılıkla değildi. Bazıları bir ölçüde doğruydu ama yardımcı değildi ya da topluluğa doğrudan zarar veriyordu. Doğru şeyi yanlış biçimde söylerseniz hâlâ yanlış bir şey söylüyorsunuz demektir
Kötü niyetli yorumları yargılamadan bağlantılamak kötü bir fikir değil. Yorum öldürülmüşse bu her zaman mümkün olmuyor ama her hâlükârda aynı yöntemle karşılık vermiyorum. Ben de yapabilirim ama benzinin etkili bir yangın söndürücü olmadığını öğrendim
Hatalıysam, o hatanın bulunduğu aynı yerde hemen kabul etmeye çalışırım. Açık saldırının ardından gelen özel özürlerden özellikle hoşlanmam
Bir çizgi var. Oldukça iyi işler yaptığımı düşünüyorum; bunu yaklaşık 40 yıldır uzun süredir yapıyorum ve bu süreçte çok şey öğrendim. Düşük kaliteli işi kabul etmeyen titiz ortamlarda da çalıştım, bu yüzden düzgün iş çıkarmak alışkanlık hâline geldi
Genel olarak başkalarını kamuya açık biçimde yargılamaktan kaçınırım. Yardımcı olmaz ve ben de her zaman haklı değilim. Ancak birlikte çalışıyorsak ya da onun ürettiği şeyi kullanıyorsam durum farklı olabilir. Çöpü kabul etmediğim için sert biçimde saldırıya uğradığım da oldu ama Linus Torvalds gibi davranmam. Mümkünse saygılı bir şekilde, o işin benim için kabul edilebilir olmadığını söylerim
Yine de her zaman gelişebilir ve yeni şeyler öğrenebiliriz; bazen hiç beklemediğimiz yerlerden öğreniriz. Böyle öğrenmelere açık olmak temelde iyi bir politikadır. Yanılarak ve öğrenerek doğruya ulaşırım. “İyi muhakeme deneyimden gelir, deneyim de kötü muhakemeden”
Sevdiğim podcast’lerden biri olan YouTube’daki well there's your problem, podcast’ten şikâyet eden yorumları neredeyse her zaman sabitler. Genelde “Bu podcast’i sevmiyorum, başka bir podcast olmalı” düzeyinde şikâyetlerdir; sabitlenen yorum da her seferinde o bölüm için mümkün olan en aptalca yoruma yakın olur
Bunun bu tür yorumları azaltmada işe yarayıp yaramadığını bilmiyorum ama söyleme bu şekilde katılan kişiye mecazi bir aptal şapkası takmak gibi bir anlamı var
Bazı mühendislerin kötü bir tutuma sahip olduğu konusunda hemfikirim. Herkes kötü kod yazabilir; tüm kodların kötü ve borç olduğu argümanında da bir doğruluk payı var
Bu yazı “No more pink mustache” ile birlikte okununca ilginç oluyor. O yazıda Lyft “inanılması güç ölçekte bozuk” olarak tanımlanıyor; kalitenin nedeni çoğu zaman sandalyede oturan kişi değil, organizasyondur :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Bu yazıyı 2018’de okumuştum; yeniden gündeme gelmesine sevindim. Bana soru sorduran yazılardan biriydi. Mutlakçılığı ya da uçlara savrulmayı ortadan kaldıramıyorsak, bu tür konuşmalarla ya da insanlarla karşılaştığımızda nasıl bir filtre oluşturabiliriz diye düşündürüyor. Benim bir modelim var ama başkalarının hangi stratejileri kullandığını merak ediyorum
Bu tür insanlar kendilerine ait olmayan duygusal alanı işgal etmeye çalışır. Genelde bunu “yapabileceklerini” önceden hesaplamışlardır; bu da karşı tarafı zayıf gördükleri anlamına gelir
Üç seçenek var. Vazgeçip o alanı vermek ve hayatınıza devam etmek; haksızlık yüzünden ne kadar az uykunuz kaçarsa o kadar iyi. Doğrudan karşı koymak; bunlar kavga etmeye hazırdır ama pozisyonları özünde irrasyonel olduğu için onların düşünce alanına ne kadar az çekilirseniz o kadar “kazanırsınız”. Yukarıdan yaklaşmak; onların haksız olduğunu gösteren toplumsal kanıtı kendi alanlarına taşımaktır. Orijinal yazıdaki durumda bu, birbirinin işine saygı duyan, kusur aramayan üretken programcılara karşılık gelir
Birisi “Böyle yapsaydın daha iyi olabilirdi” diye tavsiye verdiğinde, bu her zaman bana yönelik bir saldırı ya da yeteneğime hakaret değildir
Tavsiyeyi veren kişi sosyal ilişkilerde beceriksiz bir aptal olabilir ya da düpedüz aptal olabilir. Dünyanın bir kısmının benimle aynı fikirde olmaması sorun değil. İnsanların karşı görüş belirtmesi ya da aynı fikirde olmaması beni tehdit ettikleri anlamına gelmez
Tuhaf bir yazı. Tweet gibi geliyor, içeriği az ve başlık metni yansıtmadığı için clickbait gibi görünüyor
Ana fikrine karşı değilim ama işin bir de diğer tarafı var. Geri bildirimi kabul edebilme becerisi de gerekiyor
Çoğu insan geri bildirimi kabul edip uygulayabilir. Ancak bazı insanlar geri bildirimi berbat biçimde verip karşı tarafın geri bildirimi kaldıramadığını düşünür.
Bu kişiler, kendi tercih ettikleri geri bildirim biçiminin en iyisi olduğunu, herkesin de aynı hissetmesi gerektiğini; aksi halde değişmesi gerekenin karşı taraf olduğunu düşünür. Elbette yanılıyorlar. Ama bunu onlara söylediğinizde, ilk cümlede neden “çoğu” dediğimi bizzat göstermiş olurlar
1 yorum
Hacker News yorumları
Tek başınaysanız gerekli işi önceliklendirebilirsiniz, ama ekipte ikinci en iyi kararlar sonsuza kadar kalır ya da “sistem çöktü” anına kadar bekletilir. Sonrasında postmortem’de, aylar önce bu bombayı düzeltmeyi istediğiniz ticket’ı gösterdiğinizde bu “suçlama” ya da “saldırganlık” olarak algılandı; sonuçta çözüm, sanki asla ikinci en iyi kod yazmamakmış gibi oldu ve kod yazarken hayal kırıklığı ile kaygı arttı.
2017’de, 2003/2004’te yazdığım kodu düzeltmem için de benimle iletişime geçildi; o kod hâlâ production’da çalışıyordu. Bozuk kodu ve yaptığım tavizleri yeniden görüp sorumlusunun bizzat ben olduğumu fark etmek epey alçakgönüllü kılan bir deneyim; bundan sonra bakımı yapılabilir kod ve dokümantasyon konusundaki bakış açım ciddi biçimde değişti.
S&P 500 büyük şirketlerinden, 100 milyon–1 milyar dolar ölçeğindeki şirketlere ve startup’lara kadar bu deneyim bende oldukça olağandı. Bu tür durumlarda makul ödünler verebilen ve iş ihtiyaçlarını da gözetebilen deneyimli yazılım mühendisleri ve yöneticiler vardı; mühendislerin müşterilerle doğrudan etkileşime girmesi de sık görülüyordu.
Esas mesele denge; bu denge de genellikle dengeli yargıda bulunabilen insanlar sayesinde oluşuyor. Sadece “mükemmeli” kovalarsanız sonu gelmeyen refactor ve hiç yayınlanmayan ürünlere gidersiniz; teknik borcu ya da çöp kaliteyi yok sayarsanız zamanla işiniz çökebilir. Nerede durulacağı ürün, sektör, müşteri ve işe göre değişir.
Geçmişteki ben genç ve saftı ama üretkendi; çok da yol katetti. Kodu anlamam iki gün sürdü ama nihayetinde oldukça zekiceydi; şu anki benim her şeyi unutmuş olması belki de hafızamın kötü olmasındandır.
Gelecekteki ben bütün yanlışları düzeltecek. Daha yaşlı ve daha bilge; XXX ve TBD’yi akıllı koda çevirmek, iyi fikirleri uygulamak ve vasat fikirleri yeniden uygulamak için sonsuz zamanı olduğuna inanıyorum. Daha iyi yorumlar olursa belki bu üçü bir olur.
Bu sadece bir öğrenme fırsatı değil; aynı zamanda açık bir kültürü gösterir ve impostor sendromuna karşı da etkilidir. Mükemmeliyetçi tavır bunun tam tersine “daha çok çalış ve hata yapma” demekten ibarettir; öğrenilecek bir şey sunmaz, sadece bireysel çabayı artırmayı ister.
Bir defasında, bir junior’ın rapora yanlış yazılım sürümünü koyduğu küçük bir hatayı ben üstlendim. Müşteriye “bir hata oldu, düzeltilmiş rapor burada” demek yeterliyken yöneticim sadece “bunu saklayıp kusursuz olduğumuz imajını koruyabilir miyiz?” diye düşünüyordu. Aynı kişi, başkalarının hatalarını indirim, tazminat ya da ücretsiz hizmet istemek için fırsat olarak kullanıyordu.
Yine de sorun değil. Değiştirmek için bir neden doğarsa toparlarız; o zamana kadar kötü pratiklere ve daha iyi yaklaşımlara örnek olarak duruyorlar.
Şimdilerde “Muhtemelen IQ’nuz benimkinden yüksek olduğu içindir. Benim IQ’m düşük, o yüzden daha aptalca ve basit işler yapmam gerekiyor” diye cevap veriyorum. Bazen karşı taraf, ne kadar düşünmeden küçümseyen küçük bir tuhaf gibi davrandığını fark edip kızarıyor.
Sorunun kendisi kötü değil, ama “benim fikrim çok kolay” ve “sen bu açık ve kolay düşünceyi akıl edemedin” varsayımları can sıkıcı ya da aşağılayıcı gelebiliyor. Buna karşılık ben başkalarına sorarken “neden sadece” demekten kaçınmaya çalışıyorum; “X’i yapmamanızın bir nedeni olduğunu mu anlamalıyım?” gibi sormak ya da sadece nazikçe nedenini sormak daha iyi olabilir.
Soru bağlam eksikliğinden kaynaklanıyorsa, yaptığım işi açıklamadan önce en bariz yöntemlerin neden işe yaramadığını ya da zorlayıcı gereksinimleri ve problem girdilerini baştan belirtmek bunu önleyebilir. Kod zaten commit’lenmişse amaç, commit ya da merge request yorumlarıyla sonradan gelen geç kalmış itirazları azaltmaktır. Bazen de karşı çıkmadan o yöntemi denediğimi ama neden işe yaramadığını doğrudan açıklamak ve gerçekten başka fikirleri olup olmadığını sormak da faydalı olur.
Eğer gerçekten benim düşünemediğim ve sorunu çözebilecek bir öneriyse bunun iyi bir fikir olduğunu söyleyip uygulamaya yardım etmelerini isterim. Böyle durumlarda karşı tarafın varsayımına ya da üslubuna karşı çıkma dürtüsü olsa da, kabul edip kısa süreliğine utanmayı seçmeye çalışıyorum.
“Karmaşıklıkla mı yoksa bir tiranozorla bire bir dövüşmek mi diye seçmek gerekse, grug tiranozoru seçer. En azından grug tiranozoru görebilir.”
İkinci soru genelde makul bir geri bildirim olabilir. İnsanların beceri ve bilgi alanları her zaman örtüşmez. A için akıl almaz derecede karmaşık olan bir şey B için öyle olmayabilir; tersi de mümkündür ve bu mutlaka birinin daha zeki olduğu anlamına gelmez. A SQL bilmiyor olabilir, B de pandas bilmiyor olabilir
Teknoloji yığınınızda zaten hem SQL hem de pandas olduğunu varsayarsak, bazı kodları SQL’den pandas’a ya da tersine taşımak mantıklı olabilir. Bazı insanlar nesne yönelimli stili daha kolay bulur, bazıları fonksiyonel stili. Hangisinin daha anlamlı olduğu her zaman apaçık değildir; bu yüzden soru iyi bir soru olabilir. Öneri kötüyse neden kötü olduğunu açıklarsınız; iyiyse şu anda yapmaya değip değmeyeceğini değerlendirirsiniz. Ortadaysa ya da vaktiniz yoksa bunu kabul edip geçebilirsiniz
Böylece karşı tarafın, en iyi olmayan bir şey yaptınız diye sizi utandırması ya da suçlu hissettirmesi zorlaşır. Bu tür sözlerin amacının çoğu zaman utandırarak üstünlük kurmak olduğunu düşünüyorum. Oyuna katılmamayı seçmektir ve genelde kazandıran hamle de budur
Örneğin saklanacak 10 öğe varsa basit bir dosya pratik bir seçim olabilir; ama 10.000’e çıktığında bir veritabanına ihtiyaç duyulabilir. Oysa en baştan 10 öğe için veritabanı kullansaydı, aşırı mühendislik diye şikâyet ederdiniz
2 sınıf varsa if/else yeterli olabilir; 20 sınıf olduğunda Factory deseni gerekebilir, ama en baştan yapılsaydı mimari astronotluk gibi görünürdü. Bu büyümeyi tahmin etmeye çalışıp yanılırsanız karmaşık kod üretirsiniz. Sürekli geliştirilen projeler sistematik olarak kendi boylarını aşar
Kötü niyetli yorumları yargılamadan bağlantılamak kötü bir fikir değil. Yorum öldürülmüşse bu her zaman mümkün olmuyor ama her hâlükârda aynı yöntemle karşılık vermiyorum. Ben de yapabilirim ama benzinin etkili bir yangın söndürücü olmadığını öğrendim
Hatalıysam, o hatanın bulunduğu aynı yerde hemen kabul etmeye çalışırım. Açık saldırının ardından gelen özel özürlerden özellikle hoşlanmam
Bir çizgi var. Oldukça iyi işler yaptığımı düşünüyorum; bunu yaklaşık 40 yıldır uzun süredir yapıyorum ve bu süreçte çok şey öğrendim. Düşük kaliteli işi kabul etmeyen titiz ortamlarda da çalıştım, bu yüzden düzgün iş çıkarmak alışkanlık hâline geldi
Genel olarak başkalarını kamuya açık biçimde yargılamaktan kaçınırım. Yardımcı olmaz ve ben de her zaman haklı değilim. Ancak birlikte çalışıyorsak ya da onun ürettiği şeyi kullanıyorsam durum farklı olabilir. Çöpü kabul etmediğim için sert biçimde saldırıya uğradığım da oldu ama Linus Torvalds gibi davranmam. Mümkünse saygılı bir şekilde, o işin benim için kabul edilebilir olmadığını söylerim
Yine de her zaman gelişebilir ve yeni şeyler öğrenebiliriz; bazen hiç beklemediğimiz yerlerden öğreniriz. Böyle öğrenmelere açık olmak temelde iyi bir politikadır. Yanılarak ve öğrenerek doğruya ulaşırım. “İyi muhakeme deneyimden gelir, deneyim de kötü muhakemeden”
Bunun bu tür yorumları azaltmada işe yarayıp yaramadığını bilmiyorum ama söyleme bu şekilde katılan kişiye mecazi bir aptal şapkası takmak gibi bir anlamı var
Bu yazı “No more pink mustache” ile birlikte okununca ilginç oluyor. O yazıda Lyft “inanılması güç ölçekte bozuk” olarak tanımlanıyor; kalitenin nedeni çoğu zaman sandalyede oturan kişi değil, organizasyondur :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Üç seçenek var. Vazgeçip o alanı vermek ve hayatınıza devam etmek; haksızlık yüzünden ne kadar az uykunuz kaçarsa o kadar iyi. Doğrudan karşı koymak; bunlar kavga etmeye hazırdır ama pozisyonları özünde irrasyonel olduğu için onların düşünce alanına ne kadar az çekilirseniz o kadar “kazanırsınız”. Yukarıdan yaklaşmak; onların haksız olduğunu gösteren toplumsal kanıtı kendi alanlarına taşımaktır. Orijinal yazıdaki durumda bu, birbirinin işine saygı duyan, kusur aramayan üretken programcılara karşılık gelir
Tavsiyeyi veren kişi sosyal ilişkilerde beceriksiz bir aptal olabilir ya da düpedüz aptal olabilir. Dünyanın bir kısmının benimle aynı fikirde olmaması sorun değil. İnsanların karşı görüş belirtmesi ya da aynı fikirde olmaması beni tehdit ettikleri anlamına gelmez
Bu kişiler, kendi tercih ettikleri geri bildirim biçiminin en iyisi olduğunu, herkesin de aynı hissetmesi gerektiğini; aksi halde değişmesi gerekenin karşı taraf olduğunu düşünür. Elbette yanılıyorlar. Ama bunu onlara söylediğinizde, ilk cümlede neden “çoğu” dediğimi bizzat göstermiş olurlar