किसी के दिमाग में एक प्रोग्राम रखना

अगस्त 2007

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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