हैकर और चित्रकार

मई 2003

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

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

इन दोनों छवियों में से कोई भी सही नहीं है। हैकिंग और चित्रकला में बहुत कुछ समान है। वास्तव में, सभी विभिन्न प्रकार के लोगों में से जिन्हें मैंने जाना है, हैकर और चित्रकार सबसे समान हैं।

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

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

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

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

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

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

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

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

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

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

तो विश्वविद्यालयों और शोध प्रयोगशालाएँ हैकरों का मूल्यांकन प्रकाशनों के आधार पर क्यों करती हैं? उसी कारण से कि "शैक्षणिक योग्यता" सरल-मन वाले मानकीकृत परीक्षणों द्वारा मापी जाती है, या प्रोग्रामरों की उत्पादकता को कोड की पंक्तियों में मापा जाता है। ये परीक्षण लागू करने में आसान होते हैं, और ऐसा कोई भी चीज़ नहीं है जो एक आसान परीक्षण के रूप में लुभावना हो जो कुछ हद तक काम करता है।

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

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

मुझे लगता है कि हैकरों को बस अपनी प्रतिष्ठा में एक बड़ा यादृच्छिक घटक होने के लिए resign करना होगा। इस मामले में वे अन्य निर्माताओं से अलग नहीं हैं। वास्तव में, वे तुलना में भाग्यशाली हैं। फैशन का प्रभाव हैकिंग में चित्रकला की तुलना में इतना बड़ा नहीं है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

और उन्होंने माध्यम को इतना आगे बढ़ाया कि हर नाटककार को उसके साए में जीना पड़ा। अल्ब्रेक्ट ड्यूरर ने उत्कीर्णन के साथ वही किया, और जेन ऑस्टेन ने उपन्यास के साथ।

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

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

नोट्स

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

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

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

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

[5] पाठ संपादकों और कंपाइलरों को छोड़कर। हैकरों को इन्हें डिज़ाइन करने के लिए सहानुभूति की आवश्यकता नहीं होती, क्योंकि वे स्वयं सामान्य उपयोगकर्ता होते हैं।

[6] खैर, लगभग। उन्होंने उपलब्ध RAM को कुछ हद तक ओवरशूट किया, जिससे बहुत असुविधाजनक डिस्क स्वैपिंग हुई, लेकिन इसे कुछ महीनों के भीतर एक अतिरिक्त डिस्क ड्राइव खरीदकर ठीक किया जा सकता था।

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

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