İşin açık tarafı, teknoloji topluluklarında en sevdiğim şeylerden biri şu: yıllarca kenardan izleyip bir gün “tamam, artık ben de konuşuyorum” diyen insanlar. Thabang Gideon Magaola’nın Dev.to’daki ilk yazısı da tam olarak bu duyguyu taşıyor (en azından benim deneyimim böyle). Gürültü yok. Kasıntı yok. Sadece “ben buradayım ve öğrenmeye devam ediyorum” havası var — ve bence bu bayağı samimi bir başlangıç, yani gerçekten.
Dürüst olmak gerekirse, Ben de yıllar önce, 2012’nin sonlarında İstanbul’da küçük bir ofiste çalışırken benzer bir hissi yaşamıştım. O zamanlar blog yazmak gözümde kocaman bir işti; sanki. Her şeyi biliyorsan yazabilirsin, aksi halde ağzını açma diye bir kural varmış gibi geliyordu. Sonra anladım ki mesele bilgi gösterisi değil, öğrenme sürecini paylaşmakmış — hem de tam olarak o haldeyken. Thabang’ın yaptığı da biraz bu: tüketen taraftan üretken tarafa geçmek. Küçük adım, ama doğru yön.
Durun, bir saniye.
Bir geliştiricinin ilk selamı neden önemli?
Dışarıdan bakınca “tanıtım yazısı işte” deyip geçebilirsiniz. Haksız da sayılmazsınız. Ama böyle ilk paylaşımlar aslında çok şey anlatıyor — bir insanın nasıl düşündüğünü, hangi araçlarla çalıştığını, topluluğa nasıl yaklaşacağını daha ilk andan okuyabiliyorsunuz. Bu özellikle teknik topluluklar için önemli çünkü iyi kod kadar iyi iletişim de değerli, hatta bazı noktalarda daha da değerli.
Thabang’ın yazısında beni çeken şeylerden biri, kendini olduğundan büyük göstermemesi oldu (yanlış duymadınız). Full-stack olduğunu söylüyor ama bunu “ben her şeyi hallettim” havasıyla yapmıyor. Tam tersine, hâlâ öğrenen biri gibi konuşuyor — ve açık konuşayım, bu tavır bana çok daha fazla güven veriyor. Çünkü gerçek hayatta en sağlam geliştiriciler genelde sorusunu saklamayanlar oluyor. İddialı ama mütevazı olan tipler, yani.
2024’te Cape Town’dan uzaktan çalışan bir ekip için içerik editörlüğü yaparken buna çok benzer profillerle karşılaştım. En iyi katkıyı yapanlar çoğu zaman en çok bağıranlar değildi; sessizce not tutanlar, sonra net ve temiz şekilde paylaşanlardı (en azından benim deneyimim böyle). Thabang’ın “ben de katkı vermek istiyorum” yaklaşımı tam o kategoriye giriyor bence.
Sessiz gözlemci olmaktan üreticiye geçiş
Zor geliyor bazen. Topluluklara girmek, yani. En çok da teknik konularda herkesin her şeyi bildiği sanılıyor ya — o hava biraz bunaltıcı olabiliyor, kabul edelim. Ama işin aslı şu ki kimse baştan uzman doğmuyor (buna dikkat edin). Öğrenirken paylaşmak da zaten başlı başına bir beceri ve çoğu insan bunu hiç geliştiremeden geçiyor üstünden.
“Önce tüketici oldum, şimdi katkı veren tarafa geçiyorum” cümlesi küçük görünüyor olabilir ama teknik topluluklarda en sağlıklı dönüşüm tam da bu.
Kullandığı teknoloji yığını ne anlatıyor?
Thabang’ın listesi klasik ama sağlam duruyor. Java, JavaScript, TypeScript; ön tarafta React; arka tarafta NestJS ve GraphQL; veri tarafında PostgreSQL, MySQL ve MongoDB; DevOps tarafında Docker, Git ve Jenkins. Masası bayağı dolu yani. Tek bir oyuncakla oynamıyor.
Peki neden?
Böyle bir set bana hep şu soruyu düşündürür: “Bu kişi her şeyi biraz mı biliyor, yoksa gerçekten uçtan uca ürün çıkarabiliyor mu?” Hmm (ciddiyim). Eğer doğru kurgulanmışsa ikinci seçenek çok daha güçlüdür — özellikle startup ortamında bu tarz geniş yetenek seti altın değerinde oluyor çünkü aynı kişi hem API’yi kurup hem arayüzle uğraşıp hem de deploy zincirini anlayabiliyor, sabah planladığını akşam canlıya alabiliyor.
| Bileşen | Ne işe yarıyor? | Pratik yorum |
|---|---|---|
| Java / TypeScript | Dil temeli | Biri kurumsal dünyaya yakın durur, diğeri modern web akışını hızlandırır |
| React + Flowbite | Arayüz katmanı | Daha hızlı prototip çıkarmak için iş görüyor |
| NestJS + GraphQL | API katmanı | Düzenli mimari isteyen projelerde bayağı rahatlatır |
| Docker / Jenkins / Git | Teslimat hattı | Ekip büyüdükçe asıl fark burada ortaya çıkar |
Neyse uzatmayalım… Bu kombinasyonun güzel yani esnekliği ama eksik yani da var — yüzeysel kalma riski hiç küçümsenmemeli. Her şeyi biraz bilmek harika görünür dışarıdan fakat derinlik olmadan bazı projelerde ciddi şekilde tıkanırsınız. Mesela GraphQL ile rahat çalışan biri REST’te bir düşüneyim… tökezleyebilir, ya da Jenkins’i kullanan biri pipeline mantığını ezbere bilir. Sorun çıktığında neyin bozulduğunu ayıklayamaz. Bu gerçek bir risk.
Küçük ekipte avantaj, büyük ekipte sınav
Küçük bir startup’ta böyle biri çok rahat parlıyor çünkü karar alma hızlı, çapraz beceriler doğrudan üretime dönüyor. Enterprise seviyede ise işler değişiyor; orada uzmanlık kadar süreç bilgisi de lazım oluyor — ve evet, bazen prosedürler can sıkıcı olabiliyor ama o kısmı atlayamazsınız.
Bi saniye — Bana göre Thabang’ın profili startup dünyasında hemen değer üretecek tipte duruyor. Kurumsal tarafta ise biraz daha sistem tasarımı ve ölçekleme deneyimi isterdi diye düşünüyorum — bu konuda %100 emin değilim açıkçası, ama sanırım birçok full-stack geliştiricinin yolu aynı: önce geniş alan kaplanıyor, sonra bazı bölgeler derinleşiyor. Zamanla.
Neden topluluğa katılmak hâlâ önemli?
Dijital çağda bilgi bol ama dikkat azaldı. Garip bir denklem bu. Tam bu yüzden toplulukların önemi artıyor. Insanlar sadece cevap değil bağlam da arıyor — “nasıl yapılır” kadar “neden böyle yapılır” sorusunu soran insanlar var artık her yerde. Dev.to gibi yerlerde yazmak ise yalnızca makale yayımlamak değil; düşünme biçimini görünür kılmak demek.
Peki neden?
Editör masasında geçen ay Ankara’da okuduğum birkaç yeni başlayan geliştirici yazısına baktığımda aynı şeyi fark ettim yeniden. İyi içerik illa kusursuz olmak zorunda değil. Dürüst olmak zorunda. İnsanlar mükemmel çözümü değil gerçek yolculuğu seviyor çoğu zaman — bu değişmiyor. ₹12 LPA Alan Yeni Mezunun Gerçek Beceri Paketi: Ne Öğrenmişti? yazımızda bu konuya da değinmiştik.
- Sorularınıza hızlı geri dönüş alırsınız.
- Aynı problemi yaşayan insanlarla tanışırsınız.
- Kendi öğrendiklerinizi kalıcı hale getirirsiniz.
- Zamanla portföyünüz sessizce büyür. (bu kritik)
Ha bu arada şu kısmı atlamamalıyım: Toplulukta aktif olmak bazen moral bozucu da olabiliyor. İlk paylaşımınıza beklediğiniz ilgi gelmeyebilir. Hatta hiç gelmeyebilir! Bu normaldir çünkü teknik içerikte görünürlük bazen zamana yayılıyor — biraz sabır işi yani. Ben kendi blogumda bunu defalarca yaşadım; ilk aylarda üç kişi okurken altıncı ayda eski notların trafik getirmeye başladığını gördüm. Beklenmedik bir şekilde.
Sadece araç listesi yetmez — süreç tarafı da lazım
Thabang Agile geliştirme yaklaşımını özellikle vurguluyor. Bence burası önemli bir detay. Çünkü modern stack’in yarısı araçsa diğer yarısı çalışma kültürü oluyor — yazılımda bazen herkes framework konuşuyor. Sprint planlaması aksayınca bütün yapı çöküyor. Siz hiç denediniz mi? Hani o meşhur “kod güzel ama teslim yok” hali vardır ya, tam o. Daha fazla bilgi için CSS Animasyonlarında Doğrulama: 2026 İçin Teknik Rehber yazımıza bakabilirsiniz. Bu konuyla ilgili RGAA’da %62 Otomasyon: Erişilebilirlikte Yeni Oyun Planı yazımıza da göz atmanızı tavsiye ederim.
Kendi adıma şunu söyleyebilirim: Şubat 2023’te İzmir’deki freelance projemde React tarafını hızlıca toparladık ama test süreci zayıf kaldığı için son hafta iki kere geri dönüş yapmak zorunda kaldık. Kod iyiydi aslında. Sorun süreçteydi. O yüzden Agile benim gözümde laf olsun diye söylenen bir kelime değil; doğru uygulanırsa ekibi ayakta tutuyor, yanlış uygulanırsa sadece toplantı sayısını artırıyor.
Tamam güzel de nerede eksik kalabilir?
Açık konuşayım. Böyle giriş yazılarının en büyük riski fazla genel kalmalarıdır. Teknoloji listesi verirseniz okuyucu sizi tanır gibi olur ama gerçekten tanımaz. Biraz kişisel proje detayı olsaydı — mesela hangi problem üzerine çalıştığına dair küçük ipuçları verseydi — etki çok daha kuvvetli olurdu.
Bilmem anlatabiliyor muyum, Ayrıca React ile Zustand veya GraphQL ile gerçek dünya performans problemleri hakkında minicik örnekler görmek isterdim. Çünkü araç isimleri tamamdır. Asıl merak edilen şu oluyor: bu araçlarla hangi acıyı çözmüşsün? Hangi bug seni gece yarısı uyutmamış? İşte orası hikâyeyi insanileştiriyor. Orası okuyucuyu bağlıyor.
- Kimin olduğunuzu söyler;
- Nerede güçlü olduğunuzu gösterir;
- Neyi henüz öğrenmekte olduğunuzu saklamaz.
Benden küçük notlar: Ben olsam ne beklerdim?
Biraz editör gözüyle bakıyorum burada, tabi (bizzat test ettim). Eğer ben Thabang’ın yerine olsaydım sonraki yazıda mutlaka mini vaka analizi koyardım. “React + NestJS ile nasıl panel yaptım”, “Jenkins pipeline’da ne patladı”, ya da “GraphQL sorgularını nasıl optimize ettim” gibi somut konular okuyucuyu yakalar — soyut listelerden çok daha fazlası.
Mersin’de geçen yıl konuştuğum genç bir geliştirici vardı — adı Emre’ydi — o da ilk blogunda sadece teknolojileri saymıştı (ki bu çoğu kişinin gözünden kaçıyor). İkinci postta ise tek bir hata mesajını adım adım çözmüştü. İlkinden üç kat fazla okunmuştu. Bir düşünün. Demek istediğim şu: hikâye varsa okunurluk geliyor, yoksa ne kadar iyi araç listesi de yapsan kayıp gidiyor.
// Basit düşünce akışı
if (problem === "genel tanıtım") {
console.log("Okur seni tanır.");
} else if (problem === "gerçek olay") {
console.log("Okur sana bağlanır.");
} else {
console.log("İkisi birlikteyse zaten taş gibi içerik çıkar.");
}Bazen içerikte teknik doğruluktan önce ritim gerekiyor (yanlış duymadınız). Cümlenin nefes alması lazım. Kimi yerde kısa kesersiniz, kimi yerde uzun uzun açarsınız — işte o dalgalanma metni canlı tutuyor. Düz giden yazı, düz giden kod gibi: çalışır ama sıkar.
Sıkça Sorulan Sorular
Dev.to’ya ilk kez yazmak neden faydalıdır?
Çünkü hem görünürlük sağlar hem de öğrendiklerinizi düzenler. İlk yazılar kusursuz olmak zorunda değildir;asıl amaç düşüncenizi dışarı çıkarmaktır. Zamanla bu alışkanlık portföyünüzün gizli gücü olur.
Tam stack geliştirici olmak için büyük çoğunluk teknolojileri bilmek gerekir mi?
Hayır,gerekmez. Önemli olan her katmanda yeterince rahat olup belirli alanlarda derinleşebilmektir. Başlangıçta geniş yelpaze normaldir,sonra doğal olarak bazı alanlara ağırlık verirsiniz.
Açık kaynak topluluklarına yeni başlayan biri nasıl katkı verir?
Küçük başlayın:düzeltme önerisi yapın,belge okuyun,küçük hata raporu açın veya deneyiminizi paylaşın. Büyük katkılar çoğu zaman küçük adımlarla gelir. En kritik nokta düzenliliktir.
Sadece teknoloji listesini paylaşmak yeter mi?
Kendi deneyimimden konuşuyorum, Pek sayılmaz. Liste iyi bir başlangıçtır ama okurun sizi hatırlaması için örnek proje, sorun çözme biçimi. Kişisel gözlem gerekir. Kısacası araçları değil kullanım hikâyesini anlatmak daha etkili olur.
Kaynaklar ve İleri Okuma
Açıkçası, Dev.to Resmi Sitesi
AI PR’ler Hızlıdır:Neden Yine de İnsan Gözü Şart?
Server-Sent Events:Sessiz Akan Veri,Düzgün Çözülen Meseleler
Yapay Zekâ İş Arama Ajanı:Dedalus ile Yeni Katman
@endsection
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.
