अपने दिमाग में एक कार्यक्रम रखना

अगस्त 2007

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

यह एक परियोजना की शुरुआत में विशेष रूप से मूल्यवान है, क्योंकि प्रारंभ में सबसे महत्वपूर्ण बात यह है कि आप जो कर रहे हैं उसे बदलने में सक्षम होना। न केवल समस्या को एक अलग तरीके से हल करने के लिए, बल्कि उस समस्या को बदलने के लिए जिसे आप हल कर रहे हैं।

आपका कोड उस समस्या की आपकी समझ है जिसे आप खोज रहे हैं। इसलिए यह केवल तब होता है जब आपके पास अपने दिमाग में आपका कोड होता है कि आप वास्तव में समस्या को समझते हैं।

अपने दिमाग में एक कार्यक्रम लाना आसान नहीं है। यदि आप किसी परियोजना को कुछ महीनों के लिए छोड़ देते हैं, तो जब आप वापस आते हैं तो इसे फिर से समझने में दिन लग सकते हैं। यहां तक कि जब आप सक्रिय रूप से एक कार्यक्रम पर काम कर रहे होते हैं, तो हर दिन काम शुरू करते समय इसे अपने दिमाग में लाने में आधा घंटा लग सकता है। और यह सबसे अच्छे मामले में है। सामान्य प्रोग्रामर जो सामान्य कार्यालय की परिस्थितियों में काम कर रहे हैं, कभी भी इस मोड में नहीं जाते। या इसे अधिक नाटकीय रूप से कहें, सामान्य प्रोग्रामर जो सामान्य कार्यालय की परिस्थितियों में काम कर रहे हैं, कभी भी वास्तव में उन समस्याओं को नहीं समझते हैं जिन्हें वे हल कर रहे हैं।

यहां तक कि सबसे अच्छे प्रोग्रामरों के पास हमेशा वह पूरा कार्यक्रम नहीं होता है जिस पर वे काम कर रहे हैं। लेकिन आप मदद करने के लिए कुछ चीजें कर सकते हैं:

विक्षेप से बचें। विक्षेप कई प्रकार के काम के लिए बुरे होते हैं, लेकिन प्रोग्रामिंग के लिए विशेष रूप से बुरे होते हैं, क्योंकि प्रोग्रामर आमतौर पर उस विवरण की सीमा पर काम करते हैं जिसे वे संभाल सकते हैं।

विक्षेप का खतरा इस पर निर्भर करता है कि यह कितना लंबा है, बल्कि इस पर कि यह आपके दिमाग को कितना उलझा देता है। एक प्रोग्रामर कार्यालय छोड़ सकता है और एक सैंडविच लेने जा सकता है बिना अपने दिमाग में कोड खोए। लेकिन गलत प्रकार का विघटन आपके दिमाग को 30 सेकंड में मिटा सकता है।

अजीब बात है, निर्धारित विक्षेप अनियोजित विक्षेपों से बदतर हो सकते हैं। यदि आप जानते हैं कि आपके पास एक घंटे में एक बैठक है, तो आप कुछ कठिन पर काम करना शुरू नहीं करते।

लंबे खिंचाव में काम करें। चूंकि हर बार जब आप एक कार्यक्रम पर काम करना शुरू करते हैं तो एक निश्चित लागत होती है, इसलिए कई छोटे सत्रों की तुलना में कुछ लंबे सत्रों में काम करना अधिक कुशल होता है। बेशक, एक बिंदु आएगा जब आप थकावट के कारण बेवकूफ बन जाएंगे। यह व्यक्ति से व्यक्ति में भिन्न होता है। मैंने सुना है कि लोग लगातार 36 घंटे हैकिंग करते हैं, लेकिन मैं जो सबसे अधिक प्रबंधित कर सका वह लगभग 18 घंटे है, और मैं 12 घंटे से अधिक के टुकड़ों में सबसे अच्छा काम करता हूं।

सर्वश्रेष्ठ वह नहीं है जिसे आप शारीरिक रूप से सहन कर सकते हैं। एक परियोजना को तोड़ने का एक लाभ और एक लागत होती है। कभी-कभी जब आप आराम के बाद किसी समस्या पर लौटते हैं, तो आप पाते हैं कि आपका अवचेतन मन आपके लिए एक उत्तर छोड़ चुका है।

संक्षिप्त भाषाओं का उपयोग करें। अधिक शक्तिशाली प्रोग्रामिंग भाषाएँ कार्यक्रमों को छोटा बनाती हैं। और प्रोग्रामर कम से कम आंशिक रूप से उन भाषाओं में कार्यक्रमों के बारे में सोचते हैं जिनका वे उन्हें लिखने के लिए उपयोग कर रहे हैं। जितनी संक्षिप्त भाषा होगी, कार्यक्रम उतना ही छोटा होगा, और इसे अपने दिमाग में लोड करना और बनाए रखना उतना ही आसान होगा।

आप एक शक्तिशाली भाषा के प्रभाव को एक शैली का उपयोग करके बढ़ा सकते हैं जिसे बॉटम-अप प्रोग्रामिंग कहा जाता है, जहां आप कई परतों में कार्यक्रम लिखते हैं, निचली परतें ऊपर की परतों के लिए प्रोग्रामिंग भाषाओं के रूप में कार्य करती हैं। यदि आप इसे सही करते हैं, तो आपको केवल सबसे ऊपरी परत को अपने दिमाग में रखना होगा।

अपने कार्यक्रम को फिर से लिखते रहें। एक कार्यक्रम को फिर से लिखने से अक्सर एक साफ डिजाइन मिलता है। लेकिन इसके फायदे होंगे भले ही ऐसा न हो: आपको इसे फिर से लिखने के लिए एक कार्यक्रम को पूरी तरह से समझना होगा, इसलिए इसे अपने दिमाग में लोड करने का इससे बेहतर तरीका नहीं है।

पुनः पढ़ने योग्य कोड लिखें। सभी प्रोग्रामर जानते हैं कि पढ़ने योग्य कोड लिखना अच्छा है। लेकिन आप स्वयं सबसे महत्वपूर्ण पाठक हैं। विशेष रूप से शुरुआत में; एक प्रोटोटाइप आपके साथ एक बातचीत है। और जब आप अपने लिए लिख रहे होते हैं तो आपकी प्राथमिकताएँ अलग होती हैं। यदि आप दूसरों के लिए लिख रहे हैं, तो आप कोड को बहुत घना नहीं बनाना चाह सकते हैं। कार्यक्रम के कुछ भाग पढ़ने में सबसे आसान हो सकते हैं यदि आप चीजों को फैलाते हैं, जैसे एक परिचयात्मक पाठ्यपुस्तक। जबकि यदि आप कोड लिख रहे हैं ताकि इसे अपने दिमाग में फिर से लोड करना आसान हो, तो संक्षिप्तता के लिए जाना सबसे अच्छा हो सकता है।

छोटे समूहों में काम करें। जब आप अपने दिमाग में एक कार्यक्रम को संचालित करते हैं, तो आपकी दृष्टि उस कोड के किनारे पर रुक जाती है जो आपके पास है। अन्य भागों को आप उतना अच्छी तरह से नहीं समझते हैं, और अधिक महत्वपूर्ण, आप उनके साथ स्वतंत्रता नहीं ले सकते। इसलिए जितने छोटे प्रोग्रामर होंगे, परियोजना उतनी ही पूरी तरह से बदल सकती है। यदि केवल एक प्रोग्रामर है, जैसा कि अक्सर पहले होता है, तो आप सभी-समावेशी पुन: डिज़ाइन कर सकते हैं।

एक ही कोड के एक ही टुकड़े को संपादित करने के लिए कई लोगों को न रखें। आप कभी भी दूसरों के कोड को अपने कोड की तरह अच्छी तरह से नहीं समझते हैं। चाहे आपने इसे कितनी भी अच्छी तरह से पढ़ा हो, आपने केवल इसे पढ़ा है, इसे नहीं लिखा है। इसलिए यदि एक कोड का टुकड़ा कई लेखकों द्वारा लिखा गया है, तो उनमें से कोई भी इसे एकल लेखक की तरह अच्छी तरह से नहीं समझता है।

और निश्चित रूप से आप किसी ऐसी चीज़ को सुरक्षित रूप से फिर से डिज़ाइन नहीं कर सकते जिस पर अन्य लोग काम कर रहे हैं। यह केवल इतना नहीं है कि आपको अनुमति मांगनी होगी। आप खुद को ऐसी चीजों के बारे में सोचने की भी अनुमति नहीं देते। कई लेखकों के साथ कोड को फिर से डिज़ाइन करना कानूनों को बदलने के समान है; केवल आप द्वारा नियंत्रित कोड को फिर से डिज़ाइन करना एक अस्पष्ट छवि की दूसरी व्याख्या देखने के समान है।

यदि आप कई लोगों को एक परियोजना पर काम करने के लिए रखना चाहते हैं, तो इसे घटकों में विभाजित करें और प्रत्येक को एक व्यक्ति को दें।

छोटे से शुरू करें। एक कार्यक्रम को अपने दिमाग में रखना आसान हो जाता है जब आप इसके साथ परिचित हो जाते हैं। आप भागों को काले बक्सों के रूप में मानना शुरू कर सकते हैं जब आप महसूस करते हैं कि आपने उन्हें पूरी तरह से खोज लिया है। लेकिन जब आप पहली बार किसी परियोजना पर काम करना शुरू करते हैं, तो आपको सब कुछ देखने के लिए मजबूर किया जाता है। यदि आप बहुत बड़ी समस्या से शुरू करते हैं, तो आप शायद इसे कभी पूरी तरह से नहीं समझ पाएंगे। इसलिए यदि आपको एक बड़ा, जटिल कार्यक्रम लिखने की आवश्यकता है, तो शुरू करने का सबसे अच्छा तरीका इसे लिखने के लिए एक स्पेक नहीं है, बल्कि एक प्रोटोटाइप लिखना है जो समस्या के एक उपसमुच्चय को हल करता है। योजना के फायदे जो भी हों, वे अक्सर इस बात के फायदों से अधिक होते हैं कि आप एक कार्यक्रम को अपने दिमाग में रख सकें।

यह आश्चर्यजनक है कि प्रोग्रामर कितनी बार सभी आठ बिंदुओं को दुर्घटनावश हिट करने में सफल होते हैं। किसी के पास एक नए प्रोजेक्ट के लिए एक विचार है, लेकिन क्योंकि यह आधिकारिक रूप से स्वीकृत नहीं है, उसे इसे ऑफ़ आवर्स में करना पड़ता है—जो अधिक उत्पादक साबित होता है क्योंकि कोई विक्षेप नहीं होते। नए प्रोजेक्ट के प्रति अपने उत्साह से प्रेरित होकर वह कई घंटों तक काम करता है। क्योंकि यह प्रारंभ में केवल एक प्रयोग है, "उत्पादन" भाषा के बजाय वह केवल एक "स्क्रिप्टिंग" भाषा का उपयोग करता है—जो वास्तव में कहीं अधिक शक्तिशाली है। वह कार्यक्रम को कई बार पूरी तरह से फिर से लिखता है; यह एक आधिकारिक परियोजना के लिए उचित नहीं होगा, लेकिन यह एक प्रेम का श्रम है और वह इसे परिपूर्ण बनाना चाहता है। और चूंकि इसे छोड़कर कोई और इसे नहीं देखेगा, वह केवल स्वयं के लिए नोट्स के अलावा कोई टिप्पणी छोड़ता है। वह मजबूरन एक छोटे समूह में काम करता है, क्योंकि उसने अभी तक किसी और को विचार के बारे में नहीं बताया है, या यह इतना निराशाजनक लगता है कि किसी और को उस पर काम करने की अनुमति नहीं है। यहां तक कि यदि एक समूह है, तो वे एक ही कोड को संपादित करने के लिए कई लोगों को नहीं रख सकते, क्योंकि यह बहुत तेजी से बदलता है कि यह संभव नहीं है। और परियोजना छोटी शुरू होती है क्योंकि विचार छोटा होता है; उसके पास केवल कुछ कूल हैक है जिसे वह आजमाना चाहता है।

यह और भी आश्चर्यजनक है कि कितनी आधिकारिक स्वीकृत परियोजनाएँ सभी आठ चीजें गलत करने में सफल होती हैं। वास्तव में, यदि आप अधिकांश संगठनों में सॉफ़्टवेयर लिखने के तरीके को देखते हैं, तो ऐसा लगता है जैसे वे जानबूझकर गलत करने की कोशिश कर रहे हैं। एक अर्थ में, वे हैं। संगठनों की एक परिभाषित विशेषता तब से है जब से ऐसी कोई चीज़ है, व्यक्तियों को इंटरचेंज योग्य भागों के रूप में मानना। यह अधिक समानांतर कार्यों के लिए अच्छी तरह से काम करता है, जैसे युद्ध लड़ना। अधिकांश इतिहास के लिए, एक अच्छी तरह से प्रशिक्षित पेशेवर सैनिकों की सेना को व्यक्तिगत योद्धाओं की सेना को हराने के लिए गिना जा सकता था, चाहे वे कितने भी वीर क्यों न हों। लेकिन विचार रखना बहुत समानांतर नहीं है। और यही कार्यक्रम हैं: विचार।

यह केवल सच नहीं है कि संगठन व्यक्तिगत प्रतिभा पर निर्भर होने के विचार को पसंद नहीं करते, यह एक तात्कालिकता है। यह एक संगठन की परिभाषा का हिस्सा है कि ऐसा न हो। हमारे वर्तमान संगठन के विचार का, कम से कम।

शायद हम एक नए प्रकार के संगठन को परिभाषित कर सकते हैं जो व्यक्तियों के प्रयासों को बिना उन्हें इंटरचेंज करने की आवश्यकता के संयोजित करता है। तर्कसंगत रूप से एक बाजार ऐसा संगठन का एक रूप है, हालांकि इसे एक विकृत मामले के रूप में वर्णित करना अधिक सटीक हो सकता है—जैसा कि आप डिफ़ॉल्ट रूप से प्राप्त करते हैं जब संगठन संभव नहीं होता।

संभवतः हम जो सबसे अच्छा करेंगे वह कुछ प्रकार का हैक है, जैसे कि एक संगठन के प्रोग्रामिंग भागों को बाकी से अलग तरीके से काम करना। शायद सबसे अच्छा समाधान यह है कि बड़ी कंपनियाँ घर में विचार विकसित करने की कोशिश भी न करें, बल्कि बस उन्हें खरीदें। लेकिन चाहे समाधान जो भी हो, पहला कदम यह समझना है कि एक समस्या है। "सॉफ़्टवेयर कंपनी" वाक्यांश में एक विरोधाभास है। ये दो शब्द विपरीत दिशाओं में खींच रहे हैं। एक बड़ी संगठन में कोई भी अच्छा प्रोग्रामर इसके साथ संघर्ष करने वाला होगा, क्योंकि संगठन उन चीजों को रोकने के लिए डिज़ाइन किए गए हैं जिनकी प्रोग्रामर कोशिश करते हैं।

अच्छे प्रोग्रामर फिर भी बहुत कुछ करने में सफल होते हैं। लेकिन अक्सर इसके लिए उन संगठनों के खिलाफ एक प्रकार की विद्रोह की आवश्यकता होती है जो उन्हें रोजगार देते हैं। शायद यह मदद करेगा यदि अधिक लोग समझें कि प्रोग्रामरों का व्यवहार उस काम की मांगों द्वारा संचालित होता है जो वे करते हैं। यह इसलिए नहीं है कि वे गैर-जिम्मेदार हैं कि वे लंबे समय तक काम करते हैं जिनमें वे सभी अन्य दायित्वों को छोड़ देते हैं, पहले स्पेक लिखने के बजाय सीधे प्रोग्रामिंग में कूदते हैं, और पहले से काम करने वाले कोड को फिर से लिखते हैं। यह इसलिए नहीं है कि वे असामाजिक हैं कि वे अकेले काम करना पसंद करते हैं, या उन लोगों पर गरजते हैं जो दरवाजे में सिर डालकर नमस्ते कहते हैं। यह स्पष्ट रूप से यादृच्छिक रूप से परेशान करने वाली आदतों का एक संग्रह एक ही स्पष्टीकरण है: अपने दिमाग में एक कार्यक्रम रखने की शक्ति।

यह समझना कि क्या यह बड़े संगठनों की मदद कर सकता है, निश्चित रूप से उनके प्रतिस्पर्धियों की मदद कर सकता है। बड़ी कंपनियों में सबसे कमजोर बिंदु यह है कि वे व्यक्तिगत प्रोग्रामरों को महान काम करने की अनुमति नहीं देते हैं। इसलिए यदि आप एक छोटी स्टार्टअप हैं, तो यह उन पर हमला करने का स्थान है। उस प्रकार की समस्याओं का सामना करें जिन्हें एक बड़े दिमाग में हल करने की आवश्यकता होती है।

धन्यवाद सैम आल्टमैन, डेविड ग्रीनस्पैन, एरोन इबा, जेसिका लिविंगस्टन, रॉबर्ट मॉरिस, पीटर नॉर्विग, लिसा रैंडल, एम्मेट शियर, सर्गेई त्सारेव, और स्टीफन वोल्फ्राम को इस के ड्राफ्ट पढ़ने के लिए।