John Ousterhout'un "A Philosophy of Software Design" kitabını bitirdim. Notlarımı toparlarken fark ettim ki kitabın anlattığı çoğu şeyi zaten biliyordum, ama bilmekle onu bir çerçeveye oturtmak arasında ciddi bir fark var. Kitap, yıllardır kod yazarken sezgisel olarak hissettiğim ama hiç isimlendirmediğim şeylere isim koydu. Bu yazı bir kitap özeti değil, daha çok kendi kod tabanımda ve data migration takımındaki işlerimde nerede karşıma çıktığını düşünerek yazdığım bir okuma günlüğü. ## **Karmaşıklık tek bir hatadan gelmez** Ousterhout'un ilk tezi basit: > Karmaşıklık, kodun anlaşılmasını ve değiştirilmesini zorlaştıran her şeydir. Ve neredeyse hiçbir zaman tek bir büyük hatadan gelmez. Küçük küçük birikir. Bir yerde kötü bir değişken adı, bir yerde eksik bir yorum, bir yerde gereksiz bir bağımlılık. Bunun karşılığı **"sıfır tolerans"** felsefesi. Küçük bir karmaşıklık gördüğünde "zaten kod öyle, dokunmayayım" demek yerine düzeltmek. Bunu çalıştığım proje üzerinde çalışırken fark ettim. Import mantığı zamanla o kadar çok küçük özel durum biriktiriyor ki, her biri tek başına zararsız görünüyor ama toplamda kod tabanını okunmaz hale getiriyor. ## **Taktik tornado ile tanışma** Kitaptaki en çarpıcı kavramlardan biri **"taktik tornado"**. Çok hızlı kod yazan, sürekli özellik teslim eden ama arkasında temizlenmesi gereken bir yıkım bırakan geliştirici tipi. Yöneticiler onu kahraman sanıyor, ama gerçekte diğer mühendisler onun bıraktığı dağınıklığı topluyor. Bunu okurken kendi kariyerimde hem bu role yaklaştığım hem de arkasını toplamak zorunda kaldığım dönemleri düşündüm. Startup baskısı altında _"önce çıkaralım sonra düzeltiriz_ " mantığı çok tanıdık geliyor. Kitap bunun bir yanılsama olduğunu söylüyor: iyi tasarım aslında daha hızlı teslimat demek, kısa vadede değilse bile birkaç ay içinde. Sayı da veriyor: > Geliştirme süresinin yüzde on ila yirmisini tasarıma yatırım olarak ayırmak, projeyi önemli ölçüde geciktirmiyor. Bu oranı bilinçli tutmak, "zamanım yok" bahanesine karşı elle tutulur bir karşılık. ## **Derin modüller, sığ modüller** Kitabın omurgası bu kavram. Bir modülün değeri, sunduğu işlevsellik ile arayüzünün karmaşıklığı arasındaki orana bakılarak ölçülüyor. Basit bir arayüzün arkasında güçlü bir işlevsellik varsa, o modül derin. Karmaşık bir arayüzün arkasında az bir şey varsa, sığ. Unix'in dosya sistemi çağrıları (open, read, write, lseek, close) klasik örnek. Beş fonksiyon, arkasında devasa bir karmaşıklık gizli. Buna karşılık kitap **"classitis"** dediği bir hastalığı eleştiriyor: her şeyi küçük küçük sınıflara bölme takıntısı. Küçük sınıflar iyi diye düşünülür ama sistem seviyesinde tam tersi oluyor, çok fazla sığ parça birbirine bağımlı hale geliyor. Bu kısmı okurken **"boring Rails"** yaklaşımıma çok yakın buldum. Rails ekosisteminde her problem için yeni bir soyutlama katmanı, yeni bir service object, yeni bir gem eklemek cazip geliyor. Ama bazen en derin modül zaten elimizdeki, sade Active Record modelidir. Soyutlama eklemek karmaşıklığı azaltmıyorsa, o soyutlamayı hiç eklememek daha iyi. ## **Bilgi gizleme ve bilgi sızıntısı** Bir tasarım kararı birden fazla modüle yayılmışsa, bilgi sızıntısı var demektir. Kitabın verdiği örnek zamansal ayrıştırma: bir işlemi zaman sırasına göre (önce oku, sonra işle, sonra yaz) sınıflara bölmek, çünkü okuma ve yazma sınıfları genelde aynı formatı bilmek zorunda kalıyor. Bunu import araçlarında sık görüyorum. Farklı kaynak formatlarını okuyan kod ile bu veriyi veritabanına yazan kod arasında format bilgisi ileri geri sızabiliyor, format değiştiğinde iki yerde de değişiklik gerekiyor. Kitap bunun çözümünü zaman sırasına değil bilgiye odaklanarak tasarlamak olarak öneriyor. ## **Karmaşıklığı aşağı çekmek** Bir modülde kaçınılmaz bir karmaşıklık varsa, onu kullanıcıya (ya da çağıran kodlara) yansıtmak yerine modülün içine gömmek gerekiyor. Kitabın kuralı net: bir modülün basit bir uygulamaya sahip olmasından çok basit bir arayüze sahip olması önemli. Çünkü bir modülün kullanıcı sayısı genelde geliştirici sayısından fazla. Bunun en somut örneği konfigürasyon parametreleri. Emin olamadığın her şey için bir ayar eklemek, aslında kararı erteleyip başka birine (genelde sistem yöneticisine ya da gelecekteki kendine) devretmek. Kitap şunu soruyor: > Kullanıcı bu değeri gerçekten benden daha iyi belirleyebilir mi? Çoğu zaman cevap **hayır**. ## **İki kere tasarlamak** Bu bölüm bana en çok dokunan yerlerden biriydi. Önemli bir tasarım kararı için en az iki farklı alternatif düşünmek, her birinin arayüzünü kabaca çizmek, artı eksilerini karşılaştırmak. İlk fikrin zaten en iyisi olsa bile bu süreç seni çok şey öğretiyor. Kitap burada ilginç bir gözlem yapıyor: > Zeki insanlar ilk denemede doğru yapar. Okulda böyle öğreniyoruz çünkü okul problemleri küçük. Ama gerçek yazılım sistemleri o kadar zor ki, kimse ilk seferde mükemmel tasarım yapamıyor. Tech lead yönünde ilerlerken bu bölümü özellikle önemsedim, çünkü tek başına doğru kararı bulmaya çalışmak yerine alternatifleri açıkça karşılaştırıp takıma sunmak, hem daha iyi kararlar çıkarıyor hem de kararın arkasındaki mantığı paylaşılabilir kılıyor. ## **İsimler ve yorumlar üzerine** Kitabın son kısımları isim seçimi ve yorum yazma üzerine. İki fikir özellikle aklımda kaldı. Birincisi, bir değişkene ya da metoda iyi bir isim bulmak zorsa, bu genelde isim probleminden çok tasarım probleminin belirtisi. İkincisi, "iyi kod kendi kendini belgeler" cümlesine karşı çıkış. Kod, tasarımcının kafasındaki niyeti asla tam yakalayamaz. `delete(start, end)` metodunda `end` dahil mi değil mi, kod tek başına bunu söylemiyor. Yorumlar burada eksik kalan boşluğu dolduruyor. ## **Son not** Bu kitabı rubyforum.org üzerinde birlikte yürüttüğümüz kitap kulübü için okudum, bölümleri haftada dört tane olacak şekilde beş haftaya yaydık. Bir kitabı tek başına okumakla bir grupla tartışarak okumak arasındaki fark da ayrı bir yazının konusu olabilir, ama şunu söyleyebilirim: başkalarının aynı bölümden çok farklı örnekler çıkarması, kitabın anlattığı "değişim amplifikasyon" ya da "bilişsel yük" gibi kavramların ne kadar farklı bağlamlarda karşımıza çıktığını görmemi sağladı. Kitabı bitirdikten sonra elimde kalan tek cümle şu: > Karmaşıklık asla tamamen yok edilmez, sadece nereye taşınacağına karar verilir. Mesele bu kararı bilinçli vermek.

Bizim buralarda bir laf vardır. > Tavşan boku gibi ne kokar ne bulaşır. Bu laf genelde, _**kimseye yararı veya zararı dokunmayan** , pasif, silik ve sorumluluk almayan kimseler için kullanılır._ Ben bu lafı sevmiyorum. Kullanmayı da bana kullanılmasını ya da bir başkası için kullandığını duymayı da. Bana çok incitici ve aşalığıcı geliyor. İçinde **bok** kelimesi geçtiği için falan değil, tamamen kişisel davranışlara saldırı olduğu düşünüyorum. _Aman be Ender ne de incesin sen ne olacak ki?_ Çok şey olacak efendim. İnce falan da değilim. Var olanı, yıllardır bu lafı duyup, büyüyen biri olarak artık kabak tadı verdiğini ve bir anlamı olmayan tamamen karşı tarafı küçük düşürmek üzerine söylediği için sevmiyorum ve kullanılmasını kabul etmiyorum. Belki de tavşan boku olmak isteyenlerimiz vardır. Belki de başka hayvanların bokları olmak isteyenlerimiz vardır. Tebrikler! Ancak ne boku olacağımızın kararını kim verir? Bunun kararını ancak kişi kendisi verebilir, her şeye verebildiği gibi. Bazı insanlar vardır, bunlar pek bir şeye karışmak istemezler. Kendi hayatlarında, kendi alemlerinde yaşayıp giderler. Bu tamamen doğaldır. İnsanların seçimleri bu yöndedir ve bizi ilgilendirmez. Onları bir şeyler yapmak ve faydalı olmak için illa zorlamak istiyorsak, bunu başka yollarla yapabiliriz. Mesela, bizim için faydalı olabileceğini düşüneceğimiz eylemlere dahil edebiliriz. Bazı insanlar sadece durur. Doğru zamanı bekler ve öylece durur. Siz onlardan bir şeyler yapmasını beklerseniz, tavşan bokundan öteye lafınız olmaz. Çünkü bunu demek kolaydır, insanları ikna etmek daha zordur. Bu ifade **silik** insanlar için de kullanılır. Peki ne demek silik? Neye göre silik? Bir şirkette çıkıklık yapmıyorsunuz, var olanı kabul ediyorsunuz diye o şekilde çalışmak siliklik midir? Ya da etrafınızdaki olaylara tepkisiz kalmak. Bunun kararını nasıl verebiliyorsunuz? Bizlerin yöntemlerini kullanmıyorlar belki. Neler yaptıklarını ve düşündüklerini bilmiyoruz ki. Hadi biliyoruz diyelim belki onlar silik olmayı seçiyorlar ve bundan mutlular. Bu laf zaten genel olarak çok küçük olaylarda fikirlerini beyan etmeyen, kendi halinde devam eden, ortaya bir karakter koyamayan ve böylelikle bir karakteri olmadığını düşündüğümüz insanlar için kullanılır. Bakın yazarken ben utandım. **Karakteri olmayan.** Bunu diyebilmek için o kişiyle birbir yaşamış olmak, her eyleminin arkasındaki kararı bilmek ve en önemlisi de size zarar vermiş olması gerekir. Ama bunların hiç birinin yaşadığını düşünmüyorum bu süper deyimi kullanan insanların. ## Peki ne yapacaz? Tavşan boku olacağız tabiki de. Kendi yolumuza devam edeceğiz. Ben öyle yapıyorum. Sadece derdimi dile getiriyorum. Yüzüme karşı da dendi, başkasına da dendiğini de duydum. Bu kültür de bu var. Biz hep başkası için yaşıyoruz. Başkasının hayatını yaşıyoruz. Başkalarının hayatlarına ve karakterlerine hatta ve hatta fiziksel görüntülerine yorum yapma, eleştirme, biraz daha ileri gidersek hakaret etme hakkımız hep var. Çünkü biz buyuz.

Yardım istemenin zayıflık olarak görüldüğü, _her işe kendin koşman gerek, her şeyi bilmen gerek, kimseye güvenmeme_ kültüründe büyüdüm. İş hayatına atılınca, usta-çırak ilişkisinin yoğun ve önemli olduğu bir mesleği yapmaya başlayınca yardım istemenin ne kadar önemli olduğunu farkettim. Ancak yardım isteme kültürüne sahip olmadığım için ya da belki olmadığımız için bunu nasıl yapacağımı bilemedim ve bunu yapmakta zorlanan, yaparken çok fazla hata yapan insanlarla çalıştım. Buradaki asıl neden aslında insanların zamanlarını yok yere alacağımı düşünmekti. Soru sorarken ve cevap ararken soruyu soran kişi zaman harcadığını sanıyor ama aslında soruyu dinleyen ve cevabı verecek kişi de bir o kadar zaman harcıyor, hatta belki daha fazla. Meslek hayatımda ilk sorumu nasıl sordum bilemiyorum ama bildiğim ve hatırladığım şey, tanımadığım birine soru sormanın ciddi anlamda zor olduğu. Aranızda ilişki olan birine istediğiniz tonda, istediğiniz zaman, istediğiniz soruyu sorabilirsiniz ancak ya tanımadıklarınıza? Özellikle remote çalışmaya geçtikten sonra dünyam daha global oldu. Allah'a şükür bu tanımadığım insanlara soru sorma konusunu daha önceden halletmiştim. Pek zorlanmadım. Sadece farklı bir dil ve kültürde soru sormak beni zorladı. Onu da zamanla öğrenip, üstesinden geldim diyebilirim. Peki tanımadıklarımıza soru sormak neden bu kadar zor? Bunun farklı nedenleri var. Bence en önemlisi: **reddedilme ve utanç korkusu.** Muhtemelen soruyu soracağınız kişi sizden daha bilgili ve soru sormadan önce ya ben yetersizim, kimim ki bu insanın zamanını alıyorum bu basit şey için diye düşünüp vazgeçiyoruz. Aslında o kişiyi tanımadığımız için onu ve durumunu bilmiyoruz, o da bizi bilmiyor. Bu belirsizlikte bir dengesizlik yatıyor ve anlamsız düşüncelere bizi itiyor. ## Nasıl sorulur? Öncelikle kendimizi soruyu cevaplayacak kişi olarak düşünmeliyiz. Bu soru bana bu şekilde sorulsa ne düşünürdüm? Yani **empati**. Tabii bu o kadar kolay değil. Zamanla gelişecek bir kas ancak bir yerden başlamak gerek. Diğeri ise sen kimsin ve bu soruyu neden soruyorsun? Özellikle çevrimiçi ortamlarda bu daha anlamlı oluyor. Sizin bilinmediğiniz ortamlarda önce kendinizi tanıtmanız, soruyu okuyan kişi için bir referans noktası oluyor. Sonra gelişme kısmı geliyor. Yani sen bu soruyu sormadan önce neler yaptın? Neleri araştırdın ve neler buldun. Bu aslında iş yerinde de yapacağınız bir yöntem ama sizin tanınmadığınız ortamlarda daha fazla işe yarıyor. Çünkü ben, soruyu cevaplayacak kişi, sizin ne üzerinde ne kadar zamandır çalıştığınızı bilemem. O yüzden probleminizi çözmek için hangi yolları denediniz ve neler oldu, biraz anlatmanız gerekiyor. Son olarak ise çok açık bir şekilde neye ihtiyacınız var, bunu belirtmek okuyucuya zaman kazandıracaktır. Ayrıca sizin ne istediğinizi bilen biri olarak tanınmanıza neden olacaktır. ## Cevap Günler geçti cevap gelmedi. Şimdi ne olacak? 😱 Eyvah! Telaşa gerek yok. Bu çok normal bir durum. Asenkron bir ortamda bunlara alışık olmak gerek. Elbette bir soruya bir ay cevap gelmediyse bu gariptir ama 2-3 gün çok normaldir. Cevabı beklemek sabır işi ve bir alışkanlıktır. Kendinizi o cevaba bağlamadan, soruyu sorduktan sonra araştırmalara devam etmek ya da başka bir işle uğraşmak daha faydalı olacaktır. Soruyu bir engel olarak koyar, cevabı beklersek işler ilerlemez, cevap gelmedikçe sinir stres yapar bünyeye ve bunalımlar başlar. Aman dikkat 😄 ## Sonuç İşin teknik tarafı basit aslında. Formüle edersek: > **Kendini tanıt - > Derdini açıkla -> Çalışmalarını anlat -> Sorunu sor -> Aktif bekle** Ancak olayın görünmeyen yüzü var. Neden zor kısmında biraz anlattım.**Yetersiz hissetme.** Bunun kırılımları olabilir. **Kaygı** , **belirsizlik** , **reddedilme** vs. Hepsinin bir tek çözümü yok tabii ki. Ama benim bildiğim **kendine güvenmek**. Ben kendime güvenirim ve sorumu sorarım. Tabii ki bu bir günde olmadı. Nice sorularıma cevap verilmedi, nice sorularıma abuk subuk cevaplar verildi. Şahsi olarak algılamadan, daha iyisini sormak için uğraştım ve bugün çoğu sorum, anında cevap alıyor ya da başka bir soru alıyor. Ben ne yaptığımı ve ne istediğimi biliyorum. Öncelikle bu tarafımı geliştirdim. Bu da çok fazla yaparak ve çok fazla sorarak oldu. Yapay zeka çağında bu kasımız elimizden alınıyor. Kendimize olan güvenimiz ve yapabileceklerimizin sınırını o belirliyor ya da yok ediyor. Ancak bunlar bizim elimizde. Yapay zekaya soru sormakta bir sorun yok ama o soruyu insana sormak, beklemek, o cevap için bir emek vermek belki zaman alıyor ama 10 kat daha güçlendiriyor sizi. Günden güne güçlenen yapay zeka bizden bir şeyler almamalı aksine bize vermeli. Onu akıllı kullanıp, zaten doğamızda olan güçlerimizi kaybetmeden devam etmeliyiz. Nice güzel sorular sormanız dileği ile.

One day, a user tried to do something simple: transfer a CSV file with 645,000 rows (`answers.csv`). But the browser console showed this: Access to XMLHttpRequest at '.../api/steps/24186/run' blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. POST .../run net::ERR_FAILED This looks like a classic CORS error. So you go and fix the origin setting in the backend, right? I didn't. Because the CORS config was already this: origins "*" Everything is allowed. So this could **not** be a real CORS problem. The header was missing because the server **crashed** before `rack-cors` could add it. The browser can't see that. It only sees "no CORS header in the response" and points you in the wrong direction. **Lesson 1:** If you see a CORS error while `origins "*"` is set, the problem is not CORS. The server can't respond. Go read the logs. ## The logs told the truth 08:55:29 heroku[web.1]: Error R14 (Memory quota exceeded) R14. Out of memory. The web dyno crashed while handling the `/run` request. But why would a "start the job" request use so much memory? ## Fake chunking The code split large CSVs into chunks of 10,000 rows. That sounds safe. But the chunking worked like this: file = read_csv_file(...) # loads ALL 645k rows into RAM file.drop(offset).take(chunk_size) # then takes 10k of them So every chunk loaded the **whole file** into memory before doing its work. The chunking never limited memory. It only sliced the data _after_ the full load. 645,000 `CSV::Row` objects means gigabytes. It was a false sense of safety. **Lesson 2:** "We chunk it" does not mean "memory is bounded." Look at the order — where does it load, and where does it slice? ## Layers, like an onion I thought I fixed the problem in one place, but it showed up in another. There were three separate full-load points: 1. **Worker read** — every chunk job parsed all 645k rows again. 2. **Web count** — `/run` needed to know the row count to plan the chunks... so it loaded the whole file again, just to call `.count`. 3. **Raw download** — at the very bottom, `read_as_utf8` downloaded the 183 MB file into a single String (plus one more copy if it needed re-encoding). I changed the first two to streaming: read row by row (`csv.shift`), count row by row (`each_csv_row`). Only one row in RAM at a time. To learn how many pages a book has, you don't put every page on the table. You turn them one by one and count. ## Don't fix without measuring After two pull requests, it was still on the edge. Instead of guessing, I measured — I ran the real production file on a one-off dyno: raw = 183 MB streaming count = 21.6 s peak RSS = 558 MB Here is the important number: 558 MB, even with streaming. Because the bottom layer, `read_as_utf8`, still pulled the full 183 MB into a String. The web dyno had 1 GB. A 558 MB spike + the app's base memory + other requests at the same time = too close to both the 1 GB limit and the 30-second router timeout. **Lesson 3:** Streaming removes the object pile (CSV::Table), but it does not remove the cost of downloading the raw data. You can't know which layer is expensive until you measure. ## The end: quick patch vs. real fix The user was blocked, so I was pragmatic: I resized the web dyno to Performance-M (2.5 GB). The transfer finished. But this is a patch, not a solution. The real fix is in the design: **don't do heavy work inside a web request.** Counting a 183 MB file synchronously is not the web dyno's job. The codebase already had the right pattern (another count endpoint did this off-request, with a Sidekiq job + Redis cache + polling). The `/run` path just wasn't using it. **Lesson 4:** If a user request takes 30 seconds, it is running in the wrong place. Put it on a queue, return right away, and let the client poll. ## Summary * `origins "*"` + a CORS error = the server is crashing, not CORS. * "Chunking" does not automatically mean "memory-safe." * Bugs come in layers; when you close one full-load, the next one appears. * Measure before you fix. I didn't know I was on the edge until I saw 558 MB. * Heavy work belongs in the background, not in a web request.

Çok uzun zamandır blog yazıyorum ama hiçbir platformu benimseyemedim. Belki burayı da benimseyemeceğim ama şimdilik iyi gidiyor diyebilirim. 2026 Şubat ayından beri her hafta Perşembe bir yazı çıkmaya çalışıyorum. Bu efor ve biraz da kafa isteyen bir iş aslında. Yazıları yazmanın yanında neyi yazsam diye düşündüğüm vakitler de oluyor. Bir backlog'um var ancak bazen o kadar saçma şeylerle doluyor ki insan ne gerek var diyebiliyor. Neyi yazmaya karar verdikten sonra nasılı başlıyor. Ama başlayınca da geri geliyor, aynı bu yazı da olduğu gibi. Bilmiyorum sen sıkı bir takipçimisin. Bir anda ortalıktan kayboldum, fark ettin mi? Blog'da duyurmadım, 2 haftalık bir tatile çıktım ve bu yazıyı tatilin bitişinin ilk günü yazıyorum. Aslında daha eve dönmedim ama çalışmaya başladım. Çalışmıyorken de blog'a yazmaya devam edebilirdim ama istemedim. Bir ara vermek istedim. Biraz tatilden bahsedeyim belki bana da bir tatil retrosu olmuş olur. Aslında uzun tatillere pek çıkmam. Eşimin isteği ile böyle bir tatile çıktık. 7 aylık bebeğimizi de alıp, Kaş'a geldik. Neden Kaş? Hem bizim için romantik bir anlamı var hem bildiğimiz ve sevdiğimiz bir yer. Ancak bebek ile biraz zor oluyor. Denizi çok güzel olsa da denize yürüyerek girilecek pek plajı yok. Piraye'yi tabiki denize soktuk ancak alternatif az. Sadece bizi bu durum zorladı diyebilirim. Diğer taraftan Kaş'ın kalabalık olması, araba park sorunu olması, yokuşlu olması konularına girmiyorum zaten bunlar bilindik şeylerdi. Ara vermek iyi geldi. Bazen rutinlerden uzaklaşmak ve bunu başka bir yerde yapmak iyi geliyor. Tatil kavramı sizde nasıl bilmiyorum ama ben de bir kavram olarak yok. Öyle yatayım diyemiyorum, paso gezim, denize girim de diyemiyorum. Açıkcası pek bilemiyorum. Sadece ara vermek, normalden çıkmak iyi geliyor onu biliyorum. Tabi biz pek normalden çıkmadık aslında. Ünye'de yaşadığımız hayatı Kaş'a taşıdık ancak burada başka şeyler ile karşılaştık ki o da bize değişiklik oldu. Aynı hayat yeni şehir yeni düzen yeni rutinler getirdi. Bebekle tatil yapınca zaten bir rutin gerekiyor. Şükür eşim de ben de rutinleri seviyoruz. Kendimizce belli rutinler geliştirip, tatili daha tatil haline getirdik ve keyif aldık diyebilirim. Bebekle pek esnek olmak mümkün değil ancak gene de bu anne babanın elinde. Siz ona ne kadar gösterirseniz onu alıyor zaten. Biz biraz buna dikkat etmeye çalıştık. 3'müzün birlikte ilk tatili olduğu için çok fazla hata yaptık ama dersler çıkardık gelecek tatillerimiz için. Ara vermek iyi geliyor demiştim. 15 gün boyunca bilgisayar açmadım. İlk hafta sosyal medyada pek olmadım. Bunlar bana iyi geldi. İşimi ve üretmeyi özledim. Bazen plajda otururken, gelecek için neler yapabilirim diye düşündüm. Üretmeyi seven ve bunun da artık daha kolay olmaya başladığı bir dünyada farklı neler olabilir diye düşündüm biraz. Programlama yapmadım henüz ama ileride belki bir şeyler çıkar. Tatil boyunca yazmak okumak ve denize girmek iyi geldi. Güneşlenmek de güzel ancak hava cidden çok sıcak. Nemin pek fazla olmaması güzel fakat klima da baya iyi bir icat. Bunu bu coğrafyada insan daha iyi anlayabiliyor. Dinlendin mi abi derseniz, hayır diyebilirim. Çünkü ben dinlenmek ne pek bilmiyorum. Bana durmak ya da değişiklik iyi geliyor. Rutinlerini seven biriyim ama rutin değişikliğini de seviyorum. Çok uzun süreli rutinler de yorucu oluyor ve değişim istiyor. O yüzden bu tatil iyi geldi diyebilirim. Peki nerede kalmıştık? Hadi kaldığımız yerden devam edelim. Beni takipte kaldığınız için teşekkür ederim.

Very few posts on this blog explain how to do something in software. On the blogs I ran before this one, and killed later, I wrote a lot more of that kind of content, because I needed it more back then. But I noticed that with AI, this need slowly went down for me too. At some point I asked myself why I don't go back to it, and how much sense that would even make. ## Just Ask Google I used to open Google, type my problem, and somehow find a solution close enough to what I needed. Now the numbers tell a different story. > In 2026, less than a third of Google searches end with a click to any website. For the rest, AI Overviews already answer the question, so the user never leaves the search page. On queries where an AI Overview shows up, click rates sometimes drop as low as 17-20%. So which posts still get clicked? Not the "how do I do X" ones. Comparison posts and posts that share real experience get more clicks. The other type gets pulled out by AI and handed straight to the reader, without the blog in between. That's tiring, honestly. My writing gets picked up by AI before it even reaches my site, gets used, and my site gets no traffic from it. But does that actually matter? Is it worth quitting over? ## What Am I Even Writing? I sat down and went through my old posts, and a pattern showed up. I wasn't writing "how to use X." I was writing what happens when you actually use X in production, and what I learned from it. Turns out I was already doing the right thing for this era, without planning it. The first type is generic reference material. It's already in the docs, repeated in ten other blogs, and AI can summarize it faster than I ever could. The second type is something that happened to me. Which mistake I made, why I made it, how I noticed it. There's no documentation that can summarize that, because that experience only exists in me. Research backs this up too. AI isn't killing traffic, it's redistributing it. Clicks are dropping on generic, unbranded information queries. But for the sources AI actually cites, the ones that say something real, the traffic that comes through is smaller but worth more. Posts with original research and real opinions are doing better than plain SEO posts right now. ## The Question Changed So the question isn't "should I write how-tos." It's "which how-to is actually worth writing." Writing "here's the syntax for X" doesn't mean much anymore. That information is everywhere, and Google hands it over faster and cleaner than I can. But writing "I used X on a real project, got three things wrong, here's how I fixed them" is still worth it. Because nobody else can tell that story but me. I'll keep writing how-tos. I'm just going to write less **"how it's done"** and more **"how I did it."** Google can somehow give the other answer. It can't give the story. * * * **Sources:** * Website traffic decline in 2026, The Marketing Meetup * AI Overview Traffic Loss: How to Measure It, Velacore * Google AI Overviews Are Eating Your Website Traffic, Forbes * Is AI Killing Web Traffic?, HubSpot

A developer's job is not writing code. It never was. Writing code is the visible part. It is the part you can measure, the part that shows up in your GitHub graph. The real job is different. It is understanding a problem. It is breaking that problem into small parts. It is deciding which parts you actually need. It is seeing where the system will break before it breaks. Code is just the last step of this thinking process. It is a translation step. A normal day looks like this. You spend three hours finding a bug. The fix takes two minutes. You think about a new feature, and you compare three different approaches in your head. Which one will cause problems in six months? In a meeting, you explain the technical side of a product decision. In a code review, you look at a teammate's pull request and ask why they built it this way. The lines of code you write are a small part of your actual time. ## AI took the cheapest part of the job When AI started writing code, it took the easiest part first. A function skeleton, a simple CRUD endpoint, a basic test file, these things now appear in seconds. This is a real gain. I don't deny it. I use it every day. But the latest Stack Overflow survey shows something interesting. Most developers now use AI tools daily. But the top complaint is this: the output is almost right, but not quite. The second complaint is close behind: debugging AI-generated code often takes longer than writing it from scratch. So the real work, the part where you ask "is this correct, and if not, why not", still belongs to us. AI took the writing. It did not take the deciding. ## The work moved from writing to checking Here is the shift I notice in my own work. In the past, I spent most of my time producing code line by line. Now I spend most of my time reading code, questioning it, and asking why a certain choice was made. I moved from writer to editor. This is not always the easier job. Sometimes writing something from scratch is easier than following someone else's logic (or a model's logic) and finding the mistake in it. This shift also widened the gap between junior and senior developers. Junior developers used to learn by doing simple, repetitive tasks. Now AI does most of those tasks. So the learning path for junior developers is getting narrower. For senior developers, the opposite happened. One senior developer can now do what used to take a small team, because they hand off the mechanical part to AI and spend their own time on decisions. ## What hasn't changed So back to the question. A developer's job was never "writing code." It was always "making the right call." AI did not change this. It just made it visible. In the past, writing code and making decisions were mixed together in the same act. It was hard to separate them. Now they are separate. And once you separate them, it becomes clear which one was actually valuable. * * * **Sources** * Stack Overflow Developer Survey 2026 summary, byteiota * Junior developer employment decline, Hakia

Someone asked me last week if legacy code will disappear now that AI writes so much of our software. My first answer was a quick "no." Then I looked into it, and the real answer turned out to be more interesting than a simple no. ## The story we tell ourselves The pitch for AI coding tools always sounds the same. Feed the model your old codebase, and it will read the messy parts, explain the parts nobody remembers, and modernize what needs to change. In theory, legacy code stops being scary. It becomes just another input for a model with a big context window. There is some truth here. In March 2026, Anthropic launched the Claude Partner Network with a $100M commitment, and legacy code modernization was one of the main use cases they pointed to. Cleveroad, a company that works on these migrations, explains that AI-assisted modernization reads existing code and translates it step by step, instead of throwing it away and starting over. A full rewrite is risky. You lose business rules that got buried in the code over the years, rules nobody wrote down anywhere else. AI tools are good at pulling that hidden logic out before anything gets touched. So on the enterprise side, there is a real market forming around this. IBM i shops, old RPG systems, COBOL wrappers, all of it. Companies like ARCAD, Fresche, and Profound Logic are building tools and services around exactly this problem. If legacy code was disappearing, nobody would be selling shovels for it. ## But here is the part I didn't expect While AI tools get better at explaining old code, they also seem to be making developers less willing to touch it. GitClear published research that LeadDev covered recently, and the numbers are hard to ignore. Legacy refactoring, meaning changes to code that is more than 12 months old, has dropped 74% since 2023. Developers are not going back to clean up what exists. They are building new instead, because that is what AI tools are good at and fast at. The research also found a rise in "error masking," where the model writes code that never throws an error no matter what input it gets, instead of handling the input properly. That looks fine today. It becomes tech debt the moment someone has to figure out later why the error handling is there at all. This connects to something Google's DORA report found too: every 25% increase in AI usage adds about 7.2% more instability to a system. More AI does not automatically mean more stability. Sometimes it means the opposite, just with more code shipped around it. ## So which is it? Both things are true at the same time, and I think that is the honest answer. At the big, expensive, well-funded end of the industry, AI is genuinely helping teams face 25-year-old systems that no human fully understands anymore. That work was basically impossible to staff before. Now a modern developer can be productive on a legacy system they have never seen, because the AI can explain what the code does, not just what it says. But at the daily, ordinary end, where most of us actually work, AI is quietly creating a new kind of legacy code. Code that was generated fast, that passes the tests, that satisfies the prompt, and that nobody wants to open again in a year. Faros points out that developers increasingly care about net productivity, not just how fast the first draft appears, and that tools requiring constant correction lose favor quickly. That is a sign teams are noticing the same thing I noticed while reading all this: speed at the start does not mean less maintenance later. It can just move the maintenance further down the road. Legacy code is not going anywhere. If anything, AI is teaching us how legacy code gets born in the first place, and that part was always true, long before any of these tools existed. ## Sources * Code maintainability plummets in the AI coding era – LeadDev * AI-Assisted Legacy Code Modernization Guide 2026 – Cleveroad * Here Come The AI-Based Code Modernization Offerings – IT Jungle * Best AI Coding Agents for 2026: Real-World Developer Reviews – Faros * 20 Best AI Coding Agents in 2026 – Agentic.ai

Sabahın erken saatlerinde işlerine gitmek için erkenden yolla düşen insanlar. O güzel yataklarından bazıları güneş bile doğmadan çıkıyor ve iş için yollara dökülüyorlar. Hemen hemen hepsinin ellerinde çöp torbaları oluyor. Evlerinden çıkarken ya kendileri ya da bir başkası tarafından ellerine verilen çöp torbaları. Evlerinden çıkarken işe gitmeden önce onlara yoldaşlık ediyor. Çoğu doluluktan şişmiş, taşmak üzere, taşıması zor bir hale gelmiş. Gecenin mirası kalmış, içlerine doldurulmuş anılar mezarlıklarına gidiyor. Kim bilir neler yaşandı ve o çöp poşetleri ne sırlar saklıyor. Hangi hikayeler tarihe gömülüyor. Sanki yeni bir başlangıç. Sabah erkenden evden çıkarılan ve apar topar çöp kutularına atılan çöp poşetleri. Evet yeni bir gün başlıyor. Şimdi tekrar yeniden başlıyoruz dedirtiyor sahibine. Belki de öyle. Belki de yeni bir hikayeye yer açıyor. Belki de unutulması ve bir daha yaşanmaması gereken anılar gidiyor onlarla. Her evde başka bir hikaye. Zengin, fakir, orta gelirli ne fark eder? O çöp poşetlerinde dolu serüven, anı, acı ve daha bilemediğimiz duygular. Dikkatli bakınca biraz ipuçları verir bizlere. Akşam neler oldu acaba? Bebek bezleri ile doluysa, komşunun hanımı doğurmuştur. Şişeler fingirdeşiyorsa akşam bir şeyler yaşanmıştır ya da yemek fazla kaçmış, sodalar açılmıştır. Pahallı marka kutuları, kargo poşetleri, alışveriş seviyoruz demek ki. Sabahaları kendini sonsuzluğa uğurlayan çöplerin bize anlattıklarının sadece bir kısmı. Anılarımız. Unutulmak istenenleri sabah bırakıyoruz. Nereye gittiklerini bilmiyoruz. Zaten ilgilenmiyoruz da. Yenilere yer açıyoruz. Artık yeninin zamanı. Kim bilir ne acılar, ne sevinçler gidiyor o poşetlerin içinde. Sabah hepsi ellerimizde. Acelemiz var. Hemen kurtulmalı onlardan. Onlar çünkü ağır ve kokuyor. Artık gün başlıyor. Kurtul onlardan. Sanki o çöp poşetleri bizden hiç ayrılmasa gün hiç başlayamacak. Sanki onları bırakmasak yeni anılara yer açılmayacak. Elimizde bedenimize bir ağırlık. Çöpleri poşete koymak yetmiyor. Onlar bir de kopmak gerekiyor. Ruhumuz kirli. Kurtulmalı ve temizlenmeli. Onlardan kurtulunca temizleniyor, arınıyoruz sanki. Tertemiz bir ruh ve beden. Yeni güne merhaba!

A few weeks ago, I added a tagging feature to my personal finance app, Foxance. I wanted users to label their transactions with custom tags, up to 3 per transaction, with autocomplete and chip-style UI. My first instinct was to grab a library. But then I stopped myself. Do I really need another npm package for this? Let me try with just Stimulus and a bit of Rails. > Spoiler: **it worked well. Here's how I built it.** ## The Data Model First, the Rails side. Tags belong to an `Account`, not to individual users. This is important because in Foxance, multiple users can share an account. If tags belonged to a user, other members couldn't see each other's tags. Sharing them at the account level makes them a shared vocabulary. class Tag < ApplicationRecord belongs_to :account has_many :transaction_tags, dependent: :destroy has_many :transactions, through: :transaction_tags, source: :txn validates :name, presence: true, uniqueness: { scope: :account_id, case_sensitive: false } before_save { self.name = name.strip.downcase } end tag.rb The join model is simple: class TransactionTag < ApplicationRecord belongs_to :txn, class_name: "Transaction", foreign_key: :transaction_id belongs_to :tag end transaction_tag.rb And `Transaction` gets the association plus some logic we'll talk about shortly: class Transaction < ApplicationRecord has_many :transaction_tags, dependent: :destroy has_many :tags, through: :transaction_tags attr_writer :tag_names def tag_names @tag_names || tags.map(&:name) end validate :tag_count_within_limit after_save :sync_tags end transaction.rb ## The `sync_tags` Pattern This is the most interesting part on the Rails side. Instead of dealing with complex params parsing in the controller, I used an `attr_writer` + `after_save` pattern. The form sends tags as `transaction[tag_names][]`, an array of strings. The controller just passes it through with `permit(tag_names: [])`. Then `sync_tags` handles everything: def sync_tags return if @tag_names.nil? names = Array(@tag_names).map { |n| n.to_s.strip.downcase }.reject(&:blank?).uniq.first(3) self.tags = names.map { |name| Tag.find_or_create_by!(account: account, name: name) } @tag_names = nil end Two things worth noting here: **`find_or_create_by!`** : If the tag "coffee" already exists for this account, it reuses it. If not, it creates it. No duplicates, no extra logic. `**self.tags = [...]**`: This is Active Record's collection assignment. It automatically computes the diff and inserts/deletes only what changed. So if a transaction had `["coffee", "work"]` and you save with `["coffee", "travel"]`, Rails removes the `work` association and adds `travel`. One line, zero boilerplate. ## The Autocomplete Endpoint A minimal controller to power suggestions: class TagsController < ApplicationController def index tags = Current.account.tags tags = tags.where("name LIKE ?", "%#{params[:q].to_s.strip.downcase}%") if params[:q].present? render json: tags.order(:name).limit(10).pluck(:name) end end tags_controller.rb Returns a JSON array of tag names. That's it. ## The Stimulus Controller Now the fun part. The controller has four targets: * `input`: the text field the user types into * `chips`: where the blue pill badges render * `dropdown`: the autocomplete suggestion list * `hiddenContainer`: holds the actual `<input type="hidden">` fields that get submitted with the form static targets = ["input", "chips", "dropdown", "hiddenContainer"] static values = { max: { type: Number, default: 3 }, url: String } tag_input_controller.js ### Adding Tags Tags can be added three ways: pressing Enter, pressing comma, or clicking a suggestion. They all call the same `addTag()` method: addTag(name) { name = name.trim().toLowerCase() if (!name || this.tags.includes(name) || this.tags.length >= this.maxValue) return this.tags.push(name) this.inputTarget.value = "" this.closeDropdown() this.renderChips() } ### Backspace to Remove This is one of those small UX details that users expect without realizing it. When the input is empty and the user presses Backspace, the last tag gets removed: } else if (event.key === "Backspace" && this.inputTarget.value === "" && this.tags.length > 0) { this.tags.pop() this.renderChips() } ### The blur/preventBlur Problem This is a classic trap. When a user clicks a suggestion in the dropdown, the browser fires `blur` on the input _before_ the `click` on the button. If you close the dropdown on blur, the click never lands. The fix: blur() { setTimeout(() => this.closeDropdown(), 150) } preventBlur(event) { event.preventDefault() } Each dropdown button has `mousedown->tag-input#preventBlur`. The `mousedown` event fires before `blur`. Calling `preventDefault()` on it stops the input from losing focus, so the click goes through normally. The `setTimeout` in `blur` is a safety net for cases where the user clicks somewhere else entirely. ### Rendering Chips and Hidden Inputs `renderChips()` does two things at once: it updates the visual chips and regenerates the hidden inputs. renderChips() { this.hiddenContainerTarget.innerHTML = this.tags.map(t => `<input type="hidden" name="transaction[tag_names][]" value="${this.esc(t)}">` ).join("") this.chipsTarget.innerHTML = this.tags.map(t => `<span class="inline-flex items-center gap-1 bg-blue-100 text-blue-700 ..."> ${this.esc(t)} <button type="button" data-action="click->tag-input#removeTag" data-name="${this.esc(t)}">×</button> </span>` ).join("") const atMax = this.tags.length >= this.maxValue this.inputTarget.disabled = atMax this.inputTarget.classList.toggle("hidden", atMax) } When the user hits 3 tags, the input hides itself. Clean, no extra state needed. ### XSS: Don't Skip This Since we're writing directly to `innerHTML`, we need to escape user input. I wrote a small `esc()` helper: esc(str) { return String(str) .replace(/&/g, "&") .replace(/</g, "<") .replace(/>/g, ">") .replace(/"/g, """) } Tag names come from the user. Without escaping, a tag named `"><script>alert(1)</script>` would execute. A small helper, but not optional. # Wiring It All Together in the Form <div data-controller="tag-input" data-tag-input-url-value="<%= tags_path %>" data-tag-input-max-value="3"> <div class="... flex flex-wrap gap-1.5 items-center"> <div data-tag-input-target="chips" class="contents"></div> <div class="relative"> <input type="text" data-tag-input-target="input" data-action="input->tag-input#suggest keydown->tag-input#keydown blur->tag-input#blur"> <div data-tag-input-target="dropdown" class="hidden ..."></div> </div> </div> <div data-tag-input-target="hiddenContainer"> <% transaction.tags.each do |tag| %> <input type="hidden" name="transaction[tag_names][]" value="<%= tag.name %>"> <% end %> </div> </div> The `hiddenContainer` is pre-populated with existing tags when editing. The Stimulus `connect()` reads them back into `this.tags`, so the edit form shows the right chips immediately. * * * ## What I Liked About This Approach No external dependencies. The whole thing is about 110 lines of JavaScript and a handful of Ruby. It's readable, testable, and easy to extend. The `sync_tags` pattern with `find_or_create_by!` and `self.tags = [...]` is something I'll reuse. It keeps all the tag logic in the model where it belongs, and the controller stays clean. If you're reaching for a library for something like this, it's worth spending 30 minutes seeing if Stimulus and a small Rails endpoint can get you there first. Often they can.

Every year, around the time I'm about to take a few days off, the same questions come up. Should I bring the laptop? What if I get a good idea for that side project? Is it bad to push a small commit while I'm at the beach? These aren't just personal anxieties. They reflect something specific about being a software developer. Our work and our curiosity often live in the same place, and it's hard to know where one ends and the other begins. ## The problem with "just checking in" There's research on this. A UGA meta-analysis of 32 studies from nine countries found that employees who psychologically disengaged from work during vacation saw the most improvement in their well-being. The researchers put it simply: > **If you're not at work but you're thinking about work on vacation, you might as well be at the office.** And that's the trap. Lying on a beach while your brain is halfway through a refactoring plan doesn't count as rest. The parasympathetic nervous system, the part responsible for actual recovery, can't activate properly when you're in a state of low-level alertness. It's not about where your body is. It's about where your attention goes. A more recent survey found that those who fully disconnect report higher well-being and lower burnout compared to those who **"planned to work just a little."** The group that fully disconnected was, unfortunately, the smallest one. ## The side project question This is where developers tend to overthink things. For most of us, the side project isn't just a project. It's the place we go to learn freely, build without constraints, and feel like ourselves outside of tickets and stand-ups. Calling it "work" misses the point. But calling it "rest" might miss it too. The honest answer is: > **it depends on why you're doing it.** If you open your laptop on vacation because you genuinely want to, and there's no guilt, no obligation, and no one waiting on the other end, that's probably fine. Some people find flow states restorative. Some people are introverts who recharge by solving problems alone. But if you open the laptop because you feel like you should, because staying sharp feels like a duty, because the GitHub graph gives you anxiety, then you're not resting. You're performing productivity on your own time. The healthiest developers I know outside of work have something to say about this. They don't frame it as discipline. They frame it as knowing what actually recharges them. ## What actually helps A few things come up consistently in the research and in practice: **Physical disconnection helps more than willpower.** Leaving the laptop at home sounds obvious, but it changes things. Deciding not to use it isn't the same as not having it available. The decision cost adds up. **The days before and after matter.** Giving yourself a day to wind down before vacation, and a day to readjust after, reduces the stress spike that undermines the whole thing. Coming back to 300 unread messages on your first morning erases a week of rest in about 20 minutes. **Full detachment isn't the only option.** Some people do better with designated offline hours rather than a complete shutdown. What matters is that those hours are real, not negotiable, and not filled with passive scrolling. **Non-coding activities do something different.** This sounds obvious until you notice how rarely we actually do it. Walking, cooking, swimming, reading fiction, spending time with people you like. These aren't just distractions. They engage different cognitive systems and give the problem-solving part of your brain a chance to idle. Interestingly, that idle state is often when good ideas surface, not when you're chasing them. ## My own take Last year I ran a small experiment. I shut off the internet for a week. No laptop, no work-related reading, barely even the phone. I didn't go anywhere, I stayed home. And it was fine, actually good, for the first couple of days. Then something interesting happened. Around day three or four, I started missing it. Not in a withdrawal kind of way, but genuinely. I missed reading about things I was curious about. I missed having a problem to think through. I missed the work. I don't think that's a warning sign. I think it's information. Two or three days of full disconnection does something real for me. It resets a kind of baseline tension I didn't know I was carrying. But beyond that, the absence starts to feel like a void I'm not sure I want to fill with anything else. Maybe I haven't found what would fill it better. Or maybe I just actually like this. There's a version of "I love my work" that's healthy, and a version that's avoidance. I'm not always sure which one I'm in. But I've stopped treating the urge to read a tech article or think through a problem as something to be corrected. The question I ask now is simpler: am I doing this because I want to, or because I don't know how to stop? Those two feel different when you pay attention.

This week I read an article on CSS-Tricks about Stack Overflow. It showed a chart, and the chart stayed with me. Questions on Stack Overflow peaked around 2014, with more than 200,000 questions in a single month. In 2026 the site barely reaches 3,000 a month. The author points at AI as the main reason, mostly. I felt something when I saw that drop. I remember asking questions there years ago. I remember the small fear before posting: maybe my question is a duplicate, maybe someone tells me it is stupid. But I also remember how much I learned from that process. Writing the question forced me to understand the problem first. Now I almost never ask Stack Overflow. I ask an LLM. It is faster. It does not judge me, in fact it praises me too much. I get an answer in seconds. And honestly, I like it. But the more I think about it, the more I worry. My worry is not really about Stack Overflow. It is about something bigger. AI is changing how we think, how we write code, and how we read it. I am not sure this goes in a good direction. ## How we think There is a word for what happens here: cognitive offloading. We move mental work to an external tool, so our own "muscle" does less. Sometimes this is fine. We use calculators and we do not feel bad about it. But recent research suggests a cost when we offload too much. A 2025 study by Michael Gerlich looked at 666 people. It found a negative link between heavy AI use and critical thinking. The effect was stronger for younger people. The author calls one part of this "cognitive laziness", a drop in the wish to think deeply and reflect. A study from MIT Media Lab goes further. Researchers asked 54 people to write essays in three groups: one used an LLM, one used a search engine, and one used only their brain. They measured brain activity with EEG. The brain-only group showed the strongest and widest brain connectivity. The LLM group showed the weakest. The detail that scared me most: most people in the LLM group could not quote a single sentence from the essay they had just written. The text was there. The thinking was not. This matches my own feeling. When I let the model do the hard part, the answer does not really stay in my head. I ship it, and a week later it feels like someone else wrote it. ## How we write code The same pattern shows up in the code itself. GitClear analyzed 211 million changed lines of code from 2020 to 2024. The trend is clear and not great. Copy-pasted lines went up from 8.3% to 12.3%. "Moved" lines, which usually mean refactoring and reuse, dropped from around 25% to under 10%. In 2024, for the first time, developers pasted more code than they moved. So we add more and reuse less. We duplicate instead of cleaning up. Research from Cornell points in the same direction: AI-generated code tends to be simpler and more repetitive, with more unused parts. It works, but it does not always make the codebase better. For someone who likes boring, standard Rails, this is the part that bothers me. Good code is not only code that runs. It is code that stays simple over time. Refactoring is how we keep it that way. If we stop refactoring, the system slowly rots, even if every single pull request looks fine. ## How we read code There is a third change, and people talk about it less. AI is changing how we read code, or how little we read it. When the model writes a function, the easy move is to accept it. It looks reasonable, the tests pass, we move on. But reading carefully is real work, and AI makes it very easy to skip that work. Psychology Today describes a study where developers who handed coding to AI produced working code but failed to understand it on a conceptual level. The code shipped. The understanding did not. This creates a strange position. To review AI output well, you need the skill that the AI is replacing. You need to know what good looks like. A senior developer can audit the output, because they built that knowledge over years. A junior who started with AI may never build it. You cannot check work that you were never able to do yourself. ## I am not against the tool I want to be clear. I use AI every day and I am not going back. The tool is useful, and refusing it would be silly. But I try to keep some rules for myself. I ask small, specific questions instead of asking the model to build the whole thing. I read the output and ask if I really understand it. I check where the answer comes from. And I test it like I would test my own code, because the model does not know my users. These rules are simple, but they have one goal. I want to stay the person who thinks, not the person who only approves. ## The real question Stack Overflow had a lot of problems. The moderation was harsh, and beginners often felt unwelcome. I do not miss that part. But the site did one good thing for many years. It got us to ask. It got us to answer. It got us to think. The question I keep coming back to is simple. When we stop asking, do we also stop thinking? And if we hand that thinking to the model, who is left to teach the model when the next thing changes? I do not have a clean answer. I just know I want to keep asking questions, even the ones a machine could answer for me. So I want to ask you. Do you think AI is taking away our ability to ask questions and to think? Or is it turning into something else, a new way of thinking that we do not fully understand yet? I would like to hear how you see it. * * * ### References * Sunkanmi Fafowora, "Stack Overflow: When We Stop Asking", CSS-Tricks (2026): https://css-tricks.com/stack-overflow-when-we-stop-asking/ * Nataliya Kosmyna et al., "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task", MIT Media Lab (2025): https://arxiv.org/abs/2506.08872 * Michael Gerlich, "AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking", Societies (2025): https://www.mdpi.com/2075-4698/15/1/6 * GitClear, "AI Copilot Code Quality 2025" report (211 million changed lines, 2020–2024): https://www.gitclear.com/ai_assistant_code_quality_2025_research * "Analyzing the Differences Between Human-Written and AI-Generated Code", Cornell (2025): https://arxiv.org/abs/2508.21634 * "Adults Lose Skills to AI. Children Never Build Them.", Psychology Today (2026): https://www.psychologytoday.com/us/blog/the-algorithmic-mind/202603/adults-lose-skills-to-ai-children-never-build-them

Bir izlediğim filmi tekrar izlemek gibi bir huyum yoktur. Bu huyu Perfect Days filmi ile değiştirmiş bulunmaktayım. Bu filmi aslında sağda solda duyduğum zaman sanat filmi ve bir adamın bir gününü anlatıyor, ha, bir de Japon sineması falan diye öylesine bakayım dedim. Yönetmenine falan bakmadım tabiki. Ama bir şans verim, iki saatlanayım diye başına oturdum ve aman yarabbi neler oldu öyle. Çok hoşuma gitti. Hiç sıkılmadan güzelce izledim ve o zamanlarda üstüne pek düşünmedim. Üzerinden bayağı bir vakit geçtikten sonra sanırım Bu mu Yani podcast'inde biraz konusu geçince tekrar bir bakayım bu filme dedim ve bu sefer izledikten sonra filmle alakalı yapılan yorumlara bir bakayım, kendi düşüncelerimle karşılaştırayım dedim. Oturdum ve izledim, aman yarabbi gene çok keyiflendim. Adeta hayata daha güzel bakmaya başladım. Peki bana ne oldu? Neler beni bu kadar filmde tuttu? Bu yazıda teknik bir inceleme yapmayacağım. Ben izlerken ve sonrasında neler hissettim, neler düşünüyorum, biraz kendi hayatımdan bağlamlarla filmi incelemeye çalışacağım. Rutinler. Bayılırım. Ana karakterimizin rutinlerini bayağı detaylı bir şekilde izliyoruz. Sabah kalkış şeklinden akşam yatış şekline hepsi tıkır tıkır işliyor. Tabiki gerçek hayat böyle değil. Rutinleri çok sevsem de bu kadar katı bağlı kalamıyorum. Bir süre sonra bana tek düze gelmeye başlıyor rutinlerim. Ancak bu filmde adam rutinlerden mutlu. Hatta filmde rutinlerinin bozulduğu anlar var, oralarda bir sıkıntıya giriyor ve "bu adam da sinirlenebiliyormuş" diye düşündüm. Eğer rutinleriniz varsa ve biraz onlara bağlıysanız, bir noktada bozulunca moralinizin bozulması ya da sinirlenmeniz bence çok doğal. Peki bu rutinler ne getiriyor? Bence huzurla bir ilişkisi var. Beyin ne yapacağını az çok bildiği için pek strese girmiyor. Rahat rahat yaşıyorsunuz, ancak ben bir süre sonra rutinlerimin dışına çıkmak ve yeni rutinler oluşturmak istiyorum. Beynimi strese sokmazsam gelişemediğimi ve tek düze yaşadığımı hissediyorum. Her ne yapıyorsan en iyisini yapmak ve bunu hayatına yansıtmak. Ana karakter bir tuvalet temizleyicisi ve işini çok iyi yapıyor, özenli, titiz. Hatta bir yerde biri "nasıl olsa tekrar kirlenecek, ne gerek var bu şekilde detaylı yapıyorsun" diyor ama bizim karakterimiz cevap vermiyor. Aslında bu karakter pek konuşmuyor. Zaten güzel olan da o. Film, karakteri pek konuşturmuyor ve bize bırakıyor düşünmeyi, anlamayı. Burada benim düşüncem: tuvalet temizleseniz bile işinizi iyi yapmanız, özenmeniz. Ama bir fark var. Adamın hayatında diğer şeyler de o şekilde, zaten o şekilde yaşıyor. Yani sadece işine özen göstermiyor, hayatına da özen gösteriyor. Bu da beni bir önceki paragrafa, rutinlere götürüyor. Nasıl yaşıyorsa, nasıl hissediyorsa, aslında işini de öyle yapıyor. Film boyunca adamın anda kaldığını görüyoruz. Ne geleceğe gidiyor ne geçmişe. Filmin bir yerinde geçmişi önüne geliyor, bir yerinde geleceğe dair düşünceleri yıkılıyor gibi oluyor. Bu anlarda zaten resmen dağılıyor. Anda olduğu zamanlarda ise hep gülümsediğini ve o ana meraklı gözlerle baktığını görebiliyoruz. Ben pek anda kalabilen biri değilim. Kendimi zorlasam da geçmiş ve gelecek arasında biraz gider gelirim. Geçenlerde bu filmden öğrendiğimi uygulamak istedim. Bir ağacın yapraklarını izlemek. Rüzgarda savruluşunu takip etmek. Yaprakları arasından süzülen güneş ışığına bakmak. O an yok. O an o tablo sadece bir kere var ve tekrarı yok. Böyle bakınca tabiki uzun sürmedi, bir an gelecek ve geçmiş kafamdan gitti. Bunu tekrarlayabilir miyim bilmiyorum ama benim için ilginç bir andı. Rahatlatıcı mıydı pek bilemiyorum. Sadece anı hissettiğimi hatırlıyorum. Bu durumun Japoncası da varmış: **Kondo wa kondo, ima wa ima**. Anlamı: _"Bir dahaki sefere bir dahaki seferdir, şimdi ise şimdidir."_ Filmi ilk izlediğimde tam anlamamıştım. İkinci izlediğimde daha da kafama oturdu. Bir yerde gelecek için plan yapan bir akrabasının "ne zaman?" sorusuna "gelecek sefer" diye cevap veriyor karakterimiz. Akrabası da "gelecek sefer ne zaman?" diyor. O da "gelecek sefer işte" diyor. Yani zaman kavramı, gelecek kavramı metalaşmıyor. Bir kurala bağlanmıyor. O zaman gelecek ve olacak diyor. Nasıl şu an şimdi yaşanıyorsa, gelecek sefer de gelecekte yaşanacak, pek de kafaya takmaya gerek yok. Bütün olanlar aslında birer kabullenme. Ana karakterimizin hayatla bir kavgası yok. Neyse onu yaşıyor aslında. Hırsları yok. Elindekilerle yetiniyor. Doğayı seviyor ve rutinleriyle mutlu. Buna **Amor Fati** deniyor. _Kaderini sevme, kucaklama gibi yorumlayabiliriz._ Ben de biraz kendime bakınca bazen çok kafa taktığımı düşünüyorum. Var olanı kabul etmeyi, değiştirmek için resmen kendimi heba ediyorum. Zaman zaman bu gerekse de abartılınca biraz yorucu ve ruh emici olabiliyor. Filmde ilginç olan, karakterimiz geçmişi bile kabulleniyor. Ona geri gelen geçmişi, onu sorgulayan geçmişiyle bir derdi olmuyor. Tamam deyip yoluna devam edebiliyor. Filmde ara ara gölgeler görüyoruz. Karakterimiz ağaçları ve yaşadığı her anı merakla izliyor. Buna **Komorebi** deniyormuş. Belki modern dünyada böyle olmak zor. Zaten benim için bayağı zor. Çevremi dikkatle izlemeyeli bayağı oldu. Evet ağaca baktım, rüzgarı dinledim ama orada anlık kalabildim. Tekrarlayamadım. Bunu içselleştirmem belki zaman alacak. Belki de o zaman rutinler ve tek düzelik bir daha anlam kazanacak. Filmde karakterin her günü bir önceki gününün neredeyse aynısı. Aslında günler birbirine bu kadar benzese de her gün onun için özel. Hiçbiri diğerinden mükemmel değil. Bana göre tam da filmin adı buradan geliyor. Aslında her gün mükemmel. Anın kıymetini bilince günler güzelleşiyor. Benim için günler benzer geçiyor ve ben bunu seviyorum. Zaten işim gereği de tutarlılık önemli benim için. Ancak anları da kaçırmadan o günü mükemmel kılabilmeyi bazen becerebiliyorum. Bunun için ekstra bir çaba sarf etmem gerekiyor mu bilemiyorum. Demiştim ya, bir huzur doldum. Filmde bir huzur ve mutluluk var. Ama hiç böyle mutlu bir an yok. Sadece bir insanın gayet normal bir yaşamı var. Bir ara aşk, keder olur diye de bekledim çünkü hayatta bunlar da var. Aslında bir noktada oluyor ama tam benim düşündüğüm gibi değil. Karakterimiz mutluluk peşinde koşmuyor. Zaten onun içinde olduğunu biliyor. Onu dışarı çıkartıyor. Bunu kendi istediklerini yaparak, özgür bir şekilde yaşadığı için yapabiliyor. Tam bir film incelemesi olmadı biliyorum. Başlıkla biraz farklı bir yazı oldu ama biraz bana dokunan taraflarını da size vermek istedim. Umarım keyif almışsınızdır. Peki siz izlediniz mi Perfect Days'i? Neler hissettiniz? Arada bir bakmaya değer bir yapıt olduğunu düşünüyorum, ne dersiniz?

I have been on both sides of the technical interview for over years. As a candidate, as an interviewer, and sometimes both in the same month. The format never changed much: a few algorithm questions, maybe a system design, and then "do you have any questions for us?" Looking at that same format today, it feels outdated. The job changed. The interview did not. ## The problem with the current system The traditional technical interview is built on one assumption: if a candidate can write a solution from scratch, alone, under time pressure, they can do the job. That made sense ten years ago. It does not make much sense now. AI tools are used in real production environments every day. Engineers open Cursor or Copilot before they open the documentation. But in interviews, candidates are still expected to code alone, without any tools, on a blank screen. A survey of 400 engineering leaders found that 71% say AI is making it harder to assess technical skills. Two years ago, that number was around 20-30%. Something is shifting, and it is shifting fast. Take-home projects and automated code tests are losing their value too. A candidate can complete a take-home assignment with ChatGPT. A code test can be solved with an AI assistant in minutes. When you only look at the output, you cannot tell the difference. ## So what should we actually measure? The real question is not whether an engineer can use AI. It is how they use it. Writing a prompt is one thing. Reading the AI's output and saying "this is wrong" is another. Debugging a bad suggestion, spotting a security issue, asking "why did you structure it this way?" are all different skills. These are the things that matter in production. This also explains why AI is widening the gap between strong and weaker engineers, not closing it. AI increases productivity by an average of 34%, but not equally for everyone. Strong engineers get disproportionately more value from these tools. That is why 73% of engineering leaders say a strong engineer is worth at least 3x their total compensation. The questions that matter in an interview are shifting: * How does this candidate debug a system when something goes wrong? * Can they read AI-generated code with a critical eye? * How do they make decisions when there is no clear right answer? These are not things you can answer from memory. They come from experience and judgment. ## What big tech companies are doing At companies like Google and Meta, the interview format is moving away from LeetCode-style problems. The focus is shifting toward system behavior and engineering judgment. One story that stuck with me: a candidate expected a dynamic programming problem. Instead, they were given a log output from a failing service. Their job was to find a retry storm caused by a stale cache entry. The candidate started writing a BFS template. A complete mismatch. That is not just one bad interview. It reflects a real change in what companies want to see. Instead of "do you know this?" the question is becoming "how do you think when things go wrong?" Some companies are going further. Canva, Shopify, Meta, and Rippling now allow candidates to use AI during technical interviews. In New York, about 25% of companies already allow this, and that number is expected to grow. ## The process itself is getting longer There is also a practical problem that is easy to overlook. The average software engineer now goes through 4.2 interview stages before getting an offer. In 2021, that number was 3.1. The process is getting longer, candidates get impatient, and the faster offer wins. This is a loss for companies too. A slow and heavy hiring process pushes good candidates away before it is even finished. ## What this means for me Most of the time I am on the interviewer side. But I have been a candidate recently too. If the real job is no longer about coding alone without tools, the interview should not be either. Seeing how someone understands a system, questions an AI suggestion, or makes a decision under uncertainty is more useful than watching them recall an algorithm. The hard part is that this kind of interview takes more preparation. There is no single correct answer. Evaluation becomes more subjective. That is uncomfortable, but it is not a reason to avoid it. The technical interview is not dying. But it needs to grow up. ### Sources * _Karat, Engineering Interview Trends for 2026, karat.com (January 2026)_ * _IEEE-USA InSight, Three Ways AI is Reshaping Traditional Technical Interviews in 2026 (April 2026)_ * _Pragmatic Engineer, The Reality of Tech Interviews in 2025 (April 2025)_ * _Fahim ul Haq, FAANG is Changing: How Big Tech Interviews Are Evolving in 2026, Medium (January 2026)_ * _SwiftCruit, How AI Will Redefine Technical Interviews in 2026 and Beyond, Medium (December 2025)_

En sevdiğim yazarlardan biri olan Murakami'nin Mesleğim Yazarlık kitabını çok duyuyordum ama hep bekletiyordum. Bana çok teknik bir kitap gibi görünüyordu. Elime alıp, kitabın arkasını bile okumamıştım. Düzenli blog yazmaya başladığım günden sonra biraz yazarlığa olan bakışım değişti. Tabiki Murakami blog nasıl yazılır sorusuna cevap vermiyordu ama sonuçta ortada bir yazı vardı ve bu nasıl daha iyi olabilirdi? Bu soruya cevap ararken hadi şu kitaba bir bakayım diye başladım. ## Kitap ne anlatıyor Kitap direkt bir roman nasıl yazılır diye anlatıyor demek isterdim ama klasik bir Murakami kitabı olmuş. Murakami'nin denemelerini okuduysanız, mesela Koşmasaydım Yazamazdım, kendi hayatından oldukça fazla örnek verir. Adeta onun hayatını yaşarsınız kitap boyunca. Bu kitapta da biraz öyle ilerliyor. Kitabın arkasında her ne kadar yazarlık derslerinde okutulabilecek bir eser dese de ben pek buna katılmıyorum. Ders kitabından çok hayat kitabı gibi geliyor bana. Evet teknik konular var ama çok az diyebilirim. ## Okuma deneyimim Ben de kitaba başlamadan önce arkasını okuyunca "aha, teknik bir kitap, offf, ama deneyeceğim" dedim. Ve ilk sayfadan itibaren "bu Koşmasaydım Yazamazdım kitabı gibi olacak, belli oldu" dedim ve o keyifle okudum. Alınacak not çok fazlaydı ama almadım. Kitap okurken not almayı hâlâ beceremiyorum çünkü. Biraz sindire sindire okudum bu eseri. 11 bölüm var kitapta ve her bölümünü bitirdikten sonra biraz ara verdim, üzerine düşündüm. Bir yere not almadığım için burada çok derli toplu anlatamayacağım ne yazık ki. Artık aklımda kaldığı kadar. ## Teknik detaylar Kitap 208 sayfa ve Doğan Kitap'tan çıkma. Zaten Doğan Kitap, Murakami Türkiye şubesi gibi. Birçok kitabı oradan çıkıyor Türkçe olarak. Kitapta 11 farklı bölüm var. Biraz kronolojik ilerliyor ama ara ara atlamalar da var. 11 bölümde de Murakami konuyu dağıtmadan ne demek istiyorsa net bir şekilde anlatıyor. Kitabın çevirisini okuyamazdım çünkü Japonca'dan çevrilmiş. Çevirmen Ali Volkan Erdemir. Zaten dediğim gibi sade bir dille yazıldığı için Türkçesi de bir o kadar sade olmuş. ## İnceleme Bir önceki kitap incelemem bir roman olduğu için karakterlerden ve olay örgüsünden bahsedebiliyordum. Burada öyle bir durum olamıyor çünkü bir deneme. Deneme için yorum nasıl yapılır ben de bilmiyorum. Sadece biraz bende hissettikleri ve düşüncelerimi yazayım. Aslında roman yazmaya çok odaklanılmış bir deneme ki zaten bu çok normal. Murakami iyi bir roman yazarı. Hatta uzun soluklu roman yazarı ve bunu bir iş olarak yapıyor. Bütün geçimini buradan sağlıyor. Ancak ben biraz daha yazmak olayına baktım. Hatta kod yazmak bile diyebiliriz. Mesela onun da kitabında geçiyor, iyi bir yazar olmak için iyi bir okuyucu olmak lazım diyor. Çocukluğundan beri çok okuduğunu söylüyor. Bunu ne okuduğundan bağımsız olarak söylüyor. Benzer yere kod yazmada da geliyorum. Bir zamanlar birlikte çalıştığım bir yazılımcı abim demişti: iyi kod yazmak için kod okuman lazım. Açık kaynak bu yüzden var işte. Murakami yaşam tarzı olarak çok sade biri. Her Japon böyledir bilmiyorum ama kitaplarında anlattığı kadarıyla bunu hissedebiliyorum. Zaten biraz araştırma yapınca da çok net görülüyor. Bu kadar ünlü olmasına rağmen edebiyat ödülleri ile bir derdi yok. TV programlarına ya da radyo programlarına çıkmıyor. Çok nadir davet edilirse kabul ediyormuş. Yolda yürürken beni tanımazlar diyor. Dünyanın en ünlü roman yazarlarından biri yolda tanınmıyor ya da tanınmak için çaba sarf etmiyor. Acayip bir düzeni olduğunu ve bu düzen sayesinde roman yazabildiğini belirtiyor. Duygunun gelmesini değil, disiplini ön plana çıkarıyor. Tabiki şunu da ekliyor: iyi bir gözlemci olmak. Hayatı yaşarken gözlemlemek ve bunları beynin çekmecelerine koymak. Zamanı gelince oradan çıkarmak. Bu bana çok ilginç geldi. Pek benim yapabileceğim bir şey değil gibi. Denemedim. Belki o gözle hayata baksam yapabilirim. En çok hoşuma giden yer ise basit bir dille yazmaya çalışıyorum demiş olması. Ağdalı edebiyattan bilerek kaçtığını ve editörler ile sorun yaşadığını anlatıyor. Editörlerle pek iyi anlaşamadığını çünkü editörlerin ön yargılı olduğunu düşünüyor. Popüler olanı değil içinden geleni yazmak istediğini, böyle daha iyi olacağını düşünüyor. Başlarda çok zorlanmış ama Japonya'dan Amerika'ya, oradan da Avrupa'ya açılınca işler başka ilerlemiş. Aslında bunu anlatırken çok rahat fark ediliyor ki biraz da şansı yaver gitmiş. Ama şunu unutmamak lazım, evde beklerken şans gelmiyor, çabalamak lazım, işte o zaman şans bir şekilde geliyor. Kendisi ilk romanını Japonca yazıyor. Bakıyor bu olmamış. Çok ağdalı. Çok fazla karışık. Çok fazla edebiyat kasılmış ama olmamış. Gözüne güzel görünmüyor ve o romanı İngilizce yazmaya karar veriyor. Evet, bir Japon ilk romanını İngilizce yazıyor. Sonra o İngilizceden Japonca'ya çeviriyor ve bu onu daha fazla tatmin ediyor. Çünkü anadili olmayan bir dilde edebiyat kasayamam, o dille oynayamam diyor. Düz, basit, kendim ne anlatmak istiyorsam onu yaptım. Japonca'ya da öyle çevrildi. Okuttuğu insanlar "ya bu çeviri gibi duruyor" demişler hemen zaten. Ancak bu eseri edebiyat yarışmasında ödül kazanıyor. Çünkü niye, **simple is beautiful.** ## Sonuç Bu eser üzerine tek tek anlatmayı çok istesem de okumanızı tavsiye ediyorum. Ben tabiki biraz yanlı bakacağım, kusura bakmayın. Murakami'yi hem yazım stili hem yaşam tarzı olarak kendime yakın buluyorum. Kendisi hayatı biraz old school yaşıyor. Ben öyle yaşamıyorum ama çok istiyorum. Belki mesleğimden ötürü bazen bayılıyorum bu kadar teknolojiyle iç içe olmaya. 80'lerde doğan biri olarak özlüyorum daha basit ve yavaş hayatı. Yazım stili konusuna gelince ise benimkisi onun gibi değil ne yazık ki. Konuşurken ve düşünürken de çok dağınığım. Aceleciyim. Anlatmak istediğimi biraz ağdalı anlatmayı ve espriyi yaparak konuşmayı ya da yazmayı seviyorum. Beni de ben yapan bu işte. Bu eseri okuduktan sonra kendisine mektup yazmak istedim. Özellikle fiziksel mektuplara bakıyormuş. Biraz internet araştırması ile bunu öğrendim. Ancak çok net bir adres bulamadım. Ülkesindeki yayınevini buldum ama oraya göndermek de dert. Türkiye'den yollayabilirim diye düşündüm ama bilemedim. Belki ileride olur. Yaşadığım yerin bir kartpostalını koyabilirim. Açıkçası deneme incelemesi yazmak zormuş. Bundan sonra notlarımı bir yere koyacağım ki daha iyi bir yazı ortaya çıkabilsin. Umarım keyif almışsındır ve eğer bir yazar olmak istiyorsan bu denemeye bir şans ver derim, yorumlarını da duymak isterim. Ben yazmayı seviyorum ve havada kalsın istiyorum. Bu yazıyı beğendiysen blog'a kayıt olman, yorum yazman ve yazıyı paylaşman bana yapabileceğin en büyük destek olacaktır. Şimdiden teşekkürler.

I always liked tracking my income and expenses. There was an app called **Spendee** that I used a lot. I liked it. But it felt too complicated for me, so like every self-respecting developer, I switched to **Excel**. Excel was fine, but it wasn't enough. Doing anything useful required too much effort. So I thought, why not build it myself? There's AI now, anyway. > Let me build something nice with Ruby on Rails. The project was up and running very quickly. Tests were written. Deployment was done. Everything worked well. I started using the app in real life. It was doing exactly what I needed, and I could track my finances cleanly. When I build a web project, I usually try to make it responsive and mobile-friendly. This is called **mobile first**. The reason I do this is purely personal because I mostly use my phone. And for an app like this, where you're adding expenses on the go, responsive design makes more sense. **Tailwind CSS** helped a lot here, and I put together a responsive web app pretty quickly. But responsive alone wasn't enough. I wanted more. I started looking into **PWA (Progressive Web App)** and actually designed the app as a PWA from the beginning. That way I could use it like a mobile app on my phone, and it worked well enough. Now it was time to give the app a name. I hadn't thought much about it at the start, so the project was just called "finance tracker" on my computer and GitHub. But the product needed a real name. I asked my wife. I just said, _"I'm building this thing, if it were an animal, what would it be?"_ She said **fox** right away. Then I asked an AI what would come out of combining "finance" and "fox." It suggested Foxance. I liked it. My wife liked it too. For the logo, I thought maybe a fox emoji could work, but I wanted something more like a real logo. I found some visuals and shaped them a bit in Canva. After some back and forth with my wife, we had a name and a logo. She is basically the mother of the product's name. Sending her love here. So Foxance was running on web and as a PWA on mobile. That was good enough for a while. The features were there: income and expense tracking, categories, reports (this was the important part for me), export and import. It was a cute little thing with emojis and all. But at some point I thought, what if this had a real mobile app? I had been wanting to try **Hotwire Native** for a while, so I rolled up my sleeves and opened Xcode again. Since the backend was running on localhost:3000, getting the app running locally was easy. But the screen was just showing the web view, nothing native. Getting a native look isn't that hard in Rails when you know what to do. But I had very little experience and struggled a lot. I thought this approach wasn't working and started looking for alternatives. That's when I found Joe Masilotti's docs and posts. I cloned his Hotwire demo app and tried to build Foxance on top of it. It looked nice, but some demo code was still in there and I didn't feel good about it. Too much cleanup needed. I was getting tired. I also couldn't put a lot of time into this project. I work on it when I can. 14-20 minutes with an AI, then back to life. After a while I was still using Foxance daily, but I wasn't satisfied. I wanted a real mobile app. I wanted something on the App Store. While thinking about how to do that, I remembered something called RubyNative that I had seen before. It was also Joe's project. I had tried it once on a small project but it felt buggy. The documentation wasn't great at the time, so I dropped it. I decided to give it another shot for Foxance. This time I went through the docs step by step, slowly. And honestly, a native-looking app came together locally really fast. I didn't open Xcode once. I didn't write a single line of Swift. Just some YAML files and a bit of HTML/CSS. You could even say I barely wrote any Ruby either. I was surprised. Is it really this quick? I went deeper. I had a mobile design already, so I tried to match it. At one point I got stuck. I sent Joe a detailed email with screenshots explaining the problem. He helped me move forward. After getting a solid native look, it was time for the App Store submission. RubyNative helped here too, with screenshots and the upload process. A small issue came up, I emailed Joe, he found a fix quickly. I handled the other App Store details with AI help, and the app was in the store within two days. You can check it out here. That's the story. And it's still going. I enjoy it. I use it every day and it helps me. I have things I want to add. We'll see how many I actually do. * * * Let me go through the pros and cons of each approach I tried. ### Responsive Design (web) **Pros:** Zero extra infrastructure, no deployment headaches, single codebase. **Cons:** Mobile experience never feels truly "native." Safari limitations like push notifications and background fetch are annoying. ### PWA **Pros:** You can get a native-like feel quickly on top of an existing web app. It can be added to iOS home screen and behave like a mobile app. **Cons:** Limited ecosystem support. Some features don't work properly. Still can't fully replicate the native app feel. ### Hotwire Native **Pros:** A Rails developer can build a native app quickly with very little Swift knowledge. Single codebase. No need to write separate code for different environments. **Cons:** The codebase fills up with if/else conditions. CSS classes become messy. You still need to understand at least a bit of Xcode and Swift. ### Native Swift + JSON API **Pros:** A real native app. Being part of the Apple ecosystem. More flexibility in the code. No feature limitations. **Cons:** Learning a new language and environment. Managing a backend API on top. Working across two separate codebases. ### RubyNative **Pros:** No need for Swift or Xcode. Can run anywhere. You can ship a native app with just Ruby knowledge. **Cons:** Publishing to the App Store costs money. Doesn't fully deliver the native feel. Still maturing as a tool. Summary of the comparison ## Conclusion First of all, I'm happy because I solved my own problem. There are dozens of personal finance apps out there and I know that. I didn't invent anything new. I just solved my own problem with tools I know, and I built something where the data stays with me. I can change anything I want. It's mine from top to bottom. On top of that, I'm no longer a zero when it comes to native development. I learned a lot. RubyNative got me to the finish line quickly and I'm happy about that. The app isn't 100% native and I know it. Some people pointed out the design on social media. They're right. But this is where I am for now. I'm not doing much QA either, and some simple cases slipped through. Friends noticed and let me know. That's how these things grow, I guess. This isn't my professional work anyway, it's more of a side project. One last thing: do you have an idea? Do you have a problem you want to solve? Everything is here. I tried to show you what's possible in the Ruby ecosystem as someone who's still learning. I mentioned the people who helped me. The pros and cons are all laid out. Try things yourself. Ask questions. Research. Break stuff. The important thing is to say "let's see what happens" and actually go for it. I'm curious what you think. If you have questions, I'm here to answer them.

Bugün benim doğum günüm. 40 oldum. 10'lu yaş dönümlerini seviyorum. Bana iyi geliyor bu dönemlerde biraz konuşmak, yazmak. Keşke bu blog biraz daha eski olaydı da 20'li 30'lu yaşlarımda neler düşündüğümü okuyabilseydim. Olsun 40'lar bir başlangıç olsun. Kim bilir belki 50'ler, 60'lar ve ilerisinde okurum. Dile kolay ama düşününce baya uzun bir süre. 40 yıl… Az değil. Dedim ki bugün biraz iç dökeyim. Ne yaptım, ne oldu, nereye geldim… Böyle bir yazı olsun. Kime ne faydası olur bilmiyorum ama belki geleceğe bir şey kalır. 86 yılında, Ramazan ayında, Anneler Günü’nde doğmuşum. Yani kağıt üstünde baya **“hayırlı evlat”** paketi gibi duruyor 😄 Gerçekten öyle miyim… onu aileme sormak lazım. Küçük bir şehirde büyüdüm. O yüzden bazı şeylere geç ulaştım. Sinema, tiyatro… hatta bazı meyveler bile. Muz, kivi falan… İstanbul’a gidince yiyorduk. Şimdi komik geliyor ama o zaman öyleydi. Aslında bu da biraz imkan meselesi. İnternetten önce bir şeye ulaşmak gerçekten zordu. Mesela Metallica’nın St. Anger klibini indirmek için 2.5 saat beklediğimizi hatırlıyorum. 2.5 saat… Şimdi aç YouTube’u, 2 saniye. Kendi hayat hikayemi baştan sona anlatmayacağım. O kadar da değil 😄 Ama zaman meselesi garip geliyor bana. _“Yaş 35, yolun yarısı”_ demiş Orhan Veli. Ben o yarıyı geçeli 5 yıl olmuş. Ama o 5 yıl nasıl geçti… hiçbir fikrim yok. Zaten pandemi falan derken zaman komple buhar oldu. Zaman gerçekten garip. Bazen uçuyor, bazen geçmek bilmiyor. Eski fotoğraflara bakıyorum. Bebeklik hallerime… Bazen diyorum ki _“Bu ben miyim gerçekten?”_ Hiçbir şey hatırlamıyorum çünkü. Sadece fotoğraflar var. Bir kanıt gibi. Şimdi düşünüyorum… 80’li yaşlara gelince bu 40’lı yaşları da unutacak mıyım? Biraz ürkütücü aslında. Çünkü 40 benim için önemli bir yaş. > **Çünkü 40’a baba olarak girdim.** 39 yaşımdayken baba olacağımı öğrendim. Ve 40 yaşıma kızımla girdim. Hayat gerçekten bazen 10 dakikada değişiyor. Eşim doğuma girdi… 10 dakika sonra bir bebek vardı. Ve ben artık babaydım. Dünyada her gün milyonlarca insan baba oluyor. O kısmı çok zor değil. Ama mesele baba olabilmekte. Ben bunun tanımını yapamam. Gerçekten yapamam. Belki çok iyi babalar yapar. Ben öyle biri değilim. Olmaya da çalışmıyorum açıkçası.**“Süper baba”** olmak gibi bir hedefim yok. Benim hedefim daha basit: Akşam kafamı yastığa koyduğumda huzurlu olmak. Evde bir huzur varsa… eşim ve kızım iyiyse… tamam. Benim için babalık bu. Ama komik bir şey var. Eşim hamileyken bana soruyordu: _“Kızınla en çok ne yapmak istiyorsun?”_ Aklıma hep aynı şey geliyordu: > **bisiklete binmek.** Neden bilmiyorum 😄 Bisikletle çok alakam yok. Hatta doğru düzgün bisikletim bile yok. Ama kafamda hep aynı sahne: O küçük bisikletiyle, kaskını takmış… ben de yanındayım. Bir yere gidiyoruz, duruyoruz, bir şeyler yiyoruz… İlk gelen hayal hep bu. Babalıkla ilgili çok konuşulur ama ben buradan başka bir yere geçeyim. 40 oldum. Peki ne değişti? Hiçbir şey. Yarın yine aynı hayat. Aynı ben. Sadece sayı değişti. Ama yine de önemli. Çünkü 30’lar bitti. 30’lar benim için baya yoğundu, değişkendi. 40’lar için ise umutluyum. Bir ailem var. Enerjim var. İşim var. Hayatta fena bir yerde değilim bence. Maşallah diyelim, nazar değmesin 😄 Hatta şöyle hissediyorum: 40 yaşıma kadar olmak istediğim Ender’e büyük ölçüde geldim. Şimdi asıl soru şu: Buradan sonra ne olacak? Yeni bir Ender mi? Bilmiyorum. Beraber göreceğiz. Kendinize iyi bakın. ❤️

Geçenlerde karşıma şöyle bir X postu çıktı. Yazılımcı bir arkadaşımız meslekten çok bunaldığı için hobilerin peşinden gitmeye niyetlenmiş. Buraya kadar bence sorun yok. Herkes istediğini yapabilir, buna kim karışabilir ki. Sorun, eski mesleği olan yazılımcılıkla ilgili dediklerinde başlıyor ve ben bu konuda birkaç şey söylemek istiyorum. Herkesin kendi sebepleri olabilir, ancak burada sayılan sebepler bana pek gerçekçi gelmedi. Sebeplerin gerçek olmadığını söylemiyorum, sadece bu sebeplerin kişiye ait sebepler olduğunu söylüyorum. Hazır yapay zeka da geliyorken, mesleğe yeni başlayan arkadaşlara, işin içinde uzun süredir olan birinin biraz gerçekleri anlatması gerektiğini düşünüyorum. ## Para İlk önemli konuyla başlayalım: Para. Evet, bu meslekte hâlâ para var. Her meslekte olduğu gibi, tabii ki. Şimdi oturup memur olarak çalışırsanız zaten aylık bir geliriniz, belli bir gideriniz olur. Ayağınızı yorganınıza göre uzatır, geçinip gidersiniz. Bu mesleği ticaret yapmak için de kullanabilirsiniz ve ciddi paralar kazanabilirsiniz. Ay sonunu getiremeyecek kadar az para kazanmak ya da daha fazla harcamak tamamen kişisel bir tercih bence. Bundan 3-4 yıl öncesine kadar herkes yazılımcı olmak için sıraya girmişti. "Çok para var bu işte" diyorlardı. Peki şimdi ne değişti, hem de bir anda? Ben söyleyeyim: bir mesleğe sadece para var diye başlarsanız zaten sömürülürsünüz. Bu çok net. Kimse kimseye durduk yere o çok dediğiniz parayı vermez. Kısacası, yazılım yapıp para kazanabilir, ay sonunu rahatça getirebilirsiniz. ## Bilgisayara Yapıştım Bilgisayar başında 12 saat geçiriyormuş pizzacı olan arkadaşımız. Şimdi orada bir duralım. Bir iş için 12 saat harcamak, hele ki işin sahibi değilseniz, zaten çok garip. Bunun sebebi yazılımcı olmanız değil. Başka bir meslekte de bu olabilir. İşler iyi planlanmamıştır. Siz kahramancılık oynuyorsunuzdur ve bakarsınız özel hayat ile iş hayatı birbirine girmiş. Meslekten bağımsız bir durumdur bu. Bilgisayar başındayız diye her dakika kod yazmak ya da online olmak zorunda değilsiniz. Sizi zorunda tutanlardan uzak durun. ## Çok Yoruldum Kafa olarak ve fiziksel olarak yorulmak ya da yorulmamak. Yorulmadan yapılan bir iş var mı? Hobiniz bile olsa? Lütfen bana söyleyin. Hobi denilen şey para kazanılmaya başladığı zaman hobi olmaktan çıkıyor, özür dilerim. Hobinizden para kazanıyor olabilirsiniz ama o artık profesyonel işiniz oluyor, hobiniz değil. Gelelim yorgunluk konusuna. Yine aynı şeyler. Bizim meslekte tükenmek çok kolay. Fiziksel olarak erken çökmek de öyle. O yüzden dikkat edeceksiniz. Spor salonuna gidip bench presste 150 kg basın demiyorum. Süper ücretsiz uygulamalar var. Ekranınızı her yarım saatte bir kilitleyin. Bir 10 dakika gezin, evin içinde ya da neredeyseniz dolaşın. 12 saat oturursanız tabii ki ne kafa kalır ne bel ne boyun. Bu her iş için geçerli ama. Sağlığınıza dikkat etmelisiniz. O yoksa hiçbir şey yok. ## Bitmeyen Nöbetler İşte en sevdiğim. Geceleri hata mesajlarına uyanmak. Evet, bunu biz de yaptık, çünkü nöbetçiydik. Doktorlar nöbette _"gece hasta geldi, uyandım, tüh ya hobimi yapayım"_ diyorlar mı? Meslek böyle. Ama hep nöbete kalıyor ve o gece mesajları sizi uyandırıyorsa gene iş yapış şeklinizde sorun var ya da siz kahramancılık oynuyorsunuzdur. Nöbetçi olsanız bile o kadar çok uyanmamız gerekmiyor. Kodu düzgün yazmak gerekiyor. Mimariyi düzgün kurmak gerekiyor. Yoksa kaosun içinde geçer tüm ömür. ## Tükeniş Yazılımcı Yazılım ya da başka bir mesleğin sizi tüketmesine izin vermeyin. Bunu hobilerin peşinde koşarak çözebiliyorsanız eyvallah, ancak o iş de meslekten çıkmaz elbet. Ne yazık ki para diye bir kavram var. Para kazanmak için de çalışmak gerekiyor. Sistemli olmayan ve sizi sömüren yerlerde çalışırsanız zaten tükenirsiniz. Doğru, bizim meslekte tükenme payı yüksek, çünkü standartlar yok, kontrol yok. Hele ki pandemiyle birlikte ayar iyice kaçtı. Ama siz kaçırmayın bu ayarı. Uyanık olun. Sistemleri kuranlar insanlar, yani biziz. O yüzden ne iş yaparsak yapalım, düzgün insanlar ve düzgün sistemlerde tükenmezsiniz. ## Takım Elbiseli Adamlar Kurumsal hayat. Ah, ah. İnsanı bitirir işte. Bunun yine yazılımla bir alakası yok. Aslında çalıştığınız yere bağlı bu. Bazı yerler var 2-3 kişi ama yine kendilerini kurumsal sanıyorlar. Bazı yerler var yüzlerce insan çalıştırıyor ama bir gram kurumsallık yok. Peki nedir bu kurumsal? Yani ben ne anlıyorum? Açık konuşmak gerekirse, oturmamış sistemler ve tek adamcılık ya da bir zümrenin eline geçmiş sistem anlıyorum buradan. Kurumsal olmak kötü bir şey değil. Herkes, sistemin düzgün oturduğu, kimin ne iş yaptığının bilindiği ve sınırların iyi çizildiği bir yerde çalışmak ister. Buna kurumsal denir. Ama hiçbirinin olmadığı, beylerin hanımların havada uçuştuğu, maaş günü gelince yüzlerin döndüğü, sigortaların en düşükten yatırıldığı ve bunun gibi onlarca saçma işin döndüğü yer kurumsal değildir. Orası başka bir şeydir. Peki gerçek hayatı yansıtıyor mu orada yapılan toplantılar? Yansıtıyordur. Kimler var o toplantılarda? Hangi toplantılar bunlar? Neler konuşuyorsunuz? Zaten yansıtmasa o şirket batar. Nasıl para kazandıklarını anlamış değilim. ## Para Tatmin Etmiyor Kazanılan paranın karşılığını almadığını hissetmek. Bunu pek bilemedim. Ben hiç öyle hissetmedim. Belki bu işi severek yaptığım içindir. Bakın, şirketten bahsetmiyorum, yaptığım işten bahsediyorum. ## Tükendim Yine tükenmişlikten bahsediliyor ve "Türkiye'de böyle" deniyor. Dünyadaki tüm şirketlerde çalıştınız mı? Bu genellemeyi doğru bulmuyorum. Türkiye'de bu zamana kadar çalıştığım şirketlerin hiçbirinde bunu hissetmedim. Evet, çok çalıştık. Sabahlık. Ağladım bile çalışmaktan. Ama öyle gerekiyordu, ayakta kalmamız gerekiyordu. Sonra ne oldu? Sistemlerimizi oturttuk ve bir düzene girdik. Aslında sistemi siz kurmaya başladığınızda evet, çok tükeniyorsunuz. Sabahlar geceler karışıyor. Ama bir sistem kurulursa gerisi güzel. Ya da güzel bir sisteme geliyorsunuz ve ona ayak uydurup güzel devam ediyorsunuz. Ya da sistemi olmayan bir yerde aklınızı kaybediyorsunuz. Seçim burada yine sizin. Yazılım sektöründe bu çok görünür oluyor, tek konu bu bence. ## Sonuç Umarım bunu yazan arkadaş, onun dediklerine tek tek değindim diye bana kızmamıştır ya da alınmamıştır. Benim için iyi bir rehber oldu kafamdakileri toplamak için. Aslında yazacak çok şey var ama neresinden tutsam hep elimde kalıyor. Eğer bu yazıyı okuyorsan, lütfen kusura bakma. Burada senin şahsınla alakalı tek bir şey demek istemiyorum. Genel olarak bu şekilde düşünen insanlara ya da düşünecek insanlara, yaptığımız mesleği anlatmaya çalışıyorum. Hobileri yapmak güzel. Ondan para da kazanmak güzel. Ben müziği seviyorum, davul çalmaya çalışıyorum. Ama davul çalarak para kazanmak istersem yatak yorgan yerim. Müzisyen olmak istemiyorum ben. Ben davula vurmak istiyorum. Arkadaşlarımla sevdiğimiz şarkıları kafamıza göre, eğlendiğimiz şekilde çalmak istiyorum. Ben bir yazılım profesyoneliyim, müzik profesyoneli değil. Yazılım konusunda her anlamda profesyonel olmak durumundayım. Çalıştığım insanlar, dokunduğum insanlar, ağzımdan çıkanlar, yazdığım kodlar. Bunların hepsi benim sorumluluğum. Yarın _"yapmadım, etmedim, demedim"_ diyemem. Çünkü burada istediğim notayı istediğim şekilde çalamam. Bundan ekmek yiyorum. Sorumlu olduğum, belki yüzünü bile hiç görmediğim binlerce insan var. Ben ve çalıştığım şirketlerin yaptığı ürünleri kullanıyorlar. O insanlara karşı sorumluluklarım var. Buna iş deniyor işte. Bir düzen ve sistem kurup hayatıma devam ediyorum, işime odaklanıyorum. Yaptığım şeyi seviyorum ama ona aşık değilim. Onsuz da yaşayabilirim. Ama müzik olmadan yaşayabilmem biraz zor. Umarım kendimi anlatabilmişimdir.

Gece 1. Terminalde bir şeyler dönüyor. Kafanın bir köşesinde "tamam artık yatıyorum" sesi var ama parmaklarınız çoktan yeni bir prompt yazmış bile. Bunu yaşamayan kaldı mı? Ben yaşadım. Bluesky'a yazdım, LinkedIn'e de. Ama asıl anlamak istediğim şeyi tam oturtamamıştım. Şimdi oturmaya çalışıyorum. Hem kendi deneyimimden, hem de son aylarda bu konuyu ciddiye alan araştırmacıların bulgularından yola çıkarak. ## Slot Makinesi Olarak Yazılım Geliştirme Geçenlerde LeadDev'de bir yazı çıktı. Uzun süredir yazan bir geliştirici, agentic coding'i bir vampire benzetiyordu. Sizi ısırıyor, enerji veriyor ama bir şeyler alıp gidiyor da aynı zamanda. Yazıda şu benzetme var: her prompt bir kol çekmek gibi. Bazen hiçbir şey çıkmıyor, bazen ortalama bir sonuç, bazen inanılmaz bir "jackpot." Beyin bu belirsizliği seviyor. Dopamin tam da burada salgılanıyor yani kumarda olduğu gibi. WPP'de çalışan bir principal engineer, _"Gün sonuna kadar bilgisayardan kalkmakta zorlanıyorum"_ diyor. Bunu kimse ona söylememiş, kimse zorunlu tutmamış. Sadece... bırakamıyor. Tanıdık geliyor, değil mi? Kod yazmak her zaman bir tür akış haliydi. Ama şimdiki akış farklı. Daha hızlı, daha uyarıcı, daha kolay bağımlılık yapıcı. Ve çok daha zor durduruluyor. ## Verimlilik İllüzyonu Rakamlar artık ortada. Multitudes'un 500'den fazla geliştiricinin iş akışını takip ettiği araştırma, AI araçları kullananların mesai dışı commit sayısının yaklaşık %20 arttığını buluyor. ActivTrak'ın 163.000'den fazla çalışanı kapsayan çalışması ise daha da çarpıcı: Cumartesi ve Pazar verimli çalışma saatleri sırasıyla %46 ve %58 artmış. Hafta sonu kavramı sessizce eriyor. (LeadDev) Paramount'ta çalışan kıdemli bir yazılım mühendisi durumu şöyle anlatıyor: > Geçen yıla kadar normal bir sosyal hayatım vardı. Şimdi her hafta sonu bir plan yapıyorum — ne öğreneceğim, ne deneyeceğim. Ve hafta sonları yok olup gidiyor. Yani AI bize zaman kazandırmıyor. Bize daha fazlasını yapmayı mümkün kılıyor ve biz de yapıyoruz. Bu fark küçük görünüyor ama değil. 💡 ****"Daha verimli çalışmak" ile "daha fazla çalışmak" aynı şey değil. Biri sizi özgürleştirir, diğeri sömürür.**** ## Yaratıcıdan Denetçiye Agent altyapısı üzerine çalışan geliştirici Siddhant Khare, kişisel blogunda bunu çok net koyuyor ortaya: > Geçen çeyrekte kariyerimde hiç olmadığı kadar çok kod yazdım. Aynı zamanda hiç olmadığı kadar tükendim. Bu ikisi birbirinden bağımsız değil. Sebebi şu: AI her görevi hızlandırıyor, ama siz daha az iş yapmıyorsunuz daha fazlasını yapıyorsunuz. Kapasite genişliyor, iş o kapasiteyi dolduruyor. Yöneticiniz sizi daha hızlı görüyor, beklentiler ayarlanıyor. Siz de kendinize daha yüksek standart koyuyorsunuz. Önceden bir tasarım problemi üzerinde tam bir gün düşünebiliyordunuz. Kâğıda çiziyordunuz, yürüyüşe çıkıyordunuz, duşta düşünüyordunuz. Şimdi altı farklı problem arasında gidip geliyorsunuz her biri "AI ile sadece bir saat sürer" diye. Ama altı farklı probleme bağlam geçişi yapmak insan beynine çok pahalıya mal oluyor. AI üretiyor, siz denetliyorsunuz. Yaratmak enerji veriyor. Denetlemek tüketiyor. Üstelik AI'ın ürettiği kodu satır satır okumak zorundasınız bir meslektaşınızın kodunu değil bu, kalıplarını tanımadığınız, konvansiyon bilmeden çalışan bir sistemin çıktısını. Her satır potansiyel olarak şüpheli. ## Hız Artıyor, İskelet Yetişemiyor IT Pro'nun haberine göre yapılan tespitler: AI araçlarını günde birden fazla kullananların %45'i kodu daha hızlı deploy ediyor. Güzel. Ama kalite güvencesi, güvenlik testleri, code review süreçleri artık neredeyse kırılma noktasına geliyor. "Motor hızlandı ama onu tutan iskelet yetişemiyor." İnsan hızında geliştirme için kurulmuş tüm süreçler; QA, deployment kontrolleri, mimari kararlar ve şimdi makine hızında çalışmak zorunda. Ve çoğu ekipte bu geçiş henüz olmadı. Hız arttı, ama sistematik düşünme zamanı azaldı. Benim gibi 14 yıl önce kod yazmaya başlayanlar hatırlayacaktır: hata yapmak da öğrenmenin bir parçasıydı. Hatayı siz yapıyor, siz buluyor, siz düzeltiyordunuz. Şimdi bazen kendinize ait olmayan bir hatayı düzeltmeye çalışıyorsunuz ve neden yapıldığını bile bilmiyorsunuz. ## Bilişsel Yorgunluk: Kimse Konuşmuyor UC-Berkeley araştırmacıları, gerçek bir teknoloji şirketini sahada gözlemleyip bulgularını Harvard Business Review'da yayımladı. Sonuç sert: AI'ın verimlilik vaadi, onu en hevesli benimseyen çalışanların daha fazla iş üstlenmesine, daha hızlı çalışmasına ve sürdürülemez biçimde çoklu görev yapmasına yol açıyor. Araştırmacılar sahada şunları gözlemledi: çalışanlar öğle aralarında, toplantı arasında kalan beş dakikada, masadan kalkmadan önce prompt yazıyor ki agent masalarından uzakken çalışmaya devam etsin. Sonuç: molasız, sürekli, sınırsız bir iş günü. Ayrıca bu süreç, mühendislerin kendi projelerini anlamasını da zorlaştırıyor. Bir CS profesörü bunu "görünmez kararlar" olarak tanımlıyor: hangi tasarım kararının neden alındığını kimse açıklayamıyor, sistemin parçalarının birbirine nasıl bağlandığını kimse bilmiyor. Teknik borç değil bu bilişsel borç. Bir mühendis bunu çok somut anlattı: Claude bilmediği bir kütüphane kullandığında, kendi kodunu debug edemez hale geliyor. "Junior bir mühendis gibi AI'a Slack mesajı atarak cevap arıyorum" diyor. ## Doğal Hız Sınırı Kalktı Siddhant Khare'nin en çarpıcı tespiti bu: > Eskiden bir tavan vardı. Yazma hızınız, düşünme hızınız, araştırma süreniz. Sinir bozucuydu ama aynı zamanda bir vites limitleyiciydi. Artık tek sınır bilişsel dayanıklılığınız — ve çoğu insan bunu ancak geçtikten sonra anlıyor." (siddhantkhare.com) Bunu okuyunca bir şey tıklandı içimde. Saatlerce ekran başında oturmak. Telefonda agent'ları kontrol etmek. Öğle yemeğinde prompt yazmak. Yatmadan önce "bir tane daha" demek. Bunlar artık istisnai değil, normal. Ve "normal" haline gelen her şey sorgulanmaz olur. ⚠️ ****Doomscrolling'den ne farkı var bunun, dedim bir ara. Düşününce fark var aslında doomscrolling'de en azından ürettiğinizi sanmıyorsunuz.**** ## Bu Kazancı Kim Topluyor? MIT Technology Review'ın araştırması başka bir şeye dikkat çekiyor: 22-25 yaş arası yazılım geliştirici istihdamı 2022-2025 arasında yaklaşık %20 düştü. AI destekli araçların yaygınlaştığı dönemle örtüşüyor bu. Daha fazla kod, daha hızlı teslim, daha geniş kapsam bunların hepsi birer beklenti haline geliyor. Beklentiler normalleşince, ekstra çalışan "verimli" developer değil, sadece yeni standart oluyor. AI'ın verimliliği artırdığını inkâr etmiyorum. Artırıyor. Ben de kullanıyorum, işime yarıyor. Ama şu soruyu sormak için kimse durmuyor: bu kazancı kim topluyor? Remote çalışmayla birlikte mesai kavramı zaten muğlaklaşmıştı. AI bu muğlaklığı daha da derinleştiriyor. Fiziksel olarak ofiste olmak bir sınır koyuyordu — eve gidiyordun, iş kalıyordu. Şimdi iş telefonunda, kulağında, yatmadan önceki son düşüncende. Kim koyacak bu sınırı? Nasıl? Erken fark ettiğimi düşünüyorum ya da en azından erken sormaya başladım. Bluesky'daki postum bunun işaretiydi. Ama sormak yetmiyor, cevap da gerekiyor. Şimdilik cevabım şu: fark etmek, adını koymak, ve en azından "son bir prompt" dediğinde bunun bir şeyin semptom olduğunu bilmek. Hadi ben yatar, iyi geceler. ### Kaynaklar * LeadDev — "Addictive Agentic Coding Has Developers Losing Sleep" (Mart 2026) * Harvard Business Review — "AI Doesn't Reduce Work — It Intensifies It" (Şubat 2026) * Siddhant Khare — "AI Fatigue Is Real and Nobody Talks About It" (Şubat 2026) * IT Pro — "AI Doesn't Solve the Burnout Problem. If Anything, It Amplifies It." (Mart 2026) * MIT Technology Review — "AI Coding Is Now Everywhere. But Not Everyone Is Convinced." (Aralık 2025)

Geçenlerde Devnot geliştirici anketinin Ruby dili kırılımlarına bakan detaylı bir yazı yazmıştım, eğer okumadıysanız bir göz atın derim. O yazının sonuda AI çağında Ruby neden bir alternatif yazı gelecek demiştim. İşte o yazı. "Ruby öldü mü?" sorusu yıllardır sorulur. Cevap her seferinde aynıdır: hayır. Ama bu sefer cevap biraz farklı. Çünkü Ruby sadece hayatta kalmıyor ve AI çağında beklenmedik bir avantaj kazanıyor. Bu yazıda bunu somut verilerle, gerçek hikayelerle ve kod örnekleriyle anlatacağım. ## Sadece Bir Sayı: 250 Birkaç ay önce Sinaptia ekibi 250 satır Ruby koduyla tam özellikli bir coding agent yazdı. CLI arayüzü, konuşma geçmişi, slash komutları, subagent desteği, kaydet ve devam et özelliği. Hepsi 250 satırda. Projenin adı Detritus. Açık kaynak. Kodu inceleyebilirsiniz. Bu rakamı ilk duyduğumda içimden şunu geçirdim: "Tamam, ama Python'da da yapılır." Evet, yapılır. Go'da da yapılır. JavaScript'te de. Ama Ruby'de yazmak farklı hissettiriyor. Ve bu fark sadece estetik değil. Birikir. Zamanla büyür. Peki neden? ## Problem Değişti Birkaç yıl öncesine kadar yapay zeka uygulaması geliştirmek şu anlama geliyordu: veri seti topla, model eğit, uygulamayı yaz. Bu sürecin her adımı ayrı bir uzmanlık gerektiriyordu. Şimdi bu tablo köklü biçimde değişti. Modeller hazır. OpenAI, Anthropic, Google ve hepsi API sunuyor. Bizim işimiz artık model eğitmek değil, bu modelleri kullanarak ürünler inşa etmek. Sinaptia bunu çok güzel özetledi: "Problem lab'dan workshop'a taşındı." Yapay zeka artık bir araştırma problemi değil, bir entegrasyon problemi. Ve bu değişim her şeyi farklılaştırıyor. Entegrasyon problemleri için ihtiyacınız olan şeyler farklı: hızlı iterasyon, temiz arayüzler, okunabilir kod, güçlü ekosistem. Ruby'nin tam güçlü olduğu alan tam burası. ## AI Araçları Her Dili Eşit Yazmıyor Ruby committer Yusuke Endoh geçen ay ilginç bir deney yaptı. Claude Code'u kullanarak 13 farklı programlama dilinde aynı görevi yaptırdı: mini bir Git implementasyonu. Her dil için 20 ayrı deneme, toplamda 600 çalıştırma. Süreyi, maliyeti ve test başarısını ölçtü. Sonuçlar şaşırtıcıydı: Ruby birinci. Python ikinci. JavaScript üçüncü. Sonra büyük bir uçurum var. Dinamik diller ile statik tipli diller arasında 1.4 ila 2.6 kat fark. Hem sürede hem maliyette. Bu fark neden önemli? Çünkü AI ile geliştirme iteratif bir süreç. Her döngüde biriken küçük farklar, günün sonunda ciddi bir zaman ve para kaybına dönüşüyor. ## Convention Over Configuration Rails'in temel felsefesini biliyorsunuzdur: Convention over Configuration. Her şeyin belirlenmiş bir yeri var. Authentication nasıl yapılır bellidir. Background job nasıl kurulur bellidir. Dosyalar nereye gider bellidir. Bu felsefe yıllarca tartışıldı. Kimileri "çok kısıtlayıcı" dedi. Ama şimdi bu felsefe beklenmedik bir avantaja dönüştü. Cursor, Claude Code ya da Copilot bir Rails projesine baktığında ne yapacağını biliyor. Tahmin etmesi gerekmiyor. Controller nereye gider? `app/controllers` altına. Model nasıl kurulur? ActiveRecord ile. Migration nasıl yazılır? Belirli bir format var. Bu öngörülebilirlik sayesinde AI araçları Rails projelerinde çok daha doğru öneriler sunuyor. Daha az hata, daha az düzeltme. Kod ilk seferinde daha doğru geliyor. Steve Clarke geçen ay tam bunu test etti. Aynı promptları farklı framework'lerde denedi. Sonuç netti: konvansiyonları güçlü framework'lerde AI çok daha iyi iş çıkarıyor. ## Gerçek Bir Hikaye: 30 Dakika, Production Soyut konuşmayı bırakıp somut bir örneğe bakalım. Miles Woodroffe neredeyse bir yıldır dokunmadığı bir meal planning uygulamasına yeni bir özellik eklemek istedi. Vitality uygulamasındaki egzersiz puanlama sistemine benzer bir şey. Ne yaptı? Vitality'den iki ekran görüntüsü aldı, Claude Code'a sürükledi ve ne istediğini anlattı. Claude bu görüntülerdeki halkaların 3, 5 ve 8 adımlık tamamlanma hedeflerini temsil ettiğini yorumladı. Aylık pagination ekledi. Miles'ın hiç bahsetmediği bir özet bölümü önerdi. Veritabanı değişikliğini tasarladı. Model ve controller'ı yazdı. Solid Queue ile her gece çalışacak bir job kurdu. Çalıştı. 30 dakika. 6 aydır ertelenen özellik production'da. Bu sihir değil. Bu Rails'in convention'larının Claude'a "her şeyin nereye gideceğini" söylemesi. Claude tahmin etmek zorunda kalmadı. ## İki Yönlü Avantaj Ortaya çıkan tablo şu: avantaj iki yönlü işliyor. Bir yönde: Convention sayesinde AI Ruby'yi daha doğru yazıyor. Rails'in öngörülebilir yapısı, AI'ın nereye ne koyacağını bilmesi anlamına geliyor. Öte yönde: Ruby'nin berrak syntax'ı sayesinde siz AI'ın yazdığını daha hızlı anlıyorsunuz. Ne yapıldığını görüyorsunuz, neyi değiştireceğinizi biliyorsunuz, devam ediyorsunuz. Bu döngü; Yaz, anla, değiştir, ilerle ve bu saatler boyunca kesintisiz işliyor. Flow state bozulmuyor. Sinaptia bunu şöyle formüle etti: Güç sadece yapabilme kapasitesi değil. > **Güç = kapasite / efor** Ruby bu oranı maximize ediyor. ## Ekosistem Hazır "Ruby'nin AI kütüphaneleri yok" argümanını hâlâ duyuyorum. Bu artık doğru değil. **RubyLLM** şu an 12 provider'ı destekliyor: OpenAI, Anthropic, Google Gemini, Ollama ve daha fazlası. Hepsi aynı arayüzle. 800'den fazla modele erişim var. GitHub'da 4.7 milyon indirme. 37signals production'da kullanıyor. Koda bakalım. Python ile temel bir OpenAI entegrasyonu: client = OpenAI() response = client.chat.completions.create( model="gpt-4", messages=[{ "role": "user", "content": "Merhaba" }] ) Ruby ile aynı şey: chat = RubyLLM.chat chat.ask "Merhaba" Aynı sonuç. Çok daha az gürültü. Ve AI bu kodu ürettiğinde, siz Ruby versiyonunu çok daha hızlı okuyup anlıyorsunuz. Bunların yanında **langchainrb** ile RAG pipeline kurabilirsiniz, **Active Agent** ile Rails'e entegre agent'lar geliştirebilirsiniz. Ekosistem büyüyor. Evet, PyTorch ve NumPy Python'da. Model eğitiyorsanız Python seçin. Ama model kullanıyorsanız yani AI'ı bir ürün özelliği olarak entegre ediyorsanız. Ruby ekosistemi artık tam anlamıyla hazır. ## Disposable Code Garry Tan geçen ay şöyle dedi: "Rails syntactic sugar için tasarlandı, LLM'ler sugar fiend." Yani LLM'ler tatlıya düşkün, Rails de tam istediğini veriyor. Miles Woodroffe bunu "disposable code" kavramıyla açıklıyor. Fikirler bu hızda hayata geçebiliyorsa çalışma şekli de değişiyor. Bir branch açıyorsunuz, fikri deniyorsunuz. Tutmadıysa branch'i silip devam ediyorsunuz. Eskiden koda emek verirdik çünkü maliyetliydi. Şimdi kod ucuzladı. Değerli olan hâlâ fikrin kendisi. Ama o fikri test etmek artık çok daha az efor gerektiriyor. Bu kültür Rails'in prototipleme felsefesiyle mükemmel örtüşüyor. ## Bu Neden Şimdi Oluyor? 2005'te Rails çıktığında şunu söyledi: "Web uygulaması geliştirmenin doğru yolu var. Biz onu convention olarak sunuyoruz. Sen sadece iş mantığına odaklan." Bu o dönemde devrimdi. 2026'da aynı şey tekrar oluyor, bir üst katmanda. LLM'ler entegrasyon problemine dönüştü. Orchestration yazıyoruz, API çağırıyoruz, sistemleri birbirine bağlıyoruz. Rails tam olarak bu iş için tasarlanmış bir ekosistem. Aynı felsefe. Yeni katman. ## Son Olarak 250 satır. Tam özellikli coding agent. 30 dakika. 6 aydır ertelenen özellik production'da. 13 dil içinde birinci. Bu rakamlar tesadüf değil. Ruby'nin okuması ve yazması kolay syntax'ı, Rails'in öngörülebilir convention'ları ve olgunlaşan AI ekosistemi bir araya gelince ortaya çıkan şey bu. AI çağında asıl iş nereye kayıyor? **Ne inşa ettiğimizi düşünmeye.** Hangi problemi çözüyoruz, kullanıcı deneyimi nasıl olmalı, sistem nasıl davranmalı. Ruby bunu mümkün kılıyor ve bu bence yeterince güçlü bir neden. Peki siz AI projelerinizde hangi dili kullanıyorsunuz? Ruby denediniz mi? * * * **Kaynaklar** * AI agents in Ruby: Why is it so easy? — Sinaptia * Which Programming Language Is Best for Claude Code? — Yusuke Endoh * Ruby on Rails + Claude Code = Magic — Miles Woodroffe * Your AI Doesn't Write Every Framework Equally Well — Steve Clarke * RubyLLM — GitHub

We hold a Ruby Campfire at the company I work for, bi-weekly. It's not a real campfire of course we work remotely! Recently, we talked about Ruby delegated types in one of those meetings. It was really interesting. I used to use STI (Single Table Inheritance) to connect multiple tables, but it turns out there is a different and more effective solution. ## Background Single-table inheritance looks simple at first. One table, one `type` column, done. Rails makes it easy to set up. But then the problems start. I've been writing Rails apps for over 14 years. I've seen the STI trap many times in my own code too. You start with two or three similar models, put them in one table, and move on. Six months later, the table has thirty columns. Most of them are `NULL` for any given row. The `type` column is the only thing keeping it together. There's a better option. Rails has had it since 6.1. It's called delegated types. ## What's Wrong With STI STI works fine when your models are very similar. When they share most columns and only differ a little in behavior. The Rails docs say it clearly: > "STI works best when there's little divergence between the subclasses and their attributes." A simple example: you have `Message` and `Comment`. You want to show both in a feed and paginate them together. STI lets you do that. But a `Message` has a `subject` column. A `Comment` doesn't. With STI, the comment row gets a `subject` column anyway. It's just always `NULL`. Do this with enough models and enough columns, and your table becomes a mess. It's hard to query, hard to index, and hard to understand. Polymorphic associations fix the sparse table problem, but they bring other issues: no foreign key constraints, more complex queries, and it gets confusing fast. ## A Third Option DHH added delegated types to Rails 6.1. The idea is simple: keep the shared columns in one **"superclass"** table. Give each subclass its own table for the columns that are specific to it. DHH said this pattern had _"the most profound impact on how we do domain modeling at Basecamp"_. They used it in Basecamp 3 and then in HEY. Here's how it looks. You have an `Entry` model. It holds the shared stuff: `creator_id`, `account_id`, timestamps. Then `Message` and `Comment` each have their own tables with their own specific columns. class Entry < ApplicationRecord delegated_type :entryable, types: %w[ Message Comment ] delegate :title, to: :entryable end class Message < ApplicationRecord def title subject end end class Comment < ApplicationRecord def title content.truncate(20) end end Now you can call `entry.title` on anything in the feed. `Message` returns its subject. `Comment` returns a short preview. The caller doesn't need to care which one it is. The schema stays clean. The `entries` table has only shared columns. The `messages` and `comments` tables have only their own columns. No `NULL` columns, no `if record.type == "Message"` checks in your views. ## How Is This Different From Polymorphic Associations? Delegated types are built on top of polymorphic associations. DHH called it **"syntactic sugar"** in some early discussions. But the intent is different. With normal polymorphic associations, you go from parent to child: fetch a `Post`, then get its `images`. With delegated types, you go the other way. You query from `Entry` and let it delegate to the specific type. `Entry` is the main entry point. `Message` and `Comment` are details. This means you can write `Entry.all` and paginate across all types with no `UNION` queries. You can eager-load associations on `Entry`. You can build controllers around `Entry` that work for both messages and comments. The 37signals team talked about this on their dev blog. Their version of `Entry` is called `recordings`. It stays small because it only holds foreign key references. The actual content lives in the specific tables. A small table is easy to index and easy to query. The content tables can grow on their own without making everything slow. ## When to Use It Delegated types aren't always the right choice. If your models are very similar and you don't need pagination across types, STI is fine. But if you see yourself doing any of these things, delegated types are worth trying: * Adding columns to an STI table that only one model uses * Writing `if record.type == "Message"` in views or controllers * Having trouble paginating across different model types * Building a feed, timeline, or activity log with different kinds of content The `Entry`/`Message`/`Comment` example in the Rails docs looks simple. But 37signals has used this pattern in production for over ten years, across two big products. ## One Thing to Know When you need to filter by a subtype-specific column, you need a join. If you want to filter by `messages.subject`, you join `entries` to `messages`. This is usually fine, but it's good to know before you start. The 37signals engineers said the small size of the `entries` table makes this less of a problem. A small table is cheap to index. ## How to Set It Up Creating a record is simple: Entry.create!( entryable: Comment.new(content: "Hello!"), creator: Current.user, account: Current.account ) Rails gives you scopes and helpers automatically: `Entry.messages`, `Entry.comments`, `entry.message?`, `entry.comment?`. Rendering is clean too: <%# entries/_entry.html.erb %> <%= render "entries/entryables/#{entry.entryable_name}", entry: entry %> Each type gets its own partial. `Entry` doesn't need to know which one to pick. ## Why It Matters Rails is opinionated. It bets that good conventions make code easier to work with over time. Delegated types feel like one of those conventions not a new abstraction for its own sake, but a name and a structure for something developers were already doing by hand, usually in a messier way. It came from DHH's own work at Basecamp. It ran in production. It survived scaling. It got refined over years before it became part of the framework. If you've been using STI out of habit, it's worth reconsidering. Not every model hierarchy needs delegated types. But the ones that do will be much cleaner for it. If you've used STI or delegated types in your own projects, I'd love to hear about it. Which one did you go with? Did delegated types make things easier, or did you run into problems I didn't mention here? And if you're still using STI is it working well, or are you starting to feel the pain? Let me know in the comments. **References** * ActiveRecord::DelegatedType — Rails API * Add delegated type to Active Record — DHH's original PR #39341 * DHH on X — Delegated types and domain modeling at Basecamp * The Rails Delegated Type Pattern — 37signals Dev Blog * Delegated Types are an alternative to STI — DEV Community * Delegated Types in Rails — Medium / NYC Ruby on Rails * The delegated type pattern and multi-table inheritance — Mateus Guimarães

Uzun bir zamandır yazılım işi ile uğraşıyorum. Pandemiden sonra evden çalışma düzenine geçtim. Artık evden çalışıyorum. Artık herkes neden bahsettiğimi çok iyi biliyor; aynı odada, aynı sandalyede, aynı ekrana bakarak geçen saatler. İş-ev arası mesafem yatak odamdan çalışma masama on iki adım. İş arkadaşlarım video görüşmesindeki küçük kareler. Öğle aram mutfağa gidip gelmek. Uzun süre bunun ideal hayat olduğunu düşündüm. Trafik yok, ofis politikası yok, sadece ben ve kodum. Sessiz, rahat, verimli. Ama sessizliğin bir ağırlığı var. Aylar geçtikçe odanın duvarları daralır gibi oldu. Düşüncelerim aynı döngüye girip çıkıyordu. Sonsuz recursion'a düşmüş bir fonksiyon gibi. Üretkenliğim yerindeydi ama içimde bir şeyler eksikti. Huzursuz, bulanık, tarif edemediğim bir mutsuzluk. Debug edemediğim bir bug. Bir öğleden sonra, saatlerdir çözemediğim bir hatadan bunalıp ayağa kalktım. Ayakkabılarımı giydim, kapıyı açtım ve yürümeye başladım. Planım yoktu, rotam yoktu. Sadece yürüdüm. O gün hayatımın en basit ama en dönüştürücü alışkanlığına rastladım. ## İlk Nefes Deniz kenarında bir şehirde yaşıyorum. Deniz hiçbir zaman uzak değil. O ilk yürüyüşte yokuştan sahile indim. Rüzgar yüzüme çarptığında tuzlu, serin, inanılmaz taze. Bir şey değişti. Aylardır geri dönüşümlü hava soluyan ciğerlerim gerçek havayı unutmuş gibiydi. Durdum, sadece nefes aldım. Bu hissin arkasında bilim var. Deniz havası negatif iyonlarla dolu ve bunların ruh haline, zihinsel berraklığa olumlu etkisi araştırmalarla desteklenmiş. Ama o an bana bir çalışma göstermenize gerek yoktu. Göğsümdeki sıkışma gevşedi. Kafamdaki gürültü azaldı. Haftalardır ilk kez gerçekten orada olduğumu hissettim. > _Hayatımdaki her şeyi optimize ediyordum. Kodum, iş akışım, kullandığım araçlar. En önemli sistem: KENDİM._ O yürüyüş fazla uzun sürmedi, yarım saat kadar. Masama döndüğümde bütün sabah beni çıldırtan hata birden anlam kazandı. Çözüm o kadar basitti ki kendime şaşırdım. Beynim daha fazla ekran süresine değil, boşluğa ihtiyaç duyuyormuş. ## Beden Unutmaz Evden çalışmak özünde hareketsizlik egzersizidir. Parmakların klavyede, gözlerin ekranda ama bedenin park halinde. Zamanla bu hareketsizlik birikir. Omuzların kulaklarına doğru çıkar. Belin inatçı bir ağrıyla sızlar. Kendini bir insan değil, iş istasyonunun uzantısı gibi hissetmeye başlarsın. Yürümek bunu çözer. Dramatik şekilde değil, bir anda değil ama adım adım kelimenin tam anlamıyla. Düzenli yürümeye başladığımda ilk fark ettiğim şey büyük bir aydınlanma değil, basit bir fiziksel rahatlamaydı. Bacaklarım hareket etmek istiyordu. Eklemlerim bükülmek istiyordu. Omurgam öne kıvrılmak yerine yukarı uzanmak istiyordu. İnsan bedeni sekiz saatlik oturma maratonları için tasarlanmamış. Yürümek için tasarlanmış. Birkaç hafta içinde değişimler somutlaştı. Daha iyi uyudum. Öğleden sonraki enerji çökmesi geçti. Kürek kemiklerimin arasındaki inatçı düğüm çözülmeye başladı. Günlük yürüyüşümü egzersiz olarak değil fazla baskı taşıyan bir kelime bakım olarak düşünmeye başladım. Dağınık kodu refactor etmek ya da tıkanmış bir cache'i temizlemek gibi. Yürümek, içinde yaşadığım makinenin bakımıydı. ## Yabancılar, Komşular ve Monitörün Ötesindeki Dünya Uzaktan çalışmaya başladığınızda sizi kimse uyarmaz: yalnızlık sessizce gelir. Bir anda çökmez. Atlanmış bir selamlaşma, vazgeçilmiş bir sohbet, ertelenmiş bir buluşma... Derken bir gün fark edersin ki bütün hafta duyduğun sesler podcast sunucularına ve Slack bildirim seslerine ait. Şehirde yürümek benim panzehirim oldu. Her köşede arkadaş edindiğim için değil hala kod yazan bir introvertim ama insanların arasında olmak bana dünyamın dairemden büyük olduğunu hatırlattı. Parkta güvercinleri cerrah ciddiyetiyle besleyen yaşlı bir adam gördüm. Scooter'larıyla yarışan, yetişkinlerin mümkün olduğunu unuttuğu bir çığlıkla bağıran çocuklar gördüm. Yürürken tanımadığım insanlara selam verdim, karşılık aldım. Bir şehrin hayatına sessiz bir katılımcı olmanın özel bir rahatlığı var. Kimseyle konuşman gerekmiyor. Bir sunum yapman, bir toplantıya katılman gerekmiyor. Sadece orada olmak yeterli yürümek, izlemek ve insanlığın sıradan uğultusunun sana yapılacaklar listenden daha büyük bir şeyin parçası olduğunu hatırlatmasına izin vermek. > _Hayatımda bulduğum en iyi debugging aracı bir linter ya da profiler değil. Bir çift ayakkabı ve açık bir kapı._ ## Yürümek Düşünmek, Düşünmek İyileşmek Yazılım mühendisliği özünde problem çözmektir. Problem çözmek ise kendine özgü bir zihinsel durum gerektirir. Karmaşıklığı tutacak kadar odaklı ama örüntüleri görecek kadar rahat. Masada oturup bir probleme kaba kuvvetle yüklenmek nadiren atılıma yol açar. Yürümek açar. Yürürken zihnim farklı bir moda girer. Sürüklenir, dolaşır, beklenmedik bağlantılar kurar. Bir kafede kulak misafiri olduğum konuşma bir arayüz fikri doğurabilir. Dalgaların kıyıya vuruş ritmi, günlerdir uğraştığım bir veri akışındaki kadansı görmeme yardımcı olabilir. Bunun mistik bir yanı yok. Beyin böyle çalışıyor. Araştırmalar yürüyüşün yaratıcı çıktıyı ortalama yüzde altmış artırdığını göstermiş. Nietzsche, Darwin, Steve Jobs hep yürüyüşçüydü. Kendimi onlarla kıyaslamıyorum ama dürtüyü artık anlıyorum. Daha önemlisi, yürümek benim mental sağlık pratiğim oldu. Kaygının göğsümü sıktığı günlerde deniz kenarında bir yürüyüş onu gevşetti. Imposter syndrome'un yeterince iyi olmadığımı fısıldadığı günlerde ileri doğru hareket etmenin basit eylemi bir adım, sonra diğeri sessiz bir itiraz gibi geldi. Buradasın. Hareket ediyorsun. Bu yeterli. ## Davet Yürümenin bütün sorunlarını çözeceğini söylemek istemiyorum. Toksik bir codebase'i düzeltmez, deadline'larını karşılamaz, tükenmişliği sihirli bir şekilde iyileştirmez. Ama uzaktan çalışmanın sessizce, yavaşça elinden aldığı bir şeyi geri verir: kendi bedeninde, kendi şehrinde, şimdiki anda canlı olma hissi. Evden çalışıyorsan, özellikle teknoloji sektöründeysen, bildiğim en basit reçeteyi sunmak istiyorum. Laptopunu kapat. Ayakkabılarını giy. Dışarı çık. Fitness tracker'a, koşu planına, dinleyecek bir podcast'e ihtiyacın yok. Sadece yürü. Gökyüzüne bak. Havayı teninde hisset. Zihninin istediği yere gitmesine izin ver. Ekran döndüğünde orada olacak. Her zaman olur. Ama sen temiz hava solumuş, bacaklarını hareket ettirmiş, bir süre dünyanın geçişini izlemiş haliyle farklı olacaksın. Biraz daha hafif. Biraz daha berrak. Biraz daha insan. > _Adım adım, nefes nefes, yürüyüş sana ekranın asla öğretemeyeceği şeyi öğretir: sadece bir zihin değilsin. Bu dünyada bir bedensin ve dünya seni bekliyor._

2010 yılında Ruby on Rails ile tanıştım. Benim için macera o zaman başlamıştı. Ruby dilini ve globaldeki topluluğunu görünce bu dil ile profesyonel işler yapmalıyım dedim. Türkiye'de o yıllarda çok Ruby gelişticisi ve Ruby kullanan şirket yoktu ama ben bir işin içine girmiştim. Geçenlerde Devnot Yazılım Anketi sonuçları hakkında geniş bir yazı yazmıştım. Bu yazıda ise biraz daha konuyu daraltıp, bu anketteki Ruby geliştiricelerin anket cevaplarını yorumlamak istiyorum. Ankete 2.055 katıldı ve sadece 39 kişi Ruby kullandığını söyledi. Yüzde 1.9. İlk bakışta bu rakam, dilin ne kadar niş kaldığının kanıtı gibi görünüyor. Ama biraz daha derine ininince farklı bir tablo çıkıyor ortaya. > Bu 39 kişinin profili, Türkiye yazılım sektörünün genelinden o kadar farklı ki, sayının küçüklüğü neredeyse anlamsız hale geliyor. ## Uzaktan Çalışma: Asıl Fark Buradan Geliyor En dikkat çekici veri bu: > Ruby geliştiricilerinin %77'si tamamen uzaktan çalışıyor. Genel sektör ortalaması %48. Bu fark tesadüf değil. Ruby, özellikle Rails ekosistemi, uzun yıllardır remote-first şirketlerin tercihi oldu. Basecamp, GitHub, Shopify. Bunlar sadece Rails kullanan şirketler değil, aynı zamanda uzaktan çalışma kültürünü şekillendiren şirketler. Bu kültür, dilin etrafına yerleşti ve bir tür seçilim baskısı oluşturdu: Ruby öğrenenler zaten bu dünyaya adım atmayı seçmiş insanlar. Ben de bu hikayenin içindeyim. Ünye'den, Türkiye'de bir Karadeniz ilçesinden, İsveçli bir şirkete çalışıyorum. Bu, Ruby ekosistemi olmasaydı büyük ihtimalle gerçekleşmezdi. Ankette lokasyon verisine bakınca şu da göze çarpıyor: katılımcıların %28'i "Diğer" şehirlerde. Yani Ruby, İstanbul-Ankara-İzmir ekseninin dışına sızmış durumda ve bu sızmanın arkasında büyük ihtimalle remote imkanı var. ## Deneyim Dağılımı: Ruby Başlangıç Dili Değil > Junior oranı %2.6. Genel sektörde bu oran %11. Bu veriyi ilk gördüğümde "tabii ki" dedim. Ruby, öğrenmesi görece kolay ama ekosistemde yetkinleşmesi zaman alan bir dil. Rails, sizi çok şeyi soyutlayarak üretken kılıyor ama bu soyutlamanın altında ne döndüğünü anlamak için yıllar gerekiyor. Convention over configuration felsefesi, ancak o convention'ların neden var olduğunu kavradığınızda tam anlamıyla bir nimete dönüşüyor. Yeni başlayanların Python veya JavaScript'e yönelmesi anlaşılır. İş ilanları daha fazla, topluluk daha geniş, kaynak daha bol. Ruby öğrenmeye karar vermek, bir anlamda belirli bir yönde ilerlemeye zaten karar vermiş olmak demek. ## Maaş Memnuniyeti: Uluslararası Piyasanın Etkisi > "Oldukça tatmin edici" diyenlerin oranı: Ruby'de %18, genel sektörde %5.5. Bu üç katlık fark, dilin kendisinden çok nerede çalışıldığıyla açıklanıyor. Uluslararası şirketlerde, remote pozisyonlarda çalışan biri Türkiye piyasasına göre değil, global piyasaya göre ücret alıyor. Dövizle maaş almak, özellikle son yıllarda Türkiye'deki ekonomik koşullar düşünüldüğünde, memnuniyet farkını tek başına açıklamaya yetecek bir faktör. Bu bir Ruby avantajı mı, yoksa remote çalışmanın avantajı mı? İkisi bu toplulukta o kadar iç içe geçmiş ki ayırmak güç. ## Kod Kalitesi: Felsefe Kültüre Yansımış > Her PR için zorunlu code review yapan şirket oranı: Ruby'de %77, genel sektörde %46. "Convention over configuration" sadece bir teknik tercih değil, bir zihniyet. Kodun nasıl yazılması gerektiğine dair güçlü bir fikir var Ruby topluluğunda ve bu fikir, ekip pratiklerine de sızıyor. Rubocop gibi araçların yaygınlığı, Rails Standart'larına uymanın bir norm haline gelmesi, bunlar tesadüf değil. Topluluğun kaliteye verdiği önem, iş süreçlerine de yansımış. ## Teknoloji Tercihlerinde Sürpriz Yok > PostgreSQL %92. Redis yaygın. AWS dominant. Bu klasik Rails stack'i. Değişen pek bir şey yok ve değişmesine de gerek yok. PostgreSQL ile ActiveRecord arasındaki uyum o kadar sağlam ki alternatifleri denemek için çok güçlü bir neden gerekiyor. Dikkat çeken başka bir veri: katılımcıların büyük çoğunluğu polyglot. JavaScript (%62) frontend için, Python (%46) scripting ve data işleri için, Go (%36) ise performans-kritik servisler için kullanılıyor. Ruby ekosistemi içinde kalmak, diğer dilleri bilmemeyi gerektirmiyor aksine, çoğu zaman zorunlu kılıyor. ## Yapay Zeka Kullanımı: Sektörle Paralel ChatGPT başı çekiyor, ardından Gemini ve Claude geliyor. GitHub Copilot ve Cursor da yaygın. Geliştirme süresine etkisi konusunda %90'ı pozitif değerlendiriyor. Bu rakam beklenenden yüksek değil ama şirketlerin %51'inin resmi olarak AI araçlarını desteklemesi ve lisans sağlaması dikkat çekici. Daha kurumsal bir benimseme olduğunu gösteriyor. ## Sonuçta Ne Söylüyor Bu Veriler? Ruby, Türkiye'de büyümüyor ama küçülüyor da değil. Niş olmaya devam ediyor, ama bu niş içindeki koşullar ortalamanın oldukça üzerinde. 🚨 ****Dili öğrenmek isteyenler için bu verilerin söylediği şu: geniş bir iş pazarına girmeyi beklemeyin.**** Ama girdiğiniz pazarda uzaktan çalışma imkanı, görece iyi maaş ve kaliteye önem veren ekipler bulma olasılığınız yüksek. Benim için bu toplulukta olmak, sadece bir dil tercihinden ibaret değil. Teknik bir zihniyet, bir çalışma biçimi ve bir topluluğa ait olma hissiyle birlikte geliyor. Bu anket verileri, benim zaten içinde yaşadığım şeyi sayılara döküyor ve sayılar şaşırtmıyor, ama teyit ediyor. _Buraya kadar okuduysan çok teşekkür ederim. Şunu da belirtmek isterim ki içinde bulunduğumuz AI çağında Ruby çok iyi bir alternatif. Konuya dair geniş bir yazıyı yakında yayınlayacağım. Beni takip etmeyi unutma._

Benim ilk bayram yazım olabilir. Bunu kanıtlamam mümkün değil çünkü eski yazılarıma ben dahi ulaşamıyorum. Bayramlar benim için öyle süper önemli olmuyor. Büyük ailenin bir araya gelmesi çok güzel. Bazı kuzenleri görmek, onlarla hasret gidermek. Özellikle son yıllarda bütün kuzenler evlendik ettik derken memleketin sağ soluna dağıldık. Bayramlar olunca da görüşmek için fırsat oluyor. Ancak herkesin kendi hayatı var tabiki. Tatil yapmak veya başka bir şekilde bayramı değerlendirmek adına gelemeyenlerimiz de olabiliyor. "**Gelmek** " diyorum çünkü ben zaten ata topraklarında yaşıyorum. > 2020'de kesin dönüş yaptığımdan beri artık buralardayım. O yüzden insanlara "gelmek" diyorum. Benim çocukluğumdan biz ailecek beri pek büyüklere gitmeyiz, bize de pek gelen olmaz. Bizim bayram rutinlerimiz şöyledir: arife günleri mezar başları gezilir, akşam üstü köye gidilir. Gerekirse kalınır, gerekmezse geri eve dönülüyor — çünkü köy-ev arası 20 dakika falan. Sonra bayramın 1. günü tekrar köye gidilir ve duruma göre olaylar gelişir. Köydeki dede evinde herkes buluşur. Amcalar, kuzenler... Bütün aile oradadır. Gelebilenler gelmiştir, gelemeyenler de dedikodularıyla güzelce anılır. **Deli gibi yemek yenir çünkü Karadeniz'de yapacak başka şey yoktur**. Aslında hava güzelse, mevsim yazsa köyün tadı daha başka olur. Doğayla kafayı yersiniz resmen. Bayram o saatte artık bahanedir. Bu sene bayram benim için çok farklıydı. İlk kez baba olarak bir bayram kutluyordum. Zaten bu sene olan bütün şeyler benim için ilk olacak gibi duruyor. Baba olmanın duygusunu gün be gün yaşarken minik Piraye'nin de ilk bayramı olması vesilesiyle bu bayram benim için daha bir enerjik geçti diyebilirim. Arife günü çalışmamdan ötürü mezar ziyaretlerini es geçmek zorunda kaldım. Normalde aile büyükleriyle birlikte vefat etmiş büyüklerimizin mezar başlarına gidiyorduk ama ben bunu bayramın 1. günü yapmayı tercih ettim bu sefer. İşlerimi ayarlayamadım. Arife günü akşamı Piraye hanımı eşimle yıkadık. Çocuklar arife günü yıkanırmış. Böylece Piraye, ilk bayramına tertemiz girdi. Aslında süt ve minik kusmuklardan hariç zaten temiz kendisi. Bayram sabahı ise Piraye ile biraz oynadık ve kahvaltı yapmak için annemlerin evine gittik. Tabiki önce ben, eşim ve Piraye bayramlaştık. Fotoğraflar çekindik, eğlendik biraz. Bu minik ailemizin ilk bayramıydı ve bu heyecanı kaçıramazdık. Annemlerdeki bayram kahvaltısından sonra biraz gevşemeler olsa da Piraye'nin gülücükleri ortalığı birbirine kattı. Ben ve eşim Piraye'yi böyle görüyoruz ama dede ve babaanne görünce resmen mest oldular. İşin içinde bebek olunca evden ha diyince çıkılmıyor ya da yapılan planlar hiç çarşıya uymuyor. Bir şekilde kendimizi köye attık. Piraye ilk kez ata topraklarına gitmişti. Köydeki aile üyeleri ve aileye yakın misafirler ya ilk kez Piraye ile tanışıyorlardı ya da uzun zaman sonra (1 ay) onunla tekrar görüşüyorlardı. Ev gene karıştı, eğlence göğe kalktı. Ben böyle bir bayram neşesi görmedim. Piraye bebek olduğu için korkar dedim ama ortama çok hızlı adapte oldu. Sanki 40 yıllık büyük aile ferdi gibi cool durdu ve ortamı kokladı. Ortam pancar çorbası, keşke ve su böreği kokuyordu. Tatlıları saymıyorum kafayı yemeyin diye. Bayramın ikinci günü eşimin memleketine geçtik. Piraye 2 gün içinde iki farklı ortamda bulunmamıştı. Biz biraz daha alışkındık eski bayramlardan ama Piraye için bu da ilkti. Eşimin evinde de herkes Piraye'yi bir sevinçle karşıladı. Orası da kalabalıktı. Bayramın 2. günü de güzel bir kahvaltı yaptık ve genel olarak Piraye ile oynama, sohbet etme, gelen misafirlerle oturma ile geçti günümüz diyebilirim. Kalabalıklarda olmak iyi geliyor. > Her zaman kalabalıklar iyi gelmez tabiki — insan yalnız da kalmalı ama bunun bir ayarı olmalı. Eski bir tren istasyonu Son gün ise eşimin ailesinin ziyaretlerine gidebildik. Biraz büyükler gezildi, sohbetler edildi. Ben bu ziyaretleri de seviyorum. Hem büyükler mutlu oluyor hem de ben onları tekrar görmüş ve durumlarını güncellemiş oluyorum. Ayrıca edilen sohbetler ya da bayram ziyaretlerinde ortaya çıkan hoş karşılaşmalar işin bonusu oluyor. Yenen tatlıları ve akşamına basan hararet olmasa olmaz tabii. Biraz da kendimize vakit ayıralım dedik ve gezmelere çıktık. Doğaya çıkmak ve yalnız kalmak istedim açıkçası. Bayram boyunca hava soğuk ve hafif yağmurlu olduğu için insanlar kapalı alanlara tıkılmışlardı. Zaten bayramda yeteri kadar insan gördük diye düşündüm ve doğaya gidelim dedim eşime. O da şaşırdı çünkü kendisi genelde bunu derdi, bense "_ya bi kafede kahve içelim, dışarıda otururuz_ " vs derdim. Bu sefer biraz roller değişti. Yoldan kahvelerimizi aldık ve köy köy gezdik. Güzel de oldu. Hava yağışlı değildi ama soğuktu. Böylesi havaları seviyorum. Akşam üstünün de verdiği biraz karanlık havayla süper bir atmosfer oldu diyebilirim. Eski bir istasyonun sanatsal fotoğrafını çekmekten tutun, bir leyleği havada görmeye — çok yanık, ne kadar büyüklermiş ya — kadar çok şey yaptık. Leyleği görünce de mart başında dilek tutup kolumuza taktığımız marteniçkalarımızı çıkarıp bir ağaca bağladık. Sanırım kiraz ağacıydı, yeni çiçek açıyordu, çok sevimli bir ağaçtı. Seneye gidip o ağaca bakmayı ve bilekliklerimizi görmeyi çok istiyorum. (Umarım ağacı bulabiliriz çünkü onu da spontane bulduk.) Kiraz Ağacı ve ❤️ Bayramlar çok fazla şeye kapı açıyor. Ne istersek aslında o oluyor. Evde kös kös oturup birileri gelsin diye de bekleyebilirsiniz, siz de gidebilirsiniz. İnsanların aramasını da bekleyebilirsiniz, onları da arayabilirsiniz. Bayramlarda tatil yapmak da bir opsiyon — ben pek "illa büyüklere gidince" kafasında değilim, orası sizin bileceğiniz ve ilişkilerinizin nasıl olduğuyla alakalı. Benim için bayramlar küçüklüğümden beri hep böyle geçti. Yukarıda anlattığım gibi: kalabalıklar, sohbetler, zaman zaman minik laf sokmalar, karşılaşmak istenen ve istenmeyen akrabalar... Ancak bu sene ayrı bir güzeldi benim için. Minik kızımız Piraye ile ilk bayramımız. Geçmiş bayramınız kutlu olsun. Herkese iyi bayramlar ❤️

Geçen hafta belim tutuldu. Hareket edemiyorum. Tam da o gün Ünye'de hava mükemmeldi. Güneş, hafif rüzgâr, koşmak için ideal bir gün. Ve tabii ki canım koşmaya çıkmak istedi. Deli gibi. İronik olan şu: bel ağrım olmadığı günlerin çoğunda koşmaya çıkmıyorum. Bu bilinçli bir tercih. Bazen üşeniyorum, bazen "yarın çıkarım" diyorum. Ama yapamadığım an, koşmak dünyanın en güzel aktivitesi haline geliyor. Bu sadece koşmakla sınırlı değil. Tatile gidecek durumum olmadığında _"şimdi bir sahil kasabasında olsam, denize girip akşam bir balık yesem ne güzel olurdu"_ diye hayal kuruyorum. Ama tatile gittiğimde ne oluyorsa, bir süre sonra içimden _"şimdi bilgisayarım olsa da şu projeyi bitirsem"_ diye geçiriyorum. > Tatilde çalışmak istiyorum, çalışırken tatil istiyorum. Sanki beyin sürekli olmadığı yerde olmak istiyor. Bunun sadece benim tuhaflığım olmadığını öğrendiğimde rahatlama ve şaşkınlık bir arada hissettim. Çünkü bunun psikolojide hem adı var hem de arkasında ciddi bir araştırma birikimi. ## Psikolojik Tepkisellik (Reactance) 1966'da psikolog Jack Brehm, insanların özgürlükleri kısıtlandığında ya da bir seçenek ellerinden alındığında çok spesifik bir tepki verdiğini ortaya koydu: kısıtlanan şeye karşı yoğun bir arzu duyuyoruz. Buna **psikolojik tepkisellik**(psychological reactance) dedi. Teori dört temel ilkeye dayanıyor: 1. İnsanlar belirli davranışsal özgürlüklere sahip olduklarına inanır. 2. Bu özgürlükler tehdit edildiğinde ya da ortadan kalktığında psikolojik tepkisellik oluşur. 3. Bu tepkisellik, kaybedilen özgürlüğü yeniden kazanma motivasyonu yaratır. 4. Tepkiselliğin şiddeti, tehdit edilen özgürlüğün önemine ve tehdidin büyüklüğüne doğrudan bağlıdır. Yani belim ağrıdığında koşmak istemem tesadüf değil. Koşma özgürlüğüm elimden alındığı için beyin otomatik olarak **koşmak ne harika bir şey, onu geri istiyorun** moduna geçiyor. Özgürlük tamamen ortadan kalktığında tepkisellik en üst seviyeye çıkıyor ve kaybedilen şey gözümüzde çok daha değerli hale geliyor. Daha da ilginci, bu sürecin farkında olmamız bile gerekmiyor. Araştırmalar gösteriyor ki tepkisellik çoğu zaman bilinçdışı çalışıyor. **Sınırlı sayıda** ya da **son fırsat** etiketli bir ürüne karşı aniden artan istek hissettiysen, bu mekanizmayı zaten tanıyorsun. ## Duygusal Tahmin Yanılgısı (Affective Forecasting Bias) İkinci bir katman daha var. Psikologlar Timothy Wilson ve Daniel Gilbert'ın 1990'larda başlattığı araştırma programı, insanların gelecekteki duygusal durumlarını tahmin etmekte ne kadar kötü olduğunu ortaya koydu. Buna **duygusal tahmin**(affective forecasting) diyorlar. En yaygın hata **etki yanılgısı** (impact bias), gelecekteki olayların bizi ne kadar mutlu ya da mutsuz edeceğini sistematik olarak abartıyoruz. Tatile gidemediğimde **bir tatil olsa dünyalar güzelleşir** diye düşünmem, tam olarak bu. Tatili zihnimde gerçekte olacağından çok daha muhteşem bir deneyim olarak kurguluyor, diğer tüm faktörleri; yorgunluk, beklentiler, günlük aksaklıklar, hesaba katmıyorum. Bu yanılgının iki önemli kaynağı var. Birincisi **odaklanmacılık** (focalism), bir olayı düşünürken sadece o olaya odaklanıp, hayatımızdaki diğer her şeyi görmezden geliyoruz. Tatili hayal ederken sadece sahili ve güneşi düşünüyorum; bagaj taşımayı, sıcaktan bunalmayı, çocuğun uyku düzenini değil. İkincisi ise **bağışıklık ihmali** (immune neglect), zihnimizin olumsuz durumlarla başa çıkma kapasitesini sürekli hafife alıyoruz. ## Kıtlık Etkisi (Scarcity Effect) Üçüncü ve son katman Robert Cialdini'nin popülerleştirdiği **kıtlık ilkesi.** Bir şeyin erişilebilirliği azaldığında algılanan değeri artar. Bu, tepkisellikle iç içe çalışan bir mekanizma: tatile gidemediğim gerçeği, tatili zihnimde daha kıt ve dolayısıyla daha değerli kılıyor. Cialdini bunu şöyle formüle ediyor; > Daha önce sahip olduğumuz veya sahip olabileceğimize inandığımız bir şeyin kısıtlanması, hiç sahip olmadığımız bir şeyin kısıtlanmasından çok daha güçlü bir tepkisellik yaratıyor. Koşabildiğim zaman koşmanın değerini bilmiyorum, koşamayınca koşmak altın değerinde. ## Üç Mekanizmanın Buluşma Noktası Benim durumumda ve muhtemelen senin de benzer deneyimlerinde bu üç mekanizma aynı anda çalışıyor: * **Tepkisellik:** "Yapamıyorum" → "Yapmak istiyorum!" * **Duygusal tahmin yanılgısı:** "Yapsam çok güzel olurdu" (abartılmış beklenti) * **Kıtlık etkisi:** "Yapamadığım için daha da değerli" Tatilde çalışmak istememde de aynı döngü işliyor, sadece tersten. İş bilgisayarım yok, kod yazma özgürlüğüm kısıtlı, ve bir anda o yarım kalan proje dünyanın en heyecan verici işi haline geliyor. Tatilden dönüp bilgisayarı açtığımda ise o büyü çözülüyor. ## Peki Ne Yapabiliriz? Bu mekanizmaları tanımak, onları tamamen ortadan kaldırmıyor. Bu evrimsel olarak köklü tepkiler. Ama farkındalık bile işe yarıyor. Birkaç şey deniyorum. **"Şu an yapabilsem gerçekten yapar mıydım?" sorusu.** Belim ağrıdığında koşmak istiyorum, ama dürüst olayım: belim sağlamken son bir haftada kaç kez koştum? Bu soru, zihnin abartılı tahminini gerçeklikle yüzleştiriyor. **Yapabildiğim şeylere bilinçli dikkat.** Bugün ne yapabiliyorum? Okuyabiliyorum, yazabiliyorum, kızımla vakit geçirebiliyorum. Yapamadıklarıma odaklanmak yerine yapabileceklerime dönmek, tepkiselliğin şiddetini azaltıyor. **Sahip olduğum anı kaydetmek.** Koşabildiğim günlerde "bugün koştum, güzel hissettirdim" diye not almak. Tatildeyken "şu an buradayım, bu an güzel" diye bilinçli olmak. Bunlar basit ama etkililer çünkü beyni "şu an sahip olduğun şey de değerli" mesajıyla yeniden kalibre ediyorlar. Nir Eyal'in önerdiği bir yöntem de var: kendine "yapmalıyım" yerine "yapabiliyorum" diye konuşmak. "Koşmalıyım" yerine "koşabiliyorum" demek, "çalışmalıyım" yerine "çalışabiliyorum" demek. Bu küçük dil değişikliği, beynin tepkisellik devresini bypass ediyor çünkü artık bir kısıtlama yok, bir tercih var. ## Sonuç Belki de bu mekanizmaların var olmasının güzel bir tarafı da var. Yapamadığımız şeylere duyduğumuz özlem, aslında o şeyleri ne kadar sevdiğimizin bir hatırlatması. Koşamadığımda koşmayı özlemek, koşmanın benim için ne kadar önemli olduğunu gösteriyor. Tatil hayal etmek, keşif ve dinlenme ihtiyacımın sesini duyurmam. Tatilde kod yazmak istemek, işimi gerçekten sevdiğimin kanıtı. Mesele bu duyguları bastırmak ya da yok saymak değil. Mesele, "**bu duygu gerçek bir ihtiyaç mı, yoksa beynimin bana oynadığı bir oyun mu?** " sorusunu sormayı öğrenmek. Çoğu zaman ikisinin bir karışımı olduğunu göreceksin. Ve bazen, belin tutulmuşken pencerenin önüne oturup güzel havayı seyretmek de kendi başına güzel bir şey. Senin yapmak isteyip de yapamadığın zamanlar oluyor mu? Neler yapıyorsun o gibi zamanlarda? * * * **_Kaynaklar ve Önerilen Okumalar:_** * Brehm, J. W. (1966). _A Theory of Psychological Reactance._ Academic Press. * Gilbert, D. (2006). _Stumbling on Happiness._ Knopf. (Türkçesi: _Mutluluğa Toslamak_) * Cialdini, R. B. (2006). _Influence: The Psychology of Persuasion._ Harper Business. (Türkçesi: _İknanın Psikolojisi_) * Wilson, T. D. & Gilbert, D. T. (2005). "Affective Forecasting: Knowing What to Want." _Current Directions in Psychological Science_ , 14(3), 131–134. * Schwartz, B. (2004). _The Paradox of Choice._ Ecco. (Türkçesi: _Bolluk Paradoksu_)