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

अगस्त 2007

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

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

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

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

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

ध्यान भटकाने वाली चीज़ों से बचें। ध्यान भटकाने वाली चीज़ें कई तरह के कामों के लिए बुरी होती हैं, लेकिन प्रोग्रामिंग के लिए ये चीज़ें खास तौर पर बुरी होती हैं, क्योंकि प्रोग्रामर अपनी क्षमता के हिसाब से काम करते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह सिर्फ़ सच नहीं है कि संगठन व्यक्तिगत प्रतिभा पर निर्भर होने के विचार को नापसंद करते हैं, यह एक पुनरुक्ति है। यह संगठन की परिभाषा का हिस्सा है कि ऐसा न किया जाए। कम से कम संगठन की हमारी मौजूदा अवधारणा में तो ऐसा ही है।

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

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

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

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

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