Bir öğrencinin yazdığı programın ekranda doğru sonucu vermesi etkileyicidir; fakat tek başına yeterli değildir. Çünkü çalışan kod, bazen iyi düşünmenin değil, şanslı denemelerin, kopyalanmış bir parçanın ya da ezberlenmiş bir kalıbın sonucudur. Asıl öğretici an, öğrenciye şu soru sorulduğunda başlar: “Bu kodu neden böyle yazdın?” İşte bu soru, programlamayı tuşlara basma becerisinden çıkarır; gerekçelendirme, sorgulama ve bilinçli karar verme sanatına dönüştürür.
Kod yazmak bir tür inşa faaliyetidir. Değişkenler malzeme, koşullar kapı, döngüler ise tekrar eden merdivenler gibidir. Ancak bir binanın ayakta durması, mimarın her kararının iyi olduğu anlamına gelmez. Aynı işi yapan iki program arasında okunabilirlik, hız, bakım kolaylığı, hata dayanıklılığı ve etik etki bakımından büyük farklar olabilir. Öğrenci yalnızca “çalıştı” diyorsa, binanın kapısının açıldığını söylemektedir. “Neden bu yapıyı seçtim?” diyebiliyorsa, taşıyıcı kolonları da düşünmeye başlamıştır.
Doğru cevap değil, görünür düşünce
Yansıtıcı düşünme, kişinin kendi zihinsel adımlarını izlemesidir. Öğrenci örneğin bir listeyi sıralamak için hazır bir fonksiyon kullanmış olabilir. Öğretmenin görevi bunu yasaklamak değildir; “Bu fonksiyon hangi problemi çözüyor?”, “Başka bir yöntem seçseydin ne kazanır, ne kaybederdin?”, “Veri çok büyüse kararın değişir miydi?” sorularını canlı tutmaktır. Bu sorular öğrenciyi savunmaya değil, araştırmaya çağırır. Kodun arkasındaki düşünce görünür hâle gelir.
Bu yaklaşım özellikle hata ayıklamada güçlüdür. Hata mesajı, acemi gözde bir felaket ilanı gibi görünür; oysa sistemli düşünen öğrenci için bir ipucudur. Hangi varsayımım yanlış? Program hangi noktaya kadar beklediğim gibi davrandı? Girdiler mi sorunlu, yoksa işlem sırası mı? Bu sorular, yalnızca programlamada değil, bilimsel araştırmada ve gündelik hayatta da işe yarar. Hızlı bir sonuca atlamak yerine, kanıtı izleme alışkanlığı kazandırır.
Eğitimde bunun için küçük ama etkili yöntemler kullanılabilir. Öğrenciden kod tesliminin yanında kısa bir “karar günlüğü” istenebilir. Bu günlükte seçtiği algoritmayı, vazgeçtiği alternatifleri, karşılaştığı hatayı ve bir sonraki denemede değiştireceği noktayı anlatır. Eşli kod incelemelerinde öğrenciler birbirlerinin çözümünü puanlamak yerine, çözümün varsayımlarını sorabilir. “Bu değişken neden burada tanımlandı?” veya “Bu koşul hangi uç durumu koruyor?” gibi sorular, sınıfı sessiz bir cevap fabrikasından düşünce laboratuvarına çevirir.
Elbette açıklama istemek, her satır için akademik nutuk çekmek değildir. Amaç öğrenciyi jargonla boğmak değil, kararlarının farkına vardırmaktır. Başlangıç düzeyinde “Çünkü bu değer her turda değişiyor” açıklaması yeterli olabilir. İleri düzeyde ise zaman karmaşıklığı, veri yapısı seçimi, güvenlik riski ve kullanıcı deneyimi tartışılabilir. Ölçüt, ezberlenmiş teknik kelimeler değil; gerekçenin problemle kurduğu tutarlı bağdır.
Yapay zekâ araçlarının kod üretebildiği bir çağda bu ayrım daha da önemlidir. Bir öğrenci birkaç saniyede işleyen bir çözüm elde edebilir; fakat çözümün yanlış sonuç vereceği sınırları, güvenlik açığını veya önyargılı varsayımını açıklayamıyorsa araç ona düşünme gücü değil, yalnızca hız vermiştir. Geleceğin değerli becerisi kodu üretmekten çok, kodun mantığını denetlemek, sorgulamak ve gerektiğinde yeniden kurmaktır.
İyi eğitim, öğrenciye yalnızca cevap vermeyi öğretmez; cevabın nasıl doğduğunu da sordurur. Kodun neden öyle yazıldığını açıklayabilen öğrenci, bir programdan fazlasını üretir: Kendi düşüncesine karşı sorumluluk duyan bir zihin inşa eder.