हैकर्स और पेंटर्स

मई 2003

(यह निबंध हार्वर्ड में एक अतिथि व्याख्यान से प्राप्त है, जिसमें पूर्व में नॉर्थईस्टर्न में दिए गए एक वक्तव्य शामिल था.)

जब मैंने कंप्यूटर विज्ञान में स्नातकोत्तर की पढ़ाई पूरी की, तो मैं पेंटिंग सीखने के लिए कला स्कूल गया. कई लोगों को यह आश्चर्य हुआ कि कंप्यूटर में रुचि रखने वाला कोई व्यक्ति पेंटिंग में भी रुचि रखता हो. उन्हें लगता था कि हैकिंग और पेंटिंग बिल्कुल अलग प्रकार के कार्य हैं - कि हैकिंग ठंडा, सटीक और व्यवस्थित है, जबकि पेंटिंग किसी प्राथमिक प्रेरणा का उन्मत्त प्रकटीकरण है.

ये दोनों छवियां गलत हैं. हैकिंग और पेंटिंग में बहुत कुछ समान है. वास्तव में, मैंने जिन विभिन्न प्रकार के लोगों को जाना है, उनमें से हैकर और पेंटर सबसे अधिक समान हैं.

जो कुछ हैकर और पेंटर साझा करते हैं, वह यह है कि वे दोनों निर्माता हैं. रचनाकारों, वास्तुकारों और लेखकों के साथ, हैकर और पेंटर दोनों अच्छी चीजें बनाने का प्रयास कर रहे हैं. वे वास्तव में शोध नहीं कर रहे हैं, हालांकि यदि अच्छी चीजें बनाने की कोशिश करते हुए वे कोई नई तकनीक खोज लेते हैं, तो उतना ही बेहतर.

मुझे "कंप्यूटर विज्ञान" शब्द कभी भी पसंद नहीं आया है. इसका मुख्य कारण यह है कि ऐसा कुछ भी नहीं है. कंप्यूटर विज्ञान इतिहास की एक दुर्घटना के कारण एक साथ जोड़ दिए गए कुछ ढीले संबंधित क्षेत्रों का एक झुंड है, जैसे कि यूगोस्लाविया.

एक छोर पर आप ऐसे लोग हैं जो वास्तव में गणितज्ञ हैं, लेकिन जो कुछ वे कर रहे हैं उसे कंप्यूटर विज्ञान कहते हैं ताकि वे DARPA अनुदान प्राप्त कर सकें. बीच में आप ऐसे लोग हैं जो कंप्यूटरों के प्राकृतिक इतिहास पर काम कर रहे हैं - उदाहरण के लिए, नेटवर्क में डेटा के रूटिंग के लिए एल्गोरिदम के व्यवहार का अध्ययन कर रहे हैं. और फिर दूसरे छोर पर आप हैकर हैं, जो दिलचस्प सॉफ्टवेयर लिखने का प्रयास कर रहे हैं, और जिनके लिए कंप्यूटर केवल एक अभिव्यक्ति का माध्यम हैं, जैसे कि वास्तुकारों के लिए कंक्रीट या पेंटरों के लिए पेंट. यह ऐसा है जैसे गणितज्ञ, भौतिकविद और वास्तुकार सभी एक ही विभाग में होने.

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

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

शायद एक दिन "कंप्यूटर विज्ञान" को, जैसे कि यूगोस्लाविया को, इसके घटकों में विभाजित कर दिया जाएगा. यह अच्छी बात हो सकती है. खासकर अगर इसका मतलब मेरे मूल देश, हैकिंग, की स्वतंत्रता हो.

इन सभी अलग-अलग प्रकार के कार्यों को एक विभाग में एक साथ रखना प्रशासनिक रूप से सुविधाजनक हो सकता है, लेकिन बौद्धिक रूप से यह भ्रामक है. यही दूसरा कारण है कि मुझे "कंप्यूटर विज्ञान" नाम पसंद नहीं है.

गणितज्ञों को इससे कोई परेशानी नहीं है. वे खुशी-खुशी गणितज्ञों की तरह प्रमेय साबित करने में लग जाते हैं, जो कि गणित विभाग में काम करते हैं, और शायद जल्द ही यह भूल जाते हैं कि वे जिस इमारत में काम करते हैं, उस पर "कंप्यूटर विज्ञान" लिखा है. लेकिन हैकरों के लिए यह लेबल एक समस्या है. यदि उनके द्वारा किया जा रहा कार्य विज्ञान कहलाता है, तो उन्हें लगता है कि उन्हें वैज्ञानिक की तरह व्यवहार करना चाहिए.

इसलिए बजाय उसका करने का जो वे वास्तव में करना चाहते हैं, यानी सुंदर सॉफ्टवेयर डिजाइन करना, विश्वविद्यालयों और अनुसंधान प्रयोगशालाओं के हैकर अनुसंधान पत्र लिखने में लग जाते हैं.

सर्वश्रेष्ठ मामले में, पत्र केवल एक औपचारिकता हैं. हैकर कूल सॉफ्टवेयर बनाते हैं, और फिर उसके बारे में एक पत्र लिखते हैं, और पत्र उस उपलब्धि का प्रतिनिधित्व करता है जिसे सॉफ्टवेयर द्वारा दर्शाया गया है. लेकिन अक्सर यह असंगति समस्याएं पैदा करती है. सुंदर चीजें बनाने से दूर हटकर, उग्र चीजें बनाने की ओर जाना आसान है जो अनुसंधान पत्रों के लिए अधिक उपयुक्त विषय बन जाती हैं.

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

सुंदर कुछ बनाने का तरीका अक्सर किसी मौजूदा चीज में सूक्ष्म संशोधन करना या मौजूदा विचारों को थोड़ा नया तरीके से जोड़ना होता है. इस तरह का कार्य एक अनुसंधान पत्र में बताना मुश्किल होता है.

तो फिर विश्वविद्यालय और अनुसंधान प्रयोगशालाएं हैकरों का मूल्यांकन प्रकाशनों के आधार पर क्यों करती हैं? इसी कारण से कि "शैक्षिक योग्यता" का मापन सरल-मानक परीक्षणों से किया जाता है, या प्रोग्रामरों की उत्पादकता पंक्तियों की संख्या से मापी जाती है. ये परीक्षण लागू करने में आसान हैं, और कोई भी आसान परीक्षण जो कुछ काम करता है, उससे अधिक लोभनीय कुछ नहीं है.

हैकरों द्वारा वास्तव में क्या किया जा रहा है, सुंदर सॉफ्टवेयर डिजाइन करना, उसका मूल्यांकन करना बहुत अधिक कठिन होगा. आपको डिजाइन की अच्छी समझ [1] होनी चाहिए ताकि अच्छे डिजाइन का मूल्यांकन कर सकें. और लोगों की क्षमता और उनके विश्वास के बीच, शायद कुछ नकारात्मक सहसंबंध को छोड़कर, कोई सहसंबंध नहीं है.

एकमात्र बाहरी परीक्षण समय है. समय के साथ, सुंदर चीजें प्रगति करती हैं, और उग्र चीजें खारिज हो जाती हैं. दुर्भाग्य से, शामिल समय मानव जीवन से लंबा हो सकता है. सैमुअल जॉनसन ने कहा कि किसी ले

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

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

मैंने पाया है कि विचारों के सबसे अच्छे स्रोत वे अन्य क्षेत्र नहीं हैं जिनमें "कंप्यूटर" शब्द होता है, बल्कि वे अन्य क्षेत्र हैं जिनमें निर्माता होते हैं। चित्रकला कंप्यूटर के सिद्धांत से कहीं अधिक समृद्ध विचारों का स्रोत रही है।

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

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

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

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

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

यदि हैकर अन्य निर्माताओं, जैसे लेखकों और चित्रकारों, के साथ पहचान करते, तो वे इस तरह का नहीं करते। लेखक और चित्रकार गणित का ईर्ष्या नहीं करते। वे महसूस करते हैं कि वे पूरी तरह से अलग काम कर रहे हैं। मेरा मानना है कि हैकर भी ऐसे ही हैं।

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

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

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

यदि आप किसी समय पैसा कमाना चाहते हैं, तो इसे याद रखें, क्योंकि यही एक कारण है कि स्टार्टअप जीतते हैं। बड़ी कंपनियां डिजाइन परिणामों के मानक विचलन को कम करना चाहती हैं क्योंकि वे आपदाओं से बचना चाहती हैं। लेकिन जब आप दबाव को कम करते हैं, तो आप ऊंचे बिंदुओं के साथ-साथ निम्न बिंदुओं को भी खो देते हैं। यह बड़ी कंपनियों के लिए समस्या नहीं है, क्योंकि वे महान उत्पाद बनाकर नहीं जीतते। बड़ी कंपनियां इसलिए जीतती हैं क्योंकि वे अन्य बड़ी कंपनियों से कम खराब होती हैं।

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

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

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

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

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

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

लगभग सभी निर्माताओं के पास अपने करियर की शुरुआत में दिन का काम होता है। चित्रकार और लेखक ऐसा करते हैं। अगर आप भाग्यशाली हैं तो आप अपने वास्तविक काम से घनिष्ठ रूप से संबंधित दिन का काम प्राप्त कर सकते हैं। संगीतकार अक्सर रिकॉर्ड स्टोर में काम करते हैं। एक हैकर जो किसी प्रोग्रामिंग भाषा या ऑपरेटिंग सिस्टम पर काम कर रहा है, उसके पास भी इसका उपयोग करने वाला दिन का काम मिल सकता है। [1]

जब मैं कहता हूं कि हैकरों के पास दिन का काम होना चाहिए और प्यार से सुंदर सॉफ्टवेयर पर काम करना चाहिए, तो मैं यह नया विचार प्रस्तुत नहीं कर रहा हूं। यही ओपन-सोर्स हैकिंग के बारे में है। मैं जो कह रहा हूं वह है कि ओपन-सोर्स संभवतः सही मॉडल है, क्योंकि यह अन्य सभी निर्माताओं द्वारा स्वतंत्र रूप से पुष्टि किया गया है।

मुझे यह आश्चर्यजनक लगता है कि कोई भी नियोक्ता हैकरों को ओपन-सोर्स परियोजनाओं पर काम करने से रोकने में संकोच करेगा। वियावेब में, हम किसी ऐसे व्यक्ति को नहीं रखना चाहते थे जो ऐसा न करता हो। जब हम प्रोग्रामर्स का साक्षात्कार लेते थे, तो हमारा मुख्य ध्यान उनके अपने समय में किस प्रकार के सॉफ्टवेयर पर काम करते हैं, यही था। आप किसी भी चीज को बहुत अच्छी तरह नहीं कर सकते जब तक कि आप उससे प्यार न करते हों, और अगर आप हैकिंग करने से प्यार करते हैं तो आप निश्चित रूप से अपने स्वयं के परियोजनाओं पर काम करेंगे। [2]

क्योंकि हैकर निर्माता हैं, न कि वैज्ञानिक, इसलिए उपमानों के लिए सही जगह विज्ञान नहीं, बल्कि अन्य प्रकार के निर्माताओं में है। चित्रकला हैकिंग को क्या सिखा सकती है?

एक चीज जो हम सीख सकते हैं, या कम से कम चित्रकला के उदाहरण से पुष्टि कर सकते हैं, वह है कि हैकिंग सीखने का तरीका। आप चित्रकला मुख्य रूप से करके ही सीखते हैं। इसी तरह हैकिंग के लिए भी। अधिकांश हैकर कॉलेज में प्रोग्रामिंग पाठ्यक्रम लेकर नहीं सीखते। वे 13 साल की उम्र में अपने स्वयं के कार्यक्रम लिखकर सीखते हैं। कॉलेज के कक्षाओं में भी, आप मुख्य रूप से हैकिंग करके ही सीखते हैं। [3]

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

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

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

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

लेखक भी ऐसा ही करते हैं। बेंजामिन फ्रैंकलिन ने एडिसन और स्टील के निबंधों में दिए गए बिंदुओं का सारांश लेकर और फिर उन्हें दोहराने की कोशिश करके लिखना सीखा। रेमंड चांडलर ने भी गुमशुदा कहानियों के साथ ऐसा ही किया।

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

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

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

(बड़ी कंपनियों की संरचना इन्हें ऐसा करने में मुश्किल बनाती है, इसलिए यह एक और जगह है जहां स्टार्टअप्स को लाभ है।)

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

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

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

लियोनार्दो नहीं। पेंटिंग के किसी भी हिस्से पर उनका कितना कड़ा परिश्रम किया गया, यह उस पर किसकी नजर पड़ेगी, इस पर निर्भर नहीं करता था। वह माइकल जॉर्डन की तरह थे। अविराम।

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

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

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

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

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

हैकिंग में, इसका सीधा अर्थ है कि बग बचाकर रखना। मुझे डीबगिंग पसंद है: यह वह एकमात्र समय है जब हैकिंग उतना सरल है जितना लोग सोचते हैं। आपके पास एक पूरी तरह से सीमित समस्या है, और आपको केवल इसका समाधान करना है। आपका प्रोग्राम x करना है। बजाय इसके, यह y करता है। यह कहां गलत जाता है? आप जानते हैं कि आप अंत में जीतेंगे। यह दीवार पेंट करने जितना आरामदायक है।

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

जहां तक मुझे पता है, जब पेंटर किसी पेंटिंग पर एक साथ काम करते थे, तो वे कभी भी एक ही हिस्सों पर काम नहीं करते थे। यह आम था कि मास्टर मुख्य आकृतियों को पेंट करता था और सहायक अन्य और पृष्ठभूमि को पेंट करते थे। लेकिन कभी भी एक व्यक्ति दूसरे के काम पर काम नहीं करता था।

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

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

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

बहुत गलत था। यह सामने आया कि दूसरों के नजरिये से देखना लगभग सफलता का रहस्य है। यह खुद को बलिदान करने का मतलब नहीं है। इससे बहुत दूर। किसी दूसरे की चीजों को कैसे देखता है, यह यह नहीं मतलब है कि आप उसके हित में काम करेंगे; कुछ स्थितियों में - युद्ध में, उदाहरण के लिए - आप बिल्कुल उलटा करना चाहते हैं। [4]

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

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

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

सॉफ्टवेयर का एक काम यह है कि वह खुद को समझाए। इसलिए अच्छा सॉफ्टवेयर लिखने के लिए आपको यह समझना होगा कि उपयोगकर्ता कितना कम समझते हैं। वे बिना किसी तैयारी के सॉफ्टवेयर तक पहुंचेंगे, और इसे उनके अनुमान के अनुसार काम करना चाहिए, क्योंकि वे मैनुअल नहीं पढ़ेंगे। इस मामले में सबसे अच्छी प्रणाली मैंने मूल मैकिंटोश, 1985 में देखी थी। यह वह कर रहा था जो सॉफ्टवेयर लगभग कभी नहीं करता: यह बस काम कर रहा था। [[6]]

सोर्स कोड भी खुद को समझाना चाहिए। यदि मैं लोगों को प्रोग्रामिंग के बारे में केवल एक उद्धरण याद दिला सकता हूं, तो यह कंप्यूटर प्रोग्रामों की संरचना और व्याख्या में दिया गया उद्धरण होगा।

कार्यक्रम लोगों को पढ़ने के लिए लिखे जाने चाहिए, और केवल दूसरी बात मशीनों को निष्पादित करने के लिए।

आपको न केवल अपने उपयोगकर्ताओं के लिए, बल्कि अपने पाठकों के लिए भी सहानुभूति होनी चाहिए। यह आपके हित में है, क्योंकि आप उनमें से एक होंगे। कई हैकर ने एक कार्यक्रम लिखा है, लेकिन छह महीने बाद वापस आकर पाया है कि उन्हें इसके काम करने का कोई विचार नहीं है। मैं कई ऐसे लोगों को जानता हूं जिन्होंने ऐसे अनुभवों के बाद पर्ल से दूर हो गए हैं। [[7]]

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

तो, क्या हैकिंग चित्रकला और लेखन की तरह ही कूल है? अंत में, आप केवल एक जीवन जीते हैं। आप इसे किसी महान काम पर काम करते हुए बिताना चाहेंगे।

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

इसलिए जबकि मैं मानता हूं कि हैकिंग अब चित्रकला जितना कूल नहीं लगता, हमें याद रखना चाहिए कि चित्रकला खुद भी अपने महिमामंडित दिनों में इतनी कूल नहीं लगती थी जितनी अब लगती है।

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

बार-बार हम इसी पैटर्न को देखते हैं। एक नया माध्यम प्रकट होता है, और लोग इतने उत्साहित होते हैं कि वे पहले ही पीढ़ियों में इसके अधिकांश संभावनाओं का पता लगा लेते हैं। हैकिंग इस चरण में लगता है।

लियोनार्दो के समय में चित्रकला उतनी कूल नहीं थी जितनी उसके काम ने इसे बना दिया। हैकिंग कितना कूल होता है, यह इस नए माध्यम से क्या कर सकते हैं, इस पर निर्भर करेगा।

टिप्पणियाँ

[1] फोटोग्राफी ने चित्रकला को जो सबसे बड़ा नुकसान पहुंचाया है, वह यह हो सकता है कि इसने सबसे अच्छा दिन का काम खत्म कर दिया। इतिहास के अधिकांश महान चित्रकारों ने पोर्ट्रेट पेंटिंग करके अपना जीवन-यापन किया।

[[2]] मुझे बताया गया है कि माइक्रोसॉफ्ट कर्मचारियों को खुले स्रोत परियोजनाओं में योगदान करने से रोकता है, यहां तक कि अपने स्वतंत्र समय में भी। लेकिन अब सबसे अच्छे हैकरों में से बहुत से खुले स्रोत परियोजनाओं पर काम करते हैं, इसलिए इस नीति का मुख्य प्रभाव यह हो सकता है कि वे किसी भी पहली श्रेणी के प्रोग्रामर को नहीं भर पाएंगे।

[[3]] कॉलेज में प्रोग्रामिंग के बारे में जो आप सीखते हैं, वह उस तरह का है जैसे कि आप उच्च विद्यालय में पुस्तकों या कपड़ों या डेटिंग के बारे में सीखते थे: आपका बुरा स्वाद।

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

[[5]] पाठ संपादक और कंपाइलर को छोड़कर। हैकरों को इन्हें डिजाइन करने के लिए सह

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

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