Yazılım geliştirme DEHB'li bir beyne çok iyi uyabilir: zor bulmacalar, hızlı geri bildirim ve arada bir her şeyin yerine oturduğu altı saatlik dilimler. Ama aynı zamanda merak sarmalları, yarım kalmış dallar, bitmeyen bildirimler ve üç kat sapan tahminlerle dolu bir mayın tarlası da olabilir. Araştırmaların ne dediği ve neyin işe yaradığı aşağıda.

DEHB'li yazılımcılar hakkında ne biliyoruz?

Olması gerektiği kadar değil, ama bilgi artıyor.

Grischa Liebel ve meslektaşları, yazılım mühendisliğinde çalışan DEHB'li kişilerle yaptıkları 2024 tarihli nitel bir vaka çalışmasında, katılımcıların görevleri düzenlemede ve süre tahmininde, dikkati işte tutmakta ve başkalarıyla çalışmakta zorlandığını, ayrıca bedensel ve ruhsal sağlık yükü de bildirdiğini buldu. Katılımcılar gerçek güçlü yanlarını da anlattı: artan yaratıcılık, bulmaca benzeri problemlerde başarılı olmak ve sistemlerin birbirine nasıl oturduğunu önceden düşünmek (Liebel et al., 2024).

Büyük bir yazılım şirketinde yapılan daha eski bir çalışma, nöroçeşitli mühendislerle (DEHB'liler dahil) yapılan görüşmeleri 846 mühendisle yapılan bir anketle birleştirerek onları işte neyin geri tuttuğunu ve işverenlerin nasıl yardımcı olabileceğini anlamaya çalıştı (Morris et al., 2015).

Genel olarak yazılımcılar için de 379 profesyonelle yapılan bir anket, insanların görevleri önemli kesintiler ya da bağlam değişimleri olmadan tamamladıklarında kendilerini üretken hissettiğini buldu; oysa gözlemler çok sık geçiş yaptıklarını gösterdi (Meyer et al., 2014). DEHB ile bu geçişlerden toparlanmak daha zor; o yüzden onlara karşı önlem almak iki kat karşılık verir.

Merak sarmallarının bütün günü yemesini nasıl önlersin?

Bir hata mesajına bakıyorsun. Kırk dakika sonra hiç kullanmayacağın bir yazılım çatısının tarihini okuyorsun. Merak bir güç, ama bir çite ihtiyacı var.

  • Aramaya süre sınırı koy. “Cevabı bulmak için 15 dakika, sonra birine sorarım ya da başka bir yol denerim.” Görebileceğin bir zamanlayıcı kur.
  • Önce soruyu yaz. Tek satır: “Giriş yönlendirmesi Safari'de neden döngüye giriyor?” Bir sayfa bu soruyu cevaplamaya yardım etmiyorsa kapat.
  • Takip etme, sonraya bırak. İlginç ama alakasız mı? Sekmeyi bir “sonra” listesine kaydet ve kapat. Cuma günü de ilginç olacak.
  • İşaretlere dikkat et: beş sekme derinde olmak, aramadığın bir şeyi okumak, asıl soruyu unutmak. Hedefini yeniden okuma anı tam o an.

Kesintilerden sonra nasıl toparlanırsın?

Chris Parnin ve Spencer Rugaber, kaydedilmiş yaklaşık 10.000 programlama oturumunu inceleyen bir çalışmada, oturumların yalnızca yaklaşık 10'da 1'inin bir kesintiden sonraki bir dakika içinde yeniden düzenlemeye döndüğünü ve oturumların yalnızca %7'sinde programcıların bağlamlarını yeniden kurmak için önce kodun içinde dolaşmadan düzenlemeye başladığını buldu (Parnin & Rugaber, 2011). Koda geri dönmek zaman alır ve DEHB'li bir beyin ipin ucunu tamamen kaçırabilir.

Her geçişten önce bir iz bırak:

  • Tek satırlık bir not: “Sıradaki: parseUser'daki null durumunu ele al, sonra kimlik doğrulama testlerini yeniden çalıştır.”
  • Yapmak üzere olduğun şeyi gösteren, başarısız olan bir test.
  • Tam o satıra bir TODO yorumu ya da mesajında bir sonraki adımın yazdığı bir “yarım iş” commit'i.

Bu, iş yeri araştırmalarındaki “devam etmeye hazır” fikri: geçiş yapmadan önce dönüşünü kısaca planlamak dikkat kalıntısını azalttı ve araya giren görevdeki performansı artırdı (Leroy & Glomb, 2018). Kesintiler hakkında daha fazlası DEHB ile işte nasıl odaklanırsın yazısında.

Büyük bir göreve nasıl başlarsın?

“SSO'yu uygula” gibi bir görev bir duvardır. İlk adım apaçık ve küçük olana kadar onu küçült:

  1. Mevcut kimlik doğrulama akışını oku ve onunla ilgili üç madde yaz.
  2. İlk yönlendirme için başarısız olan bir test ekle.
  3. O testi geçir.

İlk adım saatler değil, dakikalar sürmeli. Göremiyorsan, görev bölücü senin için bir kontrol listesi taslağı çıkarır; yöntemin tamamı da DEHB ile bir göreve nasıl başlanır yazısında.

Tahminler neden bu kadar zor ve ne işe yarar?

DEHB'li pek çok kişi ne kadar zaman geçtiğini ya da bir şeyin ne kadar süreceğini hissetmekte zorlanıyor (daha fazlası zaman körlüğü için araçlar yazısında). Yazılım tahminleri herkes için zor; DEHB buna bir katman daha ekliyor.

  • Görevi değil, küçük adımları tahmin et. “3 adım × 1 saat”, “yarım gün”den daha dürüst.
  • Tahmin et, sonra kontrol et. Başlamadan önce tahminini, bitirdiğinde gerçek süreyi yaz. Birkaç hafta sonra kişisel çarpanını öğrenirsin.
  • Bilerek pay bırak ve bunu yüksek sesle söyle: “İki gün diyorum, ama geçmişte hep iyimser çıktım.”

Peki ya hiperodaklanma?

Kod yazmak uzun, derin hiperodaklanma dilimlerini tetikleyebilir. Bu harika olabilir ya da akşam yemeğini, uykunu ve aslında yapman gereken görevi yiyip bitirebilir. Onu doğru göreve yönelt, iki alarm kur (bir ön uyarı ve bir bitiş) ve durmadan önce bir sonraki adım notu bırak. Daha fazlası DEHB'de hiperodaklanma yazısında.

Çalışma ortamını nasıl kurarsın?

  • Odak blokları sırasında bildirimler kapalı. Sohbete ve kod incelemelerine belirli saatlerde bak.
  • Görev için tek bir ekran, yalnızca gereken pencerelerle.
  • Bilinçli seçilmiş ses: kod okurken ya da yazarken sözlü müzik değil, gürültü ya da enstrümantal müzik (DEHB için odak müziği).
  • Eşli programlama, zor ya da sıkıcı görevlerde body doubling gibi işe yarayabilir.

Kaynaklar

  • Liebel, G., Langlois, N., & Gama, K. (2024). Challenges, strengths, and strategies of software engineers with ADHD: A case study. Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society, 57–68. doi.org/10.1145/3639475.3640107
  • Morris, M. R., Begel, A., & Wiedermann, B. (2015). Understanding the challenges faced by neurodiverse software engineering employees. Proceedings of the 17th International ACM SIGACCESS Conference on Computers & Accessibility, 173–184. doi.org/10.1145/2700648.2809841
  • Meyer, A. N., Fritz, T., Murphy, G. C., & Zimmermann, T. (2014). Software developers' perceptions of productivity. Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 19–29. doi.org/10.1145/2635868.2635892
  • Parnin, C., & Rugaber, S. (2011). Resumption strategies for interrupted programming tasks. Software Quality Journal, 19(1), 5–34. doi.org/10.1007/s11219-010-9104-9
  • Leroy, S., & Glomb, T. M. (2018). Tasks interrupted: How anticipating time pressure on resumption of an interrupted task causes attention residue and low performance on interrupting tasks and how a "ready-to-resume" plan mitigates the effects. Organization Science, 29(3), 380–397. doi.org/10.1287/orsc.2017.1184

Bu makale genel bilgi içindir, tıbbi tavsiye değildir. Sende DEHB olabileceğini düşünüyorsan ya da tedavini değiştirmeyi düşünüyorsan, yetkin bir sağlık uzmanıyla konuş. Nasıl araştırıp yazıyoruz.

Hemen dene

Ertelediğin görevi yaz. İşaretleyebileceğin küçük adımlar al.

Bir görevi minik adımlara bölChrome'a ekle

DoppiNow, odaklandığında XP, geri döndüğünde bonus veren bir Chrome uzantısı. Hiçbir siteyi engellemez. 7 gün ücretsiz.