प्रोग्रामिंग ज़्यादातर सोचने की प्रक्रिया है (2014)
(agileotter.blogspot.com)- कोड के रूप में दिखने वाला आउटपुट पूरे दिन के काम का प्रतिनिधित्व नहीं करता, बल्कि पढ़ने, शोध, debugging, verification और निर्णय के बाद बचा हुआ शुद्ध परिणाम होता है
- कई वर्षों तक programmers से पूछे गए एक अनौपचारिक सवाल में, 6 घंटे के बदलाव को सिर्फ diff देखकर दोबारा टाइप करने में सबसे आम जवाब लगभग 30 मिनट था
- यह अनुपात वैज्ञानिक शोध नहीं, बल्कि सर्वे और diff के अवलोकन पर आधारित है, लेकिन प्रोग्रामिंग को 1/12 क्रिया, 11/12 सोच के रूप में देखने का एक व्यावहारिक मानदंड देता है
- software development फैक्टरी-शैली के निर्माण से अधिक design work के करीब है, और शुरुआती design के बाद की copy मशीनें लगभग 0 के सीमांत लागत पर कर देती हैं
- अगर management और process को typing time बढ़ाने की दिशा में optimize किया जाए, तो उसका असर उल्टा पड़ सकता है; सोच की गुणवत्ता बढ़ाने वाला environment और collaboration का तरीका अधिक महत्वपूर्ण है
6 घंटे के काम को दोबारा टाइप करने में कितना समय लगेगा
- मान लीजिए कि मीटिंग और रुकावटें लगभग न के बराबर हों, और किसी अच्छे दिन एक programmer ने 6 घंटे की गंभीर programming की हो
- घर जाने से पहले उसने diff प्रिंट कर लिया, लेकिन रात में version control system खराब हो गया और पिछले दिन के backup से restore होने पर पूरे दिन का काम गायब हो गया
- सवाल का सार यह है कि अगर programmer को वह diff दे दिया जाए, तो वह 6 घंटे का काम codebase में दोबारा दर्ज करने में कितना समय लगाएगा
- कई वर्षों तक conventions, client कंपनियों, सहकर्मियों और पहली बार मिले programmers से यह सवाल पूछा गया, और सबसे आम जवाब लगभग 30 मिनट था
- 6 घंटे में 30 मिनट 12 बार आता है, इसलिए यह अवलोकन इस बात तक पहुँचता है कि programming 1/12 क्रिया और 11/12 सोच है
इस अनुपात की प्रकृति और सीमाएँ
- यह संख्या किसी कठोर वैज्ञानिक शोध से नहीं आई, न ही यह अच्छे रिकॉर्ड वाली कोई औपचारिक study है
- लक्ष्य programming गतिविधि के सांख्यिकीय या गणितीय नियम खोजना नहीं था, बल्कि एक उचित सवाल का उचित जवाब ढूँढना था
- किसी भी कंपनी ने पूरे दिन का काम सचमुच मिटाकर इस विचार को साबित या खारिज करने की कोशिश नहीं की, इसलिए आधार अनुमान और रोज़ाना diff के अवलोकन तक ही सीमित रहा
- कई changelog और diff देखने के बाद, अच्छे दिन में शुद्ध बदलाव की मात्रा आम तौर पर 30 मिनट ± 10 मिनट जैसी लगी
टाइपिंग bottleneck नहीं है
- “टाइपिंग bottleneck नहीं है” जैसी बात लंबे समय से stickers और social media में दोहराई जाती रही है
- कुछ programmers के लिए typing खुद bottleneck हो सकती है, लेकिन तेज़ी से code बनाने की कुंजी आम तौर पर सिर्फ typing speed या tools की mastery नहीं होती
- Quora के “How do programmers code so quickly?” नामक लंबे लेख में एक उत्तरदाता ने muscle memory, tools की skill, debugging क्षमता, typing ability और information search ability का ज़िक्र किया
- लेकिन तेज़ code production में typing और tools सहायक साधन के अधिक करीब हैं; असली बड़ा हिस्सा यह तय करने में जाता है कि करना क्या है
software factory और design work में अंतर
- भौतिक उत्पादों के उत्पादन में दिखाई देने वाला ज़्यादातर काम movement होता है; steel को roll करना, stamp करना, press करना, mill करना, रखना और assemble करना ही काम जैसा दिखता है
- आधुनिक factories CNC मशीनों की तरह abstract model, यानी data, के आधार पर सटीक movement करती हैं, और इंसान मशीनों को हाथ से चलाने के बजाय उन्हें manage करते हैं
- software की तरफ़ वाली factory तो पहले से बनी हुई है, और user “copy” या “download” बटन दबाकर bit-perfect copy पा लेता है
- एक बार शुरुआती model मौजूद हो, तो उसके बाद की replication की सीमांत लागत लगभग 0 के बराबर होती है; software एक बौद्धिक संपदा है
- Uncle Bob Martin लंबे समय से कहते आए हैं कि software development निर्माण कार्य नहीं, बल्कि design work है, और शुरुआती design के बाद उसकी copy मशीनें लगभग 0 लागत पर बना देती हैं
- programmers, testers, PO, Scrum Master और software managers उस data model को design करते हैं, जिसके आधार पर ग्राहक और community इस्तेमाल करने वाली प्रतियाँ बनती हैं
बौद्धिक काम को देखना कठिन है
- औद्योगिक युग की सोच software development को factory की तरह देखना चाहती है, और developers पर यह दबाव पड़ता है कि वे काम को भौतिक श्रम जैसा दिखाएँ, भले ही इससे असली process को नुकसान हो
- बौद्धिक गतिविधि का अवलोकन और मापन कठिन है, और 80% पूरी हो चुकी idea का कोई भौतिक रूप नहीं होता
- experiments, proof-of-concept code और notes हो सकते हैं, लेकिन वे भौतिक काम की तरह सटीक completion rate नहीं दिखाते
- बन रही कुर्सी 50% बिंदु पर लगभग 50% तैयार दिखती है, और पूरी होने पर पूरी बनी हुई लगती है
- लेकिन कुर्सी का design 70% से आगे बढ़ने तक कागज़ पर भी मौजूद न हो सकता है, और design पूरा होने से पहले यह जानना भी कठिन है कि वह सचमुच 70% पूरा हुआ है या नहीं
30 मिनट का बदलाव 6 घंटे के काम का मतलब क्यों होता है
- 30 मिनट पूरे दिन लिखे, मिटाए, edit किए और दोबारा बनाए गए code के शुद्ध परिणाम को पुनः बनाने का समय है; यह कुल लगाए गए प्रयास का समय नहीं है
- programmer code लिखते समय लगातार उसका मूल्यांकन करता है और bugs व security vulnerabilities से बचने के लिए hypotheses बनाता है
- code text में run time पर program को क्या करना है, यह तो रहता है, लेकिन यह आम तौर पर नहीं बचता कि वह तरीका क्यों चुना गया, system के दूसरे हिस्सों पर उसका क्या असर पड़ता है, या कौन-सी गलतियाँ डाली गईं और फिर हटाई गईं
- असली काम का बड़ा हिस्सा बदलाव खुद करने में नहीं, बल्कि बदलाव कैसे करना है यह तय करने में होता है; और क्योंकि मौजूदा code को समझना पड़ता है, इसलिए खराब code या design वाले source में और ज़्यादा समय लगता है
- programmer का आउटपुट shared codebase में integrate होता है, इसलिए उसका एक social context भी होता है; दूसरे programmers, testers और operations staff को काम समझने में मदद करना भी ऐसा cost और benefit बनाता है जो code में दिखाई नहीं देता
code की lines प्रगति का मापदंड नहीं हैं
- 6 घंटे का बौद्धिक काम पढ़ने, शोध, निर्णय, पुष्टि, verification और review के बाद codebase में 30 मिनट के शुद्ध बदलाव में बदल सकता है
- इसका मतलब यह नहीं कि उतनी lines of code जुड़ी हों; कभी bug fix और feature addition करने के बावजूद सप्ताहांत पर code की पंक्तियाँ सप्ताह की शुरुआत से कम हो सकती हैं
- एक बार कई हफ्तों तक negative lines of code दर्ज होने से समस्या खड़ी हो गई, क्योंकि यह पता नहीं था कि टीम का senior management SLOC को progress metric की तरह report कर रहा था
- programmer ने वास्तव में जो काम किया, वह पढ़ना, सीखना, समझना, अनुमान लगाना, शोध करना, debugging, testing, compiling, running, hypotheses बनाना और उन्हें गलत साबित करना जैसा था
- बहुत-सा काम आखिरकार सोचने और निर्णय लेने का ही काम होता है
कम लिखना ही तेज़ development हो सकता है
- Quora के एक जवाब में कहा गया कि keyboard पर उँगलियाँ चलती हुई दिखाई देती हैं, लेकिन users से बात करने, सहकर्मियों के साथ समस्या पर चर्चा करने, शोध करने और सोचने में लगा समय दिखाई नहीं देता
- एक दूसरे जवाब में कहा गया कि ग्राहक जिन अनावश्यक बातों को “requirements” या “must have” कहते हैं, उन्हें हटाने में मदद करना समाधान पहुँचाने की गति सबसे अधिक बढ़ाता है
- एक और जवाब के अनुसार, बेहतरीन developers keyboard छूने से पहले requirements को समझकर और सही solution की कल्पना करके काम का 90% से अधिक पूरा कर लेते हैं
- “क्या नहीं लिखना है यह जानना”, “कम करना”, “छोटे steps में काम करना”, और “पहले क्या करना है यह समझना” जैसे जवाब बार-बार सामने आए
- जो लोग ज़्यादा typing करते हैं या ज़्यादा copy-paste करते हैं, उनमें सोच और समझ की कमी हो सकती है, और उसके परिणामस्वरूप errors बढ़ सकते हैं तथा दूसरे programmers के लिए समझने और बदलने का बोझ भी बढ़ सकता है
process को सोच के लिए design किया जाना चाहिए
- अगर programming 1/12 क्रिया और 11/12 सोच है, तो लोगों पर समय के 11/12 हिस्से में typing करते रहने का दबाव नहीं डालना चाहिए
- ज़रूरत उन सामग्रियों, environment और process की है जो सोच की गुणवत्ता को बेहतर बनाते हैं
- उल्टा करने पर system को गलत प्रभावों के लिए optimize किया जाएगा
- जब हम जानबूझकर ऐसे systems बनाते हैं जिनमें software के बारे में साथ मिलकर सोचना और निर्णय लेना आसान हो, तब productivity बढ़ सकती है
- हमें यह सोचना चाहिए कि काम के दौरान सीखने के प्रयोग करते हुए ऐसे systems कैसे बनाए जाएँ जिनमें सोच optimize हो
1 टिप्पणियां
Hacker News की रायें
लेख में कही गई बात, “वाकई बेहतरीन डेवलपर कीबोर्ड छूने से पहले 90% से ज़्यादा काम पूरा कर लेते हैं”, कभी-कभी सही होती है, लेकिन मेरे हिसाब से यह इस तथ्य को नज़रअंदाज़ करती है कि लोग अपने दिमाग में बहुत सारी बाधाएँ और concepts एक साथ नहीं रख सकते
बिना कुछ लिखे, सिर्फ़ शुद्ध सोच से काम कर पाने की सीमा बहुत सीमित होती है, इसलिए जैसे ही कोई संभावित approach सूझती है, उसे पूरी तरह specified design में तराशने से पहले ही मैं लगभग तुरंत कीबोर्ड पकड़ लेता हूँ
असली code लिखकर कई approaches आज़माने पर अक्सर पाया कि शुरुआत में सबसे अच्छा लगा समाधान, कम promising लगे समाधान से कहीं ज़्यादा खराब निकला, और समस्या को चलने वाले ठोस code जितना अच्छी तरह कुछ नहीं दिखाता
आखिरकार coding ideas को code में मूर्त रूप देकर verify करने की प्रक्रिया है, और पहले iteration को फेंक देने वाली prototyping दृष्टि की तरह code लिखने को भी सोचने की प्रक्रिया का हिस्सा मानना चाहिए
किंवदंती जैसी कहानी है कि उन्होंने Git पर करीब एक महीने सोचा, फिर 6 दिनों में उसे पूरा कर दिया और 7वें दिन आराम किया; लेकिन आम लोगों के लिए, खासकर मेरे मामले में, यह ज़्यादा एक interaction जैसा है: क्या लिखना है सोचना, लिखना, test करना, फिर सोचना, और कुछ हिस्से ठीक करना
अंत में final working version तक पहुँचने की प्रक्रिया कुछ हद तक कला जैसी होती है
मोटा-मोटा idea पकड़ लेने के बाद, उन “चिपचिपे” हिस्सों से code लिखना शुरू करता हूँ जहाँ समस्या आने की संभावना सबसे ज़्यादा लगती है
सभी समस्याओं का पहले से अनुमान नहीं लगाया जा सकता, इसलिए सच में उनसे टकराना पड़ता है, और इस तरीके में अक्सर बहुत-सा काम फेंकना पड़ता है
जब तक यह भरोसा न हो जाए कि दिशा सही है, मैं दस्तावेज़ बहुत कम लिखता हूँ[0], ताकि मैं उस स्थिति को कम कर सकूँ जिसे मैं Concrete Galoshes[1] कहता हूँ
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
इसे सीखने का एकमात्र तरीका बहुत सारी real-world coding और active learning है, और इसका मतलब यह भी है कि वही technology stack बार-बार इस्तेमाल किया जाए
मैं उसी stack पर टिककर समस्या पर ही ध्यान देने का तरीका पसंद करता हूँ, लेकिन यहाँ जिस “बेहतरीन developer” की बात हो रही है, वह tools चुनने के मामले में काफ़ी एक-आयामी हो सकता है
उम्र बढ़ने के साथ यह बहुत साफ़ हो जाता है कि microscopic फैसलों से ज़्यादा architecture महत्वपूर्ण है
microscopic चीज़ों को optimize किया जा सकता है, लेकिन macro decisions आम तौर पर स्थायी होते हैं
अक्सर tests के भीतर code design करता हूँ और implementation को कुछ हद तक guide करने देता हूँ
दिमाग में final result की कल्पना करने के बाद, system के लिए अच्छी API जैसी लगने वाली shape में test लिखता हूँ और वहीं से शुरुआत करता हूँ
नतीजतन code मूल रूप से testable हो जाता है, और Red → Green → Refactor को कई बार चलाते हुए संतोषजनक स्थिति तक पहुँचता हूँ
उत्सुक हूँ कि क्या दूसरे लोग भी इसी तरह काम करते हैं
Jonathan E. Steinhart की किताब “The Secret Life of Programs” में दिया गया वर्णन मुझे सबसे अच्छा लगा
बात यह है कि computer programming दो चरणों वाली चीज़ है: 1. ब्रह्मांड को समझना 2. उसे तीन साल के बच्चे को समझाना
मतलब, आप ऐसा program नहीं लिख सकते जो वह काम करे जिसे आप खुद नहीं समझते; spelling rules नहीं जानते तो spell checker नहीं बना सकते; और physics नहीं जानते तो अच्छा action video game बनाना मुश्किल है
अच्छा programmer बनने के लिए बाकी हर चीज़ के बारे में जितना हो सके उतना सीखना चाहिए, और समस्या का समाधान अक्सर अनपेक्षित जगहों से आता है, इसलिए सिर्फ़ अभी relevant न दिखने की वजह से उसे नज़रअंदाज़ नहीं करना चाहिए
दूसरा चरण है, जो आप जानते हैं उसे ऐसी machine को समझाना जो दुनिया को तीन साल के बच्चे की तरह बहुत सख्ती से देखती है
अगर बच्चे से पूछें “जूते कहाँ हैं?” तो वह “वहाँ” जवाब दे सकता है; उसने सवाल का जवाब तो दे दिया, लेकिन असल में जूते पहनकर बाहर चलने के इरादे का अनुमान नहीं लगा पाया
बच्चे बड़े होते हुए flexibility और inference सीखते हैं, लेकिन computer Peter Pan की तरह कभी बड़ा नहीं होता
हर व्यक्ति और समस्या के लिए उपयुक्त thinking style अलग होता है, और कई तरीकों से सोचकर programming करना सीखने से चुनने के लिए tools बढ़ जाते हैं
इसलिए मुझे यह दावा पसंद नहीं कि programming ज़रूर एक ही सही तरीके से होनी चाहिए
“जिस चीज़ को आप समझते नहीं, उसे program के रूप में नहीं लिख सकते” भी सच नहीं है; कई बार software का इस्तेमाल यह समझने के लिए किया जाता है कि कोई चीज़ वास्तव में कैसे काम करती है
physics modeling भी अक्सर reality के प्रति पूरी fidelity का लक्ष्य नहीं होती, बल्कि game के user experience और difficulty के बीच संतुलन खोजने की exploration होती है
programming एक exploratory cognitive tool हो सकती है, और इसका मतलब यह नहीं कि ज़्यादातर सोच हमेशा पहले ही आनी चाहिए
मुझे generalists और self-taught लोग पसंद हैं, लेकिन अच्छा programmer बनने के लिए यह अनिवार्य पहला कदम नहीं है
बच्चों का “strict worldview” होना नहीं, बल्कि वे social implications का हमेशा inference नहीं कर पाते; और computers को भी ज्ञात facts से logical conclusions निकालने के लिए program किया जा सकता है
अलग-अलग उम्र के बच्चों को, तीन साल के बच्चे को भी, कुछ समझाने का अनुभव रहा है, लेकिन वह अनुभव computer programming जैसा बिल्कुल नहीं था
मुझे पूरा भरोसा है कि यह आंकड़ा व्यवहार में सही है, लेकिन अब तक किसी भी कंपनी ने इस प्रयोग को साबित या खारिज करने के लिए पूरे एक दिन का काम मिटाने पर सहमति नहीं दी है
पहले, जब मैं कहीं ज़्यादा धैर्यवान था, मेरा एक बॉस था जो हर रात सभी code changes की समीक्षा करता था और जो पसंद नहीं आता था उसे delete कर देता था
उस बॉस का मानना था कि version control जरूरत से ज्यादा जटिल है, इसलिए वह अपने घर के network drive पर remote access को कंपनी standard बनाना चाहता था
इसलिए कभी-कभी अगले दिन ऑफिस आने पर पिछले दिन का काम मिटा हुआ मिलता था, और आखिरकार चुपके से SVN install करने तक मैं पिछले दिन का काम फिर से बनाने में काफी माहिर हो गया था
edge case tests शामिल करने पर भी इसमें शायद ही कभी एक घंटे से ज्यादा लगता था
पहली job में कुछ trauma जैसा हो गया था, इसलिए दूसरी job में मैंने तुरंत पूछा कि क्या Git repository है; बॉस ने Git को Github जैसा ही समझा और कहा कि वे code public नहीं करना चाहते
बाद में एक बड़ी कंपनी ने हमें acquire किया और मुझे intranet access मिला; उसके अंदर मैंने एक GitLab instance ढूंढा, अपने ज्यादातर अकेले किए जाने वाले code को वहीं version control और document किया, और GitLab Runner तक install किया
code चलाने का तरीका भी step-by-step document कर दिया था, और जब मुझे निकाला गया तो उन्होंने code hand over करने को कहा; मैंने सब दिखाया और reproduce करने का तरीका बताया, तो बॉस काफी प्रभावित हुआ और उसने धन्यवाद कहा
शायद एक खराब workplace में भी जिस तरीके को मैं सही मानता था उसे आगे बढ़ाने की वजह से थोड़ा अच्छा असर छोड़ पाया
उस GitLab को ढूंढने से पहले मैंने network share पर एक bare Git repository बनाई थी और उसी में push करता था
इरादा अच्छा हो तब भी, manager का code या review में शामिल होना लगभग हमेशा team के लिए net loss होता है
यह non-programmers को भेजने के लिए अच्छा लेख है
जैसे programmer को domain knowledge चाहिए, वैसे ही programmer से कुछ हासिल करना चाहने वाले व्यक्ति को भी programming थोड़ी समझनी चाहिए
बहुत छोटा diff भी debugging, design और learning की वजह से कई घंटे ले सकता है
output की मात्रा देखकर प्रभावित न होना आसान है, लेकिन किसी से समझ लेना और खुद कई घंटे दीवार पर सिर पटकते हुए समझना, दोनों बिल्कुल अलग चीजें हैं
performance को 100 गुना सुधारने वाला one-line commit ढूंढने में कई दिन लग जाते हैं, और साथ ही sync meeting में यह भी समझाना पड़ता है कि ticket आगे क्यों नहीं बढ़ रहा
इसलिए domain knowledge ही मुख्य चीज है
मैंने finance sector में काम करते हुए trading desk पर बैठकर कई exchanges देखे हैं और तरह-तरह की strategies implement करने वाला code लिखा है
अगर आपको नहीं पता कि business को क्या करना चाहिए, तो आप यह भी नहीं सोच सकते कि computer को क्या करना चाहिए
इस नज़रिए से coders को translators की तरह train करना समझ में आता है
मेरा translator दोस्त कई भाषाओं की grammar और idioms अच्छी तरह जानता है और नई भाषा भी वैसे ही सीखता है जैसे हम नई programming language सीखते हैं, लेकिन उसने pharmaceutical industry के बारे में भी काफी समय लगाकर सीखा, और अब medical documents translate करता है
lawyers और accountants भी ऐसे पेशे हैं जिनमें language barrier होता है
expert बनने पर आप law, accounting और software की भाषा सीखते हैं, लेकिन अच्छा expert professional jargon में नहीं, business language में जवाब देता है
कम अच्छे lawyer legal terms में हर संभव outcome बता देते हैं और फैसला आपके ऊपर छोड़ देते हैं, लेकिन अच्छा lawyer कहता है कि मामूली संभावनाएं बहुत हो सकती हैं, फिर भी व्यवहार में इसी स्थिति वाले customers इस business goal की वजह से सभी X करते हैं
मेरी पहली trading job में एक trader ने Excel VBA module बनाया था, जिससे stocks scan करके trading candidates खोजने की प्रक्रिया चलती थी
version control नहीं था, सिर्फ disk पर save की हुई files थीं; एक नए व्यक्ति ने कुछ ही हफ्तों में वह पूरा VBA module मिटाकर save कर दिया, और न backup था न IT की मदद
उस trader का चेहरा लाल हो गया, फिर वह शांत हुआ, यह मान लिया कि backup होना चाहिए था और VBA में कर ही क्या रहा था, और बैठकर पूरा module फिर से ऐसे type किया जैसे 80s के terminal screen पर अक्षर एक-एक करके छप रहे हों
मेरा विश्वास है कि अच्छा समाधान बनाने के लिए पहले उस domain में experience होना चाहिए
अभी मैं अपना ज्यादातर समय नए domain का experience पाने में लगा रहा हूं, और जरूरी knowledge जल्दी बनाने के लिए domain expert के बगल में बैठता हूं
वे मेरे जैसे background वाले व्यक्ति के बजाय 15 साल से accounting-related software बना रहे software engineer को पसंद करती हैं, और उसे किसी accountant से 30 मिनट बात करा देना चुनती हैं
बार-बार ऐसे prescriptions दिखते हैं कि programming को अनिवार्य रूप से किसी एक ही तरीके से काम करना चाहिए, लेकिन subfields के हिसाब से काम के प्रकार बहुत अलग होते हैं
हर field पर लागू होने वाली perfect single methodology सीखने या सिखाने की कोशिश करने के बजाय, मेरे हिसाब से कई approaches और methodologies वाली toolbag रखना और यह समझना बेहतर है कि कौन-सी कब अच्छी बैठती है
इसलिए industry बदलते हुए transfer हो सकने वाली general programming skills पर ध्यान देना पड़ता है
Bjarne की PPP किताब[0] की शुरुआत में भी कुछ ऐसा ही आता है
भाव यह है कि “सबसे अच्छे programmers भी, खासकर सबसे अच्छे programmers, अपना ज़्यादातर समय code लिखने में नहीं बल्कि problem को समझने में लगाते हैं. problem को समझने में गंभीर समय लगता है और अक्सर काफी बौद्धिक मेहनत चाहिए होती है. कई programmers जब कहते हैं कि programming दिलचस्प है, तो वे इसी intellectual challenge की बात कर रहे होते हैं”
हाल ही में front page पर आई[2] नई edition[1] भी मैंने खरीद ली
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
कौन-सा database इस्तेमाल करें, कौन-सी language सबसे अच्छी है, code और database में null allow करें या नहीं, API format, log format जैसी चीज़ें
ये खास दिलचस्प भी नहीं हैं और कभी-कभी इन्हें फिर से देखना ज़रूरी होता है, लेकिन पिछली तीन companies में ऐसे जो time sinks देखे, उनमें से ज़्यादातर ऐसे मुद्दे लगे जो पहले ही solve हो चुके होने चाहिए थे
सच तो यह है कि अगर company की कोई मजबूत सोच हो, तो वह संदिग्ध लगे तब भी कहीं ज़्यादा productive हो सकती है
अगर यह तय कर दिया गया होता कि Perl, MongoDB, CGI ही इस्तेमाल करने हैं, तो लगता है उस stack के बावजूद मैं हाल के मुकाबले ज़्यादा productive होता
“programming ज़्यादातर सोचना है” उन वाक्यों में से है जिन्हें हम खुद से किसी गहरी सच्चाई की तरह कहते हैं, लेकिन observation के तौर पर यह बहुत productive नहीं है
programming का सोच होना ठीक उसी अर्थ में है जिसमें हर knowledge work सोच है
design भी ज़्यादातर सोच है, accounting भी ज़्यादातर सोच है, और management भी काफी हद तक सोच है
meaningful फर्क सोच में नहीं, बल्कि किस बारे में सोचते हैं इसमें है
managers को लोगों से जुड़ी समस्याएं debug करनी होती हैं, इसलिए उन्हें लोगों के साथ काफी समय चाहिए होता है, यानी meetings
developers को computer problems debug करनी होती हैं, इसलिए उन्हें computer के साथ काफी समय चाहिए होता है
इसमें साफ tension है और कोई भी extreme काम नहीं करता, इसलिए ऐसा balance ढूंढना होगा जिससे हम एक-दूसरे के काम में कम बाधा डालें
मैं कोई उलझा हुआ code-golf style code नहीं कह रहा, बल्कि इस लिहाज से कि जो भी हम produce करते हैं उसे maintain करना पड़ता है
यह स्पष्ट रूप से novelist से अलग है, जिसे शायद maintenance में खास रुचि नहीं होती और text से पैदा होने वाली भावनाओं की ज़्यादा चिंता होती है
“job के दौरान learning को experiment करके ऐसा system कैसे बनाएं जिसमें thinking optimize हो?” का सबसे अच्छा optimization है interruptions कम करना
research के मुताबिक interruptions का programming पर विनाशकारी असर होता है
interruption के बाद काम दोबारा शुरू करने में 10–15 मिनट लगते हैं, programmer को दिन में शायद सिर्फ एक ही 2 घंटे का uninterrupted session मिलता है, और edit/search/understand करते समय interrupt करना सबसे खराब timing है
सोचता हूं कि क्या ऐसी interruptions को track करके दिखाने का कोई तरीका है
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
लेकिन developers से उम्मीद की जाती है कि वे endless meetings, Slack/Zoom के छोटे-छोटे pings और syncs के बीच कई घंटों वाला coding task पूरा करें
कभी-कभी जब weekend पर घर से काम करना पड़ा, तो देखा कि बिना interruption वाले weekend के काम की quality, chaotic weekdays से कहीं बेहतर होती है
यह सभी के लिए सही नहीं, हर case में भी सही नहीं, और बाकी 20% दिन में काम करने वालों के साथ coordination है, लेकिन कई घंटों तक चलने वाले अच्छे uninterrupted sessions से मिलने वाली productivity की तुलना नहीं हो सकती
फिर कहूंगा, यह हर किसी के लिए—शायद ज़्यादातर लोगों के लिए—सही तरीका नहीं है
घर पर कोई मुझे interrupt नहीं करता, और interruption आए भी तो मैं खुद तय कर सकता हूं कि कब respond करना है
खासकर किसी कठिन problem पर काम करते हुए हर 10–20 मिनट में interruption आए तो उसे छोड़ देना ही बेहतर है, नहीं तो बाद में headache देने वाला गंदा code बनाने की संभावना बड़ी होती है
इसे privacy का सम्मान करने के लिए design किया गया था: यह record करता था कि web browser इस्तेमाल हुआ, लेकिन यह नहीं कि specific URL company intranet था या fb.com
कभी-कभी popup से users अपनी productivity खुद rate करते और free text में comment छोड़ते; और ताकि लोग superhuman दिखने के लिए झूठ न बोलें, इसे user ID से link नहीं किया गया था
हमने Windows frontend और Scala backend बनाया और developers, lawyers, finance staff सहित volunteers के group में deploy किया, लेकिन पहली data analysis के बाद जब चीज़ें interesting होने लगीं तभी time और budget खत्म हो गया, इसलिए इसे paper के रूप में publish नहीं कर पाए
Rescue Time( https://www.rescuetime.com/
) जैसे existing tools भी देखे, लेकिन internal productivity data को external cloud में store करना acceptable नहीं लगा
अच्छी programming कभी-कभी ज़्यादातर सोच होती है, लेकिन “कोई भी plan दुश्मन से पहली भिड़ंत के बाद नहीं बचता” वाली बात सही है
practical programming, planning और IDE में code चलाकर देखने का सोच-समझकर किया गया combination है, और इसका balance use case के हिसाब से बदलना चाहिए
अगर आप कई दिनों तक code नहीं लिख रहे, तो या तो आपको problem surface पूरी तरह पता है, या आप बस guess कर रहे हैं
अगर दूसरी बात है, तो सोचने के लिए बहुत कुछ नहीं है
दूसरी बार तेज़ हो जाता है
मैं सहमत हूं कि thinking को “tools की मदद वाली thinking” तक expand किया जा सकता है
यह Peter Naur के Programming as Theory Building को दोहराने वाली अभिव्यक्ति है, और प्रोग्रामिंग के सार को समझने में मेरे लिए निर्णायक रही
प्रोग्रामिंग खुद प्रोग्राम बनाने का काम नहीं है, बल्कि दुनिया के कामों के बारे में एक खास insight विकसित करने का काम है, और अंत में जो code output होता है, वह आपके बनाए गए theory की बस एक सरल अभिव्यक्ति भर होता है