Kod yazmak ve mühendislik yapmak çoğu zaman aynı şeymiş gibi düşünülür. Oysa aralarında ciddi bir fark vardır. Kod yazmak verilen görevi tamamlamaktır; mühendislik ise o görevin sistem içindeki etkisini, sürdürülebilirliğini ve uzun vadeli sonuçlarını düşünmektir. Bu yazıda, engineering ownership kavramı üzerinden bu farkı gerçek örnekler ve senaryolarla inceliyoruz.
Yazılım dünyasında kariyer ilerledikçe fark edilen en kritik ayrımlardan biri şudur: Kod yazmak ile mühendislik yapmak aynı şey değildir. Günün sonunda herkes kod yazar. Junior da yazar, senior da yazar. Hatta bugün geldiğimiz noktada AI bile kod yazabiliyor. Ama buna rağmen iyi mühendis ile sadece kod yazan biri arasındaki fark hâlâ çok net bir şekilde hissediliyor.
Bu farkın temelinde “ownership” yani sahiplenme yatıyor. Çünkü mühendislik, sadece verilen işi yapmak değil; yapılan işin sorumluluğunu almakla ilgili bir yaklaşım.
Birçok projede şu senaryoya mutlaka denk gelmişsindir: Bir feature geliştirilir, test edilir ve yayına alınır. Her şey doğru gibi görünür. Ama birkaç hafta sonra aynı feature ile ilgili farklı problemler ortaya çıkmaya başlar. Edge-case’ler patlar, performans düşer ya da başka bir modülü etkilemeye başlar. Bu noktada genelde şu cümle duyulur: “Ama bana verilen task buydu.”
İşte bu cümle, kod yazmak ile mühendislik yapmak arasındaki farkın en net göstergesidir.
Kod yazan kişi için görev, tanımlandığı haliyle tamamlanır. Mühendis için ise görev, sistem içindeki etkisiyle birlikte değerlendirilir. Yani mesele sadece “ne yaptığın” değil, “neyi neden yaptığın”dır.
Gerçek hayattan basit bir örnek üzerinden gidelim. Diyelim ki bir e-ticaret uygulamasında sepete ürün ekleme özelliği geliştiriyorsun. Kod yazan biri için bu task oldukça nettir: Butona basıldığında ürün sepete eklenecek ve UI güncellenecek. Bu senaryoyu hızlıca implement edebilirsin ve gerçekten de “çalışır”.
Ama mühendis burada durmaz. Şu soruları düşünmeye başlar: Aynı ürün art arda hızlıca eklenirse ne olur? Backend tarafında idempotent bir yapı var mı? Kullanıcı farklı sekmelerden aynı işlemi yaparsa veri tutarlılığı korunur mu? Bu state client’ta mı tutulmalı yoksa server ile senkron mu olmalı? Yarın bu sepete kampanya kuralları eklendiğinde bu yapı ne kadar esnek kalacak?
Gördüğün gibi, aynı feature iki farklı bakış açısıyla ele alındığında ortaya çıkan çözümün kalitesi tamamen değişir. İlk yaklaşım sadece çalışır bir çözüm üretir. İkinci yaklaşım ise sürdürülebilir bir sistem parçası üretir.
Benzer bir durum performans tarafında da sıkça görülür. Örneğin bir liste render ediyorsun ve performans problemi yaşanıyor. Kod yazan biri doğrudan useMemo, useCallback veya React.memo ekleyerek problemi çözmeye çalışır. Bu bazen işe yarar, bazen de sadece problemi maskeler. Mühendis ise önce problemi anlamaya çalışır: Bu liste neden yavaş? Render mı ağır, yoksa veri mi fazla? Virtualization gerekir mi? State yanlış yerde mi tutuluyor? Bu sorgulama yapılmadan yapılan optimizasyonlar genelde kısa vadeli çözümler üretir.
Ownership dediğimiz kavram tam olarak burada devreye girer. Ownership, “bu task bana ait” demek değildir. Ownership, yazdığın kodun davranışını production ortamında da sahiplenmektir. Yani kodun sadece çalışmasından değil, doğru çalışmasından, sürdürülebilir olmasından ve sistemle uyumlu olmasından sorumlu olmaktır.
Bu bakış açısı, iletişim şeklini bile değiştirir. Örneğin bir code review sürecinde “bu böyle çalışıyor” demek ile “bu çözüm şu senaryolarda problem çıkarabilir” demek arasında ciddi bir fark vardır. Birincisi savunma refleksidir, ikincisi ise sahiplenmedir. Mühendislikte gelişim genelde bu geçişle başlar.
Bir başka önemli nokta da şu: Mühendislik çoğu zaman büyük kararlarla değil, küçük ama kritik kararlarla şekillenir. Bir değişkenin ismi, bir component’in nasıl parçalandığı, bir fonksiyonun nerede konumlandığı gibi detaylar ilk bakışta önemsiz gibi görünür. Ancak bu küçük kararlar zamanla birikir ve sistemin okunabilirliğini, bakım maliyetini ve esnekliğini doğrudan etkiler.
Örneğin basit bir form component’i düşün. Tüm logic’i tek bir component içine yazabilirsin ve bu çalışır. Ama form büyüdükçe validasyon, API çağrıları, state yönetimi gibi konular iç içe geçmeye başlar. Bu noktada mühendislik devreye girer ve şu sorular sorulur: Bu logic ayrılmalı mı? Custom hook yapılmalı mı? Bu yapı test edilebilir mi? Bu kararlar erken aşamada verilmezse, ileride refactor maliyeti katlanarak artar.
Mühendislik aynı zamanda “hayır diyebilme” becerisidir. Her gelen isteği olduğu gibi implement etmek yerine, gerekirse alternatif önermek, riskleri belirtmek ve daha sağlıklı bir çözüm önermek de ownership kapsamına girer. Çünkü bazen en doğru karar, verilen task’ı olduğu gibi yapmak değil, o task’ı yeniden tanımlamaktır.
Zamanla şunu fark ediyorsun: Seni iyi bir mühendis yapan şey yazdığın kodun miktarı değil, verdiğin kararların kalitesi oluyor. Hatta çoğu zaman daha az kod yazarak daha iyi sistemler kurmak mümkün oluyor. Çünkü gereksiz abstraction’lardan kaçınmak, doğru yerde basit kalabilmek ve ihtiyaç odaklı ilerlemek de mühendisliğin önemli bir parçası.
Kod yazmak ve mühendislik yapmak arasındaki fark, teknik beceriden çok düşünme biçimiyle ilgilidir. Kod yazmak çıktıdır; mühendislik ise o çıktıyı şekillendiren kararlar bütünüdür. Ownership ise bu sürecin merkezinde yer alır. Yazdığın kodun sadece bugün değil, yarın da çalışmasından sorumlu olmak demektir.
Günün sonunda mesele sadece bir feature’ı tamamlamak değildir. Mesele, o feature’ın sistem içinde nasıl yaşayacağını belirlemektir. Çünkü iyi mühendisler sadece çalışan kod yazmaz; sürdürülebilir, anlaşılabilir ve uzun vadede sorun çıkarmayan sistemler kurar.
