ज़्यादातर तकनीकी समस्याएँ दरअसल लोगों की समस्याएँ होती हैं

• बड़े पैमाने के technical debt वाली कंपनियों में code duplication और पुराने framework के कारण अक्षम्यता पैदा होती है
• प्रोजेक्ट के दौरान management का भरोसा खोना और संगठन के भीतर बदलाव का विरोध प्रमुख बाधा बनते हैं
• technical debt के मूल कारण अस्पष्ट requirements, अवास्तविक deadlines, पुरानी तकनीक की पसंद, management की अल्पकालिक प्रतिक्रिया, व्यक्तिगत अहं जैसे मानवीय कारक हैं
• प्रोजेक्ट की सफलता के लिए तकनीकी उपलब्धियों के साथ perception management और communication भी अनिवार्य हैं
• engineer को तकनीकी क्षमता के अलावा संगठन के भीतर collaboration और मानवीय संबंधों को संतुलित करने की क्षमता भी रखनी चाहिए

---

technical debt और duplicated code की समस्या

• एक पहले की कंपनी में लाखों lines of code, unit tests की अनुपस्थिति, और 10 साल से पुराने framework के उपयोग के कारण गंभीर technical debt मौजूद था
  • Windows-विशिष्ट module को Linux पर चलाने के लिए लाखों नहीं बल्कि सैकड़ों हज़ार lines of code को copy-paste करके काम चलाया गया
  • इसके कारण दो अलग codebase बन गए, और feature जोड़ने व bug fix करने का काम दोनों में अलग-अलग करना पड़ता था
• ऐसी स्थिति maintenance के लायक न रहने वाली संरचना पैदा करती है, और लंबे समय में code के बीच का अंतर बढ़ता जाता है

लोगों की समस्याओं से पैदा होने वाला technical debt

• technical debt projects के लिए management को मनाना कठिन होता है, और क्योंकि नतीजतन feature-level बदलाव लगभग नहीं दिखते, इसलिए दृश्य उपलब्धि कम रहती है
  • प्रोजेक्ट में देरी होती है और management का भरोसा कम हो जाता है
• समस्या की जड़ तकनीक नहीं बल्कि लोगों का रवैया और संगठन की संस्कृति है
  • कई developer बदलाव का विरोध करते हैं और पुराने तरीकों में सहज बने रहते हैं
  • code structure उसके लेखक के स्वभाव और बदलाव स्वीकारने की क्षमता को दर्शाती है
• technical debt अस्पष्ट requirements, अवास्तविक वादों, पुरानी तकनीक के चयन, management द्वारा बीच में रोक देने के फैसलों, और व्यक्तिगत अहं से पैदा होता है
  • जिन टीमों में बदलाव से बचने की प्रवृत्ति अधिक होती है, उनके code में भी बदलाव-प्रतिरोधी विशेषताएँ दिखती हैं
• कई developer सालों से उसी तरीके से काम कर रहे थे, यहाँ तक कि यह भी कहा गया कि “मैं कुछ नया सीखना नहीं चाहता”
• ऐसे माहौल में सफाई की गति से ज़्यादा तेज़ी से debt जमा होता है, इसलिए debt घटाने से पहले यह रोकना ज़रूरी है कि नया debt और न बढ़े
  • emergency room के triage (प्राथमिक वर्गीकरण) की तरह, पहले “खून बहना रोकने” का चरण ज़रूरी होता है

आदर्श दुनिया और वास्तविकता के बीच की खाई

• engineering समस्याओं को राजनीति या संगठनात्मक संदर्भ से अलग करके सुलझा सकने वाला आदर्श माहौल लगभग कभी नहीं होता
  • अधिकांश प्रोजेक्ट में गैर-तकनीकी stakeholders मौजूद होते हैं
  • “हम यह कर रहे हैं, बस हम पर भरोसा कीजिए” वाला रवैया काम नहीं करता
• उपलब्धियों की perception management वास्तविक उपलब्धियों जितनी ही महत्वपूर्ण है
  • गैर-तकनीकी लोग technical debt साफ़ करने की ज़रूरत को सहज रूप से नहीं समझते, इसलिए इसे मात्रात्मक और business value के रूप में समझाना पड़ता है
  • अगर leadership का engineering background न हो, तो दिखाई देने वाले metrics और असर पेश करना आवश्यक है
• आखिरकार टीम का productive दिखाई देना भी वास्तविक productivity जितना ही महत्वपूर्ण होता है

senior engineer के लिए ज़रूरी क्षमताएँ

• senior या उससे ऊपर के स्तर पर विभागों के बीच collaboration और मानवीय संबंधों का समन्वय अनिवार्य है
  • computer science education में स्वभाव, अहं, और रिश्तों के प्रबंधन जैसी ‘लोगों को संभालने’ की बातें नहीं सिखाई जातीं
• बेहतरीन तकनीकी कौशल वाला engineer भी बड़े पैमाने के, संगठनात्मक बदलाव माँगने वाली समस्याओं में अटक सकता है
  • व्यक्तिगत productivity ऊँची हो सकती है, लेकिन संगठनात्मक प्रभाव सीमित रह सकता है
• ‘Heads up coder’ की भूमिका महत्वपूर्ण है
  • जो गहरी तकनीकी क्षमता बनाए रखते हुए भी प्रोजेक्ट risk को जल्दी पहचान सके और टीम को समन्वित कर सके
  • single core की तरह अकेले तेज़ काम करने के बजाय, पूरी टीम को कुशलता से आगे बढ़ाने वाली भूमिका
  • शुद्ध तकनीकी engineer से अलग, ऐसा व्यक्ति संगठन के संदर्भ और risk दोनों को साथ पढ़कर काम कर सकता है

निष्कर्ष

• तकनीकी समस्याओं की जड़ में हमेशा लोग होते हैं
  • ज़्यादातर तकनीकी समस्याएँ आखिरकार लोगों, संस्कृति, और communication की समस्याओं पर जाकर टिकती हैं
• technical debt code की समस्या नहीं, बल्कि संगठन के व्यवहारिक पैटर्न और संस्कृति का परिणाम है
  • technical debt को हल करने के लिए संगठनात्मक बदलाव को स्वीकारना और leadership की समझ पहले आनी चाहिए
• और केवल तकनीकी उत्कृष्टता से हल न होने वाली समस्याएँ करियर के बाद के चरणों में बड़े मंच पर इंतज़ार कर रही होती हैं
  • सच्चा senior engineer वह संतुलित leader है जो तकनीक और मानवीय समझ, दोनों को साथ लेकर चलता है

[GN⁺]

Hacker News राय

• मुझे लगा कि ज़्यादातर समस्याएँ communication problems होती हैं
  engineers product vision या customers से कटे रहते हैं, और product team engineers को सिर्फ़ in-house outsourced team की तरह ट्रीट करती है
  sales और CS यह नहीं समझते कि उनके किए गए वादों का product roadmap पर क्या असर पड़ता है
  नतीजतन goals और success metrics आपस में मेल नहीं खाते, और हर कोई अलग-अलग दिशा में चप्पू चलाता रहता है
  समाधान “बेहतर लोग” नहीं, बल्कि यह है कि सब एक ही goal पर committed हों और समझें कि उनकी भूमिका पूरे सिस्टम से कैसे जुड़ती है
  पुराना technical debt भी ऐसा ही है, उसे अनदेखा करने से वह गायब नहीं होता। उस debt की company पर क्या cost और risk है, उसे quantify करके दूसरे goals के साथ balance करना और उसे चुकाने की plan बनानी चाहिए

  • इसलिए मैंने BigCo की internal tooling team के लिए Shadow Sessions program बनाया
    इसमें users ठीक बगल में होते हैं, तो आप उनसे सीधे मिलते हैं, दोस्त बनते हैं, और उनकी रोज़मर्रा की ज़िंदगी व context को समझते हैं
    यह हर 3 हफ्ते में अपने-आप schedule होता है, और इसमें अलग से कोई action item नहीं रखा जाता। हर बार लोग हैरान होते हैं, छोटे bugs ठीक होते हैं, और connections बनते हैं
    मैं इसे Slack API से जुड़े automated scheduler के साथ चला रहा हूँ, और सबसे मुश्किल हिस्सा scheduling और participation बढ़ाना है
  • मुझे लगता है कि इसकी वजह यह है कि कंपनियाँ लोगों को एक-दूसरे की बात सुनने के लिए incentive नहीं देतीं
    management junior लोगों की नहीं सुनता, और junior लोग attention पाने के लिए आपस में compete करते हैं
    हाल ही में हमारे department में भी एक consultant ने नई platform पर switch करने को कहा, किसी की सहमति नहीं थी, फिर भी उसे रोका नहीं जा सका। आखिर में कोई किसी की नहीं सुनता
  • “उस technical debt की company पर क्या cost पड़ती है, यह निकालो” वाली बात दिलचस्प लगी, लेकिन इसे practically कैसे करते हैं, यह जानना चाहता हूँ
  • बेशक “बेहतर लोग” कई समस्याएँ हल कर देते हैं। सब नहीं, लेकिन काफ़ी बड़ा हिस्सा ज़रूर हल हो जाता है
  • product team engineers को outsourced workers की तरह इसलिए ट्रीट करती है क्योंकि उनके भीतर “idea मेरा है और तुम बस इसे execute कर रहे हो” वाली श्रेष्ठता की भावना होती है
    “हम यह क्यों कर रहे हैं?” पूछने पर जवाब बस “मुझ पर भरोसा करो” जैसा मिलता है
    मुझे नहीं लगता कि PMs का यह व्यवहार बदलेगा। इसलिए engineers खुद product role लेने लगे हैं ताकि communication gap कम हो सके

• मैंने यह भी समझा कि बहुत से लोग असल में अपने काम पर गर्व नहीं करते
  कुछ लोगों के लिए यह बस salary है
  ख़ासकर उम्रदराज़ colleagues ने systems को टूटते देखा है, इसलिए वे चाहते हैं कि वैसी स्थिति फिर न आए
  हर नई नौकरी में मैं 90-day plan के भीतर साफ़ guidelines सेट करने की कोशिश करता हूँ, लेकिन आख़िर में असली बात team ही होती है
  कुछ teams बदलाव के लिए उत्सुक होती हैं, और कुछ बदलाव को रोकती हैं
  अगर leader अनजान हो या सिर्फ़ सबसे तेज़ और सस्ता विकल्प चुने, तो चीज़ें और मुश्किल हो जाती हैं
  UK के Post Office scandal जैसी घटनाएँ भी याद आती हैं, जहाँ अंदर से लोग समस्या जानते थे लेकिन उन्हें रोका गया

  • लोगों ने अपने काम पर गर्व इसलिए खोया है क्योंकि उनसे ownership छिन गई है
    पहले आधे से ज़्यादा लोग self-employed थे, अब मुश्किल से 10% हैं
    अब हम जो बनाते हैं, वह “हमारा” नहीं बल्कि “employer का” होता है
    ज़्यादा मेहनत करने पर भी reward नहीं मिलता, उल्टा और ज़्यादा काम थमा दिया जाता है
    आख़िर में लोगों को सिर्फ़ resource की तरह ट्रीट किया जाता है, और ज़रूरत न हो तो हटा दिया जाता है
  • ज़्यादातर कंपनियों को कर्मचारियों की परवाह नहीं होती, और employees यह जानते हैं
    crisis में सबसे पहले employees को निकाला जाता है, और CEO millions of dollars ले जाता है
    ऐसे ढाँचे में employees से company के लिए समर्पण की उम्मीद करना नामुमकिन है
  • गर्व क्यों गायब हुआ, इसका जवाब साफ़ है
    कम काम करने वाला ज़्यादा salary पाता है, और आप अपनी आधी salary वाले replacement की वजह से निकाले जा सकते हैं
    interviews लगातार कठिन होते जा रहे हैं, credit चुरा लिया जाता है, और inflation salary को खा जाती है
    इसलिए “गर्व क्यों गायब हुआ” कोई mystery नहीं, जवाब काफ़ी साफ़ है
  • “गर्व” से groceries नहीं खरीदी जा सकतीं, और मेहनत करने पर भी salary वही रहती है
  • लोग तभी care करते हैं जब उन्हें काम में दिलचस्पी हो
    लेकिन companies जानती हैं कि ज़्यादातर लोग वही काम नहीं कर पाएँगे जो वे चाहते हैं, इसलिए वे processes और workflows पर ध्यान देती हैं
    किसी व्यक्ति के लिए सबसे अच्छा यही है कि वह अपनी पसंद का काम करे और उसके लिए अच्छा pay पाए

• अगर कोई developer कहता है “मैं कुछ नया सीखना नहीं चाहता”, तो यह ज़रूरी नहीं कि बुरी बात हो
  JavaScript ecosystem की तरह रोज़ बदलते frameworks से होने वाली थकान और Go या LTS आधारित technical stability अलग चीज़ें हैं
  stability product agility में भी मदद करती है
  हो सकता है आपको किसी senior engineer के साथ negotiate करना पड़े जो पुराना C++ codebase संभाल रहा हो, लेकिन उसे सीधे technical debt कहना prejudice है
  कोई codebase technical debt है या नहीं, यह सिर्फ़ उस codebase के ज़िम्मेदार lead IC और उसे manage करने वाला manager ही तय कर सकते हैं

• interview में इंसानी समस्याओं का ज़िक्र करना reject होने का आसान तरीका है
  बहुत से interviewers सिर्फ़ technical answers को ही सही मानते हैं और human insight को नज़रअंदाज़ कर देते हैं
  मैं तो ऐसे perspective की क़द्र करता हूँ, लेकिन फिर मुझे colleagues से बहस करनी पड़ती है

  • शुक्र है, blog posts को interviews की तरह judge नहीं किया जाता :)
  • हाल की एक interview process में सभी interviewers ने hire के लिए हाँ कहा, लेकिन एक ने विरोध किया
    मैंने कहा कि message throughput के हिसाब से batch processing काफ़ी हो सकती है, तो उसने मान लिया कि मुझे “queues” नहीं आतीं
    मैंने बताया कि मैं 10 साल से ज़्यादा समय से petabyte-scale data products पर काम कर चुका हूँ, लेकिन उसकी system design सोच से मेल न खाने के कारण मुझे reject कर दिया गया
    और अब वही team सभी microservices को एक single API के पीछे बाँधने का काम कर रही है
  • interview में मैं दोनों तरफ़ के trade-offs साथ रखता हूँ
    अगर team उस balance को नहीं समझती, तो उस team में शामिल न होना ही बेहतर है
  • वैसे, Graph DB अक्सर cool लगने की वजह से ज़रूरत से ज़्यादा इस्तेमाल होती है

• Big Tech में data engineer के रूप में मुझे दो सबसे कठिन समस्याएँ दिखती हैं
  पहली, Conway’s Law की वजह से हर department के पास अलग toolchain और data philosophy होती है
  दूसरी, हर silo यह दावा करता है कि उसका तरीका ही सही है, जबकि उसे दूसरों का data भी चाहिए
  standardization इसलिए नामुमकिन हो जाती है क्योंकि हर department के leaders मानते हैं कि उनका तरीका ही अकेला सही समाधान है
  असल में देखें तो ज़्यादातर approaches कुछ हद तक सही भी होती हैं और ग़लत भी
  ऊपर से यह technical problem लगती है, लेकिन आख़िर में यह लोगों की समस्या है

  • इसके अलावा requirements शुरू से साफ़ नहीं होतीं, और automation की कमी के कारण छोटे-छोटे requests में समय डूब जाता है
    upstream systems में बदलाव की कोई सूचना नहीं मिलती, और हमें तभी पता चलता है जब downstream में alarms बजने लगते हैं
    इतने ad-hoc requests आते हैं कि sprints बेकार लगने लगते हैं, और undocumented knowledge भरी पड़ी होती है
    ऐसे अनुभवों ने मुझे computer science के और low-level हिस्सों को पढ़ने की motivation दी
  • इस तरह की समस्या IT की सबसे बुनियादी people-centric problem है
    बदलाव लाने के लिए network बनाना पड़ता है, लोगों को साथ जोड़ना पड़ता है, और transparency के साथ change को फैलाना पड़ता है
    लेकिन असली बदलाव के लिए director या VP जैसे senior leaders का support चाहिए
    AWS ने ऐसे organizational change के लिए एक guide दी है, और AWS Prescriptive Guidance एक शानदार blueprint है
  • बड़े institutional systems को implement करते समय सबसे बड़ी रुकावट departments के बीच अविश्वास होती है
    शुरुआत “सबको एक solution में जोड़ते हैं” से होती है, लेकिन जल्दी ही यह हर department के अलग project में टूट जाती है
    इसे रोकने के लिए मज़बूत authority वाला leader चाहिए
    ख़ासकर public sector में यह और मुश्किल है क्योंकि वहाँ कई बार लोग एक-दूसरे को पसंद ही नहीं करते, जबकि private sector में कम-से-कम jobs बचाए रखना एक common goal होता है

• जैसा Jerry Weinberg ने 『Secrets of Consulting』 में कहा था,
  “ऊपर से यह technical problem लगे, तब भी आख़िरकार यह लोगों की समस्या होती है”
  technical problems की जड़ आखिरकार लोगों के choices, communication, management और capability में होती है

  • मैं भी यही कहने आया था। उनकी insight समय बीतने पर भी पुरानी नहीं पड़ती

• मैंने system replacement project में analyst के रूप में काम किया है
  पुराना system काम को साधारण round-robin तरीके से बाँटता था, लेकिन नया system हर व्यक्ति के workload को देखकर ज़्यादा fair allocation करता था
  लेकिन कुछ employees ने system को इस तरह manipulate किया कि वे व्यस्त दिखें, और नतीजे में ईमानदारी से काम करने वाले employees पर और ज़्यादा काम आ गया
  हमने साफ़ कहा कि असली समस्या technology नहीं बल्कि supervision की कमी है, फिर भी आख़िर में हम पर technical solution थोप दिया गया

  • मुझे लगता है कि यह दो technical options के बीच की समस्या थी
    इंसानी स्वभाव ऐसा है कि काम उतना फैलता है जितना समय दिया जाए, और ऐसे perverse incentives को technically control करना पड़ता है
    अगर आप ideal इंसानों को मानकर system design करेंगे, तो आप fail होंगे

• Jerry Weinberg ने 『The Psychology of Computer Programming』 (1971) से ही
  इस सिद्धांत पर ज़ोर दिया था कि “ऊपर से technical problem लगे, तब भी वह हमेशा लोगों की समस्या होती है”
  उनकी किताबें आज भी पढ़ने लायक़ हैं

  • title देखते ही मुझे Jerry याद आ गए

• मुझे यह रवैया पसंद नहीं कि लोगों को “अपने काम पर गर्व नहीं है” कहकर दोष दिया जाए
  ज़्यादातर employees अपने काम के मालिक नहीं होते, company मालिक होती है
  अगर company किसी दिशा को थोपे और विरोध करने पर नुकसान पहुँचाए, तो फिर कोई क्यों लड़े
  हम बस machine के पुर्ज़े हैं, और अगर हमारे साथ वैसा ही बर्ताव होगा, तो हम भी वैसा ही व्यवहार करेंगे
  लेखक का self-centered रवैया मुझे खटकता है

  • अगर आप non-developed countries में काम करें तो यह और साफ़ दिखता है। वहाँ सब लोग बस गुज़ारे के लिए काम करते हैं

• मैं अब काफ़ी senior हूँ और funding sponsors व requirements owners के साथ सीधे काम करता हूँ
  वे पूछते हैं, “यह कर दो, कितना खर्च आएगा?”, और मुझे 30 मिनट की meeting में 18 मिनट के भीतर एक rough estimate देना पड़ता है
  उन्हें technology नहीं आती, लेकिन वे पैसे और politics की भाषा पूरी तरह समझते हैं
  कुछ समस्याएँ मैंने सिर्फ़ एक text message से हल कर दीं, जबकि budget 6 million dollars था
  कुछ दूसरे projects दूसरी team ले गई, 35 million dollars जला दिए, और fail हो गई
  budget पकड़े sponsors के लिए अक्सर politics पहले होती है, और उनका goal “अगली कुर्सी” होता है
  उनकी careers देखकर कई बार लगता है, “ये वहाँ तक पहुँचे कैसे?”

[chebread]

जो लोग इसके बारे में और विस्तार से जानना चाहते हैं, उन्हें मैं Peopleware पढ़ने की सलाह दूंगा!