İşin aslı şu ki, çoğumuz iyi şeyler yapıyoruz ama onları kayıt altına almıyoruz. Sonra bir mülakat geliyor, bir terfi görüşmesi açılıyor ya da performans değerlendirmesinde “Son dönemde ne başardın?” sorusu pat diye masaya düşüyor (kendi tecrübem). ve zihin boşalıyor. Tam o anda. İşte tam o anda bir brag document, yani başarı günlüğü, bayağı işe yarıyor.
David Ballester Mena’nın anlattığı fikir de buradan çıkıyor zaten: düzenli güncellenen, bir yerde duran. Gerektiğinde açılıp bakılabilen küçük bir profesyonel zafer arşivi. Kağıt üstünde basit görünüyor. Pratikte ise unutmaya çok müsait bir şey bu — ve bunu bizzat yaşadım. Ben de editör masasındayken, 2024’ün Kasım ayında benzer bir not düzeni kurmaya çalışmıştım; iki hafta sonra Notion sayfam öylece bırakılmış, terk edilmiş, kimsesiz duruyordu orada (kendi tecrübem). Yani mesele fikir değil… süreklilik.
Brag Document Tam Olarak Ne İşe Yarıyor?
Brag document’i “övünme defteri” gibi kaba bir yere koymak istemem. Hayır, bu daha çok kişisel kariyer hafızası. Hangi projede ne yaptın, nerede düğümü çözdün, hangi hatayı toparladın, hangi ekibe nefes aldırdın — hepsi orada duruyor. Hafıza bazen acımasızdır; özellikle de iş hayatında birbirine benzeyen haftalar üst üste binince, her şey bulanık bir kitleye dönüşüyor (buna dikkat edin)
Ve işler burada ilginçleşiyor. Bu konuyla ilgili neden ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Geçen yıl Şubat ayında Ankara’da görüştüğüm bir ürün yöneticisi bana şunu söylemişti: “En büyük problemim başarısızlıklar değil, başarıları hatırlayamamak.” Kısa cümle. Ama tokat gibi. Çünkü insanlar sorunları unutmuyor; aksine fazla iyi hatırlıyor, üstüne üstlük tekrar tekrar düşünüyor. Ama güzel giden işleri? Onlar günlük koşturmacanın içinde sessizce kayboluyor, kimse fark etmiyor bile.
Bu yüzden brag document sadece mülakat için kullanılmıyor. İç terfilerde, maaş pazarlığında, hatta ekip içi görünürlükte bile ciddi fark yaratıyor. Uzaktan çalışan ekiplerde bu iş daha da önemli hale geliyor — koridorda tesadüfen anlatılan başarılar artık kimsenin kulağına çarpmıyor çünkü. O raslantısal görünürlük yok oldu.
Bir başarı günlüğü tutmak gösteriş değil; hafızayı dışarıya taşımak. Ve açık konuşayım, kariyerde çoğu zaman hafıza tek başına yetmiyor.
Neden İnsanlar Güncellemeyi Unutuyor?
Bence ana sebep şu: başarıyı yazmak çoğu zaman acil hissettirmiyor. Bugün sprint kapandıysa herkes zaten başka işe koşuyor. Bugünkü küçük kazanımı not etmek yerine e-posta temizleniyor, toplantıya giriliyor, Jira kartı kapanıyor… ve akşam oluyor. Ertesi gün de aynı döngü. Ve bir sonraki gün de.
Bir şey dikkatimi çekti: Ben bunu ilk kez 2023’te İstanbul’da kendi blog işlerimde yaşadım. Bir içerik serisini haftalarca toparlamıştım, emek vermişim, üstüne kafa yormuştum — ama sonunda “Hangi bölümde ne kadar trafik artışı oldu?” diye sorunca elim ayağım karıştı. Rakam vardı aslında… ama parçalanmış haldeydi, her yerde dağılmıştı. Tek yerde olsaydı işim çok kolaylaşacaktı (en azından benim deneyimim böyle). Basit ama o an anlıyorsun.
Dürüst olmak gerekirse, Burada küçük ama kritik bir detay var — bence çok yerinde bir karar —. İnsan zihni başarıyı olay anında değil, duyguyla birlikte kaydediyor; eğer o an çok yorulduysan, kafan dağıldıysa ya da sadece üşendiysen, o başarı sanki hiç olmamış gibi silinip gidiyor zihninden. Brag document’in güzelliği tam burada devreye giriyor — duygusal bulanıklığı bir kenara bırakıp çıplak gerçeği saklıyor.
Ve işler burada ilginçleşiyor.
Küçük takımda başka, kurumsalda başka
Küçük bir startup’ta bu belgeyi bireysel olarak tutmak yeterli olabilir; karar vericiler yakındır, hikâyeni yüz yüze anlatma şansın vardır. Kurumsal tarafta ise durum değişiyor… Katman çoğalınca görünürlük azalıyor. Sesin yankısı bile kısılıyor bazen.
Büyük organizasyonlarda yöneticiler onlarca kişiyi takip ediyor, her birinin ne yaptığını bilmesi mümkün değil. Senin kurtardığın hata belki ürün teslimatını bir düşüneyim… iki gün erkene çekti ama bunu kimse kayıt altına almadıysa, geçmiş olsun. Tam burada brag document devreye girip “ben ne yaptım?” sorusuna veriyle, somut örneklerle, tarihiyle cevap veriyor.
David’in Yaptığı Şey Neden İlginç?
Size bir şey söyleyeyim, David Ballester Mena’nın yaklaşımı bana pratik geldi çünkü işi süslemiyor; doğrudan problemi çözüyor. “Unutuyorum” deyip oturup kendi aracını yapmış, düşük sürtünmeli hale getirmeye uğraşmış — yani kullanıcıdan ekstra çaba istemeyen bir sistem kurmaya çalışmış. Bu önemli bir detay aslında.
Editör olarak böyle mikro SaaS hikâyelerini seviyorum. Çünkü çoğu zaman en değerli öğrenmeler büyük bütçelerden değil, dar kapsamlı küçük denemelerden çıkıyor. Bu projede de Cloudflare’a ilk kez dalması var, otomatik e-postalarla boğuşması var, Copilot’u sıfırdan denemesi var. Kulağa basit geliyor. Ama pratikte ufak detaylar can sıkabiliyor — bunu bilen bilir. Casio G-Shock GWR-B3000 sızdı: GravityMaster sahaya iniyor yazımızda bu konuya da değinmiştik.
Çok konuştum, örnekle göstereyim.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Düz metin dokümanı | Aşırı basit, hızlı | Zamanla unutulabiliyor |
| Notion / benzeri araç | Düzenli yapı kurmak kolay | Açık kalması gerekiyor |
| Hatırlatma odaklı mini uygulama | Sürdürülebilirlik sağlar | Kurmaya zaman ister |
| Tam otomasyonlu sistem | Neredeyse zahmetsizdir | Karmaşıklık hızla artar |
Küçük bir detay: Bu tabloya bakınca şunu görüyorsun: mesele en parlak araç değil, seni gerçekten kullandıran araçtır. Bazen sade olan kazanır. Hep böyle.
Copilot ile Yaparken Öğrendikleri Bana Ne Söylüyor?
İşin garibi, Copilot tarafındaki deneyim bence yazının en gerçekçi kısmı. Çünkü AI destekli geliştirme deyince insanlar bazen sihir bekliyor — sanki model her şeyi doğru biliyormuş gibi davranılıyor! Halbuki model sana hız verir, evet,. Yön duygusunu sen veriyorsun. Neden önemli bu? Bu farkı kavramak önemli.
Bunu geçen ay İzmir’de bir arkadaşımın SaaS prototipinde de gördüm: kodun yüzde yetmişi birkaç saatte çıktı. Son yüzde otuzda iş uzadı da uzadı… Çünkü sınırlar net çizilmemişti ve model bazen kendinden emin bir tavırla yanlış yola sapıyordu. Açık konuşayım, burada insan gözü şart (şaşırtıcı ama gerçek). Tartışmasız.
David’in anlattığı gibi farklı modeller farklı sonuç veriyor; biri işini iyi yaparken diğeri gereksiz token yakabiliyor ya da fazla konuşup az iş çıkarabiliyor — tam klasik durum bu. Ben bunu birkaç proje denemesinde fark ettim: model hızlanırken kalite düşebiliyor, ya da tam tersi oluyor, tempo yavaşlıyor. Çıktı düzeliyor. Motorola Razr 70 Sızdı: Katlanabilirde Neler Değişiyor? yazımızda bu konuya da değinmiştik.
Kod üretmek kolaylaştı mı? Evet… ama dikkatle.
Şimdi gelelim can sıkıcı tarafa: AI destekli kodlama sizi tembelleştirebilir mi? Evet. Eğer kontrol etmezseniz kesinlikle evet. David’in yaptığı gibi her satırı gözden geçirmek bence doğru refleks olmuş; üretilen kodun mantığını anlamadan ilerlerseniz teknik borcu torbaya doldurmuş olursunuz, ve o torba bir gün patlar.
# Basit bir hatırlatma akışı örneği
1) Kullanıcıya nazik bir e-posta gönder
2) Kullanıcının son giriş tarihini kontrol et
3) Boşsa tekrar hatırlat
4) Yazdıysa puan/başarı notunu kaydet
5) Haftalık özet oluştur
# Mantık basit görünüyor,
# ama asıl mesele zamanlama ve istisnalar.
Bence, Bana göre Copilot’un en iyi tarafı “ilk taslak” üretmesi — orası gerçekten işe yarıyor. En kötü tarafı ise bazen kendinden fazlasıyla emin olması. Hani yeni başlayan biri gibi değil de aşırı özgüvenli bir stajyer gibi davranabiliyor bazen. Tanıdık geldi mi?
Mikro SaaS Mantığıyla Bakınca İş Nereye Gidiyor?
Bu tarz mini ürünlerin değeri sadece gelir üretmeleri değil elbette; bazen tamamen kişisel ihtiyacı çözmeleri yeterli (ki bu çoğu kişinin gözünden kaçıyor). Peki bunu neden söylüyorum? David’in projesi de tam böyle duruyor: kendi ihtiyacından çıkmış, üzerine düşünülmüş ve yayınlanmış küçük bir araç.
Kendi açımdan bakınca bu tür projeler üç sebeple kıymetli: öğrenme hızı yüksek, kapsam dar olduğu için bitirme ihtimali artıyor ve gerçek kullanım senaryosu hemen ortaya çıkıyor (inanın bana). Bir startup’ta bunun değeri çok daha net hissediliyor çünkü herkes “işe yarıyor mu?” sorusuna hızlı cevap istiyor — uzun vadeli teorilere tahammül pek yok. DEV’in Haftanın Seçtikleri: Neden Herkes Bunları Konuşuyor? yazımızda da bu konuya değinmiştik. Apple Zirveye Çıktı: 2026’nın İlk Çeyreğinde Ne Oldu? yazımızda da bu konuya değinmiştik.
- Düşük sürtünme varsa kullanıcı devam eder. (bu kritik)
- E-posta hatırlatmaları dozunda olmalı; yoksa rahatsız edici olur.
- Kayıt ekranı kısa olmazsa alışkanlık oluşmaz.
- Zorlayıcı onboarding çoğu zaman projeyi boğar.
E tabi burada küçük bir hayal kırıklığını da söylemek lazım: böyle araçların büyük kısmı ilk heyecan geçince terk ediliyor. Çünkü alışkanlık inşa etmek ürün kadar psikoloji işi. İletişim dili, hatırlatma tonu, ne zaman ne kadar dürtüleceği… bunların hepsi ayrı bir dert aslında.
Bunu Kullanan Biri Ne Kazanır?
Garip gelecek ama, Bence en büyük kazanç özgüvenin somutlaşması. Görmediğin şeyi savunamazsın. Ama elinde tarihleriyle birlikte kayıtlı başarıların varsa görüşmeye ya da performans değerlendirmesine çok daha rahat girersin — savunmaya değil, anlatmaya hazır olarak.
Bir diğer fayda da impostor sendromunu biraz törpülemesi. Geçmişte ben kendi blogumda bunu yaşadığımda — özellikle 2024 Ocak ayında — “Ben aslında pek bir şey yapmamışım” hissine kapılıyordum. Sonra eski notlara baktım… meğer bayağı doluymuşum. İnsan kendi emeğini küçümsemeye meyilli olabiliyor, bu çok yaygın bir şey.
Kime uygun?
Kariyerinin başındaki biri için ayrı değer taşır, deneyimli biri için ayrı. Junior seviyedeyken neleri başardığını görünür kılar; senior seviyede ise etki alanını ölçmene yardım eder. Yönetici pozisyonlarında ise ekip katkısını tek tek toplamak için bayağı kullanışlı olur — kim ne yaptı, hangi dönemde, ne sonuç çıktı. Hepsini hatırlamak beklenmiyor zaten, ama kayıt altında olması başka bir şey.
Sıkça Sorulan Sorular”>
“”Brag document”, kariyer boyunca yaptığınız önemli işleri düzenli olarak kaydettiğiniz kişisel başarı dosyasıdır. Mülakatlarda,terfi görüşmelerinde ve performans değerlendirmelerinde elinizin altında hazır veri olur.”
”
“En basit yöntem tek bir dokümana tarih,proje adı,etki,öğrenilen ders şeklinde not düşmektir. Haftada 10 dakika ayırmak yeterlidir; önemli olan süreklilik.”
”
“Kısmen evet, mesela toplantı notlarından veya görev yönetim araçlarından taslak çıkarılabilir. Ama son karar sizin olmalı; çünkü bağlamı en iyi siz bilirsiniz.”
”
“Evet, özellikle ölçülebilir etki yazıyorsanız oldukça işe yarar. ‘Şu projeyi tamamladım’ yerine ‘X süresini %15 azalttım’ demek fark yaratır.”
Kaynaklar ve İleri Okuma
”
bragreminder.com GitHub Sayfasi
”
Orijinal Yazı — David Ballester Mena
”
“
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
