Öğrenmek İçin Doğru Projeyi Seçmek: Ne Çok Kolay Ne İmkânsız

Doğru bir öğrenme projesi seçmek, hangi kursu izleyeceğinizi seçmekten çok daha belirleyicidir. Çünkü bilgi izlerken değil, uygularken yerleşir. Ancak proje seçimi genellikle iki uçtan birine savrulur: ya çok kolay bir şey seçilir ve hiçbir şey öğrenilmez, ya da fazlasıyla iddialı bir şeye girişilir ve üçüncü haftada bırakılır. Bu yazıda arada duran o dar aralığı bulmanın somut ölçütlerini ele alıyoruz.

Zorluk dengesi: %70 bildik, %30 yeni

Öğrenmenin en verimli olduğu bölge, tamamen tanıdık olanla tamamen yabancı olanın arasındadır. Pratik bir oran şudur: projenin yaklaşık dörtte üçü zaten yapabildiğiniz şeylerden oluşmalı, kalanı sizi zorlamalıdır.

Neden? Çünkü her şey yeniyse ilerleme olmaz. Bir hata aldığınızda bunun dilden mi, framework'ten mi, veritabanından mı yoksa kendi mantığınızdan mı kaynaklandığını ayırt edemezsiniz. Bu belirsizlik, bırakmanın en yaygın sebebidir. Buna karşılık tanıdık bir temel üzerinde tek bir yeni parça denediğinizde, hata çıktığında nereye bakacağınızı bilirsiniz.

Bu yüzden "yeni dil + yeni framework + yeni veritabanı + yeni dağıtım ortamı" kombinasyonu, kulağa verimli gelse de öğrenme açısından en kötü seçimdir. Bir seferde tek bir yeni değişken tutmak, ilerlemenin en hızlı yoludur.

Kapsam: bir haftada çalışan bir şey çıkmalı

Yarıda bırakılan projelerin çoğu zor oldukları için değil, sınırsız oldukları için biter. "Bir sosyal medya platformu yapacağım" cümlesinin bir bitiş çizgisi yoktur; her yeni özellik bir sonrakini doğurur ve çalışan bir şey görmeden haftalar geçer.

Bunun panzehiri, ilk çalışan sürümü acımasızca küçültmektir. Kendinize şunu sorun: bir hafta içinde uçtan uca çalışan, kullanılabilir bir sürüm çıkarabilir miyim? Cevap hayırsa kapsam hâlâ büyüktür. Bir görev listesi uygulamasında ilk sürüm "görev ekle ve listele" olabilir; kullanıcı hesapları, etiketler ve bildirimler sonraki turlara kalır.

Çalışan bir sürümün psikolojik etkisi hafife alınmamalı: elinizde gerçekten çalışan bir şey olduğunda, devam etme motivasyonu tamamen değişir. Aynı ilke oyun geliştirmede de geçerlidir; kapsamı küçültmenin önemi için ilk oyununuzu bitirme yazımıza bakabilirsiniz.

Gerçek bir ihtiyaçtan yola çıkın

En çok bitirilen projeler, geliştiricinin kendi kullandığı projelerdir. Yapay bir "e-ticaret klonu" yaparken tıkandığınızda devam etmek için tek motivasyon disiplindir. Oysa kendi kitap listenizi tuttuğunuz, kendi faturalarınızı takip ettiğiniz veya evdeki bir işi kolaylaştıran bir araç yaptığınızda, onu bitirmek için ikinci bir sebebiniz olur: gerçekten ihtiyacınız vardır.

Ayrıca gerçek kullanım, öğretici bir yan etki üretir: gerçek veriyle karşılaşırsınız. Öğretici içeriklerdeki temiz örnek verilerin aksine, kendi verinizde boş alanlar, Türkçe karakterler, beklenmedik uzunluklar ve tutarsızlıklar vardır — ve asıl mühendislik pratiği tam olarak burada öğrenilir.

Öğretici tuzağından kaçınmak

Bir öğretici izleyerek proje yapmak, öğrenme hissi verir ama çoğu zaman öğrenme üretmez; çünkü zorlanma anını atlarsınız. Bu tuzağın ayrıntılı bir çözümlemesi için tutorial tuzağı yazımıza bakabilirsiniz. Pratik bir kural: öğreticiyi bitirdikten sonra kapatın ve aynı projeye bir özellik daha ekleyin — kaynak olmadan. Ekleyebiliyorsanız öğrenmişsinizdir; ekleyemiyorsanız yalnızca izlemişsinizdir.

Bitiş tanımı yazın

Projeye başlamadan önce iki cümlelik bir "bitmiş sayılır" tanımı yazmak, sonraki haftalarda en çok işe yarayan şeydir. Örneğin: "Bu proje, kendi makinemde görev ekleyip listeleyebildiğim ve veriler yeniden başlatınca kaybolmadığı zaman bitmiş sayılır." Bu tanım hem kapsamı sabitler hem de bitirme duygusunu mümkün kılar.

Tanıma ulaştığınızda ikinci bir tur açabilirsiniz — ama bu bilinçli bir karar olur, kapsamın kendiliğinden büyümesi değil.

Proje seçerken sorulacak beş soru

1. Bu projede bilmediğim kaç yeni şey var? (Birden fazlaysa azaltın.)
2. Bir hafta içinde çalışan bir sürüm çıkarabilir miyim?
3. Bitirdiğimde bunu gerçekten kullanacak mıyım?
4. Takıldığımda soracağım bir kaynak veya topluluk var mı?
5. "Bitti" demenin net bir tanımını yazabiliyor muyum?

Beş sorunun tamamına rahatça cevap verebiliyorsanız, proje muhtemelen doğru ölçektedir.

Bitirdikten sonra: öğrenmeyi kalıcı kılmak

Proje bittiğinde iş bitmiş sayılmaz. Öğrendiklerinizi kalıcı hâle getiren birkaç adım vardır: kısa bir README yazmak (neyi neden böyle yaptığınızı anlatan), kodu birkaç hafta sonra tekrar açıp okumak ve mümkünse birine göstermek. Kendi kodunuzu açıklamak, anlamadığınız yerleri en hızlı ortaya çıkaran yöntemdir. Çalışma yöntemlerinin genel çerçevesi için etkili çalışma yöntemleri yazımız, projeyi işe dönüştürme aşaması için portföy ve mülakat rehberimiz ilgili okumalardır. Konu bazlı yol haritaları için roadmap.sh faydalı bir kaynaktır.

Sonuç

Doğru öğrenme projesi, en etkileyici olan değil, bitirebileceğiniz ve gerçekten kullanacağınız olandır. Formülü basittir: bildiklerinizin üzerine tek bir yeni parça koyun, ilk çalışan sürümü bir haftaya sığdırın, kendi ihtiyacınızdan yola çıkın ve daha başlamadan "bitti" tanımını yazın. Şu an aklınızda bir proje fikri varsa, ona bu beş soruyu uygulayın. Çoğu fikir bu süzgeçten geçtiğinde küçülür — ve tam da bu yüzden ilk kez tamamlanır.