Kariyerimin en pahalı hataları, bir kod satırı veya bir sistem mimarisi tercihi değildi. Genellikle, en büyük bedelleri, içimden “hayır” demek gelirken “evet” dediğim anlarda ödedim. Bu durum, sadece iş yükü değil, aynı zamanda öğrenme eğrisi, kişisel gelişim ve hatta mental sağlık üzerinde ciddi etkiler yarattı.
Bugün geriye dönüp baktığımda, genç Mustafa’ya söylemek istediğim çok şey var. Bunlar, ne bir programlama dilinin detayları ne de bir network protokolünün incelikleri; bunlar daha çok “nasıl çalışmalı” ve “nasıl bir mühendis olmalı” üzerine düşündüğüm, saha tecrübesiyle şekillenmiş dersler.
”Hayır” Demenin Gücü ve Bedeli Nedir?
Bir junior olarak, önüme gelen her işi, her projeyi, her isteği kabul etmeye meyilliydim. Bu durum, hem “ben yaparım” motivasyonundan hem de kendimi kanıtlama isteğinden kaynaklanıyordu. Ancak zamanla anladım ki, “evet” demek kolay, asıl zor olan ve sizi ileri taşıyan “hayır” demeyi öğrenmek.
Bir keresinde, henüz 5 yıllık bir ERP projesinin başında, aynı anda hem yeni bir modül geliştirmem hem de mevcut bir entegrasyonun performans sorununu çözmem istendi. İkisinin de acil olduğunu söylediler. “Yaparım” dedim. Sonuç, iki işin de yarım kalması ve hem benim hem de ekibin ciddi stres yaşaması oldu. O an, kaynaklarımın sınırlı olduğunu ve önceliklendirme yapmam gerektiğini net olarak anladım.
Teknik Borç Sadece Koda Ait Değil, Kariyerime de Mi Ait?
Teknik borç kavramını hep kod tabanında, mimaride duyarız. Hızlı çözüm üretmenin gelecekte çıkaracağı maliyetler olarak tanımlanır. Ama benim tecrübelerime göre, bu kavramın kariyerimizde de karşılığı var. Öğrenmeyi ertelediğimiz konular, üzerine gitmediğimiz eksiklikler, konfor alanımızdan çıkmadığımız anlar, hepsi birer “kariyer borcu” olarak birikiyor.
Bir üretim ERP’sinde çalışırken, AI destekli üretim planlama modülünü tasarlarken, kendimi PostgreSQL’in derinliklerinde buldum. GIN index’ler, WAL segmentleri, Vacuum parametreleri… Bunlar o güne kadar “nasıl olsa DBA halleder” dediğim konulardı. Oysa ben, uygulamanın mimarı olarak, bu detayları bilmeden doğru kararlar alamazdım. Bu borcu ödemek için haftalarca döküman okuyup testler yaptım. Eğer bunu daha önce yapsaydım, hem proje daha hızlı ilerlerdi hem de ben o stresi yaşamazdım.
İnsan İlişkileri ve Organizasyonel Akış Neden Bu Kadar Önemli?
Yazılım mimarisi üzerine yıllarca kafa yordum. Monolith mi, Microservice mi, Event-Sourcing mi, CQRS mi? Ancak zamanla anladım ki, bir yazılım projesinin başarısı çoğu zaman teknik mimariden çok, organizasyonel akışa ve insan ilişkilerine bağlı. Yazdığımız kodlar, insanların iş yapış biçimlerini ve birbirleriyle iletişim kurma şekillerini yansıtır.
Bir bankanın iç platformunu geliştirirken, en büyük zorluk teknik değil, farklı departmanlar arasındaki silo yapısıydı. Her ekip kendi doğrusunu savunuyor, ortak bir dil oluşturmakta zorlanıyorduk. En iyi tasarlanmış sistem bile, eğer kullanıcılar ve ekipler arasında doğru iletişim akışı yoksa, kağıt üzerinde kalır. Bu yüzden mühendislik sadece kod yazmak değil, aynı zamanda insanları anlamak ve ortak bir vizyon etrafında birleştirmektir.
Sürekli Öğrenmenin Ötesinde, Unutmayı Öğrenmek Ne Demek?
Teknoloji dünyasında “sürekli öğrenme” artık bir klişe. Ancak ben, bunun ötesinde, “unutmayı öğrenmenin” de en az onun kadar değerli olduğunu düşünüyorum. Bildiklerimiz, bizi bazen yeni çözümlerden alıkoyabilir. Eski alışkanlıklar, yeni paradigmaları görmemizi engelleyebilir.
Geçen ay, kendi yan ürünümün bir parçası olan finansal hesaplayıcıların backend’inde bir performans sorununu çözmeye çalışıyordum. Yılların alışkanlığıyla hemen PostgreSQL sorgularına, index’lere daldım. Saatler sonra fark ettim ki sorun, basit bir Redis OOM eviction policy ayarından kaynaklanıyordu. Eski bilgilerim, beni doğrudan soruna götürmek yerine, dolambaçlı yollara sokmuştu. Bazen eski “doğruları” bir kenara bırakıp, soruna tamamen yeni bir gözle bakmak gerekiyor.
Kendine Yatırım Yapmak Neden Sadece Sertifika Almak Değil?
Junior’ken, kendime yatırım yapmayı daha çok yeni bir dil öğrenmek, bir sertifika almak ya da popüler bir framework’e hakim olmak olarak görürdüm. Bunlar önemli, evet. Ancak asıl yatırım, problem çözme yeteneğine, eleştirel düşünceye ve adaptasyon kabiliyetine yapılan yatırım. Bir de tabii ki, hem kariyerimi hem de kişisel finansımı daha iyi yönetmek için finansal okuryazarlık ve zaman yönetimi gibi konulara yaptığım yatırım.
Kendi siteme eklediğim anonim Türkiye veri platformu gibi projelerle uğraşırken, karşıma çıkan teknik zorluklar kadar, veri analizi ve sunumu konusundaki eksiklerimi de gördüm. Bu beni sadece teknik olarak değil, aynı zamanda yeni bir alanda bilgi edinmeye itti. Kendine yatırım, sadece “daha iyi kod yazmak” değil, “daha iyi bir problem çözücü olmak” anlamına geliyor.
Peki, sen kariyerinin başında olsaydın, kendine hangi tavsiyeyi verirdin? Senin en pahalı “evet”in ya da en değerli “hayır”ın neydi? Yorumlarda duymak isterim.