Codefiction Podcast

709 - Overengineering: Kodu Altın Kaplamak mı, Ürünü Hizlandırmak mı?

Bu bölümde ekibin tamamı “overengineering” dertlerine odaklanıyor. • Overengineering nedir? Golden-plating, premature optimization ve “her soruna mikroservis” refleksinin köklerini arıyoruz.• MVP vs. POC vs. uzun vadeli mimari. Bir teknolojiyi “denemek için” mi, gerçekten ihtiyaç olduğu için mi kullanıyoruz?• Ölçek, maliyet ve vizyon. 100 kullanıcıya hizmet veren bir sistemi event driven mimariye taşıma senaryosu neden çoğu zaman boşa efor?• ADR, OKR’ler ve pragmatizm. Overengineering’i sürecin başında yakalamak ve ekipçe “yeterince iyi”de uzlaşmak için kullanabileceğimiz araçlar.• Kodu çöpe atmak korkulacak şey mi? Refactor etmek mi, yeniden yazmak mı? “Trabzon hurması gibi legacy” örnekleriyle tartışıyoruz. Junior’dan senior’a herkesin içindeki “Şuraya da bir queue atsak mı?” sesini susturmak bazen zor. Bu kayıtta, hem tatminsizliğin hem merakın projeleri nasıl karmaşıklaştırdığını masaya yatırıyor; ürünün, ekibin ve şirketin gerçeklerine uygun “optimum” çözüme nasıl yaklaşıldığını konuşuyoruz. Katılımcılar;Fırat ÖzbolatDeniz İrginMert SusurDeniz ÖzgenBarış ÖzaydınOnur Aykaç

708 - Bilişsel Yük (Cognitive Load) ve İş Hayatındaki Etkileri

Bu bölümde ekiplerin ve bireylerin omuzlarındaki “bilişsel yük” kavramını masaya yatırıyoruz. Codefiction ekibi, context-switching’in verimliliği nasıl düşürdüğünü, ölçek büyüdükçe teknoloji setinin çeşitlenmesinin ve sorumlulukların yayılmasının geliştiricinin zihinsel kapasitesini nasıl zorladığını örneklerle anlatıyor. Front-end’den veri tabanına, CI/CD pipeline'larına insan-kaynakları işlemlerine kadar uzanan dağınık görevlerin, doğru kurgulanmamış süreçler ve eksik dokümantasyonla birleşince ne kadar görünmez bir “yavaşlatıcı”ya dönüştüğü açıklanıyor. İkinci kısımda bilişsel yükün hem ekip çıktısını hem de çalışan sağlığını (burn-out riskini) nasıl etkilediği tartışılıyor; Team Topologies, Developer Experience ekipleri, “discovery” time-box’ları, standardize teknoloji seçimleri, net domain sınırları ve iyi yazılmış dokümantasyon gibi çözümler tartışılıyor. Teknik borcun ve sürekli toplantı trafiğinin yaratabileceği gizli maliyetlere değinilirken, yöneticilerin olduğu kadar ekip üyelerinin de yükü ölçme-dile-getirme sorumluluğu vurgulanıyor. Bölüm, “her şeyi yapmaya çalışmak yerine önceliklendirmek, sınırlar koymak ve odaklanmak” çağrısıyla kapanıyor. Katılımcılar;Fırat ÖzbolatDeniz İrginMert SusurDeniz ÖzgenBarış ÖzaydınOnur Aykaç

707 - Otonomi Verilmez Alınır!

Bu bölümde “otonom takım” kavramını masaya yatırıyor, “empowered” ekipler ile otonom ekipler arasındaki farkları tartışıyoruz. Bir takımın kendi kararlarını alabilmesi için hangi yetkinliklere ve süreçlere ihtiyaç duyduğunu, şirket kültürünün ve liderliğin bu süreçteki rolünü ele alıyoruz. Ayrıca, otonomi sağlayan (veya sağlamayan) kurumların hangi motivasyonlarla hareket ettiğini, büyük işten çıkarmaların ekiplerin risk alma iştahını ve güven duygusunu nasıl etkilediğini inceliyoruz. Takımın içindeki işbirliği, teknik karar süreçleri, liderlik ve kurumsal iletişim boyutlarıyla otonomiye bütüncül bir bakış sunuyoruz. Otonominin “her kararı dilediğince almak” olmadığını, sağlam bir yönetişim ve ortak anlayışla birleştiğinde gerçek değer yarattığını pratik örnekler üzerinden anlatırken, “otonomi verilmez, alınır” söyleminin ne anlama geldiğini somutlaştırmaya çalışıyoruz. Katılımcılar; Uğur Atar Mert Susur Deniz İrgin Onur Aykaç Deniz Özgen Fırat Özbolat Barış Özaydın

706 - Ürün geliştiriciler için şirket içi politika rehberi

Bu bölümde, yazılım ekiplerinde “politika” kavramının neden kaçınılmaz olduğunu ve iyi niyetli diplomasiyle toksik davranışlar arasındaki farkı tartışıyoruz. Şirket hedeflerine ulaşırken teknik borcun önceliklendirilmesi, ekipler arası iletişimin sağlanması ve “dedikodu” gibi negatif politikaların önüne geçilmesi için nelere dikkat edilmesi gerektiğini somut örneklerle ele alıyoruz. Ayrıca, doğru yönetilen bir politikayla hem ürün geliştirme süreçlerinde nasıl hız kazanabileceğinizi hem de ekip uyumunu nasıl koruyabileceğinizi inceliyoruz. RFC (Request for Comments) gibi yaklaşımlarla şeffaf karar alma kültürünü güçlendirmenin önemini vurgulayarak, yöneticilerin sorumluluğu ve bireysel kariyer gelişimi için en etkili politika ipuçlarını paylaşıyoruz.

705-Yöneticinin iyi veya kötü olduğunu anlamak

Şüphesiz yöneticilerimizin kariyerimize iyi veya kötü anlamda katkıları büyük. İyi bir yönetici bize huzurlu bir çalışma ortamının sağlanması, gelişimimiz ve büyümemize katkı sağlarken, kötü bir yönetici kariyerimizi olumsuz anlamda etkileyebilir. Bu yayında yöneticilerinizi daha iyi tanımanıza ve anlamanıza yardımcı olacak püf noktaları tartışık.