- Aylar boyunca korku yüzünden yazmayı ve çevrimiçi etkinliklerini durdurmuş bir geliştirici, öz sansürü bırakıp bugüne kadar kabullenemediği teknik ve kişisel eksiklerini itiraf ediyor
- Polimorfizm (polymorphism) kavramını 10 yıldan uzun süre anlayamadığını, SQL becerilerini kaybettiğini ve kodlarının büyük bölümünü otomatik test olmadan yayına aldığını kabul ediyor
- Şirketin teknoloji yığını değişimine ayak uydurmaya çalışırken C# ve Blazor öğrenimini yarıda bırakması, hâlâ Ruby’yi sevmesine rağmen onu profesyonel olarak kullanamaması ve yöneticileriyle ekip arkadaşlarının blogunu okumasının yarattığı psikolojik baskı
- Yapay zeka ile yazılmış bir PR gönderdikten sonra siber zorbalığa uğrama deneyimi, uzaktan çalışmaya dair dürüst duyguları ve kurum içindeki özel geliştirme süreçlerinin gereksizliği hakkında açık görüşleri
- Korkuyu geride bırakıp artık öz sansür uygulamadan sürekli öğrenmeyi ve açıkça yazmayı sürdüreceğine dair bir kararlılıkla bitiyor
Başlangıç: Korkuyu ve öz sansürü bırakmaya karar vermeme ne sebep oldu
- Nisan’dan sonra korkunun çok büyüdüğü ve yazı yayımlayamadığım bir dönem oldu; sosyal medya, haber toplayıcılar ve forumların hepsini bırakmıştım
- Bu hâli daha fazla sürdüremeyeceğimi hissedip korkunun ötesine geçerek yeniden yazmaya karar verdim
- Zayıf temellerimi göstermek istemediğim için bunları sıkıca sakladım, ama aslında birçok geliştiricinin benzer bilgi boşluklarıyla çalıştığını görmeye başladım
- O güne kadarki öğrenme biçimim, yalnızca kullanılan alanın aşırı büyüdüğü bir slime mold gibiydi; kullanılmayan bilgi ise olduğu yerde kuruyup kalmıştı
- Son dönemde temelleri yeniden doldurmaya başladım ve öğrendiklerimi yazarak, anlatarak yeniden kurarken “bilmiyorum” demeyi hafifçe kabullenme hissi yerleşmeye başladı
- Temellerin yeniden öğrenilebileceğini bizzat hissedince, artık geç kalmış sayılmayacağına dair bir güven oluştu
Polimorfizmi 10 yıldan uzun süre anlayamadığım dönem
- 2012’den beri nesne yönelimli kod yazdığımı sanıyordum, ama yakın zamana, hatta yaklaşık bir yıl öncesine kadar polimorfizmi gerçekten anlamadığımı kendi kendime kabul ettim
- Şimdiye kadar yazdığım kodun nesne yönelimliden çok yapısal programlamaya daha yakın olduğu gerçeğiyle yüzleştim
- Koşul ifadelerini sınıflarla değiştirerek tasarımı dönüştürme fikrini daha önce hiç düşünmemiştim
- Sandi Metz’in yazılarını ve Martin Fowler’ın kaynaklarını okuyunca kavramı geç de olsa anladım; bu süreçte kaçırdığım şeylerin ne kadar çok olduğu da netleşti
-
Bunu açığa vurmanın zor olmasının nedeni
- İşe alım mülakatlarında nesne yönelimli kavramları değerlendiren kişi rolünü üstlenmiş birinin aslında polimorfizmi bilmediğini ortaya koyması çok ağır geliyordu
- Kariyerimin başında ilkelerden çok araç odaklı öğrenmeye kaymış olmam doğrudan görünür hâle geliyordu; ayrıca CS mezunu olmamam nedeniyle kaçırdığım temel konuların çokluğu ile yüzleşmek kolay değildi
SQL’i unutma deneyimi
- Geçmişte SQL kitaplarındaki alıştırmaları çözerek JOIN ve alt sorguları rahatça yazabildiğim bir dönem gerçekten vardı
- Ön uç ağırlıklı işlerin sürmesi ve SQL kullanma ihtiyacının tamamen ortadan kalkmasıyla, bir noktada bütün bir becerinin zihnimden silinmiş olduğunu fark ettim
- Temel sorgular aklıma geliyor ama left join ile outer join arasındaki farkı açıklamak için yeniden dokümantasyona bakmam gereken bir duruma gelmiştim
-
Bunu kabul etmenin zor olmasının nedeni
- Gençken, yıllar geçse bile bilgi ve becerilerin küçük bir ipucuyla yeniden canlanabileceğine dair bir hafıza gücüne sahip olduğuma inanıyordum
- Artık bunun aynı şekilde sürmediğini hissediyorum; üstelik hafızamdan ilk tamamen silinen becerinin SQL olması bana özellikle çarpıcı geldi
- Yaş almayı ve belleğin değişen akışını kamusal olarak yazmak kolay değildi
Otomatik test olmadan geliştirmiş olmanın gerçeği
- Şimdiye kadar yayına alınmış kodlarımın %95’ten fazlasının otomatik test olmadan çalıştığını kendime itiraf ettim
- Kariyerimin başlarında test kavramıyla hiç karşılaşmamıştım; Ember döneminde de test araçlarını düzgün kullanmak zordu
- Son zamanlarda daha çok legacy kodla uğraştığım için kodu test edilebilir hâle getirecek hazırlık işlerine yeterince zaman ayıramadım
- Yalnızca yeni oluşturulan alt sistemlerde teste yer verebildim
-
Bunu açığa vurmanın zor olmasının nedeni
- Bu itiraf, kariyerim açısından en yıkıcı gerçek gibi hissettirecek kadar ağırdı
- Uncle Bob’un ölçütlerine göre test olmadan çalışan kod, etik dışı sayılabilecek bir tutum olarak görülebilir; bu ölçüt ile kendi gerçeğim arasındaki farkla yüzleşmek korkutucuydu
- Bunun ortaya çıkmasının işe alım süreçlerinde aleyhime yorumlanma ihtimalini büyüttüğünü düşündüğüm için öğrenme sürecimi kaydetmeyi bile erteledim
Blazor’u neden öğrenemedim
- Şirket Angular’dan Blazor’a geçmeye karar verdiğinde, ekipte C# deneyimi olmayan tek kişi bendim; bu yüzden hızla yetişmek için çalışmaya başlamıştım
- Birkaç ay sonra geçiş kararı geri çekilince, öğrenme motivasyonum tamamen kayboldu; kitabı da bitiremeden bıraktım
- Zaten C# ya da .NET, yan projelerimde kullanmak istediğim diller değildi; bunu yalnızca iş için öğrendiğim gerçeği de açıkça ortaya çıktı
-
Bunu yazmanın zor olmasının nedeni
- Önceki bir yazıda devam yazısı yazacağıma açıkça söz vermiştim; o sözü tutamadan başka şeyler yazmak gittikçe daha rahatsız edici gelmeye başladı
- Blazor hakkındaki yazı yüksek görüntülenme aldığı için, yön değiştirdiğimi kabul etmenin bir yenilgi gibi görüneceğinden korktum
Ruby’yi daha çok kullanma isteği
- Ruby hâlâ benim için en rahat ve en keyifli dil; örneklerde, open source’ta, kata’larda ve hackathon’larda elim doğal olarak ona gidiyor
- Ancak 2013’ten beri Ruby ile maaş aldığım tek bir iş bile olmadı; işte ise TypeScript gibi diller kullanıyorum
- Birlikte çalıştığım insanları birçok şirkette çok sevdiğim için, insanları seçerken dili taviz konusu yapmak zorunda kaldım
- Mesai sonrası ve hafta sonu vaktimi Ruby’ye ayırmak istiyorum, ama başka sorumluluklar ve öğrenme hedefleri yüzünden Ruby’ye yeterince zaman ayırabildiğim anlar çok az
-
Bunu açıklamanın zor olmasının nedeni
- Müdürüm ve CTO bu blogu okuyor; Ruby’yi daha çok kullanmak istediğimi söylemenin işten ayrılma sinyali gibi okunmasından korkuyordum
- Şirkette alışılmadık bir dili zorla dayatmaya çalışan biri gibi görünmek de istemiyordum
Yetişkin olunca da can yakan siber zorbalık deneyimi
- Bir open source projeye LLM ile hazırlanmış küçük bir yama gönderdikten ve bu deneyimi çevrimiçi bir forumda paylaştıktan sonra,
yetersiz, iğrenç, tehditkâr gibi kişisel saldırıların patlama hâlinde üzerime geldiği bir durum yaşadım
- Bu saldırılar siteyi aşarak başka web sitelerine, e-postaya, SMS’e ve telefona kadar uzandı; gerçekten güvende olmadığımı hissettim
- Forum yöneticilerinden gerçek adımı kaldırmalarını istedim ama bunun yerine profilime daha fazla PII eklendi ve
dışarıdan gelen iletişimlerle ilgili yalan uydurduğuma dair asılsız bir ifade kalıcı biçimde profilime işlendi
- Sonunda hesabımı devre dışı bırakıp siteden ayrılmaktan başka çarem kalmadı
-
Bunu yazmanın zor olmasının nedeni
- Günlerce süren bu zorbalık, hayatımda yaşadığım en zehirli çevrimiçi deneyimdi ve etkisi hâlâ sürüyor
- Bunu anlatırsam saldırganların yeniden beni bulabileceğine dair korku devam ediyor
- Profilimde kalan yanlış bilgilerin istihdamımı olumsuz etkileyebileceği ihtimali de konuşmayı daha da zorlaştırdı
SaaS ekiplerinin ‘özel süreçlere’ ihtiyacı olmadığını düşünmem
- Yazılım sektöründe onlarca yıl içinde rafine edilmiş süreçler zaten var;
Agile, Lean, Kanban ve XP gibi yaklaşımlar zaten doğrulanmış yapılar olarak mevcut
- Şirketin sınırlı kapasitesini yeni süreç icat etmeye değil ürün geliştirmeye odaklaması gerektiği düşüncesi bende doğal biçimde yer etti
-
Bunu söylemenin zor olmasının nedeni
- Yazarken her zaman iyi bildiğim konulara dayanma alışkanlığım var ve bu durumda çıkış noktası, aynı şirketteki bir çalışma arkadaşının önerdiği özel bir yazılım geliştirme süreci olmuştu
- Bunun belirli bir çalışma arkadaşını ya da onun fikrini kamu önünde eleştiriyormuş gibi görünme riski taşıdığını hissettim
- Kent Beck ve Martin Fowler gibi isimlerin, daha iyi işbirliği yollarını anlatırken aynı anda hata yapan iş arkadaşlarını doğrudan hedef almayan yazı yazabilme becerisine hayranım
- Benimse henüz o dengeyi kuracak kadar iyi olmadığımı düşündüğüm için yazmakta tereddüt ettim
Uzaktan çalışmanın gerçek işbirliğini engelleme biçimi
- Uzaktan çalışma birçok sorunu çözüyor ama yazılım geliştirmenin bizzat aynı fiziksel ortamda daha iyi aktığı hissini üzerimden atamıyorum
- Görüntülü görüşmeler düşük bant genişlikli, düşük duyusal iletişim biçimleri; çevresel farkındalık kaybolduğu için ekip arkadaşlarının zorlandığı anları yakalamak zorlaşıyor
- Yardım istemek de daha büyük bir yük hâline geliyor; beyaz tahta ve yapışkan notlar gibi mekânsal düşünme araçları çevrimiçi araçlarda kolayca dağılıyor
- Çatışmalar, monitördeki insana düşman imgesi yüklemenin kolay olması nedeniyle daha hızlı tırmanıyor
-
Bunu yazmanın zor olmasının nedeni
- Pandemiden sonra şirket tamamen uzaktan çalışan bir yapıya dönüştü ve bu sayede 27 dönümlük araziye ve aile için süt ineğine kadar uzanan bir hayat kurabildim
- Şehre taşınmayı zorlaştıran bir yaşam düzeni oluştuğu için, uzaktan çalışmayı tercih etmediğimi söylemek
hem mevcut işimde hem de gelecekte başvurabileceğim tüm uzaktan işlerde aleyhime izlenim yaratacakmış gibi geldi
Bundan sonraki plan
- Bu yazıyla birlikte korkunun ötesine geçmek için ilk adımı yeniden attığımı hissediyorum;
bundan sonra da temel bilgileri öğrenmeyi sürdürecek ve öğrendiğim her şeyi saklamadan yazacağım
- Benzer deneyimler yaşamış olanlara, yardımcı olmak isteyenlere ya da sonraki yazıları merak edenlere
Mastodon, RSS ve e-posta listesi üzerinden haberleri takip edebileceklerini söylüyor
Henüz yorum yok.