क्या चीज़ डेवलपरों को उत्पादक बनाती है

• डेवलपर productivity पर कई तत्व असर डालते हैं
• कुछ स्पष्ट होते हैं और उन्हें मापना आसान होता है, लेकिन कुछ को मापना कठिन होता है इसलिए वे अक्सर छूट जाते हैं

क्या बनाना है यह जानना (Knowing what to build)

• गलत चीज़ को जल्दी बनाना बिल्कुल भी उत्पादक नहीं है
  • यह जानना ज़रूरी है कि ग्राहक क्या मांग रहे हैं,
  • और यह भी कि दूसरी टीमें क्या स्वीकार कर सकती हैं (DB table में कितने indexes संभव हैं, कानूनी रूप से कौन-सी जानकारी साझा की जा सकती है?),
  • और यह जानना कि पहले क्या कोशिश की गई थी लेकिन काम नहीं आई

कम काम करना

• काम को जल्दी पूरा करना अच्छा है, लेकिन उससे भी बेहतर यह है कि कोई काम करना ही न पड़े
• कंपनी की processes productivity को घटाने वाले “busy work” जोड़ सकती हैं
  • कभी-कभी process को आसानी से इस तरह बदला जा सकता है कि बहुत कम काम में वही value दी जा सके
• “Keep the lights on (KTLO)” के लिए कुछ हद तक effort ज़रूरी हो सकता है
• यह ऐसे काम हैं जिन्हें लगातार करना पड़ता है (उदाहरण: support tickets का जवाब देना), लेकिन ये project को आगे नहीं बढ़ाते
• ऐसे काम कई metrics (tickets पूरे होने की संख्या, commits merge होने की संख्या) में productive दिख सकते हैं, लेकिन वे कंपनी को बेहतर जगह नहीं बनाते

तेज़ response वाले tools

• डेवलपर लगातार tools इस्तेमाल करते हैं: editor, git, build system
• इन tools से जुड़ने वाला समय, इनके उपयोग की आवृत्ति के अनुसार, काफ़ी बड़ी लागत बन जाता है
• यह सिर्फ़ प्रति घंटे की लागत नहीं बढ़ाता, बल्कि डेवलपर का focus भी तोड़ देता है

डेवलपर के दिमाग़ में मौजूद ज्ञान

• इसे मापना कठिन है
• अगर बाकी सभी स्थितियाँ समान हों, तो ज़्यादा प्रासंगिक ज्ञान वाला डेवलपर अधिक productive होता है
  • क्योंकि उसे पता होता है कि code कैसे काम करता है, इसलिए उसे code में बहुत गहराई तक जाने की ज़रूरत नहीं पड़ती,
  • वह tools इस्तेमाल करना जानता है, और किन pitfalls से बचना है यह भी जानता है
  • वह सही सवाल पूछता है
  • 10x डेवलपर वास्तव में होते हैं, और वे “codebase को अच्छी तरह जानने वाले लोग” होते हैं
• इसका मतलब यह भी है कि किसी team को सामूहिक रूप से अपने दिमाग़ में संभाल सकने से ज़्यादा चीज़ों का ownership नहीं लेना चाहिए। (bus number का 1 से बड़ा होना आदर्श है: Bus Factor theory)
  • इसका यह भी मतलब है कि ownership बदलने की आवृत्ति को कम से कम रखना फ़ायदेमंद है
  • कोई भी व्यक्ति किसी चीज़ को उसके निर्माता से ज़्यादा नहीं जानता
  • आदर्श रूप से, जो लोग पहली बार किसी system का उपयोग कर रहे हों, उन्हें उन लोगों के साथ काम करके सीखना चाहिए जो पहले से उस system से परिचित हैं
• systems के बीच स्पष्ट boundaries होनी चाहिए
  • सरल semantics वाले साफ़ interfaces का मतलब है कि interface के पीछे पूरे system को जाने बिना, interface की properties के बारे में सोचा जा सकता है
• documentation ज्ञान साझा करने का अच्छा तरीका है
  • यह विशेष रूप से तब महत्वपूर्ण है जब डेवलपर को कोई ऐसा specific काम करना हो जिससे वह परिचित न हो
  • documentation की कमी होने पर डेवलपर को खुद यह शोध करना पड़ता है कि काम कैसे करना है, गलतियाँ करनी पड़ती हैं और काम दोबारा करना पड़ता है, या फिर किसी दूसरी team के सवालों का जवाब देने तक इंतज़ार करना पड़ता है, जिससे काम धीमा हो जाता है
  • इससे 1 घंटे का काम बहुत जल्दी 2 दिन का काम बन सकता है
  • अगर 100 डेवलपरों को यह काम करना पड़े, तो documentation के एक page की कमी की लागत एक डेवलपर की सालाना salary के बराबर हो सकती है
• इसका यह भी मतलब है कि specialization बढ़नी चाहिए
  • हर डेवलपर से बहुत व्यापक तरह के काम कराना non-productive है
  • किसी security system या capacity planning process को लिखने में लगने वाला एक घंटा, और किसी समस्या को हल करने के लिए domain को समझने में लगने वाला एक घंटा, एक जैसे नहीं होते

उपयोगी infrastructure

• infrastructure रुकावट नहीं बल्कि मददगार होना चाहिए
• इसे किए जाने वाले लगभग हर काम के साथ उचित रूप से closely aligned होना चाहिए
• infrastructure का हर हिस्सा किसी specific use case को ध्यान में रखकर design किया जाता है, लेकिन projects में कभी-कभी ये use case पार हो जाते हैं
  • ऐसे समय “आपको सिर्फ़ हमारा infrastructure ही इस्तेमाल करना होगा” या “हमारे infrastructure में यह संभव नहीं है” जैसी बातें बहुत निराशाजनक होती हैं
  • तब या तो infrastructure को bypass करके काम करना पड़ता है, या infrastructure owners को requirements समझाने वाली meetings में समय बर्बाद करना पड़ता है

कम technical debt

• मौजूदा code कभी भी उस काम के लिए पूरी तरह उपयुक्त नहीं होता जो आप करना चाहते हैं
  • मूल code लेखक के पास यह देखने वाला कोई “crystal ball” नहीं था कि आप कौन-सा बदलाव करने वाले हैं
  • लेकिन कुछ code दूसरे code की तुलना में बदलने में बहुत आसान होते हैं
• “X कैसे किया जा सकता है?” का जवाब “हमें यह सब फिर से design करना होगा” नहीं होना चाहिए
• अगर technical debt ज़्यादा है, तो किसी feature में छोटा-सा बदलाव करने के लिए भी system में बड़ा बदलाव करना पड़ता है
• technical debt कम करने से उस surface area को कम किया जा सकता है जिसे (a) समझना है और (b) बदलना है
• technical debt चुकाने वाले projects पूरे होने चाहिए
  • अगर उन्हें बीच में छोड़ दिया जाए या priority कम कर दी जाए, तो system पहले से भी बदतर हो सकता है

कम failure rate

• tool execution failure, build failure, deployment failure, या production error से आई regression जैसी चीज़ें समय की बर्बादी हैं
• ऐसी failures की संभावना कम करने से productivity बढ़ती है
• failure झेलने वाले engineer के अलावा, उस failed system की owner team का समय भी अक्सर बर्बाद होता है (क्योंकि failure का analysis और fix साथ मिलकर करना पड़ता है)

उत्पादक practices व्यावहारिक होती हैं (Productive practices are practical)

• किसी specific समस्या को हल करने का तरीका सीखने का सबसे अच्छा तरीका prototype बनाना है
• अगर environment prototyping में बाधा डालता है, तो सबसे productive approach भी बाधित हो सकती है
• अगर monitoring tools इस्तेमाल करना कठिन है, तो डेवलपर कम dashboards बनाएँगे, कम चीज़ें मापेंगे, और decisions कम data-driven होंगे
• इसके विपरीत, अगर बड़े changes को छोटे code reviews में बाँट दिया जाए, तो code को review और deploy करना आसान हो जाता है

engineer कितना focus कर सकता है

• engineers को build schedule के अनुसार काम करना होता है, और उन्हें focus कर पाने की ज़रूरत होती है
• यह focus meetings और interruptions से छिन सकता है
• interruptions में धीमे CLI commands, धीमे tests, और ऐसे tasks भी शामिल हैं जिनमें तरीका न जानने के कारण investigation करनी पड़ती है
• एक हफ़्ते में बहुत सारी चीज़ों के बारे में सोचना भी focus करने की क्षमता को नुकसान पहुँचाता है
• आने वाले deadlines या manager से अब तक न मिले जवाब, किसी और चीज़ पर ध्यान लगाने की कोशिश करते समय भी मानसिक RAM घेरते रहते हैं

काम को पूरा करना

• 50% बनाना, 50% productivity नहीं बल्कि 0% productivity है
• फेंक दिया जाने वाला काम जितना non-productive कुछ नहीं होता
• कभी-कभी project को बीच में छोड़ देना सही फ़ैसला भी हो सकता है
  • sunk cost fallacy से लड़ना कई बार सही काम होता है
  • लेकिन project पूरा होने से पहले priorities बदलने का लगातार pattern नहीं होना चाहिए
  • ऐसे में team की productivity 0 तक गिर सकती है

निष्कर्ष

• इन अलग-अलग तत्वों को मापने के लिए हमेशा dashboards नहीं बनाए जा सकते, लेकिन यह समझा जा सकता है कि ऊपर जैसी चीज़ें productivity पर कैसे असर डालती हैं
• इन समस्याओं को हल करने से किए जाने वाले काम की मात्रा काफ़ी बढ़ सकती है
• कुछ समस्याएँ चौंकाने वाली हद तक आसानी से ठीक की जा सकती हैं
  • documentation लिखने में कुछ घंटे लगाने से, कंपनी हज़ारों घंटे बचा सकती है
• जब पेड़ को जल्दी काटना हो, तो शुरुआत आरी की धार तेज़ करने से करनी चाहिए

[kofmania]

वाह, इसमें काफ़ी ऐसे हिस्से हैं जो बहुत सोचने पर मजबूर करते हैं।

[laeyoung]

"अगर दस्तावेज़ीकरण की कमी हो, तो डेवलपर को काम करने का तरीका खुद खोजने, गलतियाँ करने और काम दोबारा करने, या किसी दूसरी टीम के सवालों का जवाब देने तक इंतज़ार करने की वजह से काम की रफ़्तार धीमी पड़ सकती है"

यह डेवलपमेंट दस्तावेज़ नहीं है, लेकिन जब हमने onboarding दस्तावेज़ पाने वाले लोगों से कहा कि वे एक हफ़्ते बाद उसे अपडेट करें, तो दस्तावेज़ बेहतर हो गया। क्योंकि जब कोई कंपनी में शामिल होता है और उसके पास कोई जानकारी नहीं होती, तब उस समय क्या ज़रूरी है यह वही लोग सबसे अच्छी तरह जानते हैं।

मुझे यह भी लगता है कि GitHub पर मौजूद open source projects के Readme.md अक्सर काफ़ी अच्छे लिखे होते हैं, शायद इसलिए कि बहुत से शुरुआती users आकर feedback देते हैं।

[devsepnine]

आजकल इतना ज़्यादा काम आ रहा है कि दिमाग़ चकरा गया है T_T

[ahwjdekf]

इन्फ्रास्ट्रक्चर को रुकावट नहीं बल्कि मददगार होना चाहिए --> लेकिन फिलहाल कोरिया की कंपनियों में सुरक्षा को बहाना बनाकर इसका बिल्कुल उल्टा हो रहा है।

[hero512]

भावना मैं समझता हूँ, लेकिन यह लेख अंग्रेज़ी में लिखा गया था। अंग्रेज़ी भाषी कंपनियों में भी स्थिति मिलती-जुलती दिखती है।

[kuroneko]

यह सारांश नहीं, बल्कि अनुवाद के स्तर का लग रहा है... इतनी विस्तृत और अच्छी तरह से की गई整理 के लिए धन्यवाद।