एक अपना प्रोजेक्ट

जून 2021

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

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

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

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

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

[ 1 ]

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

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

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

[ 2 ]

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

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

तो अपने खुद के प्रोजेक्ट का किनारा वास्तव में कहां है? यह एक दिलचस्प सवाल है, आंशिक रूप से क्योंकि इसका उत्तर इतना जटिल है, और आंशिक रूप से क्योंकि इसमें बहुत कुछ दांव पर है। यह पता चलता है कि काम अपने खुद का होने के दो अर्थ होते हैं: 1) कि आप इसे स्वेच्छा से कर रहे हैं, न कि केवल इसलिए कि किसी ने आपको बताया, और 2) कि आप इसे अकेले कर रहे हैं।

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

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

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

[ 3 ]

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

[ 4 ]

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

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

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

[ 5 ]

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

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

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

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

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

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

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

नोट्स

[ 1 ] "शौक" एक अजीब शब्द है। अब इसका मतलब ऐसा काम है जो वास्तविक काम नहीं है — ऐसा काम जिस पर किसी को नहीं आंकना चाहिए — लेकिन मूल रूप से इसका मतलब एक सामान्य अर्थ में एक जुनून था (यहां तक कि एक राजनीतिक राय, उदाहरण के लिए) जिसे कोई उस तरह से सवारी करता था जैसे एक बच्चा एक शौक-घोड़े पर सवारी करता है। यह कहना कठिन है कि इसका हालिया, संकीर्ण अर्थ बेहतर के लिए एक परिवर्तन है या बुरे के लिए। निश्चित रूप से कई झूठे सकारात्मक हैं — कई प्रोजेक्ट जो अंततः महत्वपूर्ण बन जाते हैं लेकिन शुरू में केवल शौक के रूप में खारिज कर दिए जाते हैं। लेकिन दूसरी ओर, यह अवधारणा प्रारंभिक, बदसूरत बत्तख के चरण में प्रोजेक्ट के लिए मूल्यवान कवर प्रदान करती है।

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

[ 3 ] अपने खुद के प्रोजेक्ट पर काम करने और दूसरों के साथ सहयोग करने के बीच जटिल, क्रमिक किनारा "एकाकी प्रतिभा" के विचार के बारे में इतनी असहमति का एक कारण है। व्यवहार में लोग सभी प्रकार के विभिन्न तरीकों से सहयोग करते हैं (या नहीं), लेकिन एकाकी प्रतिभा का विचार निश्चित रूप से एक मिथक नहीं है। इसमें एक निश्चित तरीके से काम करने के साथ एक सत्य का मूल है।

[ 4 ] सहयोग भी शक्तिशाली है। आदर्श संगठन सहयोग और स्वामित्व को इस तरह से संयोजित करेगा कि प्रत्येक को कम से कम नुकसान पहुंचे। दिलचस्प बात यह है कि कंपनियां और विश्वविद्यालय विभाग इस आदर्श की ओर विपरीत दिशाओं से बढ़ते हैं: कंपनियां सहयोग पर जोर देती हैं, और कभी-कभी स्केटर्स को भर्ती करने और उन्हें स्केट करने की अनुमति देने में भी सफल होती हैं, और विश्वविद्यालय विभाग स्वतंत्र अनुसंधान करने की क्षमता पर जोर देते हैं (जो कि प्रथा द्वारा स्केटिंग के रूप में माना जाता है, चाहे वह हो या न हो), और वे जिन लोगों को नियुक्त करते हैं वे जितना चाहें सहयोग करते हैं।

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

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