Acil tıp eğitimine başladığınızda önünüze yüzlerce sayfalık, rengarenk akış şemalarıyla (flowcharts) dolu kılavuzlar koyarlar: İleri Yaşam Desteği (ACLS), Travma Protokolleri (ATLS), Pediatrik Aciller...
Bu şemalar kâğıt üzerinde kusursuz birer matematiksel algoritmadır:
"Ritim analiz et. Ritim şoklanabilir mi (VF/VT)? Evetse 200 Joule şok ver, 2 dakika CPR yap, damar yolu aç, 1 mg Adrenalin uygula. Ritim şoklanamaz mı (Asistol/PEA)? Şok verme, CPR'a devam et, geri döndürülebilir nedenleri (4H - 4T) ara..."
Sınavlarda bu şemaları ezbere çizen öğrenciler en yüksek notları alır. Kendinizi dünyanın en donanımlı, her duruma hazır acil tıp uzmanı gibi hissedersiniz.
Sonra mezun olursunuz. Ve bir gece saat 03:00'te ambulansın kapısı açılır.
Olay yeri: Şarampole yuvarlanmış, tavanı ezilmiş bir araç. Hava buz gibi, zifiri karanlık ve yağmur yağıyor. Kazazede arabanın içinde baş aşağı sıkışmış durumda. Solunum yolu kan ve kusmukla tıkanmış. Monitörün kablosu çamura bulanmış, pille çalışan aspiratörün şarjı zayıflamış ve hastanın boynunu kılavuzda yazdığı gibi "nötr pozisyonda" sabitlemeniz fiziksel olarak imkânsız.
Kitabı açıp "Sayfa 142'deki şemaya göre hastanın sırtüstü düz bir zeminde yatması gerekiyordu, bu araba neden ters döndü?" diyemezsiniz. O an o kılavuz çöpe gider. O an sizi ve hastayı kurtaracak tek bir şey vardır: Protokolün ardındaki temel biyolojik prensibi kavramış olmak ve o kaosun içinde soğukkanlılıkla doğaçlama yapabilmek.
Gerekiyorsa baş aşağı pozisyonda, dizlerinizin üzerine çökerek, çamurun içinde parmaklarınızla hava yolunu açarsınız. Çünkü prensip basittir: Beyne oksijen gitmek zorundadır. Yolun kitabî olup olmaması hastanın umurunda değildir; hastanın tek derdi yaşamaktır.
Yazılım Dünyasının Kutsal Kitapları ve Ezbercilik
Şimdi bu sahneyi zihninizde dondurun ve yazılım dünyasının steril koridorlarına adım atın.
Yazılım sektörü, belki de yeryüzünde dogmalara ve ezberlere en çabuk teslim olan sektördür. Her dönemin bir "kutsal kitabı" ve amentüsü vardır:
"Clean Architecture", "Gang of Four Design Patterns", "Domain-Driven Design (DDD)", "Microservices", "TDD olmadan asla kod yazılmaz"...
Geliştiriciler konferanslarda bu kalıpları birer dini inanç gibi savunur. Yeni başlayan bir mühendise sorsanız, size ezberden "Dependency Injection", "Singleton Pattern" ya da "CQRS" mimarisini kusursuzca anlatabilir. Tıpkı sınavda akış şemasını eksiksiz çizen tıp öğrencisi gibi.
Ama o mühendis, gerçek hayatta kanayan bir sistemle karşılaştığında ne yapar?
Canlı ortamda veritabanı kilitlenmiştir (deadlock). Mikroservisler birbirini zaman aşımına uğratıyordur. Dokümantasyonu olmayan, 10 yıl önce şirketten ayrılmış birinin yazdığı legacy bir PHP/C++ servisi bellek sızdırıyordur. Ve şirket dakikada on binlerce lira kaybediyordur.
O an o "kusursuz" mimari kitapları susar. StackOverflow'u açarsınız; orada da sizin yaşadığınız o tuhaf kenar duruma (edge case) dair tek bir hazır cevap yoktur. Çünkü StackOverflow ve ChatGPT sadece genel durumları bilir; sizin sisteminizin o an yaşadığı spesifik doku nekrozunu bilemez.
Ve ezberci yazılımcı o an terminalin başında felç geçirir. Çünkü o sadece yemek tariflerini ezberlemiştir; mutfakta yangın çıktığında ne yapacağını bilmez.
Kurallar Acemiler İçindir, Prensipler İse Ustalar İçin
Dövüş sanatlarında ve Doğu felsefesinde "Shu-Ha-Ri" adı verilen üç aşamalı bir öğrenme modeli vardır:
- Shu (İtaat Et): Kuralları, formları ve protokolleri harfiyen öğren ve uygula.
- Ha (Kır / Ayrıl): Kuralların sınırlarını anla, nerede yetersiz kaldıklarını gör ve gerektiğinde kuralları esnet.
- Ri (Aş / Yarat): Kuralları tamamen unut. Artık kuralların değil, bizzat sanatın kendisi ol ve anın gerektirdiği şekilde özgürce yarat.
Yazılımda ve acil tıpta acemiler her zaman Shu aşamasında takılı kalır. Kurallara taparlar; çünkü kural onlara sahte bir güvenlik hissi verir. "Ben kılavuza uygun davrandım, hasta öldüyse benim suçum değil" veya "Ben kodu Clean Architecture prensiplerine göre yazdım, sistem ölçeklenmediyse mimarinin suçu değil" diyerek sorumluluktan kaçarlar.
Oysa gerçek bir usta, kuralların sadece birer "çocukluk tekerleği" olduğunu bilir.
Bazen bir sistemi ayakta tutmak için en katı mimari prensibi delmeniz gerekir. Bazen bir fonksiyonu bölmek yerine tek bir dosyada 500 satır monolitik bırakmak, o anki bellek ve CPU darboğazını çözmenin en zarif yoludur. Bazen kriz anında test yazmayı bir kenara bırakıp, doğrudan problemi cerrahi bir müdahaleyle kesip çıkarmanız gerekir.
Bu kuralları çiğnemek değildir; kuralların hizmet ettiği amacı (pragmatizmi) kuralların şeklinden üstün tutmaktır.
Mutfakta Aşçı Olmak
Yemek yapmayı öğrenen biri tarife sıkı sıkıya bağlı kalır: "İki çay kaşığı tuz, 100 gram tereyağı." Eğer evde tereyağı yoksa yemek yapamaz, panikler.
Ama büyük bir şef, elindeki malzemeye bakar. Havanın nemine, etin yağ oranına, fırının sıcaklığına göre tarifi o an yeniden yazar. Çünkü o, malzemelerin kimyasını ve ısının mantığını kavramıştır.
Acil tıpta hastayı kurtaran şey, ters dönmüş bir arabada doğaçlama yapabilme cesaretidir.
Yazılımda sistemi kurtaran şey, StackOverflow cevapları tükendiğinde terminal başında derin bir nefes alıp, sistemin temel prensipleriyle (CPU, bellek, network paketleri, disk I/O) düşünebilme yetisidir.
Kılavuzları okuyun, protokolleri öğrenin, kitapları hatmedin. Onlar sizin temellerinizdir.
Ama sahaya çıktığınızda o kitapları bir kenara bırakmaya hazır olun.
Çünkü hayat ve kod; hiçbir zaman o kitapların kurguladığı kadar steril ve uslu olmayacaktır.