Geliştirici olmak için izlediğim yol

Zaman zaman birileriyle sohbet ederken “Nasıl geliştirici olunur?”, “Zaten geliştiriciyim ama kendimi nasıl daha iyi bir noktaya taşırım?” gibi sorular geliyor. Bu yazıda doğrudan bu sorulara cevap vermektense, kendi yolculuğumu, yaptığım hataları, doğruları ve yanlışları paylaşmak istiyorum. Anlatacaklarım bu konu hakkında fikir edinmenize yardımcı olacaktır diye umuyorum.

Bu yazıda anlatacaklarım:

• Yazılıma neden başladım
• Yaptığım en büyük hatalar
• İlk işe nasıl girdim
• Startup neden bana çok şey kattı
• Bugün yeniden başlasam ne yapardım

Amacım yazılım öğrenmek değil, sorun çözmekti

Öncelikle yazılıma başlama amacım, yazılımcı olmak değil de aklımdaki bir sorunu bilgisayar yardımı ile çözüp hayata geçirebilmekti. Yazılım; bunu yapabilmem için sadece bir araç görevi görüyordu. Örnek olarak Visual Basic 6.0 ile yaptığım ilk uygulamalardan birisi, fizik dersindeki formülleri hesaplamaya yarıyordu.

Daha sonra öğrendiğim Arduino ve C# ile geliştirdiğim uygulamalar da, uzaktan kumandalı aracı bilgisayardan kontrol etmeye yarıyordu.

Dolayısıyla, yazılım öğrenmedeki motivasyonumuz problem çözebilmek üzerine olmalı. Aksi takdirde yazılımı sırf öğreneyim, para kazanayım kafasıyla öğrendiğinizde hem ilerlemek çok sancılı oluyor hem de gerekli özeni göstermediğinizden süreç uzuyor.

Her şeyden azar azar ama hiçbirinden tam değil

Bu süreçte yaptığım yanlışlardan ilki, bir şeyi tam öğrenmeden yeni bir dile geçmekti. Örneğin Visual Basic’te for-while döngüsü, if-else’i vs. öğrenir hemen yeni bir dile geçerdim. Sonra da yine başka bir dile. OOP, class falan hak getire. Daha da vahim olanı, ben if-else, for-while döngüsü yazabildiğim her dili bildiğimi kabul ederdim. Framework’ler vs. hakkında en ufak bir fikrim yoktu. En fazla yapabildiğim; txt, SQLite veya AccessDB’ye veri yazıp okumaktı.

Şu an geriye dönüp baktığımda önce X dilinin her şeyini, ayrıntılarını öğrenir daha sonra başka dillere/platformlara geçerdim. Bir alanda uzman olmak, diğer alanlarda da nasıl ilerlemeniz gerektiği hakkında hem size fikir vermekte hem de daha kolay platform değiştirmenize olanak sağlamakta.

Yazılım, bisiklet sürmek gibidir

Bir kez öğrendikten sonra farklı modele geçmek çok daha kolaydır.

Buradan sonrası biraz daha backend’e kayıyor. Kendi yolculuğum ve uzmanlık alanım o tarafta şekillendiği için örneklerimi Java ekosisteminden vereceğim; yine de anlattıklarımın çoğu alan fark etmeksizin geçerli.

Frontend/mobil alanında kariyerlerinde ilerleyen arkadaşların bunu nispeten gözlemlemesi zor olsa da, backend geliştiren arkadaşlar bir süre sonra şunu fark edecekler:

Siz Java’da yazsanız, Node.js’te yazsanız, Python’da yazsanız istisnasız hepsinde:

• CRUD (create, read, update, delete) işlemleri var. Zaten yazılımın büyük çoğunluğu business rules (iş kuralı) a göre değişen CRUD operasyonları. Bunu da öğrenmek için yapılabilecek en mantıklı şey içerisinde 1-1, 1-n, n-m tablo ilişkileri bulunan bir proje yapmak.
• Controller (route, API), istekleri karşılayan ana yapı. GET, POST, PUT, DELETE metotlarının söz dizimi olarak yazılışı farklı sadece. Hepsinde path variable, request parameter vs. ortak olarak var.
• API validations yine tüm dillerde mevcut. Bazılarında şema objesi (Node.js Express) üzerinden oluyor, bazılarında anotasyon (Java) ile.
• Loglama, Swagger/OpenAPI (kodda yazdığınız API’leri tarayıp bulan ve deneme yapmanızı kolaylaştıran doküman aracı) hepsinde mevcut.
• Exception handling de yine tüm platformlarda ortak, olması gereken bir yapı.
• Authentication-Authorization (Kimliklendirme ve Rol Yetkisi), JWT token artık de facto olmuş ve projelerin büyük çoğunluğu bu standardı kullanıyor. Ek olarak OAuth2 gibi standartları kullananlar da oldukça yaygınlaştı. Neredeyse tüm diller/platformlar için kütüphanesi var.
• Scheduled / Cron Jobs Zamanlanmış işlere; rapor vs oluştururken illaki gerek oluyor.

Buradan çıkartacağımız sonuç; bir dil için yukarıdaki özelliklere sahip full+full paket bir proje yaptığınızda herhangi bir X platformuna geçip aynı şeyleri orada da uygulamanız çok basit.

Kod yazmak tek başına yeterli değil

İşveren sizden if, for, class istemiyor. İstediği tek şey var: müşterinin problemini çözmek. Kod bunun aracı, amacı değil.

Bunu geç fark ettim. Uzun süre “daha iyi kod nasıl yazılır” diye uğraştım; halbuki asıl fark yaratan şey, yazdığım kodun kime ne faydası olduğunu anlamakmış.

Yazılım sadece e-ticaret sitesi yapmak değil. Bir backend geliştirici olarak gün içinde şunları yaptığınız oluyor:

• Kredi borcunu ödeyemeyen müşterileri bulan bir sorgu yazmak
• Sisteme eksik belge yüklemiş kullanıcıları tespit edip onlara bildirim göndermek
• Milyonlarca kaydı gece çalışan bir job ile işleyip rapora dönüştürmek
• Sistemin çalışması için gerekli ortmların hazırlanması. Firewall gibi bir çok taleplerin açılması

Bunların hiçbiri algoritma sorusu değil. Hepsi bir iş kuralının koda çevrilmiş hali. Çalıştığınız alanı — bankacılık, havacılık, lojistik, ne ise — anlamadan bu işleri doğru yapmanız mümkün değil.

Bu yüzden çalıştığınız yerin işini öğrenin. Toplantıda anlamadığınız terimi sorun, “bu ekran neden var, kimin işine yarıyor” diye merak edin. Domain bilgisi, dil bilgisinden daha uzun ömürlü.

Öğrenciyken paranın miktarını önemsemek

Geriye dönüp baktığımda gözlemlediğim bir diğer hatam; paraya, deneyim kazanmaktan daha fazla öncelik vermekti. Üniversite 1. sınıfta pandeminin de araya girip okulların uzaktan eğitime dönmesi sebebiyle evde iyice canım sıkılmaya başlamıştı. Yine yukarıda belirttiğim döngüdeki gibi azıcık ondan azıcık şundan, for döngüsü, if-else falan yazar sonra da yeni dile geçerdim. Bu da bana her şeyi biliyormuşum ve işe hazırmışım gibi bir özgüven vermişti. Üniversiteden hocam ile tanıştıktan sonra kendisine staj yapabileceğim bir yer arayışında olduğumu söylemiştim. O da sağ olsun tanıdığı tecrübeli ve startup sahibi olan bir abi ile tanışmama ve sonrasında staja başlamama vesile olmuştu.

Staja başladığımda düşük bir ücretle başlamıştım ve çevremden bazı staja başlayan arkadaşlardan da benden yüksek farklı rakamlar duyuyordum. Bu motivasyonumu çok düşürüyordu. Halbuki çok şey öğreniyordum bir de üstüne para alıyordum fakat bunu o zaman için akıl edemiyordum. Aslında işletme açısından düşünecek olursak da ortada haksız bir durum yoktu. Şu an kendimi sorguluyorum ve diyorum ki acaba kendi iş yerim olsa, yalnızca ufak bir kaç şey bilen bir üniversite 1. sınıf öğrencisini alsam ne kadar para verirdim diye. Bence öğrenci/stajyer iken düşük ücretlere morali bozulan arkadaşlar kendilerini işletmenin sahibi yerine koymalı ve tekrar düşünmeli. Para yerine edindiği tecrübeden motive olmalı. Fakat mezun olduktan ve 1-2 sene tecrübe kazandıktan sonra kendinizi elbette ki piyasanın altında konumlandırmamalı ve hakkınızı aramalısınız. Çünkü o işi artık profesyonel olarak icra ediyorsunuz.

Topluluklar, teknik çıktılar kadar etkili olmayabilir

Bunu kesin bir kural olarak değil, kendi gözlemim olarak yazıyorum: topluluklarda geçirilen zaman, ortaya konan teknik çıktılar kadar karşılık bulmuyor gibi görünüyor.

Üniversitede okurken bazı topluluklarda yer aldım, eğitim verdim. Bunlardan üniversiteye ait topluluklar da vardı, üniversite dışından olan da. Aralarında en çok verim aldığım şüphesiz ki üniversite dışından olan, Hollanda ve Almanya’daki Türk yazılımcıların kurmuş olduğu FolksDEV topluluğu idi.

Topluluklardan bazı arkadaşlar, üniversiteden mezun olup iş hayatına girdiğinde konuşmacı olarak etkinliklere katılırlardı. Çoğunun söylediği, toplulukta idari görev yapmanın iş hayatında pek bir karşılığı olmadığıydı. Burada geriye dönüp baktığımda mantıklı bulduğum konu; sırf topluluğa girmiş olmak için girmek yerine o toplulukta kendi mesleki gelişimimi artıracak roller almak ve o topluluğu network aracı olarak kullanmak oldu. Tavsiyem, bu topluluklarda boşa vakit harcamayın. Eğer size bir şey katmıyorsa boşuna idari roller almayın, teknik roller üstlenin, mesleki anlamda kendinizi projeler/staj yaparak geliştirin veya okul dışında sektörden insanların oluşturduğu topluluklara katılıp gerçek network edinin.

Önerebileceğim bazı topluluklar: FolksDEV, Turkey Java Community, Devnot, Java Users Group

Çok çalışmak tek başına karşılık getirmiyor

Hiçbir zaman, çok çalıştım ve bunun kesinlikle karşılığı olacak diye bir yanılgıya düşmedim.

LinkedIn’de bazı serzeniş postları görüyorum. Adam paylaşıyor, YouTube’daki tutorial’dan bakarak HTML-CSS-JS website tasarlamış ve diyor ki “Aylardır proje yapıyorum hala iş yok”. Başka birisi; React ile in-memory çalışacak, API bile çağırmayan proje yapmış yine aynı serzenişi söylüyor. Kendi fikrimce buradaki en büyük yanılgı, sektörün ihtiyacı olmayan bir şeyi öğrenmeye vakit ayırıp karşılık aramak. Eğer millet React ile Next.js ile API’ye istek atıp işlemler yapıyor, login-logout JWT mekanizması ekliyor, Next.js, Supabase vs. ile uçup kaçarken; sen gidip de HTML-CSS-JS ile 6 aydır proje yapıyorum iş yok dersen sana “….. git” derler.

Burada kilit konu sektörden arkadaşlar edinip veya üniversiteden hocalara danışıp hangi teknolojinin sektörde tercih edildiğini öğrenmek. Ek olarak hocalara danışma meselesinde de dikkat etmek gerek. Çünkü akademi ile gerçek hayattaki durumlar çoğu zaman birbiri ile örtüşmüyor. Aksi takdirde hala Visual Basic yazan bir hoca sektörde Java kullanılmıyor diyebilir ve hayatınızı yanlış etkileyebilir.

Sonuç olarak çalışmanın her zaman karşılığını alacağını beklemek yerine yaptığımız çalışma doğru mu diye sorgulayıp ilerlemek daha güzel bir yöntem olabilir.

Yetiştirilmek üzere iş arıyorum

Diğer mesleklerde durum farklı olabilir ama bilgisayar mühendisliğinde sen kendi kendini yetiştirmeli, çabalamalısın. Kimsenin sana 0 dan bir şey öğretme gibi bir zorunluluğu yok! Sen çabala, çabanı gören insanlar zaten yardım edecektir.

Bir diğer mantıksız bulduğum olay LinkedIn’de “Selam X üniversitesi mezunuyum, Y alanında yetiştirilmek üzere iş/staj arıyorum.” diyerek yapılan paylaşımlar.

Sevgili arkadaşım, kendini bir işveren yerine koy ve birinin sana gelip “ben hiç bir şey bilmiyorum, yetiştirilmek üzere iş arıyorum ama bana iyi para da vermelisin, üstüne ben işi öğrendikten 1 sene sonra maaşı beğenmeyip seni bırakıp gideceğim ve tecrübe ile kazandığım para da yanıma kar kalacak” dese, nasıl cevap verirdiniz? Böyle bir durumdaki arkadaşın iş bulma olasılığı çok düşük.

Almadan vermek, Allah’a mahsustur

— bir işveren atasözü

Burada kendimce yapılabilecek en mantıklı hareket öncelikle birçok proje geliştirip işverenin karşısına dolu dolu çıkabilmek. Bir şeyler yapabildiğinizi göstermek. Elbette ki işveren yeni mezundan çok bir şey bekleyemez ama hiçbir şey bilmeyen bir adama da para vermek sizce ne kadar doğru? Siz olsanız verir miydiniz? İşletmeler kar amacı güder, kimsenin bize hayır yapma, yardım etme gibi bir misyonu yok (yapan iyi insanlara selam olsun)!

İlk işe/staja girmeyi kolaylaştırmak için alınabilecek aksiyonlar

• İş/staj deneyimi olmasa bile sürekli projeler yapıp GitHub’da paylaşmak. Eğer proje geliştirme konusunda eksiğiniz var ise YouTube’dan tutorial izleyip aynılarını yapmak. Eğer biraz kendinizi geliştirdiyseniz X Clone, Y Clone gibi projeler yapıp bunlara kendinizden bir şeyler katmak.
• Üniversite boş diyenlere aldırmayıp; üniversitedeki arkadaşlarınızın, üst dönemlerin, topluluktan tanıştığınız kişilerin veya hocalarınızın network’ü aracılığı ile iş aramak.
• İlk işleriniz için maaş beklentinizi düşük tutmak. Bu demek değil ki ileride de maaşım düşük olacak. Çoğunluğun 35-40 bin istediği yerde 25-30 civarı isterseniz işe girme olasılığınız artabilir.
• Üniversite birinci sınıftan itibaren staja başlayıp deneyim kazanmak.
• Eğer LinkedIn’den iş arayışınızı paylaşacaksanız kesinlikle “ilgilenen olursa CV’mi iletebilirim” tarzı ifadeler kullanmayın. Doğrudan CV’nizi, bilgilerinizi paylaşımın içine ekleyin. İnsan kaynaklarının size ulaşmasını kolaylaştırın. İnsan kaynakları ve müdür pozisyonundaki kişileri ağınıza ekleyin. Asla “yetiştirilmek üzere” ifadesini kullanıp kendinizi işverene karşı güçsüz göstermeyin.
• İnternetten mülakat sorularına çalışmanız mülakatın iyi geçme olasılığını artırır. Ek olarak her mülakattan çıktıktan sonra bilmediğiniz konuları, soruları not alın ve o akşam çalışın. Reddedilseniz bile o mülakat size sektörün sizden ne beklediğini göstermiş oldu. Her mülakat benim için ücretsiz bir eğitim oldu; ikinci görüşmede, ilkinde takıldığım soruyu cevaplıyor oluyordum.
• Doğrudan firmaların bünyesine girmektense dış kaynak olarak işe başlayıp zaman içerisinde firmaya geçmeyi deneyin. Burada önerebileceğim daha önce çalıştığım iki firma var. Biri Metasis diğeri Experilabs. Çalışmadığım fakat adını sıkça duyduğum yerler ise: RDC, OBSS, Infonal, Mirsis.
• Geliştirdiğiniz projeleri düzgün bir README ile anlatın. Depoya girildiğinde okunan ilk şey o: proje ne işe yarıyor, nasıl çalıştırılır, hangi teknolojiler kullanılmış, varsa bir ekran görüntüsü. Kodu baştan sona okumaya kimsenin vakti yok ama README’yi herkes okuyor. Markdown öğrenmek yarım saatinizi alır ve projelerinizi bir anda ciddi gösterir.
• Medium’da öğrendiğiniz bilgileri makale şeklinde paylaşın. Yaptığınız projeleri, yazdığınız makaleleri LinkedIn’de paylaşın.

İlk işime startup’ta başlamak

Geriye dönüp baktığımda yaptığım en mantıklı hareket neydi diye soracak olursanız, muhtemelen bu derdim. İlk işinize startup’ta başladığınızda; production ortamının veritabanı şifresi de dahil olmak üzere birçok konuda bilgi sahibi olur, bir çok farklı alanda çalışmalar yaparsınız. Bu sayede büyük resmi görebilme imkanınız da olur.

Eğer ilk işinize kurumsalda başlarsanız muhtemelen çok büyük bir organizasyonun ufak bir parçası olacaksınız. Gidip de X, Y, Z ihtiyacınız olduğunda bunu siz değil bunun için özel olarak ayrılan ekipler yapacak ve siz arkada ne olup bittiğinin farkına bile varmayacaksınız.

Startup’ta ilk işe başlamanın bir diğer artısı da; yoğun tempoya alışıp kurumsal firmaya geçtiğinizde rahatlama yaşayacak olmanız. Diyeceksiniz ki adamlar ne basit tasklara kaç günlük eforlar veriyor. O taskları havada karada yapacaksınız. Farkınızı emin olun göstereceksiniz. Bir de olduğunuz yerden çok yüksek ihtimalle memnun olup bir daha startup’a geçmeyi falan düşünmeyeceksiniz. Ama ilk defa kurumsalda işe başlayan arkadaşlar muhtemelen sahip oldukları nimetin farkında olmadığından mutsuz olacaklar. Belki de daldan dala ufak paralar için atlayacaklar.

ölümü görüp sıtmaya razı olmak (!)

Tabii bu benim yolum. Kurumsalda başlayıp çok iyi yerlere gelen bir sürü insan tanıyorum; sadece startup’ın bana kattığını başka türlü edinmem zor olurdu, uzun sürerdi.

Yazılımda en önemli beceri kendi kendine öğrenebilmek

Üniversitede veya kursta size her şeyi kimse öğretmeyecek. Bir problemle karşılaştığınızda doğru anahtar kelimeleri aratabilmek, dokümantasyonu okuyabilmek ve yabancı kaynaklardan faydalanabilmek zamanla sizi diğerlerinden ayırıyor.

Pratikte kullandığım kaynaklar, sırasıyla:

• Google — ilk durak, ama nasıl arattığınıza bağlı. “How to search Google” diye bir araştırın.
• Resmi dokümantasyon — en doğru, en güncel ve en az okunan kaynak
• Stack Overflow — aynı hatayı sizden önce almış birileri var
• W3Schools — unuttuğunuz söz dizimini hızlıca hatırlamak için
• YouTube — bir şeyi ilk defa uçtan uca görmek için

Google kullanmayı öğrenmek

Yeni başlayanların en büyük problemi bu. Yazılımcıların büyük kısmı kod ezberlemez, problemi nasıl arayacağını bilir.

Şöyle aratırsanız bir yere varamazsınız:

java hata

Şöyle aratırsanız çoğu zaman ilk sonuçta cevabı bulursunuz:

spring boot datasource bean not found
postgres docker permission denied

Aradaki fark şu: ikincisinde hatanın kendi cümlesini arıyorsunuz. Konsoldaki mesajı olduğu gibi kopyalayın, içinden size özel kısımları (dosya yolu, kullanıcı adı, id) atın, geri kalanını aratın. Bu alışkanlık tek başına hata çözme sürenizi ciddi biçimde kısaltıyor.

İngilizce bilmeden yazılımcı olunur mu?

Olunur. Ama üç yerde zorlanırsınız:

• Dokümantasyonu okuyamazsınız. Ciddi kütüphanelerin çoğunun Türkçe kaynağı yok, olanı da genelde eski.
• Hataları çözmeniz zorlaşır. Aldığınız hata mesajı İngilizce, cevabı da İngilizce.
• Topluluklardan geri kalırsınız. Yeni bir şey çıktığında Türkçe içeriğin gelmesi aylar alıyor.

Kendi gelişimimde en çok hızlandığım dönem, aramalarımı Türkçe yapmayı bırakıp doğrudan İngilizce aramaya başladığım dönem oldu. Konuşma seviyesinde İngilizce şart değil; okuduğunu anlayacak kadarı yeterli. Gerisi zaten doküman okuya okuya geliyor.

Yeni başlıyor olsaydım yapay zekayı tarayıcıdan kullanırdım

Bugün sıfırdan başlıyor olsaydım, kodlamayı hiç bilmezken ya da çok az bilirken yapay zekayı terminalden Claude Code gibi araçlarla veya IDE’nin içinde Copilot ile kullanmazdım.

Bunun yerine tarayıcıdan sorardım. Gelen cevabı okur, anlamaya çalışır, kodu ya kopyalar ya da elle yazardım. Doğru sınıfı nereye koyacağımı, hangi yapıyı kullanmam gerektiğini kendim bulmaya uğraşır, zihnimi yorardım. Çünkü yaparak hakim olunuyor.

Aradaki fark şu: terminalden veya IDE’nin içinden kullandığınızda araç dosyaları kendisi açıyor, kodu kendisi yazıyor, kendisi çalıştırıyor. İş bitiyor ama sizde bir şey kalmıyor. Tarayıcıda ise araya siz giriyorsunuz; kodu taşımak, doğru yere koymak, çalışmadığında nedenini bulmak zorundasınız. İşte o zorunluluk öğrenmenin kendisi.

Temeli attıktan sonra elbette bu araçların hepsini kullanın, gerçekten hız kazandırıyorlar. Ama öğrenme aşamasındayken kendinize bu kolaylığı tanımayın.

Keşke yapmasaydım dediklerim

Yazı boyunca dağınık şekilde anlattıklarımı bir arada toplayayım:

• Öğrenciyken maaşı fazla önemsemek. Stajda öğrendiğim şeyin değeri, aldığım rakamın çok üstündeydi; o zaman göremedim.
• Her dilden biraz öğrenmek. if-else yazabildiğim her dili bildiğimi sanıyordum. Bir dili sonuna kadar götürmek, hepsinden yarım bilmekten kıyaslanamayacak kadar değerliymiş.
• Business tarafını ihmal etmek. Yazdığım kodun kime ne faydası olduğunu geç anladım.
• Saatlerimi yalnızca algoritma sorularına gömmek. Bir dönem HackerRank ve LeetCode tarzı sitelerde epey vakit geçirdim.

Sonuncusunu biraz açayım, çünkü yanlış anlaşılmaya müsait: sorun bu soruları çözmek değil, başka hiçbir şey yapmadan onları çözmekti. Eğer hedefiniz FAANG benzeri şirketler değilse, gerçek bir proje geliştirmek çoğu zaman daha fazla katkı sağlıyor. Algoritma sorusu mülakatın bir bölümünü geçirtir; proje ise size anlatacak bir hikaye, gösterecek bir repo ve mülakatta konuşacak bir konu verir. İkisini de yapın, ama sıralamayı doğru kurun.

Sektördeki son gelişmelerden haberdar olmak

Bunu yapabilmek için aşağıdaki yöntemleri tercih edebilirsiniz:

• O dil/platform hakkında özelleşmiş toplulukları ve topluluktaki kişileri LinkedIn, X gibi mecralardan takip etmek
• LinkedIn’de ilgili gruplara katılmak
• YouTube’da paylaşım yapan, o platform ile alakalı kanalları takip etmek

Araştırabileceğiniz konular

Bu yazıda hepsine değinmedim. Aşağıdaki kavramları zaman içinde araştırıp öğrenmeniz faydalı olacaktır. Hepsini bir anda öğrenmeniz gerekmiyor, sırayla gidin. Her birinin yanına ne olduğunu kabaca yazdım ki araştırmaya başlarken kaybolmayın.

Temel

• Frontend / Backend / Fullstack —önyüz, sunucu, önyüz+sunucu
• HTTP / HTTPS — tarayıcı ile sunucunun konuşma dili, HTTPS onun şifreli hali
• REST API — iki sistemin birbirine veri iletirken kullandığı en yaygın yöntem
• JSON — o verinin taşındığı, hem insanın hem makinenin okuyabildiği format
• Git ve GitHub — kodun geçmişini tutan sistem ve onu paylaştığınız platform
• Markdown — README ve dokümantasyon yazdığınız basit metin formatı
• SQL — veritabanından veri sorgulama dili; önce bunu, sonra ORM’leri öğrenin

Orta seviye

• NoSQL (MongoDB, Redis) — tablo yapısına uymayan veriyi saklama yaklaşımları
• JWT — kullanıcı giriş yaptıktan sonra kimliğini doğrulamak için kullanılan token yapısı
• OAuth2 — “Google ile giriş yap” gibi akışların arkasındaki yetkilendirme standardı
• Docker — uygulamayı her ortamda aynı şekilde çalıştırmayı sağlayan container teknolojisi
• Postman — yazdığınız API’yi arayüz olmadan deneyebildiğiniz araç
• Linux — sunucuların büyük çoğunluğunun işletim sistemi; en azından temel komutları
• NGINX — gelen istekleri karşılayıp uygulamanıza yönlendiren web sunucusu
• DNS — alan adını sunucunun IP adresine çeviren sistem
• SSL/TLS — trafiği şifreleyen ve adres çubuğundaki kilidi getiren sertifika katmanı

Daha sonra

• CI/CD (GitHub Actions, GitLab CI) — kodu her gönderdiğinizde otomatik test edip yayına alan akış
• Redis — sık kullanılan veriyi bellekte tutup uygulamayı hızlandıran veritabanı
• Kafka / RabbitMQ — sistemler arasında yüksek hacimli mesajlaşmayı sağlayan platformlar (message brokers)
• WebSocket — sunucunun istemciye anlık veri gönderebilmesini sağlayan bağlantı türü
• Kubernetes — çok sayıda container’ı ayakta tutan ve ölçekleyen orkestrasyon aracı

Java özelinde tavsiye edebileceklerim

Web siteleri

• javagyansite.com
• vinsguru.com
• javarevisited.blogspot.com
• java67.com

Kişiler

• Robert C. Martin — Clean Code ve Clean Architecture’ın yazarı; kod kalitesi ve mimari üzerine
• Martin Fowler — refactoring, mikroservisler ve kurumsal mimari kalıpları üzerine
• Venkat Subramaniam — modern Java, fonksiyonel programlama ve JVM dilleri üzerine
• Lemi Orhan — Git, yazılım zanaatkarlığı ve ekip pratikleri üzerine

Topluluklar ve YouTube kanalları

• FolksDEV
• Turkey Java Community
• Java Users Group
• Devnot
• Devoxx
• Çağkan Kantarcı
• Bouali Ali
• Daily Code Buffer
• Amigos Code
• Dan Vega
• Siva Labs
• Programming Techie

Bugün başlıyor olsaydım: 30 günlük yol haritası

Yazı boyunca çok şey anlattım. Hepsini bir kenara bırakıp “peki yarın sabah ne yapayım” diye soracak olsanız, sıralamam bu olurdu.

Otuz günün sonunda elinizde çalışan bir proje, yayında bir site, dolu bir GitHub ve derli toplu bir LinkedIn olur. Bu, “yetiştirilmek üzere iş arıyorum” cümlesinden çok daha güçlü bir giriş.

Son olarak

Aynı yolu yürümek zorunda değilsiniz. Yazının başında söylediğim gibi hepsini mantık süzgecinden geçirin ve sadece size uyanları alın.

Eğer bu yazıdan tek bir fikir alacaksanız şu olsun: yazılım öğrenmeye çalışmayın, problem çözmeyi öğrenin. Teknolojiler değişecek, diller değişecek, yapay zeka daha da gelişecek. Ama bir problemi analiz edip çözebilen insanlar her zaman değerli olacak.