Home | Blog | Data study

Biaya Peralihan Konteks: Apa yang Diungkap 5 Juta PR GitHub

Kami menyintesis data dari 5 juta+ PR untuk mengukur biaya peralihan konteks yang sesungguhnya bagi developer – dan ternyata bukan di tempat Anda kira.

By Ellis Keane · 2026-03-29

Biaya peralihan konteks yang dikutip kebanyakan artikel – 23 menit untuk refokus setelah gangguan, dari penelitian Gloria Mark di UC Irvine – adalah temuan nyata dari studi nyata. Namun studi itu mengukur pekerja pengetahuan umum pada tahun 2008, bukan insinyur perangkat lunak. Dan industri rumahan artikel blog yang mengalikan 23 menit dengan perkiraan jumlah gangguan untuk menghasilkan angka dolar tahunan yang mengkhawatirkan (selalu disertai foto stok seseorang yang memegang kepalanya) melakukan sesuatu yang tidak pernah dimaksudkan oleh penelitian aslinya.

Saya memiliki kepentingan pribadi dalam pertanyaan ini. Di perusahaan sebelumnya, saya menghabiskan – dan ini bukan hiperbola – 80 hingga 100 persen beberapa hari hanya menjadi router manusia. Bukan menulis kode, bukan meninjau kode. Merutekan informasi di antara orang-orang dan alat, karena tidak ada satu sistem pun yang menghubungkan mereka. Pengalaman itu sebagian merupakan alasan mengapa kami membangun Sugarbug, tetapi juga mengapa saya skeptis terhadap kalkulator biaya peralihan konteks standar. Mereka mengukur gangguan. Mereka tidak mengukur hari-hari yang Anda habiskan tanpa pernah sampai pada hal yang seharusnya Anda kerjakan.

Jadi kami ingin tahu apa sebenarnya biaya peralihan konteks dalam pekerjaan rekayasa – bukan dalam istilah produktivitas developer yang abstrak, tetapi diukur dalam artefak yang dihasilkan tim setiap hari: pull request. Kami menyintesis temuan dari tiga studi berskala besar yang mencakup lebih dari 5 juta PR di ribuan proyek sumber terbuka, dan melihat apa yang benar-benar mendorong waktu tinjauan pull request.

Temuan utama: peralihan konteks yang paling mahal bukan notifikasi Slack yang memecah alur kerja Anda. Melainkan pull request yang duduk di antrean tinjauan selama sehari, memaksa penulisnya membangun ulang seluruh model mental ketika pertanyaan akhirnya datang.

Kumpulan Data yang Kami Gunakan

Kami tidak membangun scraper khusus dan menganalisis 10.000 PR secara terpisah. Kami menyintesis temuan dari dua studi yang ditinjau sejawat dan satu kumpulan data industri besar, lalu menguji kesimpulan mereka satu sama lain.

stat: "3,35 Juta" headline: "Pull request yang dianalisis oleh Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"

Tiga kumpulan data utama:

Zhang et al. (2022), ditinjau sejawat: 3.347.937 PR tertutup di 11.230 proyek. Menggunakan regresi linier efek campuran untuk mengidentifikasi apa yang mendorong penundaan tinjauan PR. Diterbitkan di Empirical Software Engineering.
Adadot (2023), kumpulan data industri: 300.000+ PR yang digabungkan dari ~30.000 developer. Tidak ditinjau sejawat, tetapi sampelnya besar dan metodologinya (korelasi tau Kendall) transparan. Berfokus pada ukuran PR vs. waktu tunggu.
Studi multi-tinjauan (2019), ditinjau sejawat: 1.836.280 PR di 760 proyek GitHub. Diterbitkan di Information and Software Technology. Memeriksa perilaku tinjauan bersamaan – proksi langsung untuk peralihan konteks dalam tinjauan kode.

Kami mencocokkan ini dengan 2024 DORA State of DevOps Report dan Atlassian Developer Experience Report 2024 (survei terhadap 2.100+ developer tentang peralihan konteks, produktivitas developer, dan sisi manusiawi dari persamaan tersebut).

Antrean Adalah Pembunuh Sesungguhnya

Zhang et al. menemukan bahwa waktu yang dibutuhkan PR untuk mendapatkan respons pertamanya – komentar pertama, tinjauan pertama, apa pun yang pertama – menjelaskan 58,7% varians dalam total masa hidup PR. Itulah prediktor terkuat yang diamati dalam kumpulan data – jauh di atas ukuran PR, kompleksitas kode, atau jumlah file yang diubah! Tidak ada yang mendekati.

Biaya terbesar peralihan konteks dalam tinjauan kode bukan peralihannya sendiri – melainkan antrean yang terbentuk saat semua orang sibuk beralih di antara hal-hal lain.

Pikirkan apa artinya dalam praktik. Seorang insinyur membuka PR pukul 10.00. Peninjau yang ditunjuk tenggelam dalam cabang fiturnya sendiri, atau sedang rapat, atau menyortir pesan Slack (dan sejujurnya, mungkin ketiganya berurutan). PR menunggu. Saat seseorang mengambilnya pukul 15.00, penulisnya sudah beralih ke hal lain sepenuhnya. Kini peninjau memiliki pertanyaan, yang berarti penulis harus beralih konteks kembali ke kode yang ditulisnya lima jam lalu, membangun ulang model mental, dan merespons. Respons itu tiba pukul 16.30, tetapi peninjau sudah pulang.

PR menua satu hari lagi.

Data menunjukkan bahwa ini lebih merupakan masalah antrean daripada masalah disiplin – dan biaya peralihan konteks dari antrean itu berlipat ganda dengan cara-cara yang sama sekali terlewatkan oleh kalkulator gangguan.

PR Kecil Tidak Akan Menyelamatkan Anda

Anda sudah pernah mendengar ini: PR yang lebih kecil ditinjau lebih cepat, jadi jaga PR Anda tetap kecil. Itu tidak sepenuhnya salah, tetapi ukuran efeknya (sungguh-sungguh) lebih kecil dari yang Anda harapkan.

Analisis Adadot terhadap 300.000+ PR menemukan korelasi tau Kendall hanya 0,06 antara ukuran PR dan waktu tunggu – asosiasi yang lemah, meskipun studi tersebut tidak melaporkan interval kepercayaan untuk angka agregat. PR di bawah 100 baris memang memiliki probabilitas sekitar 80% untuk diselesaikan dalam seminggu, yang terdengar bagus sampai Anda menyadari bahwa itu adalah tingkat penyelesaian yang sama dengan PR yang sudah enam hari duduk di antrean tinjauan seseorang!

stat: "0,06" headline: "Korelasi antara ukuran PR dan waktu tunggu" source: "Analisis Adadot terhadap 300.000+ PR dari ~30.000 developer (2023)"

Temuan yang lebih menarik: korelasi ini sangat bervariasi di antara organisasi, berkisar dari 0,1 hingga hampir 0,7 tergantung perusahaannya. Yang mengisyaratkan bahwa ukuran PR bukanlah hambatan yang melekat – melainkan budaya tinjauan dan proses di sekitar PR. Tim dengan ritme tinjauan yang kuat dapat menangani PR yang lebih besar secara efisien. Tim yang menganggap tinjauan sebagai hal sampingan akan kesulitan dengan PR ukuran apa pun.

Ambang batas 400 baris dari studi tinjauan kode SmartBear/Cisco tetap berlaku sebagai heuristik yang berguna – data Adadot juga menemukan bahwa keterlibatan tinjauan menurun di atas rentang itu. Tetapi mengoptimalkan ukuran PR tanpa memperbaiki ritme tinjauan yang mendasarinya adalah (dan saya mengatakan ini dengan kasih sayang tulus kepada setiap engineering manager yang pernah mencobanya) menata ulang kursi dek di Titanic.

Semua Orang Meninjau Segalanya Sekaligus

Studi multi-tinjauan menemukan bahwa 62% pull request melibatkan developer yang secara bersamaan meninjau beberapa PR. Yang lebih penting, mereka menemukan korelasi yang signifikan secara statistik: lebih banyak tinjauan bersamaan per peninjau berkaitan dengan latensi penyelesaian PR yang lebih panjang.

62% pull request melibatkan developer yang secara bersamaan meninjau beberapa PR – dan multi-tinjauan berkorelasi langsung dengan waktu penyelesaian yang lebih lama. attribution: Studi multi-tinjauan pull request, 1,8 juta PR di 760 proyek

Mekanismenya intuitif (meskipun studi tersebut, karena bersifat observasional, tidak membuktikan arah kausalitas). Seorang peninjau mengambil PR #1, membaca diff, mulai membentuk model mental tentang apa yang coba dilakukan kode tersebut. Kemudian sebuah notifikasi tiba – PR #2 perlu ditinjau karena memblokir penerapan. Peninjau beralih. Ketika mereka kembali ke PR #1, mereka harus membaca ulang setengah diff karena model mentalnya telah memudar.

Skalakan itu ke tim delapan insinyur, masing-masing dengan dua atau tiga PR terbuka, masing-masing meninjau untuk dua atau tiga kolega, dan biaya koordinasi mulai menjelaskan dirinya sendiri. Terpisah dari itu, 2024 DORA Report menemukan bahwa kluster "high performer" menyusut dari 31% menjadi 22% sementara kluster low-performer tumbuh dari 17% menjadi 25%. DORA tidak mengisolasi konkurensi tinjauan PR sebagai faktor, tetapi meningkatnya biaya koordinasi adalah salah satu kontributor yang masuk akal untuk pergeseran itu.

Yang Salah dari Estimasi Biaya Peralihan Konteks

Izinkan saya berbicara langsung tentang angka "$50 ribu per developer per tahun" yang beredar luas dalam artikel biaya peralihan konteks. Metodologi di balik sebagian besar estimasi ini adalah: ambil waktu refokus 23 menit, kalikan dengan perkiraan gangguan harian (biasanya antara 6 dan 15, tergantung seberapa dramatis penulis merasa), kalikan dengan tarif per jam developer, dan jadikan tahunan.

Masalahnya bukan matematikanya salah. Masalahnya adalah semua peralihan konteks diperlakukan setara. Beralih dari pengodean mendalam ke pesan Slack yang menanyakan di mana makan siang tim – itu adalah peralihan konteks. Beralih dari meninjau satu PR ke meninjau PR yang berbeda dalam basis kode yang sama sekali berbeda – itu juga peralihan konteks. Tetapi biaya kognitifnya tidak sebanding sama sekali, dan meratakan semuanya menjadi satu tarif per jam mengaburkan tempat kerusakan nyata terjadi.

Untuk mengatakannya secara konkret: di pekerjaan terakhir saya, hari biasa berarti beralih antara Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster, dan saluran Telegram serta Signal yang tak terhitung – dan saya yakin saya melupakan setengah lusin. Sekarang saya menggunakan segelintir (Signal, Obsidian, Figma, GitHub, email, kalender). Biaya per peralihan tidak berubah. Yang berubah adalah berapa banyak konteks yang mengantri menunggu perhatian – dan mana yang benar-benar penting.

Data PR menunjukkan bahwa peralihan yang mahal adalah yang menciptakan antrean, bukan yang menginterupsi alur kerja. Seorang developer yang segera (dalam hitungan menit) mendapat ping untuk meninjau PR dan melakukan tinjauan cepat 50 baris – itu adalah gangguan singkat dengan imbal hasil tinggi. Seorang developer yang mengantrekan permintaan tinjauan itu bersama empat yang lain dan baru menanganinya besok – itu adalah gangguan lebih panjang bagi peninjau tetapi menciptakan biaya yang jauh lebih besar bagi penulis dan tim.

Apa yang diukur kalkulator biaya

Gangguan individual – seberapa sering alur kerja seseorang terganggu
Waktu refokus – berapa lama untuk kembali ke tugas sebelumnya
Perkalian tarif per jam – angka tahunan besar yang menakutkan

Apa yang sebenarnya ditunjukkan data PR

Pembentukan antrean – PR menunggu respons pertama
Konkurensi tinjauan – peninjau menyulap beberapa PR
Penundaan kaskade – peralihan konteks penulis yang memperbesar penundaan peninjau

Apa Artinya bagi Tim Anda

Jika Anda mencoba mengurangi biaya peralihan konteks bagi developer di tim Anda, jawaban praktisnya membosankan – yang mungkin menjadi alasan mengapa hal ini jarang ditulis. Ini bukan alat. Ini bukan kerangka proses dengan program sertifikasi. Ini adalah ritme tinjauan. (Saya tahu, saya tahu. Tidak ada yang pernah dipromosikan karena meningkatkan ritme tinjauan.)

Tolok ukur rekayasa 2025 LinearB, yang diambil dari 6,1 juta PR di 3.000 organisasi, menemukan bahwa tim yang mencapai waktu siklus elite (di bawah 2,5 hari) memiliki satu kesamaan: mereka meninjau PR dengan cepat. Bukan karena mereka memiliki lebih sedikit PR, atau karena PR mereka lebih kecil (meskipun seringkali memang demikian), tetapi karena merespons permintaan tinjauan dalam hitungan jam adalah norma tim, bukan renungan setelahnya.

Sebagai catatan, Ben dan saya – tim dua orang – rata-rata butuh menit untuk respons pertama PR, bukan jam. Itu bukan memamerkan disiplin (kami tidak punya itu). Itu adalah kesepakatan tim: permintaan tinjauan adalah satu-satunya notifikasi yang tidak Anda antrekan. Tindakan CI dan pengujian otomatis menangani pemeriksaan mekanis, yang berarti tinjauan manusia – bagian yang membutuhkan konteks nyata – lebih pendek dan terjadi segera. Kesepakatan datang lebih dulu. Perkakas hanya membuatnya berkelanjutan.

Secara praktis, itu berarti:

Ukur waktu hingga respons pertama, bukan hanya waktu siklus. Jika Anda melacak metrik DORA, tambahkan yang satu ini. Ini adalah prediktor terkuat tunggal untuk throughput PR (menjelaskan 58,7% varians masa hidup, menurut Zhang et al.).

Batasi konkurensi tinjauan. Jika seorang peninjau memiliki tiga permintaan tinjauan yang tertunda, permintaan keempat tidak akan mendapatkan tinjauan yang baik. Data multi-tinjauan menunjukkan asosiasi yang jelas antara konkurensi dan latensi. Mulailah dengan batas WIP dua tinjauan bersamaan dan pantau dampaknya.

Berhenti mengoptimalkan ukuran PR secara terpisah. PR kecil itu baik, tetapi bukan pengganti tim yang benar-benar meninjau sesuatu. Tim yang menghasilkan dua puluh PR 50 baris per hari dengan backlog tinjauan 48 jam lebih buruk dari tim yang menghasilkan lima PR 200 baris dengan tinjauan di hari yang sama.

Akui bahwa tinjauan adalah pekerjaan nyata. Survei Atlassian 2024 menemukan bahwa 69% developer kehilangan 8+ jam per minggu akibat inefisiensi. Tinjauan tidak harus menjadi salah satu dari inefisiensi itu – tetapi hanya jika diperlakukan sebagai aktivitas rekayasa kelas satu, bukan gangguan dari pekerjaan "nyata".

Dan inilah bagian yang tidak ada di ruang alat produktivitas (termasuk kami sendiri, sejujurnya) yang ingin dikatakan dengan lantang: intervensi paling berdampak untuk biaya peralihan konteks dalam tim rekayasa bukanlah sebuah alat. Melainkan kesepakatan tim tentang kapan PR ditinjau. Jika norma implisit tim Anda adalah "saya akan menangani tinjauan ketika ada celah," tidak ada perkakas yang akan mencegah kaskade antrean yang diungkap data PR.

Alat membantu – mampu melihat konteks lengkap PR tanpa membuka empat tab browser mengurangi beban kognitif per peralihan, dan menampilkan tinjauan mana yang memblokir pekerjaan orang lain membantu penentuan prioritas. Tetapi tuas utamanya adalah kesepakatan, dan kesepakatan itu gratis. Tidak perlu kalkulator 23 menit.

Peralihan konteks yang paling mahal bukan notifikasi yang memecah alur kerja Anda. Melainkan permintaan tinjauan yang duduk di antrean selama sehari, memaksa penulis membangun ulang konteks mental ketika pertanyaan akhirnya datang.

Dapatkan intelijen sinyal langsung ke kotak masuk Anda.

Pertanyaan yang Sering Diajukan

Q: Berapa biaya peralihan konteks per developer per tahun? A: Perkiraan bervariasi, tetapi penelitian yang mendasarinya lebih tipis dari yang disarankan kebanyakan artikel. Studi Gloria Mark di UC Irvine menemukan 23 menit waktu refokus per gangguan, dan survei Atlassian 2024 terhadap 2.100+ developer menemukan 69% kehilangan 8+ jam per minggu akibat inefisiensi. Angka dalam dolar sangat bergantung pada asumsi gaji, frekuensi gangguan, dan bagaimana Anda mendefinisikan "peralihan" – itulah mengapa kami fokus pada data PR.

Q: Apakah Sugarbug membantu mengurangi peralihan konteks untuk tim rekayasa? A: Ya. Sugarbug menghubungkan alat seperti Linear, GitHub, Slack, dan Figma ke dalam satu grafik pengetahuan tunggal, sehingga insinyur dapat melihat konteks lengkap suatu tugas – PR yang relevan, diskusi Slack, komentar Figma – tanpa membuka empat tab. Tujuannya adalah lebih sedikit peralihan, bukan lebih sedikit alat.

Q: Berapa ukuran pull request ideal untuk meminimalkan penundaan tinjauan? A: Penelitian dari analisis Adadot terhadap 300.000+ PR menemukan bahwa PR di bawah 100 baris kode memiliki probabilitas sekitar 80% untuk diselesaikan dalam satu minggu. Di atas 400 baris, kualitas tinjauan dan kecepatan penyelesaian keduanya menurun. PR yang lebih kecil juga mengurangi beban peralihan konteks peninjau.

Q: Apakah Sugarbug berintegrasi dengan pull request GitHub? A: Ya. Sugarbug mengambil aktivitas GitHub – PR, komentar, tinjauan, dan perubahan status – dan menghubungkannya ke sinyal terkait di alat Anda yang lain. Jika issue Linear memunculkan PR tersebut, dan utas Slack mendebat pendekatannya, Sugarbug menghubungkan ketiganya secara otomatis.

Q: Dari mana statistik "23 menit untuk refokus" berasal? A: Statistik itu berasal dari penelitian Gloria Mark di UC Irvine, yang diterbitkan dalam "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Studi tersebut menemukan pekerja rata-rata membutuhkan 23 menit dan 15 detik untuk kembali ke tugas semula setelah gangguan. Perlu dicatat bahwa studi tersebut mengamati pekerja pengetahuan umum, bukan insinyur perangkat lunak secara khusus.