Slack–Kod Bağlam Değiştirme: Derin Çalışmanın Gizli Vergisi
Slack ile kod arasında bağlam değiştirme, geliştiricilere haftalık saatler kaybettiriyor. Nasıl ölçülür, azaltılır ve akış durumu korunur?
By Ellis Keane · 2026-03-13
Bugün gerçekte kaç dakika derin çalışma yaptınız? Masada geçirilen süre değil. IDE açık geçirilen süre değil. Tek bir probleme gerçek, sürekli, kesintisiz odaklanma. Bunu güvenle yanıtlayabiliyorsanız ya kendinizi kandırıyorsunuzdur ya da Slack ile kod arasında bağlam değiştirmeyi hiç yaşamamışsınızdır – ki bu durumda gerçekten, lütfen yönteminizi öğretin.
Bunu soruyorum çünkü çoğu gün kendi sayımı bilmiyorum. Sabah 9'da bir veritabanı migrasyonu üzerinde çalışmak için oturduğumu biliyorum. Bir noktada bakıp saat 13.00 olduğunu gördüm. Ve bu arada Slack'i belki yirmi küsur kez açtığımı biliyorum – kimse bana ihtiyaç duyduğu için değil, o küçük kırmızı rozet küçük bir ayın utanmasına yol açacak kadar güçlü bir çekim kuvvetine sahip olduğu için. Bir sabaha bitmesi gereken migrasyon Çarşamba'ya uzadı.
23 Dakika Efsanesi (ve Gerçekte Ne Olduğu)
Muhtemelen şu istatistiği görmüşsünüzdür: "Bir bağlam değiştirmesinin ardından yeniden odaklanmak 23 dakika alır." Bu, UC Irvine'den Gloria Mark'ın araştırmasından geliyor; araştırma gerçek olsa da sayı o kadar sık yanlış alıntılanıyor ki neredeyse bir his meselesine dönüşmüş durumda. 23 dakikalık rakam, özgün göreve dönme süresini ifade ediyor – aynı odaklanma derinliğine dönme süresini değil – ve özellikle geliştiriciler için değil, genel bilgi çalışanları için ölçülmüş.
Geliştiriciler için gerçek maliyet tamamen kafanızda ne taşıdığınıza bağlıdır. Nihayet yirmi dakika bakmaktan sonra birbiriyle kilitlenmiş üç durum makinesinin zihinsel modelini oluşturduğunuz ince bir yarış koşulunu mu hata ayıklıyorsunuz? O modeli kaybetmek size yirmi dakikanın tamamına mal olur. Bir config dosyasındaki yazım hatasını mı düzeltiyorsunuz? Saniyeler. Mesele kesin sayı değil. Mesele, Slack ile kod arasında bağlam değiştirmenin anlık olarak tamamen görünmez bir maliyete sahip olması; ama haftanın sonunda sprint hızınızda açıkça ortaya çıkması.
Lokalise Araç Yorgunluğu Raporu, çalışanların günde ortalama 33 kez uygulama arasında geçiş yaptığını ve %17'sinin 100 kez'den fazla geçiş yaptığını ortaya koydu. Temel ölçülebilir etkisi üretkenliği kesmek olan bir "verimlilik" yazılımı ekosistemi inşa ettik. Bir yerde bir ürün yöneticisi, yalnızca işe geri dönebileceklerini kontrol eden kişilerden oluşan DAU sayılarını kutluyor.
Slack ile Kod Arasındaki Bağlam Değiştirme Neden Özellikle Pahalıdır?
Burada Slack konusunda adil olmak istiyorum. Gerçekten iyi bir araç ve mühendislik ekiplerinin IRC'ye geri dönmesi gerektiğini savunmayacağım (her ne kadar bazı günler bu düşünce aklıma gelse de). Ancak Slack'ten IDE'ye geçiş, iki tarayıcı sekmesi arasında geçiş yapmaktan kategorik olarak daha pahalıdır ve nedenini anlamak önemlidir.
Zihinsel model uyuşmazlığı. Koda derinden daldığınızda kafanızda karmaşık bir model tutuyorsunuzdur – değişken durumları, fonksiyon çağrı zincirleri, değiştirmekte olduğunuz sistemin genel şekli ve belirli bir sırayla yapmanız gereken değişikliklerin sırası. Slack tamamen farklı bir bilişsel modda çalışır: sosyal bağlam, konuşma zincirleri, kimin ne hakkında konuştuğunu ve bunun sizinle ilgili olup olmadığını anlamaya çalışmak. Bu iki mod arasında geçiş yapmak sekme değiştirmeye benzemiyor. İki tamamen farklı düşünme türü arasında geçiş yapmak gibi; beyninizin ikisi için de "durum kaydet" düğmesi yok.
Belirsizlik vergisi. Odaklanmanızı gerçekten mahveden şey şu: kesintinin kendisi değil, kesintinin olasılığı. Bir bildirim rozeti göründüğünde, kontrol edene kadar önemli olup olmadığını bilmiyorsunuzdur. Bu belirsizlik, çalışma belleğinizde çözümsüz bir soru olarak yerleşir ve geçişe direnseniz bile dikkatinizi kemirer. Ve bakın, ben buna direnme konusunda herkes kadar kötüyüm – bir commit mesajının ortasında, rozet çevresel görüşümde belirdiği için ⌘-Tab tuşuna basarak Slack'e geçtiğimi fark ettim. Commit mesajı ölü kodu kaldırmakla ilgiliydi. Slack bildirimi birinin bir gif'e gif ile tepki vermesiydi. Üretken bir öğleden sonra.
İplik tuzağı. Slack'i açıyorsunuz, bir bildirim görüyorsunuz, bir iş parçacığına tıklıyorsunuz, üç mesaj okuyorsunuz, bunun girdinizi gerektirmediğini anlıyorsunuz, geri çekiliyorsunuz, başka bir kanalın rozeti olduğunu fark ediyorsunuz, onu da kontrol ediyorsunuz – ve birden beş dakika yok olmuş, migrasyon mantığınız uzak bir anıya dönmüş. İronik olan şu ki Slack'in gürültüyü azaltmak için tasarlanmış iş parçacığı modeli, aslında "bir rozet gördüm" ile "hiçbir şeyin beni gerektirmediğini doğruladım" arasındaki tıklama sayısını artırıyor. İş parçacıkları içinde iş parçacıkları. Sonsuza kadar devam eden kaplumbağalar.
Slack ile kod arasında bağlam değiştirmenin maliyeti, Slack'te geçirilen saniyeler değildir. Temelden farklı iki düşünme modu arasında geçiş yapmanın bilişsel yüküdür; bildirimin kesmeye değer olup olmadığını bilmemenin belirsizliğiyle katmerleşir.
Gerçekten İşe Yarayan (ve Yaramayanlar)
Standart tavsiyelerin çoğunu denedim – ve gerçekten denedim demek istiyorum, "blog yazısını okuyup başımı salladım" anlamında değil. İşte yaklaşık altı ay kendi kesinti kalıplarımı aktif olarak izledikten sonra ulaştığım yer.
İşe Yarayan
- Planlanmış Slack pencereleri. Derin çalışma günlerinde Slack'i sabah 9'da, öğlende ve 15.00'te kontrol edin ve arada uygulamayı tamamen kapatın (gerçekten kapatın – simge durumuna küçültmeyin, kapatın). Geçiş sayısını yirmilerden tek haneye düşürür. Odak günlerinde dock simgesini tamamen gizlemek saçma ama etkili.
- Anahtar kelime istisnaları ile DND. Slack'in Rahatsız Etme modu, belirli terimler içeren veya belirli kişilerden gelen mesajların geçmesine izin verecek şekilde yapılandırılmış. Gürültüden sessizlik, gerçek aciliyet için uyarılar. Mükemmel değil, ama ikili seçenekten iyi.
- Giden mesajları toplu gönderme. Slack mesajlarını bir not defterinde not edin ve toplu olarak gönderin. Ekipteki diğer kişiler için kesintileri azaltır ve "dur, son mesajı yok sayın" takip mesajlarını ortadan kaldırır.
Makul Görünen Ama Gerçekle Karşılaşınca Hayatta Kalmayan
- "Bildirimleri kapatın." Akış durumunu güzelce korur. Aynı zamanda ekibinizin şu anda geliştirdiğiniz API sözleşmesini değiştirdiği iş parçacığını kaçırmanıza neden olur. Tedavi kendi hastalığını yaratır.
- "Durumunuzu meşgul olarak ayarlayın." İnsanlar durumları görmezden gelir. Durum gerçek bilgi taşımaz çünkü herkes her zaman meşgul olduğunu iddia eder – bu, iş yerindeki "nasılsın?" / "iyiyim" karşılığıdır.
Sistem Düzeyinde Filtreleme
Planlanmış pencereler yaklaşımı işe yarıyor, ama bir disiplin çözümü – ve disiplin çözümlerinin bir raf ömrü var. Üç hafta koruyorsunuz, bir şey acil olarak kalıbı bozuyor ve rozet seğirdikçe Slack'i kontrol etmeye geri dönüyorsunuz. Bu döngüden yeterince geçtim ki düzeltmenin daha fazla irade gücü olmadığını biliyorum. Daha iyi bir filtre.
Bağlam değiştirme sorununu sistem düzeyinde gerçekten çözecek şey, hem ne üzerinde çalıştığınızı hem de Slack'te neler olduğunu anlayan ve "yazmakta olduğunuz kodu doğrudan etkileyen bir iş parçacığında bir karar var" ile "#random'da biri öğle yemeği seçeneklerini tartışıyor" arasındaki farkı söyleyebilen bir şeydir.
Sugarbug ile inşa ettiğimiz şey bu. Slack'e (ve GitHub, Linear, Figma ve diğerlerine) bağlanıyor, her sinyali türüne göre sınıflandırıyor – karar, engelleyici, soru, durum güncellemesi, gürültü – ve bunları ilgili görevler ve kişilerle ilişkilendiriyor. Slack'i açmadan hangi Slack etkinliğinin mevcut görevinizle ilgili olduğunu görüyorsunuz. Rozet yok. Belirsizlik vergisi yok. Bildirimin sizinle ilgili olmadığını keşfetmek için beş dakikalık iş parçacığı araştırması yok.
Geçen haftadan somut bir örnek: Bir vektör arama migrasyonuna derinlemesine dalmıştım ve bir ekip arkadaşı ileriye dönük kullanacağımız gömme modeli hakkında bir Slack iş parçacığında bir karar aldı. Filtreleme olmadan ya tamamen kaçırırdım (DND modu) ya da iş parçacıklarını manuel olarak tarayarak saatler sonra rastlardım. Sugarbug'un sınıflandırıcısı bunu "karar – mevcut görevinizle ilgili" sinyali olarak yüzeye çıkardı. Bir bakış, migrasyona geri dön.
Bunu henüz mükemmel çözmedik – sınıflandırıcı hâlâ uç durumları kaçırıyor ve filtrelenmiş sinyalleri başka bir bildirim yüzeyi oluşturmadan nasıl sunacağımızı geliştiriyoruz (ki bu güzelce ironik bir kendi kendine gol olurdu). Ama mükemmel olmayan filtreleme bile DND modunun hepsini-ya-da-hiçbirini yaklaşımından iyidir. O migrasyon gününde, Slack ziyaretlerimin en az yirmisinin gereksiz olduğunu tahmin ediyorum – iyi bir filtrenin tamamen önleyebileceği yirmi bağlam yeniden yüklemesi.
Her rozet göründüğünde bağlam vergisi ödemeyi bırakın. Sugarbug, yalnızca mevcut çalışmanızı gerçekten etkileyen Slack sinyallerini yüzeye çıkarır.
Q: Slack ile kod arasında bağlam değiştirme gerçekte ne kadara mal oluyor? A: UC Irvine'den Gloria Mark'ın araştırması, bir kesintinin ardından özgün göreve dönmenin yaklaşık 23 dakika aldığını ortaya koyuyor; ancak gerçek maliyet, yaptığınız işin karmaşıklığına göre büyük ölçüde değişiyor. Günde onlarca kez Slack ile IDE arasında geçiş yapan geliştiriciler için bu, her hafta saatlerce kaybedilen derin çalışmaya dönüşüyor – ve özenle oluşturduğunuz zihinsel model gidiş-dönüş yolculuğundan nadiren sağ çıkıyor.
Q: Sugarbug, Slack ile kod arasındaki bağlam değiştirmeyi azaltmaya yardımcı oluyor mu? A: Evet. Dikkat gerektirip gerektirmediğini kontrol etmek için Slack'e geçmek yerine, Sugarbug Slack mesajlarını türlerine göre sınıflandırır ve üzerinde çalıştığınız göreve bağlar. Mevcut çalışmanızla ilgili kararlar, engelleyiciler ve sorular, siz aramak zorunda kalmadan yüzeye çıkar. Amaç, "ihtimale karşı kontrol et" geçişlerini ortadan kaldırmak – Slack'i açtığınızda, uygulanabilir bir şey bulmadığınızda ve ne yaptığınızı hatırlamak için üç dakika harcadığınız durumları.
Q: Bağlam değiştirmeyi azaltmak için Slack bildirimlerini kapatmalı mıyım? A: Sesi kapatmak akış durumunu korur; ancak gerçekten önemli şeyleri kaçırmanıza neden olur – örneğin ekibinizin uyguladığınız bir API'yi değiştirmeye karar verdiği iş parçacığını. Daha iyi yaklaşım filtrelemedir: hemen dikkat gerektiren sinyalleri bekleyebilecek gürültüden ayırt etmek. Planlanmış Slack pencereleri bunun iyi bir manuel versiyonudur; Sugarbug ise otomatik versiyondur.
Q: Bağlam değiştirme ile çoklu görev arasındaki fark nedir? A: Çoklu görev, iki şeyi aynı anda yapmaya çalışmaktır (insanlar bunu gerçekten kötü yapar). Bağlam değiştirme, görevler arasında sırayla geçiş yapmaktır – maliyet, kodun zihinsel modelini yeniden yüklemenin zaman ve bilişsel enerjisidir. Kafasında karmaşık bir sistem tutan bir geliştirici için bu yeniden yükleme, işin derinliğine bağlı olarak saniyeler ile yarım saat arasında sürebilir.
Q: Sugarbug hangi Slack mesajlarının kesmeye değer olduğunu filtreleyebilir mi? A: Sugarbug sinyalleri türlerine göre sınıflandırır ve üzerinde çalıştığınız görevlere bağlar. Böylece Slack'i açıp her kanalı taramak yerine, hangi etkinliğin mevcut çalışmanızla ilgili olduğunu görürsünüz. Alaka düzeyi puanlaması üzerinde hâlâ çalışıyoruz (mükemmel değil), ancak DND modunun hepsini-ya-da-hiçbirini yaklaşımından anlamlı ölçüde daha iyi.
---
Slack-IDE gidiş-dönüşü derin çalışma saatlerinizi tüketiyorsa – ve bir bildirim rozetinden kaçınmak için dock simgesini gizlemek makul bir verimlilik stratejisi gibi geliyorsa – bu, Sugarbug'u azaltmak için inşa ettiğimiz vergidir. Bekleme listesine katılın.