बड़ी कंपनियों में सक्षम इंजीनियर खराब कोड क्यों लिखते हैं

 (seangoedecke.com)
17 पॉइंट द्वारा GN⁺ 2025-11-29 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • बड़ी tech कंपनियों में कम tenure और बार-बार होने वाले organizational re-org के कारण, कई इंजीनियर ऐसे codebase पर काम करते हैं जिनसे वे परिचित नहीं होते
  • code changes का एक बड़ा हिस्सा वास्तव में जॉइन करने के 6 महीने के भीतर के ‘शुरुआती’ स्तर के इंजीनियरों द्वारा किया जाता है
  • कुछ अनुभवी ‘old-hand’ इंजीनियर गुणवत्ता की कमी को संभालते हैं, लेकिन अत्यधिक workload और अनौपचारिक जिम्मेदारियों के कारण उनकी सीमाएँ होती हैं
  • कंपनियाँ विशेषज्ञता से अधिक workforce mobility और legibility को प्राथमिकता देती हैं, और यह गुणवत्ता में जानबूझकर की गई गिरावट की कीमत है
  • नतीजतन, किसी इंजीनियर की व्यक्तिगत क्षमता से अलग, अनजान सिस्टम में तेज़ delivery पर केंद्रित होकर काम करने की संरचनात्मक समस्या ही खराब code का मूल कारण है

बड़ी कंपनियों में खराब code बनने की संरचना

  • बड़ी tech कंपनियाँ ऊँचे वेतन पर सक्षम इंजीनियरों को hire करती हैं, लेकिन उनका tenure अक्सर सिर्फ 1–2 साल होता है
    • stock compensation (share grant) 4 साल बाद पूरी तरह vest होती है, जिसके बाद वेतन प्रभावी रूप से आधा रह जाता है
    • कुछ annual refresh भी होते हैं, लेकिन वे guaranteed नहीं होते, इसलिए इंजीनियर नौकरी बदलना चुनते हैं
  • आंतरिक transfer को शामिल करें तो, एक ही codebase पर 3 साल से अधिक टिके रहना दुर्लभ है
    • re-org हर साल, या उससे भी अधिक बार होते हैं
  • दूसरी ओर, codebase अक्सर 10 साल या उससे अधिक समय तक चलती है, इसलिए ज़्यादातर इंजीनियर किसी नए सिस्टम को अभी ‘सीख ही रहे होते’ हैं
    • नतीजतन, code changes का बड़ा हिस्सा जॉइन करने के 6 महीने के भीतर के शुरुआती इंजीनियरों द्वारा किया जाता है

‘old-hand’ की भूमिका और सीमाएँ

  • कुछ इंजीनियर किसी खास सिस्टम पर लंबे समय तक टिके रहकर गहरी विशेषज्ञता हासिल कर लेते हैं
    • वे code review के जरिए समस्याओं को शुरुआती चरण में पकड़ सकते हैं
  • लेकिन यह संरचना अनौपचारिक है और संस्थागत नहीं है
    • कंपनियों की दीर्घकालिक विशेषज्ञता बनाए रखने में रुचि कम होती है, और वे अनुभवी लोगों को दूसरी टीमों में भेज देती हैं
  • अनुभवी लोग हमेशा अत्यधिक workload झेलते हैं
    • हर बदलाव को खुद review करने का समय नहीं होता
    • अगर उनकी अपनी performance output घटे, तो उन्हें नुकसान उठाने का जोखिम भी रहता है

औसत productive इंजीनियर की वास्तविकता

  • बड़ी कंपनी का औसत productive इंजीनियर आम तौर पर इन विशेषताओं वाला होता है
    • वह hiring bar पार करने लायक सक्षम होता है, लेकिन नए codebase या language से परिचित नहीं होता
    • साथ ही, वह कई projects की एक-दूसरे पर चढ़ी हुई deadlines के बीच काम कर रहा होता है
  • नतीजतन, यह एक ऐसी संरचना बन जाती है जहाँ लोग गुणवत्ता से अधिक schedule-केंद्रित माहौल में अपना सर्वश्रेष्ठ देने की कोशिश करते हैं
    • उदाहरण: एक शुरुआती इंजीनियर अनजान code में bug को अस्थायी तरीके से ठीक करता है, और अनुभवी व्यक्ति हल्का review करके उसे deploy कर देता है
    • फिर कई साल बाद वही code दोबारा सामने आता है और सवाल उठता है, “ऐसा code आखिर लिखा ही क्यों गया था?”

कंपनियाँ इस संरचना को बनाए क्यों रखती हैं

  • बड़ी कंपनियाँ उत्पादकता से अधिक आंतरिक legibility को महत्व देती हैं
    • वे ऐसी संरचना पसंद करती हैं जिसमें पता रहे कि कौन क्या कर रहा है, और जिसे किसी भी समय फिर से reassign किया जा सके
  • यह विशेषज्ञता और code quality की कीमत पर किया गया एक जानबूझकर चयन है
    • skill loss स्वीकार करके, समस्या आने पर लोगों को तेज़ी से इधर-उधर लगाने की flexibility मिलती है
  • खासकर AI जैसे नए क्षेत्रों की ओर तेज़ pivot महत्वपूर्ण होने पर, यह रणनीति कंपनियों के लिए फायदेमंद काम करती है
  • लेकिन ऐसे माहौल में अनजान सिस्टम में जल्दबाज़ी में काम करने वाले इंजीनियरों की संख्या बढ़ना तय है

इंजीनियर की व्यक्तिगत सीमाएँ और ‘pure/impure’ engineering

  • व्यक्तिगत इंजीनियर के पास इस संरचना को बदलने की शक्ति नहीं होती
    • 2025 तक शक्ति का केंद्र इंजीनियरों से management की ओर खिसक चुका है
    • व्यक्ति अधिकतम इतना कर सकता है कि किसी खास क्षेत्र का ‘old-hand’ बनकर न्यूनतम गुणवत्ता बनाए रखे
  • लेकिन ज़रूरत से ज़्यादा दखल देने पर उल्टा कम performance के आधार पर PIP में डाले जाने का जोखिम भी होता है
  • लेख ‘pure’ और ‘impure’ engineering का अंतर बताता है
    • pure engineering: स्वतंत्र technical projects (जैसे programming language development) पर केंद्रित
    • impure engineering: अनजान सिस्टम में schedule-केंद्रित वास्तविक कामकाजी वातावरण
  • बड़ी कंपनियों के ज़्यादातर इंजीनियर impure engineering में आते हैं, और इस स्थिति में खराब code एक अपरिहार्य उप-उत्पाद बन जाता है
    • अगर सिस्टम पर्याप्त रूप से काम कर रहा है, तो project को सफल माना जाता है

निष्कर्ष: संरचनात्मक कारण के रूप में ‘अनजान codebase’

  • बड़ी कंपनियों के पास इंजीनियरों को स्वतंत्र रूप से इधर-उधर ले जाने की शक्ति होती है, और यह विशेषज्ञता के नुकसान को स्वीकार करने वाला उनका अपना चयन है
  • खराब code की जिम्मेदारी व्यक्ति पर नहीं, बल्कि संगठनात्मक संरचना और workforce संचालन के तरीके पर है
  • सभी इंजीनियरों की क्षमता दोगुनी कर दी जाए, तब भी अनजान codebase में गलतियाँ होती रहेंगी
  • मूल कारण यह है कि “ज़्यादातर इंजीनियरों को अपने अपरिचित code में ही ज़्यादातर काम करना पड़ता है”
  • खराब code के उदाहरणों की ओर इशारा करना सुधार में मदद कर सकता है, लेकिन दोष इंजीनियरों का नहीं, सिस्टम का है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.