किसी प्रोग्राम को अपने दिमाग में रखना
अगस्त 2007
एक अच्छा प्रोग्रामर जो अपने कोड पर गहनता से काम कर रहा है, उसे अपने दिमाग में उसी तरह रख सकता है जैसे एक गणितज्ञ किसी समस्या को हल करने के लिए रखता है। गणितज्ञ स्कूली बच्चों को सिखाए जाने वाले तरीके से कागज़ पर हल करके सवालों के जवाब नहीं देते हैं। वे अपने दिमाग में ज़्यादा काम करते हैं: वे किसी समस्या के क्षेत्र को इतनी अच्छी तरह समझने की कोशिश करते हैं कि वे उसमें उसी तरह घूम सकें जैसे आप उस घर की यादों में घूम सकते हैं जिसमें आप बड़े हुए थे। अपने सर्वोत्तम रूप में प्रोग्रामिंग भी ऐसी ही है। आप पूरे प्रोग्राम को अपने दिमाग में रखते हैं, और आप उसे अपनी मर्ज़ी से बदल सकते हैं।
यह किसी प्रोजेक्ट की शुरुआत में विशेष रूप से मूल्यवान होता है, क्योंकि शुरुआत में सबसे महत्वपूर्ण बात यह है कि आप जो कर रहे हैं उसे बदलने में सक्षम हों। न केवल समस्या को एक अलग तरीके से हल करने के लिए, बल्कि उस समस्या को बदलने के लिए जिसे आप हल कर रहे हैं।
आपका कोड उस समस्या की आपकी समझ है जिसे आप खोज रहे हैं। इसलिए यह तभी होता है जब आपका कोड आपके दिमाग में होता है कि आप समस्या को वास्तव में समझते हैं।
किसी प्रोग्राम को अपने दिमाग में उतारना आसान नहीं है। यदि आप कुछ महीनों के लिए किसी प्रोजेक्ट को छोड़ देते हैं, तो जब आप उस पर वापस आते हैं तो उसे फिर से समझने में दिन लग सकते हैं। यहां तक कि जब आप सक्रिय रूप से किसी प्रोग्राम पर काम कर रहे होते हैं तो हर दिन काम शुरू करने पर उसे अपने दिमाग में लोड करने में आधा घंटा लग सकता है। और यह सबसे अच्छी स्थिति में है। सामान्य प्रोग्रामर जो सामान्य कार्यालय की परिस्थितियों में काम करते हैं, वे कभी भी इस मोड में प्रवेश नहीं करते हैं। या इसे और अधिक नाटकीय रूप से कहें तो, सामान्य प्रोग्रामर जो सामान्य कार्यालय की परिस्थितियों में काम करते हैं, वे उन समस्याओं को कभी भी वास्तव में नहीं समझते हैं जिन्हें वे हल कर रहे हैं।
यहां तक कि सबसे अच्छे प्रोग्रामर भी हमेशा अपने दिमाग में वह पूरा प्रोग्राम नहीं रखते हैं जिस पर वे काम कर रहे होते हैं। लेकिन ऐसी चीजें हैं जो आप मदद के लिए कर सकते हैं:
- ध्यान भंग करने से बचें। ध्यान भंग करना कई प्रकार के काम के लिए बुरा है, लेकिन प्रोग्रामिंग के लिए विशेष रूप से बुरा है, क्योंकि प्रोग्रामर उस विवरण की सीमा पर काम करते हैं जिसे वे संभाल सकते हैं।
किसी ध्यान भंग का खतरा उसकी अवधि पर निर्भर नहीं करता है, बल्कि इस बात पर निर्भर करता है कि यह आपके दिमाग को कितना अस्त-व्यस्त करता है। एक प्रोग्रामर कार्यालय छोड़कर सैंडविच लेने जा सकता है और अपने दिमाग में कोड खोए बिना वापस आ सकता है। लेकिन गलत तरह का व्यवधान 30 सेकंड में आपके दिमाग को मिटा सकता है।
अजीब बात है कि निर्धारित ध्यान भंग अनियोजित ध्यान भंग से भी बदतर हो सकते हैं। यदि आप जानते हैं कि एक घंटे में आपकी बैठक है, तो आप किसी कठिन चीज़ पर काम करना शुरू भी नहीं करते हैं।
- लंबे समय तक काम करें। चूंकि हर बार जब आप किसी प्रोग्राम पर काम करना शुरू करते हैं तो एक निश्चित लागत होती है, इसलिए कई छोटे सत्रों के बजाय कुछ लंबे सत्रों में काम करना अधिक कुशल होता है। निश्चित रूप से एक बिंदु आएगा जब आप थक जाने के कारण मूर्ख हो जाएंगे। यह व्यक्ति से व्यक्ति में भिन्न होता है। मैंने लोगों को 36 घंटे लगातार हैकिंग करते सुना है, लेकिन मैं सबसे अधिक जो प्रबंधित कर पाया हूं वह लगभग 18 घंटे है, और मैं 12 घंटे से अधिक के टुकड़ों में सबसे अच्छा काम करता हूं।
अनुकूलतम वह सीमा नहीं है जिसे आप शारीरिक रूप से सहन कर सकते हैं। किसी प्रोजेक्ट को तोड़ने के फायदे के साथ-साथ लागत भी होती है। कभी-कभी जब आप आराम के बाद किसी समस्या पर वापस आते हैं, तो आपको पता चलता है कि आपके अवचेतन मन ने आपके लिए एक उत्तर छोड़ दिया है।
- संक्षिप्त भाषाओं का प्रयोग करें। अधिक शक्तिशाली प्रोग्रामिंग भाषाएं प्रोग्राम को छोटा बनाती हैं। और प्रोग्रामर प्रोग्राम को कम से कम आंशिक रूप से उस भाषा में सोचते हैं जिसका उपयोग वे उन्हें लिखने के लिए कर रहे हैं। भाषा जितनी संक्षिप्त होगी, प्रोग्राम उतना ही छोटा होगा, और उसे अपने दिमाग में लोड करना और रखना उतना ही आसान होगा।
आप बॉटम-अप प्रोग्रामिंग नामक एक शैली का उपयोग करके एक शक्तिशाली भाषा के प्रभाव को बढ़ा सकते हैं, जहां आप प्रोग्राम को कई परतों में लिखते हैं, निचली परतें ऊपर वालों के लिए प्रोग्रामिंग भाषाओं के रूप में कार्य करती हैं। यदि आप इसे सही ढंग से करते हैं, तो आपको केवल शीर्ष परत को अपने दिमाग में रखना होगा।
-
अपने प्रोग्राम को बार-बार लिखें। किसी प्रोग्राम को बार-बार लिखने से अक्सर एक स्वच्छ डिज़ाइन मिलता है। लेकिन अगर ऐसा नहीं भी होता तो भी इसके फायदे होते: आपको किसी प्रोग्राम को पूरी तरह से समझने के लिए उसे फिर से लिखना पड़ता है, इसलिए उसे अपने दिमाग में लोड करने का इससे बेहतर कोई तरीका नहीं है।
-
पठनीय कोड लिखें। सभी प्रोग्रामर जानते हैं कि पठनीय कोड लिखना अच्छा है। लेकिन आप स्वयं सबसे महत्वपूर्ण पाठक हैं। विशेष रूप से शुरुआत में; एक प्रोटोटाइप स्वयं के साथ एक बातचीत है। और जब अपने लिए लिख रहे हों तो आपकी प्राथमिकताएँ अलग होती हैं। यदि आप दूसरों के लिए लिख रहे हैं, तो आप कोड को बहुत सघन नहीं बनाना चाह सकते हैं। किसी प्रोग्राम के कुछ हिस्सों को पढ़ना सबसे आसान हो सकता है यदि आप चीजों को फैलाते हैं, जैसे कि एक परिचयात्मक पाठ्यपुस्तक। जबकि यदि आप कोड को अपने दिमाग में फिर से लोड करना आसान बनाने के लिए लिख रहे हैं, तो संक्षिप्तता के लिए जाना सबसे अच्छा हो सकता है।
-
छोटे समूहों में काम करें। जब आप अपने दिमाग में किसी प्रोग्राम में हेरफेर करते हैं, तो आपकी दृष्टि उस कोड के किनारे पर रुक जाती है जिसका आप मालिक हैं। अन्य भाग जिन्हें आप अच्छी तरह से नहीं समझते हैं, और अधिक महत्वपूर्ण बात, जिनके साथ आप स्वतंत्रता नहीं ले सकते। इसलिए प्रोग्रामर की संख्या जितनी कम होगी, एक प्रोजेक्ट उतना ही अधिक पूरी तरह से बदल सकता है। यदि केवल एक प्रोग्रामर है, जैसा कि अक्सर शुरुआत में होता है, तो आप सर्वव्यापी पुन: डिज़ाइन कर सकते हैं।
-
एक ही कोड के टुकड़े पर एक से अधिक लोगों को संपादन न करने दें। आप कभी भी दूसरों के कोड को अपने कोड की तरह अच्छी तरह से नहीं समझते हैं। चाहे आपने इसे कितनी भी अच्छी तरह से पढ़ा हो, आपने इसे केवल पढ़ा है, लिखा नहीं है। इसलिए यदि कोड का कोई टुकड़ा कई लेखकों द्वारा लिखा गया है, तो उनमें से कोई भी इसे उतना अच्छी तरह से नहीं समझता जितना एक लेखक समझेगा।
और निश्चित रूप से आप किसी ऐसी चीज़ को सुरक्षित रूप से फिर से डिज़ाइन नहीं कर सकते जिस पर अन्य लोग काम कर रहे हों। यह सिर्फ इतना नहीं है कि आपको अनुमति लेनी होगी। आप ऐसे विचारों को अपने दिमाग में आने भी नहीं देते हैं। कई लेखकों के साथ कोड को फिर से डिज़ाइन करना कानूनों को बदलने जैसा है; अकेले अपने नियंत्रण वाले कोड को फिर से डिज़ाइन करना एक अस्पष्ट छवि की दूसरी व्याख्या देखने जैसा है।
यदि आप किसी प्रोजेक्ट पर कई लोगों को काम करवाना चाहते हैं, तो उसे घटकों में विभाजित करें और प्रत्येक को एक व्यक्ति को सौंपें।
- छोटे से शुरू करें। जैसे-जैसे आप किसी प्रोग्राम से परिचित होते जाते हैं, उसे अपने दिमाग में रखना आसान होता जाता है। एक बार जब आप पूरी तरह से अन्वेषण कर चुके होते हैं तो आप भागों को ब्लैक बॉक्स के रूप में मानना शुरू कर सकते हैं। लेकिन जब आप पहली बार किसी प्रोजेक्ट पर काम करना शुरू करते हैं, तो आपको सब कुछ देखना पड़ता है। यदि आप बहुत बड़ी समस्या से शुरुआत करते हैं, तो आप शायद उसे कभी भी पूरी तरह से समझ नहीं पाएंगे। इसलिए यदि आपको एक बड़ा, जटिल प्रोग्राम लिखने की आवश्यकता है, तो शुरुआत करने का सबसे अच्छा तरीका यह हो सकता है कि आप उसके लिए एक विनिर्देश लिखें, बल्कि एक प्रोटोटाइप लिखें जो समस्या के एक उपसमूह को हल करता हो। योजना के जो भी फायदे हों, वे अक्सर उस क्षमता के फायदों से कम हो जाते हैं जो किसी प्रोग्राम को अपने दिमाग में रखने से मिलती है।
यह आश्चर्यजनक है कि प्रोग्रामर कितनी बार संयोग से सभी आठ बिंदुओं को हिट करने का प्रबंधन करते हैं। किसी को किसी नए प्रोजेक्ट का विचार आता है, लेकिन क्योंकि यह आधिकारिक तौर पर स्वीकृत नहीं है, उसे ऑफ-आवर्स में करना पड़ता है—जो कि कोई ध्यान भंग न होने के कारण अधिक उत्पादक साबित होते हैं। नए प्रोजेक्ट के प्रति अपने उत्साह से प्रेरित होकर वह इसे कई घंटों तक लगातार काम करता है। क्योंकि यह शुरू में सिर्फ एक प्रयोग है, "प्रोडक्शन" भाषा के बजाय वह केवल एक "स्क्रिप्टिंग" भाषा का उपयोग करता है—जो वास्तव में कहीं अधिक शक्तिशाली है। वह प्रोग्राम को कई बार पूरी तरह से फिर से लिखता है; यह एक आधिकारिक प्रोजेक्ट के लिए उचित नहीं होगा, लेकिन यह प्रेम का श्रम है और वह चाहता है कि यह एकदम सही हो। और चूंकि उसे छोड़कर कोई और इसे नहीं देखेगा, इसलिए वह नोट-टू-सेल्फ किस्म की टिप्पणी को छोड़कर कोई टिप्पणी नहीं छोड़ता है। वह मजबूरी में एक छोटे समूह में काम करता है, क्योंकि उसने अभी तक किसी और को इस विचार के बारे में नहीं बताया है, या यह इतना अप्रत्याशित लगता है कि किसी और को इस पर काम करने की अनुमति नहीं है। भले ही कोई समूह हो, वे एक ही कोड पर एक से अधिक लोगों को संपादन नहीं कर सकते थे, क्योंकि यह इतनी तेजी से बदलता है कि यह संभव नहीं है। और प्रोजेक्ट छोटे से शुरू होता है क्योंकि विचार शुरुआत में छोटा होता है; उसके पास बस कुछ कूल हैक है जिसे वह आज़माना चाहता है।
और भी अधिक आश्चर्यजनक उन आधिकारिक तौर पर स्वीकृत परियोजनाओं की संख्या है जो सभी आठ चीजों को गलत करने का प्रबंधन करती हैं। वास्तव में, यदि आप अधिकांश संगठनों में सॉफ्टवेयर लिखने के तरीके को देखते हैं, तो यह लगभग ऐसा है जैसे वे जानबूझकर चीजों को गलत करने की कोशिश कर रहे हों। एक मायने में, वे हैं। संगठनों की परिभाषित गुणों में से एक, जब से वे अस्तित्व में हैं, व्यक्तियों को विनिमेय भागों के रूप में मानना है। यह अधिक समानांतर करने योग्य कार्यों के लिए अच्छी तरह से काम करता है, जैसे युद्ध लड़ना। इतिहास के अधिकांश भाग के लिए एक अच्छी तरह से प्रशिक्षित पेशेवर सैनिकों की सेना व्यक्तिगत योद्धाओं की सेना को हराने पर भरोसा कर सकती है, चाहे वे कितने भी वीर क्यों न हों। लेकिन विचार रखना बहुत समानांतर करने योग्य नहीं है। और प्रोग्राम यही हैं: विचार।
यह केवल इतना सच नहीं है कि संगठन व्यक्तिगत प्रतिभा पर निर्भर रहने के विचार को नापसंद करते हैं, यह एक पुनरुक्ति है। यह संगठन की परिभाषा का हिस्सा है कि ऐसा न हो। कम से कम, संगठन की हमारी वर्तमान अवधारणा का।
शायद हम एक नए प्रकार के संगठन को परिभाषित कर सकते हैं जो व्यक्तियों के प्रयासों को बिना उन्हें विनिमेय होने की आवश्यकता के जोड़ता है। शायद एक बाजार संगठन का ऐसा रूप है, हालांकि यह वर्णन करना अधिक सटीक हो सकता है कि एक बाजार एक पतित मामला है—जैसा कि आपको डिफ़ॉल्ट रूप से मिलता है जब संगठन संभव नहीं होता है।
शायद सबसे अच्छा हम कुछ प्रकार का हैक करेंगे, जैसे कि किसी संगठन के प्रोग्रामिंग भागों को बाकी हिस्सों से अलग तरीके से काम करवाना। शायद इष्टतम समाधान यह है कि बड़ी कंपनियां घर में विचार विकसित करने की कोशिश भी न करें, बल्कि उन्हें बस खरीदें लें। लेकिन चाहे समाधान कुछ भी हो, पहला कदम यह महसूस करना है कि एक समस्या है। "सॉफ्टवेयर कंपनी" वाक्यांश में ही एक विरोधाभास है। दोनों शब्द विपरीत दिशाओं में खींच रहे हैं। किसी बड़े संगठन में कोई भी अच्छा प्रोग्रामर उससे अलग होगा, क्योंकि संगठन उन चीजों को रोकने के लिए डिज़ाइन किए गए हैं जिनके लिए प्रोग्रामर प्रयास करते हैं।
अच्छे प्रोग्रामर वैसे भी बहुत कुछ करने का प्रबंधन करते हैं। लेकिन अक्सर इसके लिए उन्हें नियोजित करने वाले संगठनों के खिलाफ विद्रोह का कार्य करना पड़ता है। शायद यह मदद करेगा यदि अधिक लोग समझें कि प्रोग्रामर जिस तरह से व्यवहार करते हैं वह उनके द्वारा किए जाने वाले काम की मांगों से प्रेरित होता है। यह इसलिए नहीं है कि वे गैर-जिम्मेदार हैं कि वे लंबे समय तक काम करते हैं जिसके दौरान वे अन्य सभी दायित्वों को छोड़ देते हैं, पहले विनिर्देश लिखने के बजाय सीधे प्रोग्रामिंग में कूद जाते हैं, और जो कोड पहले से काम कर रहा है उसे फिर से लिखते हैं। यह इसलिए नहीं है कि वे अमित्र हैं कि वे अकेले काम करना पसंद करते हैं, या उन लोगों पर गुर्राते हैं जो नमस्ते कहने के लिए सिर घुमाते हैं। आदतों के इस प्रतीत होने वाले यादृच्छिक संग्रह की एक ही व्याख्या है: किसी प्रोग्राम को अपने दिमाग में रखने की शक्ति।
चाहे यह समझना बड़ी कंपनियों की मदद करे या न करे, यह निश्चित रूप से उनके प्रतिस्पर्धियों की मदद कर सकता है। बड़ी कंपनियों में सबसे कमजोर बिंदु यह है कि वे व्यक्तिगत प्रोग्रामर को महान काम करने की अनुमति नहीं देते हैं। इसलिए यदि आप एक छोटी स्टार्टअप हैं, तो यहीं उन पर हमला करना है। उन समस्याओं को लें जिन्हें एक बड़े दिमाग में हल करने की आवश्यकता है।
धन्यवाद सैम अल्टमैन, डेविड ग्रीन्सपैन, आरोन इबा, जेसिका लिविंगस्टन, रॉबर्ट मॉरिस, पीटर नॉरविग, लिसा रैंडल, एमेट शीयर, सर्गेई त्सारेव, और स्टीफन वोल्फ्राम को इस लेख के ड्राफ्ट पढ़ने के लिए।