Bir junior'a, işini onun yerine yapmadan nasıl mentorluk yaparım?
Soru
Ekibime yeni mezun bir geliştirici katıldı ve mentorluğundan ben sorumluyum. Niyetim iyi ama her takıldığında refleks olarak klavyeyi elinden alıp problemi ben çözüyorum; çünkü öyle daha hızlı ilerliyoruz ve teslim tarihleri de sıkışık. Sonra fark ediyorum ki aynı hatayı ertesi gün yine yapıyor, çünkü çözümü kendisi bulmadı, bana bakarak izledi. İşini onun yerine yapmadan ona nasıl gerçekten mentorluk yaparım? Somut davranış önerileri arıyorum.
Cevap
Kısa cevap: Klavyeye uzanma refleksini öldürmeniz gereken şey tam olarak budur.
Kısa cevap
Mentorluğun işi bugünü hızlandırmak değil; junior’ı sizsiz üretken hale getirmektir. O yüzden ölçütünüz “ne kadar hızlı ship ettim” değil, “her hafta bana biraz daha az ihtiyaç duyuyor mu” olmalı.
Ne yapmalı
-
Elinizi klavyeden fiziksel olarak çekin. Gerekirse ellerinizin üstüne oturun ve onun sürmesine izin verin. Sessizliğin verdiği rahatsızlık, öğrenmenin bedelidir. Devraldığınız her seferinde ona “nasılsa seni ben kurtarırım” diye öğretmiş olursunuz.
-
Söylemeyin, sorun. “Ne denedin? Bu satırın ne yapmasını bekliyorsun? Sence nerede kırılıyor?” Sokratik sorular hata ayıklama modelini inşa eder; hazır cevap ise sadece bir bilgiyi transfer eder ve ertesi gün buharlaşır.
-
Mücadeleye süre koyun (timebox). Verimli mücadelenin bir sınırı vardır. Baştan anlaşın: “30 dakika takıldıysan bana haber ver.” Çok kısa süre hüsran ve öğrenilmiş çaresizlik doğurur; çok uzun süre günü çöpe atar. Bu eşiği kişiye göre kalibre edin.
-
Geri alınabilir hatalar yapmasına izin verin. Prod’a gitmeyecek ve yıkıcı olmayan bir şeyse, yanlış yaklaşımın sonuna kadar gitmesine izin verin — kendi yaptığı hatadan çıkan ders, size bakarak aldığı tavsiyeden çok daha kalıcıdır. Sert müdahaleyi yalnızca geri alınamaz veya güvensiz şeyler için saklayın.
-
“Ne yazılacağı”na değil, “nasıl düşünüleceği”ne pair olun. Klavyeyi ele aldığınız anlarda muhakemenizi sesli anlatın: bir stack trace’i nasıl okuyorsunuz, hipotezi nasıl kuruyorsunuz, neden önce X’i kontrol ediyorsunuz. Transfer edilebilir beceri budur, kodun kendisi değil.
-
Süreci övün, ayrıntıyı async’e taşıyın. Sadece çalışan kodu değil, iyi muhakemeyi takdir edin. Ufak nitpick’leri PR review’a bırakın ki denemek için kesintisiz akışı olsun. Sürekli omzunun üstünden bakmak öğrenmeyi değil, kaygıyı büyütür.
-
“Bilmiyorum” demeyi güvenli kılın. Bir junior takıldığını saklıyorsa öğrenemez. Kendi hatalarınızı ve bilmediklerinizi açıkça paylaşın; “ben de bunu her seferinde dokümana bakarak yapıyorum” demek, mükemmel görünme baskısını kaldırır. Psikolojik güven, tüm mentorluğun üzerine kurulduğu zemindir.
-
Görünür bir ilerleme çıpası kurun. Haftada 15-20 dakikalık bir 1:1 yapın; “bu hafta ne öğrendin, nerede takıldın, gelecek hafta neyi tek başına denemek istiyorsun” diye ilerleyin. Bu, hem siz hem o için bağımsızlaşmanın somut bir ölçüsü olur ve öğrenmeyi kişinin kendi sorumluluğuna taşır.
Sonuç: Ben olsam kendimi tek bir soruyla ölçerdim: “Bu hafta bana geçen haftakinden daha az mı ihtiyaç duyuyor?” Kısa vadede yavaşlarsınız — ama o geçici yavaşlama, mentorluğun tam olarak amacıdır. Klavyeyi devralarak kazandığınız her gün, ekibe bağımlı bir kişi bırakır; sabrettiğiniz her gün ise bağımsız bir mühendis yetiştirir.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.