Her Teknolojiye Yetişme Çılgınlığı: Pragmatik Mühendislik

Geçen hafta e-posta kutuma düşen bir mesaj, aslında uzun zamandır kafamı kurcalayan ama bir türlü adını koyamadığım o büyük kariyer çıkmazını tam kalbinden vuruyordu. Gelen mesajda genç bir meslektaşım, “Mustafa abi, sistem mi öğreneyim, backend mi kasayım, yoksa bu yeni çıkan yapay zeka ajan mimarilerine mi gömüleyim? Hepsine birden bakmaya çalışınca kafam çorba oluyor ve günün sonunda hiçbir şeyde uzmanlaşamadığımı hissediyorum,” diyordu. Bu soru, son yıllarda sektörün üzerine çöken o “her şeyi bilme ve her trene binme” histerisinin en somut özetiydi.

Yirmi yıla yaklaşan saha tecrübem boyunca benzer kafa karışıklıklarını hem kendimde hem de birlikte çalıştığım ekiplerde defalarca gördüm. Teknolojinin tüketim hızı o kadar arttı ki, artık bir kütüphaneyi veya sistemi tam anlamıyla öğrenmeden yenisi piyasaya sürülüyor. Bu durum, özellikle kariyerinin başındaki ve ortasındaki mühendislerde ciddi bir yetersizlik hissi ve yön kaybı yaratıyor. Bu yazıda, bu harika konu önerisinden yola çıkarak, her şeye yetişmeye çalışmanın neden bir kariyer intiharı olduğunu ve pragmatik bir mühendis olarak nasıl ayakta kalabileceğimizi kendi süzgecimden geçireceğim.

Gelen Öneri Neydi ve Neden Bu Kadar Tanıdık?

Bana gelen e-postadaki temel kaygı, aslında birçoğumuzun her sabah tarayıcıyı açtığında karşılaştığı o bilgi bombardımanının doğal bir sonucuydu. Gönderen arkadaşımız, bir yandan PostgreSQL’in derinliklerine inmek isterken diğer yandan yeni nesil bir frontend framework’ünün detaylarında boğulduğunu, aynı zamanda çalıştığı şirketteki Docker ve Linux sistem yönetimi işlerinin de üzerine kaldığını anlatıyordu. Üzerine bir de “Yapay zeka geliyor, kod yazmayı bitirecek, hemen ajan mimarilerini (agentic patterns) öğrenmeliyim” baskısı eklenince, tam bir felç olma (analysis paralysis) durumu ortaya çıkmıştı.

Bu durum bana çok tanıdık geliyor çünkü ben de benzer bir yoldan geçtim. Yıllar önce hem VLAN segmentasyonu yapıp switch konfigüre etmeye çalışıyor, hem Linux sunucularda systemd unit’leri yazıyor, hem de kurumsal bir ERP’nin veritabanı performans sorunlarıyla boğuşuyordum. O dönemde her şeyi aynı derinlikte bilmem gerektiğine inanıyordum ve bu beni inanılmaz derecede yıpratıyordu. Zamanla fark ettim ki, her şeyi bilmek sadece imkansız değil, aynı zamanda mühendislik kalitesini de düşüren bir illüzyon.

Her Şeyi Bilme İllüzyonu: Full-Stack Yalanı mı, Sektör Baskısı mı?

Sektörde uzun süredir pazarlanan bir “Full-Stack” efsanesi var. Bu kavram, şirketlerin tek bir maaşla hem sistemci, hem veritabanı yöneticisi, hem frontendci hem de backendci çalıştırma arzusundan doğdu. Ancak pratikte, her alanda aynı seviyede uzmanlaşmış bir insan bulmak neredeyse imkansızdır. Bir alanda çok iyi olan biri, diğer alanlarda kaçınılmaz olarak yüzeysel kalır. Bu durum, sistemlerin kritik anlarda patlamasına yol açan en büyük etkendir.

Örneğin, harika bir arayüz yazan bir geliştiricinin, arkadaki PostgreSQL veritabanının B-tree indeksleme mantığını veya VACUUM süreçlerinin disk üzerindeki etkisini derinlemesine bilmesini bekleyemezsiniz. Ya da tam tersi, Linux çekirdeğindeki cgroup bellek limitlerini milimetrik hesaplayan bir sistemcinin, modern tarayıcılardaki state management karmaşasını çözmesini istemek haksızlıktır. Bu rollerin hepsini tek bir kişiye yüklemeye çalışmak, o kişinin her konuda “biraz” bilgi sahibi olup hiçbir konuda “çözüm üretemez” hale gelmesine neden olur.

graph TD;
A["Kariyer Odak Noktası"] --> B["Yatay Genişlik (Genel Kültür)"]
A --> C["Dikey Derinlik (Uzmanlık)"]
B --> D["Sistem/Network Temelleri"]
B --> E["Bulut ve Konteyner Dünyası"]
C --> F["PostgreSQL ve Veritabanı Optimizasyonu"]
C --> G["Sistem Güvenliği ve Hardening"]

T-Shaped İnsan Olmanın Pratik Sınırları

Peki, çözüm ne? Sektörde sıkça duyduğumuz “T-Shaped” (T-tipi) insan modeli burada devreye giriyor. Yani, birçok konuda genel bir bilgi birikimine (T’nin yatay çizgisi) sahip olup, bir veya en fazla iki konuda derinlemesine uzmanlaşmak (T’nin dikey çizgisi). Bu teoride harika görünen bir model olsa da pratikte uygulaması ciddi disiplin gerektiriyor. Çünkü o dikey çizgiyi nereye çekeceğinizi bilmediğinizde, T harfiniz zamanla bir tırmığa dönüşüyor ve hiçbir yere derinlemesine batamıyorsunuz.

Benim T modelim zaman içinde şu şekilde şekillendi: Yatayda network topolojileri, Linux servisleri ve temel frontend bilgisi yer alırken; dikey uzmanlık alanım kurumsal yazılım mimarisi, PostgreSQL veritabanı yönetimi ve sistem güvenliği oldu. Eğer network tarafında bir switch loop veya routing flap sorunu yaşarsam, sorunun ne olduğunu anlayacak ve teşhis koyacak kadar network bilirim. Ancak gidip de küresel bir telekom altyapısının BGP yönlendirme kararlarını optimize etmeye kalkmam; o işi gerçek uzmanına bırakırım. Önemli olan, kendi sınırlarınızı çizebilmektir.

Pragmatik Mühendislik: Hangi Teknolojiyi Çöpe Atmalı, Hangisine Tutunmalı?

Önümüze her gün yeni bir kütüphane, yeni bir veritabanı veya yeni bir bulut aracı atılıyor. Bunların hangisinin kalıcı olacağını, hangisinin iki yıl sonra unutulup gideceğini nasıl anlayacağız? Burada devreye pragmatik mühendislik süzgeci giriyor. Ben bir teknolojiyi hayatıma sokmadan önce kendime şu soruları sorarım:

1. Bu teknoloji, benim şu an çözmeye çalıştığım gerçek bir sorunu gerçekten çözüyor mu?
2. Arkasında güçlü, bağımsız ve standartlara dayalı bir topluluk var mı?
3. Bu teknolojinin getirdiği soyutlama katmanı, bana hata anında hata ayıklama (debugging) imkanı tanıyor mu, yoksa sistemi kara bir kutuya mı çeviriyor?

Eğer bir araç çok popüler olduğu halde arkasında devasa bir teknoloji şirketinin pazarlama bütçesinden başka bir şey barındırmıyorsa, ona şüpheyle yaklaşırım. Örneğin, Docker Compose ile ayağa kaldırabileceğim ve yıllarca sorunsuz çalışacak bir uygulamayı, sırf “modern” olsun diye karmaşık bir Kubernetes kümesine taşımam. Ya da basit bir Python scriptiyle halledebileceğim bir veri işleme işi için hemen gidip karmaşık bir distributed mimari kurmaya çalışmam. Pragmatizm, en havalı olanı değil, en sıkıcı ama en güvenilir olanı seçmektir.

Gerçek Hayattan Bir Örnek: Bir Üretim ERP’sinde Karar Anı

Bir üretim ERP’si üzerinde çalışırken, fabrikanın anlık üretim planlama verilerini ve operatör ekranlarındaki metrikleri gerçek zamanlı olarak sunmamız gerekiyordu. Ekipteki heyecanlı arkadaşlar hemen ortaya atılıp, “Burada kesinlikle bir event-sourcing mimarisi kurmalıyız, her operatör hareketini bir event olarak Kafka’ya basmalı, oradan mikroservislerle işlemeliyiz” dediler. Kulağa çok havalı ve CV’ye yazmalık bir proje gibi geliyordu.

Ancak fabrikanın fiziksel şartlarını, ağ altyapısının stabilitesini ve ekibin bakım (maintenance) kapasitesini düşündüğümde bu kararın bir felaket getireceğini biliyordum. Bunun yerine, PostgreSQL’in sunduğu standart mekanizmaları, optimize edilmiş indeksleri ve basit bir FastAPI backend’i ile WebSocket bağlantılarını kullandık. Sonuç ne mi oldu? Sistem kabaca sıfır bakım maliyetiyle, hiçbir mesaj kaybolmadan ve karmaşık bir distributed transaction yönetimiyle uğraşmadan yıllarca tıkır tıkır çalıştı. İşte bu, pragmatik mühendisliğin ta kendisidir.

20 Yıllık Yoğurt Yiyişi: Benim Kariyer Filtrem Nasıl Çalışıyor?

Sektördeki bunca yıllık koşturmacadan sonra edindiğim en büyük kazanım, neyi öğrenmem gerektiğinden ziyade, neyi öğrenmemem gerektiğine karar verme becerisidir. Benim kişisel kariyer ve teknoloji filtrem şu üç temel sütun üzerine kurulu:

• Temellere Yatırım Yapın: Linux çekirdeğinin nasıl çalıştığını, TCP/IP protokolünün el sıkışma (handshake) aşamalarını ve ilişkisel veritabanlarının transaction izolasyon seviyelerini öğrenmek, hiçbir zaman eskimeyecek bir yatırımdır. Bugün öğrendiğiniz bir Javascript framework’ü üç yıl sonra yok olabilir ama TCP/IP otuz yıldır orada ve otuz yıl daha orada olacak.
• Hata Semptomlarını Okumayı Öğrenin: Bir sistem patladığında loglarda ne arayacağınızı bilmek, en büyük uzmanlık göstergesidir. journald loglarını doğru süzmek, systemd servisinin neden OOM-killed olduğunu anlamak veya PostgreSQL’deki kilitlenmeleri (deadlock) teşhis edebilmek, sizi her zaman aranan insan yapar.
• Yapay Zekayı Bir Ortak Olarak Kullanın, Bir Protez Olarak Değil: Yapay zeka araçlarını (LLM’ler, kod asistanları) kod yazarken veya karmaşık bir sistem konfigürasyonunu araştırırken sıklıkla kullanıyorum. Ancak onların ürettiği çıktıyı satır satır doğrulayacak temel bilgiye sahip olmadığım sürece, o kodları asla production ortamına almam. Yapay zeka sizin hızınızı artırabilir ama sorumluluğunuzu azaltmaz.

Son Söz: Kendi Filtrenizi Nasıl Kurarsınız?

Eğer siz de her şeye yetişmeye çalışırken boğulduğunuzu hissediyorsanız, ilk yapmanız gereken şey derin bir nefes alıp tarayıcınızdaki elli farklı sekmeyi kapatmaktır. Kendinize bir ana odak alanı seçin. Bu backend olabilir, sistem yönetimi olabilir veya veri mühendisliği olabilir. Bu alanda gerçekten derinleşin; o sistemlerin sınırlarını zorlayın, hata yapın ve o hataları kendiniz çözün.

Diğer alanları ise tamamen göz ardı etmeyin, ancak onları bir “genel kültür” seviyesinde tutun. Bir sistemcinin yazılım mimarisinden anlaması, bir yazılımcının ise uygulamasının koştuğu sunucunun kaynak limitlerinden haberdar olması yeterlidir. Herkesin her şeyi bildiği bir dünya yok; sadece her şeyi biliyormuş gibi yapan ve ilk ciddi krizde ne yapacağını şaşıran insanlar var. Siz onlardan olmayın.

Bir sonraki yazıda, Linux sunucularda gereksiz kaynak tüketimini engellemek için cgroup limitlerini pratik olarak nasıl yapılandırdığımızı ve bu sınırların uygulamanın kararlılığına etkisini anlatacağım.