कॉन्टेक्स्ट स्विचिंग की असली लागत: 5M GitHub PRs
हमने 5M+ PRs के डेटा का विश्लेषण किया ताकि डेवलपर्स की असली कॉन्टेक्स्ट स्विचिंग लागत मापें – और यह वहाँ नहीं है जहाँ आप सोचते हैं।
By Ellis Keane · 2026-03-29
अधिकांश लेखों में उद्धृत कॉन्टेक्स्ट स्विचिंग लागत – व्यवधान के बाद री-फोकस करने में 23 मिनट, UC Irvine में Gloria Mark के शोध से – एक वास्तविक अध्ययन का वास्तविक निष्कर्ष है। लेकिन इसने 2008 में सामान्य ज्ञान कार्यकर्ताओं को मापा, सॉफ़्टवेयर इंजीनियरों को नहीं। और ब्लॉग पोस्ट की कुटीर उद्योग जो 23 मिनट को एक अनुमानित व्यवधान गिनती से गुणा करके चौंकाने वाले वार्षिक डॉलर आंकड़े उत्पन्न करती है (हमेशा सिर थामे किसी की स्टॉक फोटो के साथ), मूल शोध के इरादे से परे कुछ कर रही है।
इस प्रश्न में मेरी व्यक्तिगत रुचि है। एक पिछली कंपनी में, मैंने – और यह अतिशयोक्ति नहीं है – कुछ दिनों के 80 से 100 प्रतिशत समय एक मानव राउटर बनने में बिताए। कोड लिखने में नहीं, उसकी समीक्षा करने में नहीं। लोगों और टूल्स के बीच जानकारी रूट करने में, क्योंकि कोई भी एकल सिस्टम उन्हें जोड़ता नहीं था। वह अनुभव आंशिक रूप से वह कारण है जिसके लिए हमने Sugarbug बनाया, लेकिन यही कारण है कि मैं मानक कॉन्टेक्स्ट स्विचिंग लागत कैलकुलेटर के प्रति संशयवादी हूँ। वे व्यवधान मापते हैं। वे उन दिनों को नहीं मापते जो आप उस काम तक कभी न पहुँचते हुए बिताते हैं जो आपको करना था।
इसलिए हम जानना चाहते थे कि इंजीनियरिंग कार्य में कॉन्टेक्स्ट स्विचिंग की वास्तविक लागत क्या है – अमूर्त डेवलपर प्रोडक्टिविटी शब्दों में नहीं, बल्कि उस कलाकृति में मापा गया जो टीमें दैनिक रूप से उत्पन्न करती हैं: पुल रिक्वेस्ट। हमने हजारों ओपन-सोर्स प्रोजेक्ट्स में 5 मिलियन से अधिक PRs को कवर करने वाले तीन बड़े पैमाने के अध्ययनों से निष्कर्ष संश्लेषित किए, और देखा कि पुल रिक्वेस्ट रिव्यू समय को वास्तव में क्या प्रेरित करता है।
मुख्य निष्कर्ष: सबसे महंगा कॉन्टेक्स्ट स्विच वह Slack नोटिफिकेशन नहीं है जो आपके प्रवाह को तोड़ता है। यह वह पुल रिक्वेस्ट है जो एक दिन के लिए रिव्यू कतार में बैठता है, जब अंततः प्रश्न आते हैं तो लेखक को एक पूरे मानसिक मॉडल का पुनर्निर्माण करने के लिए मजबूर करता है।
जिन डेटासेट से हमने डेटा लिया
हमने एक कस्टम स्क्रेपर नहीं बनाया और 10,000 PRs को अलग से विश्लेषित नहीं किया। हमने दो पीयर-रिव्यूड अध्ययनों और एक बड़े उद्योग डेटासेट से निष्कर्ष संश्लेषित किए, फिर उनके निष्कर्षों को एक-दूसरे के खिलाफ परखा।
stat: "33.5 लाख" headline: "Zhang et al. द्वारा विश्लेषित पुल रिक्वेस्ट" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
तीन प्राथमिक डेटासेट:
- Zhang et al. (2022), पीयर-रिव्यूड: 11,230 प्रोजेक्ट्स में 3,347,937 बंद PRs। PR रिव्यू विलंब को क्या प्रेरित करता है, यह पहचानने के लिए मिश्रित-प्रभाव रैखिक प्रतिगमन का उपयोग किया। Empirical Software Engineering में प्रकाशित।
- Adadot (2023), उद्योग डेटासेट: ~30,000 डेवलपर्स से 300,000+ मर्ज किए गए PRs। पीयर-रिव्यूड नहीं, लेकिन नमूना बड़ा है और पद्धति (Kendall tau सहसंबंध) पारदर्शी है। PR आकार बनाम लीड टाइम पर केंद्रित।
- मल्टी-रिव्यूइंग अध्ययन (2019), पीयर-रिव्यूड: 760 GitHub प्रोजेक्ट्स में 1,836,280 PRs। Information and Software Technology में प्रकाशित। समवर्ती रिव्यू व्यवहार की जांच करता है – कोड रिव्यू में कॉन्टेक्स्ट स्विचिंग का एक प्रत्यक्ष प्रॉक्सी।
हमने इन्हें 2024 DORA State of DevOps Report और Atlassian के 2024 Developer Experience Report (कॉन्टेक्स्ट स्विचिंग, डेवलपर प्रोडक्टिविटी और मानवीय पहलू पर 2,100+ डेवलपर्स का सर्वे) के साथ क्रॉस-रेफरेंस किया।
कतार ही असली हत्यारा है
Zhang et al. ने पाया कि किसी PR को उसकी पहली प्रतिक्रिया मिलने में लगने वाला समय – पहली टिप्पणी, पहला रिव्यू, कुछ भी पहला – PR की कुल लाइफटाइम में 58.7% वेरिएंस की व्याख्या करता है। यह डेटासेट में सबसे मजबूत देखा गया प्रेडिक्टर है – PR आकार, कोड जटिलता या बदले गए फाइलों की संख्या से आगे! बिल्कुल भी करीब नहीं।
कोड रिव्यू में कॉन्टेक्स्ट स्विचिंग की सबसे बड़ी लागत स्विचिंग खुद नहीं है – यह वह कतार है जो तब बनती है जब सभी दूसरी चीजों के बीच स्विच करने में व्यस्त हों।
सोचें कि इसका व्यावहारिक रूप से क्या अर्थ है। एक इंजीनियर सुबह 10 बजे PR खोलता है। नामित रिव्यूअर अपनी खुद की फीचर ब्रांच में गहरा है, या किसी मीटिंग में, या Slack संदेशों की ट्राइज कर रहा है (और ईमानदारी से, शायद क्रम में तीनों)। PR इंतजार करता है। जब तक दोपहर 3 बजे कोई इसे उठाता है, लेखक पूरी तरह कुछ और काम पर आगे बढ़ चुका है। अब रिव्यूअर के प्रश्न हैं, जिसका अर्थ है कि लेखक को उस कोड पर वापस कॉन्टेक्स्ट स्विच करना होगा जो उसने पाँच घंटे पहले लिखा था, मानसिक मॉडल का पुनर्निर्माण करना होगा और जवाब देना होगा। वह जवाब शाम 4:30 बजे आता है, लेकिन रिव्यूअर घर चला गया है।
PR एक और दिन पुराना हो जाता है।
डेटा यह सुझाव देता है कि यह अनुशासन की समस्या से अधिक एक कतार की समस्या है – और उस कतार की कॉन्टेक्स्ट स्विचिंग लागत उन तरीकों से बढ़ती है जिन्हें व्यवधान कैलकुलेटर पूरी तरह से चूक जाते हैं।
छोटे PRs आपको नहीं बचाएंगे
आपने यह पहले सुना है: छोटे PRs तेज़ी से रिव्यू होते हैं, इसलिए अपने PRs को छोटा रखें। यह बिल्कुल गलत नहीं है, लेकिन प्रभाव का आकार (वास्तव में) उम्मीद से छोटा है।
Adadot के 300,000+ PRs के विश्लेषण में PR आकार और लीड टाइम के बीच केवल 0.06 का Kendall tau सहसंबंध पाया गया – एक कमजोर संबंध, हालांकि अध्ययन ने समग्र आंकड़े के लिए विश्वास अंतराल की रिपोर्ट नहीं की। 100 लाइनों से कम के PRs में एक सप्ताह के भीतर पूर्ण होने की लगभग 80% संभावना है, जो शानदार लगता है जब तक आप यह नहीं समझते कि यह उसी PR की समापन दर है जो किसी की रिव्यू कतार में छह दिनों से बैठा है!
stat: "0.06" headline: "PR आकार और लीड टाइम के बीच सहसंबंध" source: "~30,000 डेवलपर्स से 300,000+ PRs का Adadot विश्लेषण (2023)"
अधिक रोचक निष्कर्ष: यह सहसंबंध संगठनों के बीच बड़े पैमाने पर भिन्न था, कंपनी के आधार पर 0.1 से लगभग 0.7 तक। जो यह सुझाव देता है कि PR आकार स्वाभाविक रूप से बाधा नहीं है – PR के आसपास की रिव्यू संस्कृति और प्रक्रिया है। मजबूत रिव्यू कैडेंस वाली टीम बड़े PRs को कुशलता से संभाल सकती है। जहाँ रिव्यू एक afterthought है वह टीम किसी भी आकार के PRs के साथ संघर्ष करेगी।
SmartBear/Cisco कोड रिव्यू अध्ययन से 400-लाइन की सीमा एक उपयोगी heuristic के रूप में बनी रहती है – Adadot के डेटा ने यह भी पाया कि उस सीमा से परे रिव्यू engagement गिरती है। लेकिन अंतर्निहित रिव्यू कैडेंस को ठीक किए बिना PR आकार को अनुकूलित करना है (और मैं यह उन सभी engineering managers के लिए वास्तविक सहानुभूति के साथ कहता हूँ जिन्होंने कोशिश की है) टाइटैनिक पर डेक कुर्सियों को पुनर्व्यवस्थित करना।
सब एक साथ सब कुछ रिव्यू कर रहे हैं
मल्टी-रिव्यूइंग अध्ययन ने पाया कि 62% पुल रिक्वेस्ट में ऐसे डेवलपर्स शामिल हैं जो एक साथ कई PRs रिव्यू कर रहे हैं। इससे भी महत्वपूर्ण, उन्हें एक सांख्यिकीय रूप से महत्वपूर्ण सहसंबंध मिला: प्रति रिव्यूअर अधिक समवर्ती रिव्यू, लंबी PR समाधान विलंबता से जुड़ा था।
62% पुल रिक्वेस्ट में ऐसे डेवलपर्स शामिल हैं जो एक साथ कई PRs रिव्यू कर रहे हैं – और मल्टी-रिव्यूइंग सीधे लंबे समाधान समय से संबंधित है। attribution: मल्टी-रिव्यूइंग पुल-रिक्वेस्ट अध्ययन, 760 प्रोजेक्ट्स में 1.8M PRs
तंत्र सहज है (भले ही अध्ययन, अवलोकनात्मक होने के कारण, कारणता की दिशा साबित नहीं करता)। एक रिव्यूअर PR #1 उठाता है, diff पढ़ता है, कोड क्या करने की कोशिश कर रहा है इसका मानसिक मॉडल बनाना शुरू करता है। फिर एक नोटिफिकेशन आती है – PR #2 को रिव्यू की जरूरत है क्योंकि यह deploy को रोक रहा है। रिव्यूअर बदल जाता है। जब वे PR #1 पर वापस आते हैं, तो उन्हें आधा diff दोबारा पढ़ना होता है क्योंकि मानसिक मॉडल क्षीण हो गया है।
इसे आठ इंजीनियरों की एक टीम पर स्केल करें, जिनमें से प्रत्येक के पास दो या तीन PRs खुले हैं, प्रत्येक दो या तीन सहयोगियों के लिए रिव्यू कर रहा है, और समन्वय का बोझ खुद को समझाने लगता है। अलग से, 2024 DORA Report ने पाया कि "उच्च प्रदर्शनकर्ता" cluster 31% से 22% तक सिकुड़ गया जबकि low-performer cluster 17% से 25% तक बढ़ गया। DORA PR रिव्यू समवर्तता को एक कारक के रूप में अलग नहीं करता, लेकिन बढ़ता समन्वय बोझ उस बदलाव का एक प्रशंसनीय योगदानकर्ता है।
कॉन्टेक्स्ट स्विचिंग लागत अनुमान क्या गलत करते हैं
मुझे कॉन्टेक्स्ट स्विचिंग लागत लेखों में व्यापक रूप से प्रसारित "$50K प्रति डेवलपर प्रति वर्ष" के आंकड़े के बारे में सीधे बात करने दीजिए। इन अनुमानों के पीछे की अधिकांश पद्धति है: 23 मिनट के री-फोकस समय को लें, अनुमानित दैनिक व्यवधानों की संख्या से गुणा करें (आमतौर पर 6 और 15 के बीच, यह इस बात पर निर्भर करता है कि लेखक कितना नाटकीय महसूस कर रहा है), एक प्रति घंटा डेवलपर दर से गुणा करें, और वार्षिकीकृत करें।
समस्या यह नहीं है कि गणित गलत है। समस्या यह है कि यह सभी कॉन्टेक्स्ट स्विच को समकक्ष मानता है। गहरे कोडिंग से Slack संदेश पर स्विच करना जो पूछ रहा है कि टीम लंच कहाँ है – यह एक कॉन्टेक्स्ट स्विच है। एक PR रिव्यू से पूरी तरह अलग codebase में एक अलग PR रिव्यू पर स्विच करना – यह भी एक कॉन्टेक्स्ट स्विच है। लेकिन संज्ञानात्मक लागत दूर-दूर तक तुलनीय नहीं है, और उन्हें एकल प्रति घंटा दर में समतल करना यह अस्पष्ट करता है कि वास्तविक नुकसान कहाँ होता है।
ठोस रूप से कहें तो: अपनी पिछली नौकरी में, एक विशिष्ट दिन का मतलब था Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster और असंख्य Telegram और Signal channels के बीच स्विच करना – और मुझे यकीन है कि मैं एक दर्जन भूल रहा हूँ। अब मैं एक मुट्ठी का उपयोग करता हूँ (Signal, Obsidian, Figma, GitHub, ईमेल, कैलेंडर)। प्रति-स्विच लागत नहीं बदली। जो बदला वह था कि कितने contexts ध्यान के लिए कतार में थे – और उनमें से कौन से वास्तव में मायने रखते थे।
PR डेटा सुझाव देता है कि महंगे स्विच वे हैं जो कतारें बनाते हैं, वे नहीं जो प्रवाह को बाधित करते हैं। एक डेवलपर जिसे तुरंत (मिनटों में) ping किया जाता है कि PR रिव्यू करें और एक त्वरित 50-लाइन रिव्यू करता है – वह उच्च रिटर्न के साथ एक छोटा व्यवधान है। एक डेवलपर जो उस रिव्यू अनुरोध को चार अन्य के साथ कतार में रखता है और कल इसे निपटाता है – वह रिव्यूअर के लिए एक लंबा व्यवधान है लेकिन लेखक और टीम के लिए बहुत अधिक लागत पैदा करता है।
कोस्ट कैलकुलेटर क्या मापते हैं
- व्यक्तिगत व्यवधान – किसी का प्रवाह कितनी बार टूटता है
- री-फोकस समय – पिछले काम पर वापस आने में कितना समय लगता है
- प्रति घंटा दर से गुणा – बड़े भयावह वार्षिक संख्याएँ
PR डेटा वास्तव में क्या दर्शाता है
- कतार निर्माण – PRs पहली प्रतिक्रिया के इंतजार में
- रिव्यू समवर्तता – रिव्यूअर कई PRs को एक साथ संभाल रहे हैं
- कैस्केड विलंब – लेखक के कॉन्टेक्स्ट स्विच रिव्यूअर विलंब को बढ़ाते हैं
इसका आपकी टीम के लिए क्या अर्थ है
यदि आप अपनी टीम के डेवलपर्स के लिए कॉन्टेक्स्ट स्विचिंग लागत कम करने की कोशिश कर रहे हैं, तो व्यावहारिक उत्तर उबाऊ है – जो शायद इसीलिए इसके बारे में ज्यादा नहीं लिखा जाता। यह कोई टूल नहीं है। यह प्रमाणन कार्यक्रम के साथ कोई प्रक्रिया ढाँचा नहीं है। यह रिव्यू कैडेंस है। (मैं जानता हूँ, मैं जानता हूँ। रिव्यू कैडेंस में सुधार के लिए किसी को कभी पदोन्नत नहीं किया गया।)
LinearB के 2025 engineering benchmarks, 3,000 संगठनों में 6.1 मिलियन PRs से निकाले गए, ने पाया कि elite cycle times (2.5 दिन से कम) प्राप्त करने वाली टीमों में एक लक्षण साझा था: उन्होंने PRs को तेज़ी से रिव्यू किया। इसलिए नहीं कि उनके पास कम PRs थे, या उनके PRs छोटे थे (हालाँकि वे अक्सर थे), बल्कि इसलिए कि घंटों में रिव्यू अनुरोधों का जवाब देना एक टीम मानदंड था, न कि afterthought।
जो भी हो, Ben और मैं – एक दो-व्यक्ति की टीम – PR पर पहली प्रतिक्रिया में घंटों नहीं, मिनटों में औसत करते हैं। यह अनुशासन के बारे में कोई दिखावा नहीं है (हमारे पास वह नहीं है)। यह एक टीम समझौता है: रिव्यू अनुरोध वह एकमात्र नोटिफिकेशन है जिसे आप कतार में नहीं डालते। CI actions और automated tests यांत्रिक जाँच संभालते हैं, जिसका अर्थ है कि मानव रिव्यू – जिस भाग में वास्तविक संदर्भ की आवश्यकता होती है – छोटा है और तुरंत होता है। समझौता पहले आया। टूलिंग ने इसे केवल टिकाऊ बनाया।
व्यावहारिक रूप से, इसका अर्थ है:
- केवल cycle time नहीं, पहली प्रतिक्रिया तक के समय को मापें। यदि आप DORA metrics ट्रैक कर रहे हैं, तो इसे जोड़ें। यह PR throughput का एकल सबसे मजबूत प्रेडिक्टर है (Zhang et al. के अनुसार लाइफटाइम variance का 58.7% समझाता है)।
- रिव्यू समवर्तता सीमित करें। यदि किसी रिव्यूअर के पास तीन लंबित रिव्यू अनुरोध हैं, तो चौथे को वैसे भी अच्छा रिव्यू नहीं मिलेगा। मल्टी-रिव्यूइंग डेटा ने समवर्तता और विलंबता के बीच स्पष्ट संबंध दिखाया। दो समवर्ती रिव्यू की WIP सीमा से शुरू करें और प्रभाव की निगरानी करें।
- PR आकार को अलग से अनुकूलित करना बंद करें। छोटे PRs अच्छे हैं, लेकिन वे किसी टीम का विकल्प नहीं हैं जो वास्तव में चीजें रिव्यू करती है। 48-घंटे के रिव्यू backlog के साथ प्रतिदिन बीस 50-लाइन PRs उत्पन्न करने वाली टीम उस टीम से बुरी स्थिति में है जो उसी दिन रिव्यू के साथ पाँच 200-लाइन PRs उत्पन्न करती है।
- स्वीकार करें कि रिव्यू वास्तविक काम है। Atlassian के 2024 सर्वे में पाया गया कि 69% डेवलपर्स अकुशलताओं के कारण साप्ताहिक 8+ घंटे खो देते हैं। रिव्यू को उन अकुशलताओं में से एक नहीं होना चाहिए – लेकिन केवल तभी जब इसे पहले दर्जे की engineering गतिविधि के रूप में माना जाए, "वास्तविक" काम में व्यवधान के रूप में नहीं।
और यहाँ वह हिस्सा है जो प्रोडक्टिविटी-टूल के क्षेत्र में कोई भी (हम खुद भी, निष्पक्षता के लिए) ज़ोर से नहीं कहना चाहता: इंजीनियरिंग टीमों में कॉन्टेक्स्ट स्विचिंग लागत के लिए सबसे प्रभावशाली हस्तक्षेप कोई टूल नहीं है। यह एक टीम समझौता है कि PRs कब रिव्यू किए जाते हैं। यदि आपकी टीम का implicit मानदंड "जब मुझे समय मिलेगा तो रिव्यू करूँगा" है, तो कोई भी टूलिंग उस कतार cascade को नहीं रोक सकती जो PR डेटा प्रकट करता है।
टूल मदद करते हैं – चार browser tabs खोले बिना PR का पूरा संदर्भ देखने में सक्षम होना प्रति-स्विच संज्ञानात्मक बोझ कम करता है, और यह दिखाना कि कौन से रिव्यू दूसरे लोगों के काम को ब्लॉक कर रहे हैं, प्राथमिकता तय करने में मदद करता है। लेकिन मुख्य lever समझौता है, और समझौते मुफ्त हैं। कोई 23-मिनट कैलकुलेटर आवश्यक नहीं।
सबसे महंगा कॉन्टेक्स्ट स्विच वह नोटिफिकेशन नहीं है जो आपके प्रवाह को तोड़ती है। यह वह रिव्यू अनुरोध है जो एक दिन कतार में बैठता है, जब अंततः प्रश्न आते हैं तो लेखक को मानसिक संदर्भ पुनर्निर्माण के लिए मजबूर करता है।
सिग्नल इंटेलिजेंस सीधे अपने इनबॉक्स में पाएँ।
अक्सर पूछे जाने वाले प्रश्न
Q: प्रति डेवलपर प्रति वर्ष कॉन्टेक्स्ट स्विचिंग की लागत कितनी होती है? A: अनुमान अलग-अलग हैं, लेकिन अधिकांश लेखों की तुलना में अंतर्निहित शोध पतला है। UC Irvine में Gloria Mark के अध्ययन ने प्रति व्यवधान 23 मिनट के री-फोकस समय का पता लगाया, और Atlassian के 2024 सर्वे में 2,100+ डेवलपर्स में से 69% ने साप्ताहिक 8+ घंटे अकुशलताओं में खोने की बात कही। डॉलर का आंकड़ा वेतन की धारणाओं, व्यवधान की आवृत्ति, और "स्विचिंग" की परिभाषा पर निर्भर करता है – इसीलिए हमने PR डेटा पर ध्यान केंद्रित किया।
Q: क्या Sugarbug इंजीनियरिंग टीमों के लिए कॉन्टेक्स्ट स्विचिंग कम करने में मदद करता है? A: हाँ। Sugarbug Linear, GitHub, Slack और Figma जैसे टूल्स को एक ही नॉलेज ग्राफ़ में जोड़ता है, ताकि इंजीनियर किसी काम का पूरा संदर्भ देख सकें – संबंधित PR, Slack चर्चा, Figma टिप्पणी – बिना चार टैब खोले। लक्ष्य कम स्विच हैं, कम टूल नहीं।
Q: रिव्यू विलंब कम करने के लिए पुल रिक्वेस्ट का आदर्श आकार क्या है? A: Adadot के 300,000+ PRs के विश्लेषण से पता चला कि 100 कोड लाइनों से कम के PRs में एक सप्ताह के भीतर पूरा होने की लगभग 80% संभावना होती है। 400 लाइनों से ऊपर, रिव्यू की गुणवत्ता और समापन गति दोनों कम होते हैं। छोटे PRs रिव्यूअर की कॉन्टेक्स्ट स्विचिंग का बोझ भी कम करते हैं।
Q: क्या Sugarbug GitHub पुल रिक्वेस्ट के साथ इंटीग्रेट होता है? A: हाँ। Sugarbug GitHub गतिविधि – PRs, टिप्पणियाँ, रिव्यू और स्टेटस बदलाव – को स्क्रेप करता है और उन्हें आपके अन्य टूल्स में संबंधित सिग्नल से जोड़ता है। यदि किसी Linear issue ने PR को जन्म दिया और Slack थ्रेड ने दृष्टिकोण पर बहस की, तो Sugarbug तीनों को स्वचालित रूप से जोड़ता है।
Q: "23 मिनट री-फोकस" का आंकड़ा कहाँ से आता है? A: यह UC Irvine में Gloria Mark के शोध से आता है, "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008) में प्रकाशित। अध्ययन में पाया गया कि कार्यकर्ता व्यवधान के बाद अपनी मूल काम पर वापस आने में औसतन 23 मिनट और 15 सेकंड लेते थे। यह ध्यान देने योग्य है कि अध्ययन ने सामान्य ज्ञान कार्यकर्ताओं का अवलोकन किया, विशेष रूप से सॉफ़्टवेयर इंजीनियरों का नहीं।