इस कम्युनिटी स्टोरी में Franziska और Jonathan टीम डायनैमिक्स, किसी कंपनी में अलग-अलग लोग सहयोग को कैसे देखते हैं, और प्रोग्रामर बनना सीखने के लिए खुद को किस तरह रखें, इन बातों पर चर्चा करते हैं।
Jonathan: नमस्ते, और Exercism पॉडकास्ट में आपका स्वागत है। मेरा नाम Jonathan है और आज आपकी मेज़बानी कर पाना मेरे लिए सौभाग्य की बात है। मेरे साथ Franziska भी हैं, जो हमारे Go और JavaScript ट्रैक की मेंटेनर में से एक हैं। Franziska का Exercism का हिस्सा होना हमारे लिए बड़ी बात है और वे कई सालों से इससे जुड़ी हुई हैं। तो अगर आप इस समुदाय में रहे हैं, तो आप Franziska से मिले भी होंगे। चाहे लर्निंग कोहोर्ट में हों, या Go और JavaScript ट्रैक में। तो Franziska, आज आपका हार्दिक स्वागत है। हमारे साथ जुड़ने के लिए बहुत-बहुत धन्यवाद। मैं सीधे सवाल पर आता हूँ और पूछता हूँ कि आप यहाँ तक कैसे पहुँचीं?
Franziska: हाँ। ठीक है। मैं Franziska हूँ। इंटरनेट पर मैं June हूँ, या कहें तो एक June Dev हूँ। इन दिनों मैं जर्मनी में Frankfurt के पास रहती हूँ, शहर की सीमा से बाहर एक छोटे से उपनगर में। और हाल ही में मैंने Atlassian में नई नौकरी शुरू की है। Atlassian उन बहुत सारे टूल्स की कंपनी है जिन्हें लोग या तो बहुत पसंद करते हैं या बहुत नापसंद, जैसे Trello, Jira, Confluence। हाँ, और वहाँ मैं प्रोडक्ट मैनेजरों के काम में मदद करने के लिए एक नया टूल बना रही हूँ। क्योंकि Jira डेवलपरों पर केंद्रित है, लेकिन प्रोडक्ट मैनेजरों को जो करना होता है, जैसे चीज़ों को प्राथमिकता देना वगैरह, उसके लिए वह ठीक नहीं बैठता। तो हम खास उन्हीं के लिए कुछ बना रहे हैं। मुझे Go भाषा बहुत पसंद है। हमारा बैकएंड Go में बना है। तो जब मैंने नौकरी का विज्ञापन देखा, तो मुझे लगा, वाह, यह तो अच्छी बात है कि वे ऐसा कर रहे हैं। मैंने आवेदन किया और नौकरी मिल गई। अब तक बस 30 दिन हुए हैं, मुझे नहीं पता, लेकिन अनुभव बहुत अच्छा रहा है। फिर, बचपन में मुझे टेक, प्राकृतिक विज्ञान और साइंस फिक्शन में हमेशा दिलचस्पी रही, मैं बड़ी Star Trek फैन हूँ, ऐसी ही चीज़ें। स्कूल में मैंने पाया कि मैं गणित और भौतिकी में अच्छी थी। उस समय बहुत लोग कंप्यूटर साइंस पढ़ रहे थे और वे हमेशा कहते थे कि जो बाकी सब कर रहे हैं वही मत करो, वरना बाद में ऐसे लोग बहुत ज़्यादा हो जाएँगे। मैंने सोचा, ठीक है, शायद मुझे कंप्यूटर साइंस नहीं करना चाहिए, क्योंकि ऐसे लोग बहुत ज़्यादा होंगे। खैर, तो मैंने सोचा, ठीक है, चलो कुछ ऐसा ही करते हैं। तो मैंने भौतिकी पढ़नी शुरू की, जो मुझे स्कूल में बहुत पसंद थी। और कंप्यूटर साइंस मैंने सहायक विषय की तरह लिया। तो मैंने कुछ कोर्स किए, लेकिन बाकियों की तरह इतने नहीं। फिर आप उस मोड़ पर पहुँचते हैं जहाँ सोचना पड़ता है, ठीक है, बाकी ज़िंदगी मैं क्या करूँगी? पैसा कैसे कमाऊँगी, ऐसा काम करके जो मुझे सचमुच पसंद है? और मैंने महसूस किया कि पढ़ाई में जो किया, उसमें प्रोग्रामिंग वाला हिस्सा ही मुझे सबसे ज़्यादा पसंद था और उसमें मैं अच्छी भी थी। मैं वह और करना चाहती थी। और यह ऐसा काम भी है जिससे घर का खर्च चल जाता है। तो मैंने सोचा, ठीक है, उस समय क्लासिकल कंप्यूटर साइंस की डिग्री के बिना इस क्षेत्र में नौकरी कैसे मिलेगी? दूसरी बात यह थी कि तब मैं C डेवलपर या Java डेवलपर नहीं बनना चाहती थी, यानी कहीं बैंक का पुराने ज़माने वाला बैकएंड कोड। तो मैंने सोचा, ठीक है, मैं आधुनिक चीज़ें कैसे सीखूँ, इंटरनेट, वेब? मैं उसके लिए कुछ बनाना चाहती थी। तब एक दोस्त ने बताया कि बूट कैंप नाम की चीज़ें होती हैं, जहाँ आप तीन महीने के लिए कहीं जा सकते हैं और वे आपको नई, बढ़िया चीज़ें सिखाते हैं। हाँ। तो मैंने तय किया कि मुझे यह करना है। और शायद वहाँ से नौकरी ढूँढ़ने के लिए मुझे बेहतर शुरुआत मिलेगी। और उस समय जर्मनी में ऐसे बूट कैंप थे ही नहीं। वहाँ या तो आप सालों-साल यूनिवर्सिटी जा सकते थे, है ना? या कुछ जगहें थीं जहाँ थोड़ा काम और थोड़ी पढ़ाई साथ-साथ होती थी, लेकिन वे भी सालों-साल की पढ़ाई वाले बड़े प्रोग्राम थे। और बूट कैंप की तरह, वहाँ सिर्फ़... स्टार्टअप एक्सेलेरेटर जैसी चीज़ें। यानी जहाँ आप थोड़ा कोड सीखते, लेकिन फिर मैनेजमेंट, अर्थशास्त्र वगैरह भी। तो वह मेरे लिए ठीक नहीं बैठता था। हाँ, तो मैंने थोड़ा चारों ओर देखा और फिर पाया कि London में एक अच्छा बूट कैंप था, जिसमें वे विषय थे जो मैं सीखना चाहती थी।
Jonathan: यही तो चल रहा है।
Franziska: वहीं सब हो रहा है। हाँ, बिल्कुल, बिल्कुल। यानी जहाँ नई, बढ़िया चीज़ें हो रही हैं। हाँ, तो मुझे यह बूट कैंप मिला, और मैं वहाँ चली गई। वह सचमुच एक बहुत बढ़िया अनुभव था। और हमने बैकएंड के लिए Node.js किया। और फिर मैं Frankfurt वापस आई और मुझे Node डेवलपर की नौकरी मिल गई। कंपनी काफ़ी बढ़िया थी और टेक सचमुच मज़ेदार था, मैं जल्दी ही सब कुछ सीख गई और बहुत मज़ा आया। लेकिन टीम के मामले में मैं थोड़ी बदकिस्मत रही, वहाँ बहुत सारे बड़े अहंकार वाले, मचो टीम-सदस्य थे। और बात ऐसी थी कि मीटिंग में जो सबसे ज़ोर से बोलता, बहस वही जीत जाता था। और ऐसी टीम में काम करना अच्छा नहीं लगता।
Jonathan: यह तो बहुत आम बात है। लोग प्रोग्रामिंग करने के लिए आते हैं, और फिर यह टीम वाला पहलू, यह जो किनारे की चीज़ लगती है, वही लोगों के लिए अप्रत्याशित समस्या या चुनौती बन जाती है। तो यह काफ़ी आम बात लगती है। माफ़ कीजिए।
Franziska: हाँ। हाँ। बिल्कुल। और शुरुआत में आप टेक वाले हिस्से को ज़रूरत से ज़्यादा महत्व देते हैं। आप सोचते हैं, अरे, इस नौकरी में ठीक वही टेक है जो मैं करना चाहता था, तो सब ठीक रहेगा। लेकिन सच्चाई यह है कि टीम वाला हिस्सा लगभग उस टेक से भी ज़्यादा महत्वपूर्ण होता है जो आप कर रहे हैं। हाँ। तो फिर दो साल बाद, मेरे एक दोस्त उस समय Frankfurt की ही एक और कंपनी में CTO थे। उन्होंने कहा कि हम भी अपनी टेक बदलना चाहते हैं और कुछ नया बनाना चाहते हैं, लेकिन हम Node.js नहीं करना चाहते। हम Go करना चाहते थे। किसी भी वजह से उन्होंने यह तय किया और कहा कि आप हमारे साथ आ सकती हैं। लेकिन आपको Go सीखना पड़ेगा, बिल्कुल। और मैंने कहा कि अगर शुरुआत में इस भाषा को सीखने के लिए मुझे थोड़ा समय देने में आपको कोई आपत्ति नहीं है, तो मैं तैयार हूँ। मैंने भाषा को थोड़ा देखा और वह मुझे बढ़िया लगी। हाँ, मैंने कंपनी बदल दी। और उस नई जगह पर टीम सचमुच बहुत अच्छी थी। वहाँ सचमुच ऐसा था कि अगर आप CEO के साथ बहस कर रहे थे और आपकी दलील बेहतर थी, तो वह ध्यान में ली जाती थी। लोग उस पर प्रतिक्रिया देते थे। और उनके साथ काम करना सचमुच अच्छा था, लोग बहुत दिलचस्प थे वगैरह। तो मैं वहाँ पाँच साल रही। बहुत सारी ग्रोथ सर्विस बनाईं और साथ ही बहुत सारा लेखन, कॉन्सेप्ट लिखना, दूसरे डेवलपरों को Go में ऑनबोर्ड करने में मदद करना, और थोड़ा फ्रंटएंड का काम भी किया वगैरह। हाँ, लेकिन पाँच साल बाद आप नई चुनौती की तलाश में भी होते हैं, और मुझे नई नौकरी ढूँढ़ने की ओर जो धकेल रहा था वह Covid की स्थिति थी। मैंने देखा कि मैं तो वैसे भी घर से काम कर रही थी, है ना? और शायद हफ़्ते में एक बार ऑफ़िस जाती थी। तो मैंने सोचा कि पूरी तरह रिमोट नौकरियाँ तो बहुत हैं। शायद मुझे किसी बड़ी कंपनी में कुछ सचमुच बढ़िया मिल सके। जब मैं वैसे भी घर से काम कर रही हूँ, तो उस बड़ी, बेहतर कंपनी के लिए भी काम कर सकती हूँ, है ना? हाँ, तो फिर जब मैं काम कर रही थी, तभी मुझे Atlassian में यह नौकरी मिली।
Jonathan: तो मेरा सवाल यह था कि क्या पूरी महामारी ने आपके सोचने का दरवाज़ा खोल दिया कि हो सकता है Frankfurt और यहाँ के स्टार्टअप सीन से बाहर भी कुछ है? क्योंकि मैं पूछने वाला था कि Frankfurt का स्टार्टअप सीन एक जगह के तौर पर कैसा है?
Franziska: हाँ, तो पहले Covid वाली बात पर: Covid ने मेरे लिए सबसे पहले पूरी तरह रिमोट काम करने का यह विचार खोला। क्योंकि पहले मैं हमेशा ऐसी थी कि ऑफ़िस जाती हूँ, लोगों से आमने-सामने मिलना पसंद है, अपने दिन को कैसे बाँटती हूँ वगैरह। लेकिन फिर मैंने महसूस किया कि लगभग दो साल पूरी दूरी पर काम करने के बाद, यह ठीक है। मैं इसे सँभाल सकती हूँ। मेरी बेटी है, मुझे वैसे भी हर समय बाहर जाना पड़ता है वगैरह। तो अब मेरे दिन में पर्याप्त स्ट्रक्चर है। तो महामारी ने मुझे यह दिखाया और फिर इसी ने कहीं और देखने का विचार खोला। Frankfurt के लिए तो, यहाँ टेक और स्टार्टअप का बहुत कुछ चल रहा है, लेकिन जैसा आप सोच सकते हैं, यहाँ बहुत कुछ बैंकिंग पर केंद्रित है, बहुत सारे फिनटेक वगैरह। और वह मुझे खास पसंद नहीं है। मैंने पहले फिनटेक में काम किया है, लेकिन विषय के तौर पर यह मेरा कोई खास जुनून नहीं है। हाँ, तो वह हमेशा थोड़ा... नहीं, और यहाँ Go डेवलपर भी ज़्यादा नहीं हैं। हाँ, ऐसी कोई चीज़ नहीं थी जो मुझे खास तौर पर Frankfurt में या Frankfurt के सीन में बाँधे रखती। हाँ, तो।
Jonathan: नहीं, समझ गया। और क्या ऐसी कोई खास भाषाएँ हैं जिन पर Frankfurt का ध्यान केंद्रित है? ज़ाहिर है, FinTech वगैरह, और उसके पीछे जो भाषाएँ हैं, क्या उन्हीं पर ज़्यादा ज़ोर है? तो Frankfurt में एक Go डेवलपर के तौर पर आप खुद को थोड़ा दुर्लभ पाती हैं? या इनकी संख्या बढ़ रही है? आपको कैसा लगता है?
Franziska: हाँ, फ़िलहाल यह बताना मुश्किल है कि इनकी संख्या बढ़ रही है या नहीं, क्योंकि Covid की वजह से मीटअप वगैरह ज़्यादा नहीं हो रहे थे, है ना? तो यह बताना मुश्किल है कि समय के साथ मीटअप में ज़्यादा लोग आ रहे हैं या नहीं। हाँ, मुझे लगता है कि जैसे Java के क्षेत्र में बहुत ज़्यादा कुछ चल रहा है। हाँ, तो यह बताना थोड़ा मुश्किल है कि हालात ठीक कैसे हैं, लेकिन उदाहरण के लिए, JavaScript का समुदाय जुटाना आमतौर पर इतनी बड़ी समस्या नहीं होती, क्योंकि हर किसी के पास कहीं न कहीं फ्रंटएंड का काम होता है, है ना? तो फ्रंटएंड की दुनिया में आमतौर पर बैकएंड से ज़्यादा कुछ चलता रहता था।
Jonathan: और जब आपने कोडिंग शुरू की और बूट कैंप गईं, तो शायद आपने फ्रंटएंड वाला पहलू भी थोड़ा-बहुत देखा होगा, और अब आपका ज़्यादा ध्यान बैकएंड पर है। तो आप फ्रंटएंड की तुलना में बैकएंड को ज़्यादा क्यों पसंद करती हैं? या यह सिर्फ़ मेरा अनुमान है?
Franziska: नहीं, बिल्कुल, यह मैंने बूट कैंप के दौरान ही समझ लिया था कि मैं बैकएंड वाले हिस्से में ज़्यादा रुचि रखती हूँ, और इसकी कुछ वजहें हैं। सबसे पहले, मैं डिज़ाइनर टाइप की इंसान नहीं हूँ। अगर आप फ्रंटएंड करते हैं, तो आमतौर पर आपको खुद कुछ फ़ैसले लेने पड़ते हैं। कभी-कभी, यह कैसा दिखना चाहिए? यहाँ मैं क्या कर सकता हूँ? इसे बेहतर बनाने के लिए थोड़ा CSS लिखूँ वगैरह। और मेरे लिए ऐसे फ़ैसले लेना बहुत मुश्किल है। बेशक, वास्तविक दुनिया में काम करते समय आपको डिज़ाइन मिलते हैं। लेकिन मुझमें चीज़ों के लिए उतनी नज़र नहीं है। और मैंने देखा कि जिन फ्रंटएंड डेवलपरों में यह नज़र है और जो यह कर पाते हैं, वे यह काम करने में ज़्यादा प्रभावी होते हैं। तो यह एक बात थी जहाँ मुझे लगा कि यह मेरे लिए नहीं है। और दूसरी बात यह भी थी कि आजकल फ्रंटएंड की दुनिया सचमुच बहुत जटिल है। जो फ्रेमवर्क वहाँ हैं, जो आमतौर पर इस्तेमाल होते हैं, उनमें से ज़्यादातर बहुत मुश्किल हैं। तो एक तरह से आजकल का बैकएंड थोड़ा आसान भी है। यह इस मायने में मुश्किल है कि आप... इसे देख नहीं सकते, है ना? फ्रंटएंड की तरह आप स्क्रीन पर अंतिम परिणाम नहीं देखते कि यही आपका अंतिम परिणाम है। लेकिन जटिलता के हिसाब से मुझे लगता है कि आजकल यह फ्रंटएंड की दुनिया से कहीं आसान है। तो मेरे लिए, मैं अपने करियर में किसी मोड़ पर वापस फ्रंटएंड भी करना चाहती हूँ। लेकिन मैं किसी बेहतर फ्रेमवर्क का इंतज़ार कर रही हूँ। और जब यह सारा जो अभी गड़बड़ है, जब यह सारी गड़बड़ शांत हो जाएगी और कुछ बेहतर आ जाएगा, तब मैं वापस जाकर फ्रंटएंड डेवलपर बन जाऊँगी।
Jonathan: तो शायद मैं आपके फ़ैसले का इंतज़ार करूँगा कि वह फ्रेमवर्क कब आएगा, और फिर मैं भी आपके साथ जुड़ जाऊँगा। क्योंकि JavaScript पर बने फ्रेमवर्क देखते हुए, और मैं तो हर मायने में नया हूँ। इस समय मैं Go सीखने की कोशिश कर रहा हूँ और मज़ा आ रहा है। लेकिन सिर्फ़ कॉन्सेप्ट और वह सोचने का तरीका जो आपको बनाना पड़ता है, वह अपने आप में एक पूरी नई दुनिया है। और मैं पूछना चाहता था कि जब आपने प्रोग्रामिंग शुरू की और JavaScript सीखी, और फिर Go सीखा, तो आपने यह खाई कैसे पाटी? क्योंकि आपकी बातों से लगता है कि यह काफ़ी सीधा-सादा काम था, जैसे ठीक है, JavaScript से Go। लेकिन वह कैसा था? बदलाव करने के लिए आपने क्या किया?
Franziska: हाँ। अच्छा सवाल है। यहाँ एक बात ज़रूरी है कि JavaScript मेरी अकेली भाषा नहीं थी, है ना? यूनिवर्सिटी में मैंने बहुत सारी भाषाओं में गहराई तक नहीं जाना, लेकिन C सीखी, Java सीखी, C++ सीखी, Mala जैसी और ऐसी कुछ अलग-अलग भाषाएँ भी सीखीं। तो मेरे लिए Java पहले से ही लगभग मेरी पाँचवीं भाषा थी और फिर Go मेरी छठी बनी। तो उदाहरण के लिए, मेरे लिए Go में pointers वगैरह की बातें सुनने को मिलती थीं, और अगर मैं सिर्फ़ JavaScript से आ रही होती, तो यह बिल्कुल नई बात होती और मुझे सीखना पड़ता कि यह सब क्या है वगैरह। लेकिन ये सारी दूसरी भाषाएँ पीछे होने की वजह से मुझे यह C और C++ से पहले से पता था। तो मैं उन बहुत सी चीज़ों पर लौट सकी जो मैंने यूनिवर्सिटी में पहले सीखी थीं, और इससे अंदर आना सचमुच आसान हो गया। और Go के साथ एक और चीज़ मदद करती है कि यह काफ़ी छोटी भाषा है। इसमें उतने कीवर्ड नहीं हैं, उतनी ऐसी रचनाएँ नहीं हैं जो आप बना सकें। आप इसे काफ़ी जल्दी पूरा कर सकते हैं। मैं आमतौर पर कहती हूँ कि Go का आधिकारिक टूर खोलिए, वेबसाइट पर जाइए वगैरह, और दो-तीन हफ़्तों में आप इसे पूरा कर सकते हैं और आपको ठोस समझ आ जाएगी। और JavaScript के लिए यह असंभव है। बुनियादी बातों की ठोस समझ बनाने में भी आपको कहीं ज़्यादा समय लगेगा, और उसके बाद सीखने को इतना कुछ है। तो हाँ, ऐसी हल्की भाषा ने भी बदलाव आसान बनाने में बहुत मदद की।
Jonathan: ठीक है। तो अब आप Atlassian के लिए काम कर रही हैं और आपने प्रोडक्ट और टेक जैसी चीज़ों के बीच के ओवरलैप के बारे में थोड़ा बताया। और आपने कहा कि FinTech से आपको ज़्यादा कुछ नहीं मिलता, वह आपके लिए खास दिलचस्प नहीं था। क्या आप कहेंगी कि प्रोडक्ट की दुनिया और टेक तथा प्रोडक्ट के बीच का यह जोड़ एक ऐसा क्षेत्र है जो आपको सचमुच पसंद है? और टेक में खास तौर पर आपका जुनून क्या है, अगर आप इसे संक्षेप में बताएँ? मुझे पता है यह बहुत बड़ा सवाल है, लेकिन आप इसके बारे में थोड़ा बता सकेंगी?
Franziska: हाँ, मेरी रुचि कई अलग-अलग क्षेत्रों या विषयों में है। यह सिर्फ़ वह जगह नहीं है जहाँ मैं अब काम कर रही हूँ। उदाहरण के लिए, मुझे कंज़्यूमर प्रोडक्ट्स वाली चीज़ें बहुत पसंद हैं। जैसे Hello Fresh जैसी कंपनियाँ हैं जो बहुत बढ़िया काम करती हैं, टेक से जुड़ी बढ़िया चीज़ें भी। या शिक्षा के क्षेत्र में बहुत कुछ है, जैसे Exercism वगैरह। और फिर दूसरा क्षेत्र डेवलपर टूलिंग या आम तौर पर टीमों के लिए टूलिंग का है। तो कई क्षेत्र हैं, और यह उन चीज़ों में से एक था जहाँ मैं सोच सकती थी कि लोगों की इसमें मदद करना बहुत मायने रखता है। और खास तौर पर प्रोडक्ट मैनेजमेंट के साथ, मैं Jeremy की यह कहानी सुना सकती हूँ, और अपनी पिछली कंपनी के CEO को भी मैंने इस नई नौकरी के बारे में बताया और यह कि मैं क्या करने वाली हूँ, और उन्होंने भी वही कहा जो Exercism के संस्थापक Jeremy ने कहा था। उन्होंने मुझसे बिल्कुल यही कहा कि क्या आपने यह नौकरी इसलिए चुनी क्योंकि आप मेरे प्रोडक्ट मैनेजमेंट कौशल से परेशान थीं? और यह बात बताती है कि प्रोडक्ट मैनेजमेंट और उसे बेहतर बनाना हमेशा से ऐसा विषय रहा है जिसमें मेरी गहरी रुचि रही है। क्योंकि बात यह है कि एक डेवलपर के तौर पर आप दुनिया का सबसे बढ़िया कोड लिख सकते हैं। लेकिन अगर आप गलत चीज़ लिख रहे हैं, गलत चीज़ बना रहे हैं, तो सब बेकार है, है ना? तो अगर आपके प्रोडक्ट मैनेजर ने यह पता लगाने में अच्छा काम नहीं किया कि आपको क्या बनाना चाहिए, तो हो सकता है आप जो बनाया है उसे कोई कभी इस्तेमाल ही न करे, क्योंकि उन्होंने बाज़ार का ठीक से विश्लेषण नहीं किया, प्राथमिकताएँ ठीक से तय नहीं कीं वगैरह। और मैंने अपनी पिछली नौकरियों में यह देखा है। मैंने बहुत सी चीज़ें बनाईं जो कभी रोशनी में नहीं आईं, क्योंकि प्राथमिकता तय करने की कोई अच्छी प्रक्रिया नहीं थी, है ना? इसीलिए मुझे लगता है कि प्रोडक्ट मैनेजमेंट के इस क्षेत्र को बेहतर बनाने से दुनिया भर के डेवलपरों की ज़िंदगी भी बहुत बेहतर होती है, क्योंकि तब वे सही चीज़ें बना सकते हैं और सचमुच वैल्यू पैदा कर सकते हैं, न कि ऐसी चीज़ बनाएँ जो कचरे में जाए या जिसे उपयोगकर्ता कभी देखें ही नहीं।
Jonathan: हाँ, नहीं, यह बहुत दिलचस्प है, क्योंकि आप जिस बात को उठा रही हैं वह मानसिक रूप से यह है कि हमारी अकसर यह सोच रही है कि अगर आप टेक में अच्छे हैं, तो आप सब कुछ पर्दे के पीछे करते हैं। एक इंसान के तौर पर आप कभी रोशनी में नहीं आते, क्योंकि आप टेक करते हैं, और यही स्टीरियोटाइप है। लेकिन लगता है कि पिछले कुछ सालों में टेक और बिज़नेस के पहलू के बीच ओवरलैप बढ़ रहा है। और मेरे लिए, मैं हमेशा agile को एक कॉन्सेप्ट के तौर पर सोचता रहा हूँ। और वह agile का कॉन्सेप्ट, मुझे लगता है, एक बिज़नेस सोच है, या चीज़ों को देखने का एक ऐसा तरीका जो तकनीकी टीम पर थोपा जाता है। सच कहूँ तो मुझे ऐसा ही लगता है। यह मददगार है, लेकिन मैंने कभी ऐसा agile वातावरण काम करते हुए नहीं देखा जो समय पर नतीजे दे। और शायद इसकी वजह यह है कि मैंने इसे पहले खराब तरीके से प्रबंधित होते देखा है। लेकिन लगता है कि अब ज़्यादा ओवरलैप हो रहा है, जहाँ डेवलपर खुद बिज़नेस वाले पहलू में ज़्यादा शामिल होना चाहते हैं, जो मुझे बहुत दिलचस्प लगता है और मेरे ख्याल से अच्छी बात है, क्योंकि इससे कुल मिलाकर फ़ैसले बेहतर होते हैं।
Franziska: हाँ, कुछ डेवलपर ज़्यादा शामिल होना चाहते हैं, लेकिन कुछ नहीं भी चाहते, फिर भी उन्हें ज़्यादा शामिल होना पड़ता है। बात यह है कि यह ऐसे नहीं चलता कि प्रोडक्ट मैनेजमेंट बैठकर सब कुछ टुकड़ों में बाँट दे, फिर उसे दीवार के उस पार भेज दे, और डेवलपर उसे बना दे, और बस हो गया। यह कभी ठीक से काम नहीं करता, पहले भी नहीं करता जब यही आम मॉडल था। और आजकल इस पर ज़्यादा ध्यान दिया जाता है, लेकिन डेवलपरों और डिज़ाइनरों, डेवलपरों और प्रोडक्ट मैनेजरों के बीच ज़्यादा संवाद होना हमेशा से सही बात रही है। और जब भी आपके आगे की तरफ़ कोई टीम हो, जैसे सपोर्ट टीम और हो सकता है कोई जो आपके लिए मेंटेनेंस करता हो, तो ये जितना करीब से काम करते हैं और मिलकर किसी चीज़ का सबसे अच्छा हल निकालते हैं, उतना बेहतर होता है, उतनी ज़्यादा वैल्यू आप मिलकर बना सकते हैं। और यह हमेशा सच रहा है। उदाहरण के लिए, अभी हम जिस फीचर पर काम कर रहे हैं, उसमें प्रोडक्ट मैनेजमेंट के पास बहुत सारे विचार हैं कि इस नए फीचर के पहले इटरेशन में क्या-क्या हो सकता है। लेकिन वे खुद यह नहीं आँक सकते। यह चीज़ जोड़ने में एक और दिन का काम लगेगा, या इससे पूरा स्कोप फैल जाएगा और तीन महीने का और काम बढ़ जाएगा? हाँ। तो उनके लिए यह आँकना असंभव है। तो पहले इटरेशन का अच्छा पैकेज बनाने का एक ही तरीका है कि हम आपस में बात करें और कहें कि यह जोड़ना आसान होगा, यह जोड़ना मुश्किल होगा वगैरह। और फिर हम एक अच्छा स्कोप तय कर लेते हैं। और अच्छी बात यह है कि Atlassian में हमारे प्रोडक्ट मैनेजर भी इसे ऐसे ही देखते हैं। वे हमेशा कहते हैं कि स्कोप दोतरफ़ा चीज़ है। मेरे पास कुछ विचार हैं, लेकिन आपको भी मुझे बताना होगा कि सबसे ज़्यादा मायने क्या रखता है। और फिर हम मिलकर कुछ निकालते हैं। जब मैं हायरिंग की प्रक्रिया से गुज़री, तब मैंने देखा कि दूसरों से, दूसरी टीमों से संवाद करने के इस पूरे विषय पर अभी बहुत ज़ोर है। बहुत लोग पूछते हैं कि आपने दूसरी टीमों के साथ कैसे काम किया? और वे सिर्फ़ आपसे बात करके ही आँक लेते हैं कि आप अपनी बात कितनी अच्छी तरह रख पाते हैं, क्योंकि यह बहुत ज़रूरी है कि आपको इस बात की परवाह हो कि दूसरी टीमें क्या कर रही हैं और आप उसमें शामिल हों। और तभी आपके पास जो समय है उसका पूरा फ़ायदा उठा सकते हैं।
Jonathan: इस मायने में यह कहीं ज़्यादा एकीकृत तरीका लगता है। और तो यह मुझे एक और बात पर ले जाता है, वह यह कि अकसर।
Franziska: ओह, शायद आगे बढ़ने से पहले... तो आपने agile वाला शब्द छेड़ ही दिया, है ना? तो मुझे उस पर कूदना ही पड़ेगा। मुझे नहीं पता कि आपने यह जानबूझकर कहा या नहीं कि मुझे छेड़ दिया जाए। हाँ। Agile के बारे में मुझे हमेशा लगता है कि जहाँ से यह पूरी चीज़ शुरू हुई, उसके मूल विचार, जैसे लोग प्रक्रियाओं से ज़्यादा महत्वपूर्ण हैं, और ऐसी सारी बुनियादी बातें जो उन्होंने बहुत पहले सोची थीं, वे आज भी बहुत मायने रखती हैं। उनके आसपास बहुत जादू था। लेकिन फिर सारे कंसल्टेंट आए और उन्होंने इतने बड़े-बड़े फ्रेमवर्क बना डाले और उन्हें बेच दिया, और स्क्रम मास्टर वगैरह आ गए। और मेरा अनुभव भी यही है, जैसा आपने कहा, कि इसमें से बहुत कुछ ज़्यादा मदद नहीं करता। अगर उदाहरण के लिए प्रोडक्ट और डेवलपर आपस में ठीक से बात नहीं कर रहे हैं, तो ऊपर से ये सारे ढाँचे लाद देने से भी वह ठीक से हल नहीं होता। तो हाँ, मैं भी इन मानक स्क्रम प्रैक्टिसों, agile प्रैक्टिसों की बड़ी प्रशंसक नहीं हूँ, और मैंने इन्हें कहीं भी बहुत अच्छे से काम करते नहीं देखा।
Jonathan: यह दिलचस्प है, क्योंकि लगता है... अगर आप LinkedIn पर product owner या product manager की नौकरी ढूँढ़ने जाएँ, तो हर जगह scrum और Agile ही है। हर जगह यही, कमाल है। लेकिन मज़ेदार बात यह है कि जो सबसे... कैसे कहूँ... काम के मामले में सबसे काबिल डेवलपमेंट टीमें मैंने देखी हैं, वे Kanban वाली थीं, जहाँ समय-सीमा के भीतर कुछ बनाने का कोई दबाव नहीं होता, लेकिन काम की गुणवत्ता आती है। और लगता है कि ज़िम्मेदारी वापस हर इंसान पर डाल दी जाती है कि वह खुद जवाबदेह हो, और यह देखना सचमुच दिलचस्प रहा है, क्योंकि नई टीमें agile पर अटक जाती हैं, काम नहीं चलता, वे निराश हो जाती हैं, और फिर Kanban पर पहुँच जाती हैं, जहाँ हम समय के साथ लगातार थोड़ा-थोड़ा करते रहते हैं और सब चलता रहता है। लेकिन मुझे लगता है कि यह भी दिलचस्प है कि जब आपका अपना प्रोडक्ट एक बिज़नेस होता है, बनाम जब आप दूसरों के लिए प्रोडक्ट बना रहे होते हैं। मुझे नहीं पता कि आपकी पिछली नौकरी क्या थी, वह कंपनी का अपना प्रोडक्ट था या नहीं। मुझे पता है कि Atlassian में आप अपने ही प्रोडक्ट बनाते हैं।
Franziska: हाँ, मैंने हमेशा अपने प्रोडक्ट ही बनाए। मैंने कभी एजेंसी जैसी जगहों पर काम नहीं किया।
Jonathan: हाँ। एजेंसी वाला काम तो बड़ा सिरदर्द होता है, क्योंकि वहाँ हर कोई डेवलपमेंट के हर घंटे की जाँच करता है और पूछता है, मुझे समझ नहीं आता, इस बटन पर मेरे 400 डॉलर कैसे लग गए? और बात यह है कि आपने इसे यहाँ से वहाँ खिसकाना चाहा था, जिसके लिए पूरे बैकएंड को फिर से बनाना पड़ा। तो मैं आपसे एक सवाल पूछना चाहता था, जो हम अपने अलग-अलग पॉडकास्ट और लाइव स्ट्रीम पर बहुत लोगों से पूछते हैं। और वह यह पूरा विचार है कि आप किस बात पर डटे रहेंगे, या टेक में किस राय के लिए आप जान दे देंगे, या जिसे आप जीवनभर बचाएँगे। हम यह नहीं कहना चाहते कि यह राय आपको माननी ही चाहिए, बल्कि यह कि ऐसा कौन-सा एक मूल्य या राय है जो आपके लिए बिल्कुल अहम है और जिसे आप टेक की दुनिया में हर जगह देखना चाहेंगी। यह काफ़ी बड़ा सवाल है, लेकिन क्या टेक में कोई एक चीज़ है जिसका आप ज़ोरदार बचाव करेंगी?
Franziska: मुझे लगा था कि आप इसे थोड़ा हल्का-फुल्का रखेंगे। मैं तो सिर्फ़ एक हल्की, गैर-लोकप्रिय राय के साथ जाना चाहती थी। क्या वह भी चलेगा?
Jonathan: हाँ, बिल्कुल।
Franziska: ठीक है, मेरे पास ऐसी बहुत सारी बातें नहीं हैं जिन पर मैं जान दे दूँ। तो एक बात जिस पर मेरी दृढ़ राय है, वह यह है कि बहुत से लोग कहते हैं कि आप अपने निजी डेवलपमेंट सेटअप को बेहतर बनाइए। और मुझे लगता है कि यह ज़्यादातर ज़रूरत से ज़्यादा बढ़ा-चढ़ाकर कहा जाता है। जैसे लोग आपसे कहेंगे, अरे, आपको Vim सीखना चाहिए, क्योंकि फिर आप कभी माउस की तरफ़ नहीं बढ़ेंगे, और यह कितना बढ़िया है वगैरह। और फिर लोग, जब वे इस इंडस्ट्री में बिल्कुल नए होते हैं, तो वे इसे मान लेते हैं। और फिर वे एक साल ये सारे जादुई शॉर्टकट सीखने में लगा देते हैं। और अंत में, मुझे नहीं पता, शायद साल भर में एक दिन बचाते हैं। तो उस साल भर की तकलीफ़ का कोई फ़ायदा नहीं हुआ। और ऐसी बहुत सी बातें हैं, जैसे लोग कहते हैं कि आपको अपने टर्मिनल के लिए सारे alias अपनी dot files में सेट कर लेने चाहिए, और कहते हैं कि आपको सारे शॉर्टकट याद होने चाहिए वगैरह, और आप इन चीज़ों को सीखने में इतना समय लगा देते हैं, लेकिन बचत कम होती है। और मुझे लगता है कि यहाँ जो होता है वह यह कि लोग यह ज़्यादा आँक लेते हैं कि आपकी नौकरी में टाइप करने में कितना समय जाता है, है ना? जैसा हमने पहले कहा, नौकरी का बड़ा हिस्सा संवाद भी है। बड़ा हिस्सा सचमुच सोचने का है। हाँ। और आपके दिन का सिर्फ़ एक छोटा-सा हिस्सा ही सचमुच कुछ टाइप करने में जाता है, कोड टाइप करना या कमांड टाइप करना वगैरह। तो बहुत लोग दिन के इस बहुत छोटे से हिस्से को बेहतर बनाने में लगे रहते हैं और मेरी राय में, अगर यह आपका शौक़ है, तो कीजिए। या अगर इससे आपको ऐसा ही कोई फ़ायदा होता है। अगर आप SRE हैं, यानी साइट रिलायबिलिटी इंजीनियर, और आप सर्वर में हाथ डालते हैं वगैरह, तो Vim जानना मायने रख सकता है, है ना? क्योंकि वहाँ आप ग्राफ़िकल इंटरफ़ेस नहीं खोल सकते। लेकिन अगर आपको इसकी ज़रूरत नहीं है, तो इसकी चिंता मत कीजिए। जो आपको ठीक लगे वही इस्तेमाल कीजिए। और उदाहरण के लिए शॉर्टकट के लिए, मैं हमेशा कहती हूँ कि ज़्यादातर ग्राफ़िकल इंटरफ़ेस आपको जिस चीज़ पर क्लिक करते हैं उसके बगल में शॉर्टकट दिखा देते हैं। तो अगर आप दिन में पाँच बार उस चीज़ पर क्लिक करते हैं, तो शायद यह याद रखना मायने रखता है कि सेव करने का शॉर्टकट क्या है, अगर आप हर समय वही क्लिक करते हैं। लेकिन अगर नहीं करते, तो अपने ग्राफ़िकल इंटरफ़ेस में खुश रहिए, अपना काम कीजिए, और वह समय अपने वास्तविक प्रोग्रामिंग कौशल को बेहतर बनाने में लगाइए। कुछ अभ्यास कीजिए, कुछ ऐसा। कोई नई भाषा सीखिए। जो चाहें। लेकिन हाँ, मैं नए डेवलपरों से हमेशा यही कहने की कोशिश करती हूँ कि उन लोगों से डरने की ज़रूरत नहीं जो कहते हैं कि आपको इन पुराने एडिटरों में से कोई इस्तेमाल करना चाहिए और वहीं अपनी प्रोडक्टिविटी बेहतर करनी चाहिए।
Jonathan: यह मज़ेदार है, क्योंकि अकसर लोगों के शौक़ भी इसमें घुल-मिल जाते हैं, जो समझ में आता है। क्योंकि बात यह होती है कि अरे, मैं तो बहुत उत्साहित हूँ क्योंकि मैंने अपनी ज़िंदगी बेहतर बना ली। लेकिन सोचने पर पता चलता है कि यह हमेशा सबसे अच्छा नहीं होता। मेरा सीखने का अनुभव भी ऐसा ही था, लोगों की इतनी सारी सिफ़ारिशें होती हैं जो आपको मिल जाती हैं। और फिर अगर आप YouTube पर जाएँ और देखें कि कोडिंग कैसे सीखें, तो कोई शुरू करता है कि अपना GitHub कैसे सेट करें, कोई कि टर्मिनल कैसे समझें, वगैरह। मुझे तो लोकली काम करने के लिए चीज़ें उतारनी पड़ती हैं और ऑनलाइन एडिटर पर भी, वगैरह। मुझे लगता है यह सचमुच अच्छी सलाह है, इसे काफ़ी सरल रखिए। तो फिर अगर आप ज़्यादा समय सोचने में लगाना चाहते हैं, तो आप समस्याओं को सोच-सोचकर कैसे सुलझाती हैं? अगर काम पर कोई स्थिति हो, या आम तौर पर, आप अपने दिन में क्या करती हैं? क्या आप इसके लिए समय निकालती हैं? आपकी प्रक्रिया कैसी है?
Franziska: एक चीज़ जिससे मैं शुरुआत करना पसंद करती हूँ, वह यह है कि समस्या को उसे वास्तव में हल करने से पहले थोड़ा सामने रख लूँ और फिर उसे एक हफ़्ते तक अपने दिमाग़ के पीछे चलता रहने दूँ। और फिर शॉवर के नीचे उसके बारे में थोड़ा सोचती हूँ। सोने से पहले थोड़ा सोचती हूँ और कुछ समय उसे दिमाग़ में पलटती रहती हूँ। और आमतौर पर इससे मुझे कुछ शुरुआती बिंदु मिल जाते हैं। और फिर वहाँ से, खासकर अगर यह काम से जुड़ा हो, मैं आमतौर पर कुछ बिंदु लिखना शुरू करती हूँ, क्योंकि चीज़ें लिखने से मुझे दिमाग़ साफ़ करने में मदद मिलती है, वे बिंदु ढूँढ़ने में भी जहाँ मुझे अभी भी प्रोडक्ट मैनेजर से बात करनी है क्योंकि मुझे नहीं पता कि ग्राहकों के लिए वहाँ ठीक क्या चाहिए। तो मैं लिख लेती हूँ कि मुझे क्या पता है और उन्हें कैसे हल करना है। और मैं आमतौर पर खुले सवालों की एक बड़ी-सी सूची भी लिख लेती हूँ, या तो टीम में किसी और के लिए या खुद के लिए, ऐसी चीज़ें जो पता लगानी हैं। और यह मुझे चीज़ें साफ़ करने में सचमुच मदद करता है। और फिर उस बहुत ऊँचे स्तर के कॉन्सेप्ट से, मैं उसे और ठोस प्रोग्रामिंग कामों में बाँटने की कोशिश करती हूँ। तो API कैसा दिखेगा? इसके लिए मुझे कौन-सा डेटा संग्रहीत करना है? और फिर वह चीज़ स्टोरी पॉइंट से डेटा तक और वापस कैसे पहुँचती है, और रास्ते में कौन-सा लॉजिक होना चाहिए। यह निर्भर करता है। हो सकता है कि मैंने सोचने की प्रक्रिया में पहले ही हल करने वाली बहुत सी समस्याएँ ढूँढ़ ली हों, लेकिन कभी-कभी जब मैं कोडिंग शुरू करती हूँ, तो मुझे नई समस्याएँ मिलती हैं जिनका मैंने पहले अनुमान नहीं लगाया था, और फिर मुझे एक कदम पीछे हटकर फिर सोचना पड़ता है और फिर वास्तविक कोड पर वापस आना पड़ता है। ऐसा भी हो सकता है। लेकिन आमतौर पर तरीका यह होता है कि पहले उस चीज़ के बारे में थोड़ा सोच लूँ, और कुछ समस्याएँ पहले ही सुलझा लेना मेरी बहुत मदद करता है। और फिर या तो कोड सीधा-सादा हो जाता है, या मुझे और समस्याएँ मिलती हैं और मुझे पीछे लौटना पड़ता है, लेकिन वह भी ठीक है।
Jonathan: ठीक है। नहीं, यह अच्छा है। मेरे मन में अकसर यह सोच रहती है कि अगर आप पूर्णकालिक प्रोग्रामर हैं, तो आप सचमुच सुबह से रात तक अपने कंप्यूटर पर बैठे रहते हैं और बस काम करते रहते हैं। लेकिन मैं समझ रहा हूँ कि समस्याओं को सोच-सोचकर हल करने की क्षमता, और मुझे लगता है कि Exercism भी इसी पर ज़ोर देता है, यानी समस्या को अच्छी तरह सोचना, यह पक्का करना कि आपके पास पूरा संदर्भ है। और फिर कोडिंग वाला हिस्सा वास्तव में उस प्रक्रिया की अभिव्यक्ति भर है जो लागू की जाती है। Jeremy भी यही कहेंगे। मुझे लगता है वे बहुत चीज़ों को सोच-सोचकर हल करते हैं और फिर काफ़ी कम कोड लिखते हैं।
Franziska: हाँ। और एक आम सलाह यह भी है कि आप कमेंट में लिखना शुरू कर दीजिए कि आप इस चीज़ से क्या करवाना चाहते हैं। ठीक है, पहले मुझे यह करना है, फिर नतीजा यह आएगा, और फिर यह, और फिर मैं उस खास हिस्से के लिए कोड भर देती हूँ। तो यह भी बहुत मदद करता है।
Jonathan: यह मज़ेदार रहा, क्योंकि आप जो कह रही हैं, वह मैं ज़रूर आज़माऊँगा, क्योंकि मैं समझ रहा हूँ... जब आपको प्रोग्राम करना पड़ता है, खासकर Go सीखते समय या कुछ भी। तो एक अभ्यास जो मैं करने की कोशिश कर रहा था, वह यह था कि कीबोर्ड से इनपुट लेना, उसे संग्रहीत करना, और फिर लौटाना कि आपने इतने अनुमान लगाए, वगैरह। लेकिन उस समस्या को उसके महीन कामों में बाँटकर सोचने की पूरी प्रक्रिया मेरे लिए बहुत अपरिचित थी। तो किसी समस्या के बारे में इस तरह, कदम-दर-कदम सोचना सीखना सचमुच दिलचस्प रहा है। तो नहीं, ये कुछ बढ़िया छोटी सलाहें हैं जो मैं ज़रूर ले जाऊँगा।
Franziska: यह भी ऐसी बात है जो Exercism पर बहुत लोग उठाते हैं। बहुत लोगों को भाषा और सिंटैक्स समझने में उतनी दिक्कत नहीं होती। लेकिन फिर यह पूरा सवाल कि इस आम तरह की समस्या को कैसे हल करूँ, यही चीज़ है जिससे लोग जूझते हैं। और हमने इसके आसपास कुछ डॉक्युमेंटेशन देने की भी कोशिश की है, जहाँ हम कहते हैं कि यह अच्छा संसाधन है जिससे आप प्रोग्रामर की तरह सोचना सीख सकते हैं वगैरह। लेकिन हाँ, शायद हम इस पर और बेहतर कर सकते हैं।
Jonathan: नहीं, यह... नहीं, यह सच है। और मुझे लगता है इससे एक दिलचस्प सवाल निकलता है जो मैंने कुछ और लोगों से भी पूछा है, और जब भी मैंने दूसरों से बात की, यह हमेशा दिलचस्प रहा। और वह यह है कि प्रोग्रामिंग आपको कब समझ आई? मुझे नहीं पता कि आपको कभी ऐसा महसूस हुआ। कॉन्सेप्ट और थ्योरी थी, आपने किताबें पढ़ीं, लेकिन फिर एक सुबह उठीं और अचानक लगा कि अरे, यह तो समझ में आ गया। मेरा अनुभव अकसर कुछ सीखने में ऐसा ही रहा। तो आपके लिए वह कब था, या ऐसा हुआ भी? या यह धीरे-धीरे हुआ, ठीक है, मुझे यह धीरे-धीरे समझ आया? वह कैसा था?
Franziska: ओह हाँ, मैंने इस बारे में थोड़ा सोचा और हाँ, मुझे लगता है कि एक क्लिक वाला पल था। लेकिन मुझे शुरुआत से बताने दीजिए। पहले वह भी बताती हूँ जहाँ चीज़ें समझ नहीं आई थीं, अगर चले तो। जब मैं किशोर थी, तो मेरे पास ऐसा एक खिलौना लैपटॉप था जिसमें कुछ गेम थे। और उसमें एक फीचर यह भी था कि आप BASIC में प्रोग्राम कर सकते थे। और मेरे दादाजी आए और वे... वे पहले पंच कार्ड पर प्रोग्रामिंग किया करते थे। तो वे हमेशा टेक में रुचि रखते थे, और उन्हें लगा, अरे वाह, यहाँ प्रोग्रामिंग हो सकती है। और वे मुझे दिखाना चाहते थे कि प्रोग्रामिंग एक बढ़िया चीज़ है। और उन्होंने वही किया जो सब करते हैं। उन्होंने print लिखा, Hello World, और उसने Hello World छाप दिया, और मैंने कहा, मैं भी Hello World लिख सकती हूँ। आप यह क्या कर रहे हैं? और फिर उन्होंने कहा, नहीं, यह वही करता है जो आप उसे बताते हैं, वगैरह। और फिर उन्होंने कुछ ऐसा लिखा जैसे एक और दो, और वह तीन छाप देता। और मैंने कहा, यह तो मेरा कैलकुलेटर भी कर सकता है। आप मुझे यहाँ क्या दिखाना चाहते हैं? मुझे समझ नहीं आया। और बाद में स्कूल में मेरा कंप्यूटर साइंस जैसा कुछ विषय था। और वहाँ हमारे पास Turbo Pascal था और उसमें किसी प्लगइन जैसी चीज़ थी, जहाँ एक छोटा कछुआ होता था और वह स्क्रीन पर कुछ बना सकता था। और वहाँ उन्होंने हमें कुछ बढ़िया अभ्यास दिए, जहाँ आप कुछ फ़ॉर्मूले डालते और वह बहुत बढ़िया, बारीक फ्रैक्टल बना देता, जो पत्तों जैसे दिखते थे वगैरह। और यह सब सिर्फ़ एक छोटा-सा फ़ॉर्मूला लिखकर मिल जाता, जो इस कछुए को बताता कि क्या बनाना है। और मेरे लिए वही वह पल था जब चीज़ क्लिक हुई, क्योंकि मैंने समझा कि इतने सरल निर्देश देकर इतनी जटिल चीज़ बनाई जा सकती है जो मैं खुद कभी नहीं बना सकती थी। मैं इतने सारे पत्ते खुद नहीं बना सकती थी, है ना? तो मेरे लिए वह चीज़... अरे हाँ। तो वह मुझसे ज़्यादा कर सकता है, यह बात थी। लेकिन हाँ, इससे पहले, दादाजी ने जो समझाया और जो उस चीज़ में दिखाया, उससे चीज़ें समझ नहीं आईं। लेकिन इस ग्राफ़िकल चीज़ को देखकर, और यह देखकर कि कितने कम निर्देशों से कंप्यूटर यह जटिल काम कर सकता है, वहीं मेरे लिए चीज़ क्लिक हुई।
Jonathan: ठीक है, यह अच्छा है, क्योंकि मेरे साथ कुछ दिन पहले मेथड के साथ ऐसा ही हुआ। मैं सोच रहा था कि यह मेथड होता क्या है? और मुझे समझ ही नहीं आ रहा था। और मेरे साथ chemistry में भी ऐसा ही हुआ। मुझे दो साल तक वह पढ़नी पड़ी और फिर रातों-रात आवर्त सारणी पूरी तरह समझ आ गई। और मैं तब 16 साल का था। और मुझे याद है कि मैंने सोचा, हे भगवान, यह तो सबसे आसान चीज़ है। मुझे विश्वास नहीं हो रहा कि मैं इसे दो साल से समझ नहीं पाया। और फिर परीक्षा बहुत आसान लगी। क्योंकि मुझे लगा कि सारे जवाब तो आवर्त सारणी में ही हैं। आपको बस अपना थोड़ा-सा... सब कुछ मेरे दिमाग़ में तालमेल बैठ गया। और लोगों से यह भी बात करना दिलचस्प रहा कि वह पल कब आया। और Rebecca, जिन्हें आप जानती होंगी, शायद Exercism के Unison ट्रैक से, मैंने उनसे पूछा, क्योंकि उन्होंने अंग्रेज़ी साहित्य में डिग्री की थी। और मैंने पूछा, आप अंग्रेज़ी साहित्य से प्रोग्रामिंग तक कैसे पहुँचीं? और अपने दिमाग़ में उस बदलाव को समझने के लिए आपने कौन-सा तरीका अपनाया? और उन्होंने कहा कि वे अपने लिखे प्रोग्राम की कल्पना एक कहानी की तरह करती थीं, एक आख्यान की तरह, जिसमें एक मुख्य पात्र होता है और फंक्शन किरदार होते हैं वगैरह। और मैंने सोचा, वाह, यह तो बहुत दिलचस्प है। ऐसा कभी सोचा भी नहीं था। नहीं, यह सचमुच।
Franziska: हाँ। लेकिन यह उसी बात से जुड़ता है जो हम कमेंट के बारे में बात कर रहे थे, है ना? कि आप कोड से पहले लिखते हैं। यानी पहले कहानी बताइए और फिर उसके लिए बाकी कोड लिखिए।
Jonathan: यह सचमुच बढ़िया है कि आपने यह बताया, क्योंकि मैं समझ रहा हूँ कि वास्तव में मैं अपने कमेंट में एक कहानी लिख रहा हूँ। यह मैं ज़रूर अपनाऊँगा। नहीं।
Franziska: और इस विषय पर एक और बात: कुछ अध्ययन हुए हैं कि लोग प्रोग्रामिंग जैसी चीज़ों में कितने अच्छे होते हैं, और उनमें पाया गया कि आपके शब्दों वाले कौशल, यानी आपके शब्दों का भंडार वगैरह, इसमें बड़ी भूमिका निभाते हैं। तो उदाहरण के लिए, प्रोग्रामिंग में चीज़ों के नाम रखना हमेशा मुश्किल बताया जाता है। तो अगर आप ऐसे अच्छे शब्द सोचने में अच्छे हैं जो बताते हैं कि आप किस चीज़ से निपट रहे हैं, तो इससे आपका कोड बहुत बेहतर हो जाता है। तो यह सिर्फ़ गणित और विश्लेषण वाली बात नहीं है। यह भी बहुत हद तक शब्दों में अच्छे होने की बात है, जिसकी आप शुरुआत में उम्मीद नहीं करते।
Jonathan: नहीं, अंत में यह भाषा ही है, मुझे लगता है, और यह एक दिलचस्प विचार है जो मेरे मन में आया। आप जर्मन हैं, स्वाभाविक रूप से, लेकिन वह आपकी अपनी भाषा है। अब आप Atlassian के साथ अंग्रेज़ी में डेवलप करती हैं? और पहले भी अंग्रेज़ी में ही थीं? क्योंकि मैं कहूँगा कि शायद, बदकिस्मती से, सब कुछ अंग्रेज़ी में ही है। और आप बहुत अच्छी अंग्रेज़ी बोलती हैं, लेकिन क्या आपने स्कूल में अंग्रेज़ी सीखी और फिर प्रोग्रामिंग? क्या वह सब जर्मन में था, या आपने यह सब कैसे सीखा?
Franziska: हाँ, सबसे बड़ी बात यह रही कि मैं किस्मत वाली थी कि प्रोग्रामिंग की ज़्यादातर चीज़ें अंग्रेज़ी में थीं, सारे कमेंट अंग्रेज़ी में थे वगैरह। अंग्रेज़ी हमेशा सबसे अच्छी नहीं होती, लेकिन चलता है। हाँ, अंग्रेज़ी सीखने की बात करूँ तो स्कूल में मैं अंग्रेज़ी में कभी अच्छी नहीं थी। लेकिन यूनिवर्सिटी में मेरी किस्मत अच्छी थी कि मैं एक साल, जैसे एक्सचेंज का साल, UK में बिता सकी। तो वह सचमुच भाषा के बीच रहने जैसा था। और फिर मेरी अंग्रेज़ी बहुत बेहतर हो गई। उसके बाद तो सब आसान हो गया, लेकिन उससे पहले हालत बहुत खराब थी। तो उस साल, सचमुच भाषा सीखने से, आगे चलकर मुझे उन सहकर्मियों से बात करने में भी मदद मिली जो जर्मनी के नहीं हैं वगैरह। और यह निश्चित रूप से एक पहलू है। अगर अंग्रेज़ी आपकी मातृभाषा नहीं है, तो फिर चीज़ों का सही नाम तय करने के लिए लड़ना आपके लिए और मुश्किल हो जाता है, है ना? और चीज़ों के नाम रखना तो आप कोड की हर लाइन में करते हैं, है ना? आप हमेशा किसी चीज़ को किसी चीज़ में असाइन करते हैं और उस चीज़ का जितना अच्छा हो सके नाम रखना पड़ता है ताकि कोड साफ़ रहे।
Jonathan: नहीं, यह गैर-अंग्रेज़ी बोलने वालों के लिए इतना आसान नहीं लगता। मुझे लगता है यह भी बदलने लगेगा। कुछ दिन पहले मैंने एक लेख पढ़ा कि इस समय भारत दुनिया में सबसे तेज़ी से बढ़ता टेक क्षेत्र है। और अंग्रेज़ी, चाहे वे अंग्रेज़ी पर टिके रहें या अपनी स्थानीय बोलियों पर, जो मुझे पता है भारत में बहुत हैं। यह सब सोचना दिलचस्प है। तो हम लगभग एक घंटे पर पहुँच रहे हैं। मुझे यह बहुत अच्छा लगा। Franziska, मेरे पास आपके लिए एक और सवाल है। और यहाँ आपको एक सिफ़ारिश करनी है। Exercism समुदाय। आपकी एक सिफ़ारिश क्या होगी? यह कुछ भी हो सकता है, कोई खाने की चीज़ जिसे आज़माना चाहिए, या टहलने जाना, या जो भी आप समुदाय को बताना चाहें। इस हफ़्ते Exercism समुदाय के लिए आपकी क्या सिफ़ारिश होगी?
Franziska: हाँ, मैं उसी प्रोडक्टिविटी वाली बात पर लौटूँगी जो मैंने गैर-लोकप्रिय राय में कही थी। तो मेरी सिफ़ारिश यह होगी कि ब्रेक लीजिए, वह Netflix शो जिसे आप हमेशा देखना चाहते थे, एक बार में देख डालिए, या जो भी हो। लोग आमतौर पर पूरे दिन प्रोडक्टिव बने रहने पर ही ध्यान लगाए रहते हैं। और यह आपके दिमाग़ के लिए अच्छा नहीं है। इतना ज़्यादा ऑप्टिमाइज़ करना आपके दिमाग़ के लिए अच्छा नहीं है, क्योंकि काम में अच्छा होने, रचनात्मक होने वगैरह के लिए आपके दिमाग़ को ब्रेक चाहिए, क्योंकि वह उन ब्रेक में अपना काम करता है। और हाँ, और फिर सोफ़े पर बैठकर कोई शो थोड़ा-थोड़ा देखना वगैरह, यह अच्छी बात है। यह करना अच्छा है, ताकि आपके दिमाग़ को पीछे-पीछे अपना काम करने का थोड़ा समय मिले। और मुझे लगता है कि ब्रेक लेना, समय निकालना, इसकी कद्र कम की जाती है। तो यही मेरी सिफ़ारिश होगी। ब्रेक लेने और आराम करने के लिए खुद को दोषी मत महसूस कीजिए।
Jonathan: बढ़िया। नहीं, मुझे यह बहुत पसंद आया। तो सब लोग, जब आप यह सुन रहे हों, तो यह Franziska की इस हफ़्ते की सिफ़ारिश, यानी सलाह है। तो Franziska, आपके समय के लिए बहुत-बहुत धन्यवाद, और Exercism में आपने जो कुछ लगाया, उस सबके लिए भी। और उस सोच और समुदाय के साथ आपके जुड़ाव के लिए भी। मुझे पता है कि आप Exercism से बहुत जुड़ी रहीं, उसे बेहतर बनाया और मदद की, और हम इसकी बहुत कद्र करते हैं। तो मैं सिर्फ़ धन्यवाद कहना चाहता था, और आज सुबह अपना समय देने के लिए भी धन्यवाद। राष्ट्रीय अवकाश है, जब आप बाहर जश्न मना सकती थीं या कुछ मज़ेदार कर सकती थीं। और आपने यहाँ अपना समय दिया, तो बहुत-बहुत आभार। रिकॉर्डिंग बंद करने के बाद भी मैं कॉल पर ही अटका रहा, लेकिन मैं सिर्फ़ इतना कहना चाहता था कि बहुत-बहुत धन्यवाद, और हाँ, आपका बाकी दिन बहुत अच्छा गुज़रे। बढ़िया।
Franziska: मुझे बुलाने के लिए धन्यवाद।
हमारी कम्युनिटी के सदस्यों को सुनिए, उनसे सीखिए और प्रेरणा पाइए।