Junior Geliştiricilere Mentorluk: React ve .NET Öğretirken Öğrendiklerim

2025'te GoIT'de öğretmenliğe başladım; gelecek vadeden yazılımcılar için React ve .NET dersleri verdim. Bunu POMETOP'ta junior mühendislere mentorluk yaptığım deneyimle (sekizden fazla kişilik bir ekibe liderlik ettiğim yer) birleştirince, son dönem kariyerimin önemli bir bölümünü başkalarının gelişimine yardım ederek geçirdiğimi görüyorum. Bu yazı, o deneyimden öğrendiklerimle ilgili; nasıl kod öğretileceğiyle değil, insanların nasıl mühendis olmasına yardım edileceğiyle ilgili.

Neden Öğretmeye Başladım

On yılı aşkın süre yazılım inşa ettikten sonra, gelişimimin giderek teknolojiden çok insanlarla ilgili olduğu bir noktaya ulaşmıştım. Bir hafta sonunda yeni bir çerçeve öğrenebilirdim, ama bir junior geliştiricinin özgüven kazanmasına ve iyi içgüdüler geliştirmesine yardım etmek; işte bu daha derin bir zorluktu.

GoIT'deki fırsat doğru zamanda geldi. Yıllardır POMETOP'ta yazılımcılara gayriresmî olarak mentorluk yapıyordum ve bunu bir öğretmenlik rolüne dönüştürmek, teknik kavramları nasıl ilettiğim konusunda beni daha bilinçli olmaya zorladı.

Öğreticiler ile Gerçek İş Arasındaki Uçurum

Junior geliştiricilerin karşılaştığı en büyük zorluk, öğreticiler ile gerçek dünya projeleri arasındaki uçurumdur. Öğreticiler sözdizimini ve izole kavramları öğretir. Gerçek projeler ise onlarca kavramı bir araya getirmeyi, ödünleşme kararları vermeyi, birden çok sistemi kapsayan sorunları ayıklamayı ve kusurlu gereksinimlerle çalışmayı gerektirir.

Bu uçurumu GoIT derslerimde açıkça gördüm. Öğrenciler bir React öğreticisini takip edip bir yapılacaklar uygulaması kurabiliyordu, ama onlardan gerçekçi bir proje için (diyelim ki API entegrasyonlu, sayfalanmış ve filtrelenebilir bir ürün listesi) bir özellik geliştirmelerini istediğimde çoğu zorlanıyordu. Bilgileri eksik olduğundan değil, bilgileri bir araya getirme pratiğinden yoksun olduklarından.

Yaklaşımım bu uçurumu kademeli olarak köprülemekti. Zamanla karmaşıklığı ve belirsizliği artan alıştırmalar tasarladım. İlk alıştırmalar ayrıntılı spesifikasyonlara sahipti. Sonraki alıştırmalar ise öğrencileri açıklayıcı sorular sormaya ve tasarım kararları almaya zorlayan, kasıtlı olarak muğlak gereksinimler içeriyordu. Kursun sonunda öğrenciler, kendi mimarilerini seçip kararlarını savunmak zorunda oldukları açık uçlu projeler üzerinde çalışıyordu.

React Öğretmek: Bileşen Düşüncesi

React daha popüler kurstu ve çeşitli bir öğrenci grubunu çekti; bazıları programlama deneyimine sahip, bazıları tasarım kökenli, bazıları ise tam bir kariyer değişimi yapan kişilerdi.

Öğretmesi en zor kavram hook'lar, durum yönetimi ya da yönlendirme değildi. Bileşen düşüncesiydi: bir arayüze bakıp onu yeniden kullanılabilir, birleştirilebilir bileşenlerden oluşan bir ağaca ayırabilme yeteneği. Bu, deneyimli React geliştiricileri için ikinci doğa gibidir, ama arayüzler hakkında düşünme şeklinizde köklü bir kayma gerektirir.

"Ayrıştırma pratiği" adını verdiğim bir alıştırma geliştirdim. Öğrencilere karmaşık bir web uygulamasının ekran görüntüsünü gösterir ve onlardan tanımlayabildikleri her bileşenin etrafına kutular çizmelerini, her bileşeni adlandırmalarını ve prop'larını betimlemelerini isterdim. Ardından ayrıştırmalarını karşılaştırır ve farklı yaklaşımların ödünleşmelerini tartışırdık. Genel bir Card bileşenine sahip olmak mı, yoksa belirli ProductCard ve UserCard bileşenlerine sahip olmak mı daha iyiydi? Bir bileşen kendi durumunu ne zaman yönetmeli, ne zaman prop olarak almalıydı?

Bu tartışmalar inanılmaz değerliydi, çünkü öğrencilere yazılım tasarımında nadiren tek bir "doğru" yanıt olduğunu öğretiyordu. Ödünleşmeler vardır ve bu ödünleşmeleri ifade edebilme yeteneği, bir acemiyi bir profesyonelden ayıran şeydir.

.NET Öğretmek: Kurumsal Desenler

.NET kursu farklı bir kitleyi çekti; tipik olarak kurumsal geliştirme ve arka uç mühendisliğiyle ilgilenen öğrenciler. C# ve .NET öğretmek farklı bir yaklaşım gerektiriyordu, çünkü çerçeve daha görüş sahibi (opinionated) ve ekosistem daha geniş.

Yoğun olarak desenlere odaklandım: bağımlılık enjeksiyonu, repository deseni, unit of work ve CQRS. Bu desenler acemilere gereksiz bir soyutlama gibi görünebilir, bu yüzden her zaman önce deseni kullanmadan bir şey inşa ederek, ortaya çıkan sorunları göstererek ve ardından deseni kullanacak şekilde yeniden düzenleyerek başlardım. Bu "önce acıyı hisset" yaklaşımı, her desenin değerini teorik değil somut hâle getiriyordu.

Kod incelemeleri .NET kursunun merkezî bir parçasıydı. Öğrenciler kodlarını pull request'ler aracılığıyla gönderiyordu ve ben onları ayrıntılı yorumlarla inceliyordum. Bu incelemeleri öğretim fırsatları olarak ele alıyor, yalnızca neyin değiştirileceğini değil, nedenini de açıklıyordum. Zamanla öğrenciler birbirlerinin kodunu incelemeye başladı; bu daha da değerliydi, çünkü kodu eleştirel biçimde okuma ve değerlendirme yeteneklerini geliştiriyordu.

POMETOP'ta Mentorluk: Gerçek Dünya Bağlamı

GoIT'de öğretmek bana öğrencilerle yapılandırılmış etkileşimler sağladı, ama POMETOP'ta mentorluk yapmak tamamen farklı bir deneyimdi. Bir üretim ekibindeki junior geliştiriciler, öğrencilerin karşılaşmadığı baskılarla yüzleşir: teslim tarihleri, eski (legacy) kod, üretim olayları ve hatalarının gerçek kullanıcıları etkilediğini bilmenin duygusal yükü.

POMETOP'taki mentorluk yaklaşımım üç ilke etrafında kurulmuştu. Birincisi, kod incelemeleri yerine eşli programlama (pair programming). Kodu işin ardından incelemek faydalıdır, ama bir junior geliştiriciyle bir sorunu çözerken yan yana oturmak, onlara yalnızca ne yazacaklarını değil, nasıl düşüneceklerini öğretir. Direksiyonu onlara bırakır, çözümleri dikte etmek yerine yönlendirici sorular sorardım.

İkincisi, karmaşıklığa kontrollü maruziyet. Bir junior geliştiricinin konfor alanının biraz üzerinde görevler atardım; gelişim gerektirecek kadar zorlayıcı, ama onları bunaltmayacak kadar da zor olmayan. Özgüvenleri arttıkça, karmaşıklığı kademeli olarak artırırdım.

Üçüncüsü, hataları normalleştirmek. Kendi hatalarımı açıkça paylaşmaya özen gösterirdim. Bir üretim sorununa yol açtığımda ya da kötü bir mimari karar verdiğimde, bunu ekiple tartışırdım. Bu, gösteriş için bir alçakgönüllülük değildi; hataların başarısızlık değil, öğrenme fırsatları olarak görüldüğü bir ortam yaratmaya yönelik bilinçli bir çabaydı.

Gözlemlediğim Yaygın Desenler

Onlarca junior geliştiriciye mentorluk yaptıktan sonra, yinelenen desenler fark ettim. En yaygını "öğretici felci" dediğim şeydi; genel ilkeleri belirli bir duruma uygulamak yerine, tam olarak o probleme uyan bir öğretici arama eğilimi. Bu alışkanlığı kırmak, yeni problemlerle pratik yapmayı ve onları çözmekten gelen özgüveni gerektiriyordu.

Bir diğer desen aşırı mühendislikti. Mikroservisler, olay kaynaklı mimari (event sourcing) ya da alan güdümlü tasarım (domain-driven design) hakkında okumuş juniorlar, bu desenleri basit CRUD uygulamalarına uygulamaya çalışırdı. Onları nazikçe sadeliğe yönlendirir, en iyi mimarinin gereksinimleri karşılayan en basit mimari olduğunu vurgulardım.

Üçüncü desen, soru sorma korkusuydu. Birçok junior geliştirici yetersiz görünmekten korkuyordu. Bunu, onlara herkesin önünde sorular sorarak ele aldım; bir şeyi bilmemenin normal olduğunu ve merakın bir güç olduğunu göstererek.

Mentorluğun Bana Öğrettikleri

Mentorluk beni daha iyi bir mühendis yaptı. Kavramları açıklamak beni onları daha derinlemesine anlamaya zorladı. Junior geliştiricilerin kodunu incelemek, beni daha önce düşünmediğim taze bakış açılarına ve yaklaşımlara maruz bıraktı. Ve birinin kararsız bir acemiden özgüvenli bir katkıcıya dönüştüğünü izlemek son derece tatmin ediciydi.

En önemli ders, teknik mentorluğun duygusal destekten ayrılamaz olduğuydu. Profesyonel olarak kod yazmayı öğrenmek stresli bir süreçtir ve en iyi mentorlar, bu stresi kabul ederken insanların onu aşmasına yardım edenlerdir. Yerinde söylenmiş bir "ben de başlarken bununla zorlanmıştım", herhangi bir teknik açıklamadan daha değerli olabilir.

Henüz mentorluk denememiş bir kıdemli geliştiriciyseniz, sizi başlamaya şiddetle teşvik ediyorum. Bu süreçte ne kadar çok şey öğrendiğinize şaşıracaksınız.