Mentor एक जूनियर डेवलपर के लिए कैसे


99

यह शीर्षक थोड़ा व्यापक है लेकिन मुझे अपना प्रश्न ठीक से पूछने से पहले थोड़ी पृष्ठभूमि देने की आवश्यकता हो सकती है।

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

जब मैं कहता हूं कि "नए डेवलपर" वे कॉलेज के नए साल से दो या दो साल के अनुभव से कहीं भी हो सकते हैं।

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

मैं सिर्फ पर्याप्त जानकारी कैसे प्रदान कर सकता हूं ताकि वे सीखें, लेकिन इतना न दें कि उनके लिए समस्या को हल करें?

या शायद:

उन प्रश्नों की उचित प्रतिक्रिया क्या है जो कम से कम प्रतिरोध का रास्ता लेने के लिए डिज़ाइन किए गए हैं और संक्षेप में, उन्हें आसान रास्ता निकालने के बजाय सीखने के लिए मजबूर करते हैं?

ये प्रश्न संभवतः अधिक सामान्य शिक्षण प्रश्न हैं और विशेष रूप से सॉफ्टवेयर विकास के साथ ऐसा करने के लिए बहुत कुछ नहीं है।

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

मेरे मुख्य उद्देश्य हैं:

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

1
आप केवल उसी व्यक्ति की मदद कर सकते हैं जो वे स्वयं बनना चाहते हैं। उन लोगों का मार्गदर्शन करें जो निर्देशित होना चाहते हैं।
अंधेरी

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

1
इस विषय पर यहाँ शानदार प्रतिक्रिया का एक गुच्छा है: प्रोग्रामर.स्टैकएक्सचेंज
कंटेंट

आप "सलाह" बयानबाजी में क्यों खरीद रहे हैं? "प्रशिक्षण" शब्द का उपयोग करें: आप "नौकरी के लिए प्रशिक्षण" का वर्णन कर रहे हैं , यह दार्शनिक सामान नहीं है, जीवन और ब्रह्मांड को देखने का आपका तरीका और यह है कि आपकी कंपनी में चीजों को कैसे किया जाना चाहिए। (और आपकी कंपनी को उन्हें आधिकारिक रूप देने के बारे में कुछ और सोचना चाहिए)
ZJR

3
और .. सुनिश्चित करें कि उनका घन आपके घन से टॉयलेट तक के मार्ग पर मध्य में है ...
vrdhn

जवाबों:


121

एक बार यहाँ एक सवाल था, जिसमें इस तरह की जानकारी थी, और जो टुकड़ा मेरे साथ सबसे अधिक चिपक गया था, वह उनके कीबोर्ड को नहीं छू रहा था

संक्षेप में, अपने कनिष्ठ को बताएं कि वे क्या करने की कोशिश कर रहे हैं , उसे पूरा करें, लेकिन उनके लिए ऐसा न करें।

लेकिन इसके अलावा, यहां कुछ अन्य सुझाव दिए गए हैं:

  • Google (या किसी अन्य खोज टूल) को प्रोत्साहित करें। यदि आप जानते हैं कि उत्तर आसानी से ऑनलाइन पाया जा सकता है, तो उन्हें उत्तर बताने के बजाय इसे देखने के लिए कहें। अंततः आप उन्हें खुद को कैसे सिखाना चाहते हैं , न कि उन्हें आप पर निर्भर होना चाहिए।
  • सवालों के जवाब देने के लिए खुद को उपलब्ध कराएं। यदि आप कभी भी उपलब्ध नहीं हैं या बाधित होने की इच्छा नहीं रखते हैं, तो उन्हें यह स्पष्ट कर दें कि उन्हें एक निर्दिष्ट समय तक अपने प्रश्न रखने चाहिए।
  • कोड की समीक्षा नियमित रूप से उन्हें बताएं कि वे सही / गलत क्या कर रहे हैं। इसे सर्वोत्तम प्रथाओं को इंगित करने के अवसर के रूप में उपयोग करें
  • सर्वोत्तम प्रथाओं के साथ शुरुआत करें। बेहतर तरीका है कि उन्हें सही तरीके से सिखाने के लिए अतिरिक्त समय निकालें, और बाद में अपने तरीकों को बदलने की कोशिश करें।
  • उन्हें प्लानिंग / डॉक्यूमेंटेशन के साथ जल्दी शुरू कर दें जो उन्हें कोड लिखने से शुरू करने के बजाय क्या करने जा रहे हैं।
  • उनसे सीखने के लिए खुले रहें। वे शायद आपके सीखने की तुलना में अधिक समय बिताते हैं, और यह संभव है कि वे कुछ ऐसा सीखें जो आपको नहीं पता था।
  • उनकी गलतियों से सीखने में उनकी मदद करें। गलतियाँ होने जा रही हैं, इसलिए सुनिश्चित करें कि आप उन्हें दिखाएंगे कि गलतियाँ सीखने का हिस्सा हैं, और उन्हें सीखने के अवसर के रूप में उनका उपयोग करना चाहिए।

  • (नीचे RuneFS से) उन्हें कुछ करने का तरीका बताने के बजाय, उन्हें यह पता लगाने में मदद करने की कोशिश करें। यह एक समस्या के माध्यम से तार्किक रूप से काम करने की उनकी क्षमता में सुधार करने में मदद करेगा, और उनकी सीखने की क्षमता को बढ़ाता है

  • (नीचे RuneFS से) उन्हें यह बताने के बजाय कि उन्होंने क्या गलत किया, उन्हें ऐसे तरीके बताएं जिससे वे इसमें सुधार कर सकें। यह सुनिश्चित करें कि आपका तरीका उनके मुकाबले बेहतर क्यों है। इससे उनका आत्मविश्वास कमजोर होने के बजाय बढ़ेगा। बेशक, अगर वे आपकी बात नहीं सुन रहे हैं तो डरने की ज़रूरत नहीं है कि आप उन्हें इसे सही तरीके से बताएं :)

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

3
मुझे पता है कि यह पहले ही कहा जा चुका है लेकिन "कीबोर्ड को मत छुओ"। एक बहुत अच्छा बिंदु है
टॉम स्क्वायर्स

3
यह मुझे बताता है कि इसमें से बहुत से लोग कनिष्ठ डेवलपर को अधिक चतुर प्रश्न पूछना सिखा रहे हैं। इसके लिए महान संसाधन: catb.org/esr/faqs/smart-questions.html
तालमा

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

1
@ जय: सलाह मेंटर को जूनियर के कीबोर्ड को न छूने के लिए है।
फुट

21

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

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

अपने ज्ञान पोर्टफोलियो के साथ, उन्हें पता चल जाएगा कि उनके पास समस्या है या नहीं। जहां देखो वहीं सिखाते हैं। मैंने खुद हाल ही में स्टैकऑवरफ्लो की उपयोगिता की खोज की (और जैसा कि आप जानते हैं, यह बेहतर है तो बस यहां Google देखें)।

ऐसा लगता है कि आप उनके साथ बहुत समय नहीं बिता सकते हैं, लेकिन जोड़ी प्रोग्रामिंग बहुत मददगार है। यदि आप ऐसा नहीं कर सकते, तो कम से कम कोडकॉलबोरेटर या इसी तरह के अन्य उपकरण का उपयोग करके कोड की समीक्षा करें। वे उतना समय नहीं लेते जितना आपको लगता है कि वे करते हैं।

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


10

उनसे पूछे जाने वाले सवालों के जवाब देने के बजाय केवल उन्हें बताने के लिए कहें (अच्छी तरह से आप उन्हें कुछ बुनियादी बातें बता सकते हैं जैसे कि सर्वर का नाम क्या है और डेटाबेस क्या जानकारी संग्रहीत करता है)। उसे दिखाओ कि कैसे उसके उत्तर खोजने हैं।

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

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

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

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

उसकी पृष्ठभूमि के बारे में प्रश्न पूछें। वह कुछ ऐसी चीजों को जान सकता है जिनके साथ आपको काम करने का मौका नहीं मिला है। यदि ऐसा है और उन्हें उपयोग करने का अवसर आता है, तो उनसे उनके ज्ञान के बारे में सवाल पूछें।

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

अंत में, आप सम्मान देकर भाग में सम्मान प्राप्त करते हैं। हर किसी के साथ सम्मानपूर्वक व्यवहार करें। उन्हें बेझिझक या बेवकूफ मत बनाओ। यदि आप उनसे आदर के साथ पेश आते हैं तो वे आपको बेहतर तरीके से सुनेंगे।


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

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

1
@ S.Robins, मैंने पाया है कि यह इस बात को भी इंगित करने में मदद करता है कि आप इस सामान को जानते हैं क्योंकि आप जिन गलतियों में गिरे थे।
HLGEM

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

पुन: "उन्हें कुछ सही करते हुए पकड़ो": मुझे यकीन नहीं है कि मैं इससे सहमत हूं, क्योंकि इसका मतलब है कि आप हमेशा उनके कंधे पर देख रहे हैं, या कम से कम, नियमित रूप से उन पर जांच कर रहे हैं। ऐसे कुछ रिश्ते हो सकते हैं जहाँ यह आवश्यक है, लेकिन मुझे नहीं लगता कि संरक्षक / प्रोटेग संबंध उनमें से एक है; और यह "उन्हें समान के रूप में व्यवहार करने" की आपकी उत्कृष्ट सलाह का खंडन करता है।
रूआख

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

ठीक है, हाँ, मैं उस पर सवार हूं। +1। :-)
मारख

7

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

इसके अलावा, अगर कभी वह कुछ ऐसा कर रहा था जो मेरे लिए उपयोगी हो सकता है, तो वह मुझे फोन करेगा कि वह क्या कर रहा है और क्यों कर रहा है।

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

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


5
+1 मैंने नौकरी पर अधिक सीखा तो मैं कभी भी विश्वविद्यालय में हो सकता था, सिर्फ इसलिए कि लोगों ने मुझे सिखाने के लिए समय लिया।
जेम्स खुरै

7

दिए गए कार्य के आधार पर, मुझे कुछ अलग तरीके अपनाने के लिए लुभाया जाएगा:

  • उनसे पूछें कि वे कार्य को पूरा करने के लिए आगे क्या प्रयास करेंगे। यह एक अनुमान दे सकता है कि "मुझे नहीं पता कि क्या करना है" से "ठीक है, मैं यह कोशिश करूँगा लेकिन ..." श्रेणी वे अपने स्वयं के विचार के संदर्भ में हैं जो एक शुरुआती बिंदु के लिए उपयोगी हो सकती हैं ।

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

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

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


+1 मैं कुछ लिखने जा रहा था लेकिन इसने इसे मेरे दृष्टिकोण में बदल दिया।
जेसन सेब्रिंग

5

मैंने अपने काम में यहां एक बात की है कि मैं वास्तव में उपयोगी पाया गया था कि आंतरिक क्यू एंड ए के लिए एक मंच (यानी PHPbb) सेटअप करना था, और नियम का पालन करना चाहिए कि यदि प्रश्न और / या उत्तर में 5 मिनट से अधिक समय लगता है, तो यह होना चाहिए मंच के माध्यम से पूछा और उत्तर दिया। लाभ:

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

4

मैं यहाँ प्रवृत्ति को हिरन करने जा रहा हूं और सुझाव देता हूं कि आप जूनियर डेवलपर्स को यह जानने के लिए प्रोत्साहित करने की कोशिश करें कि वे स्वयं उत्तर कैसे खोजें। यह "मेरे पास है, लेकिन मैं इसे आपको नहीं देने जा रहा हूं।"

इसके बजाय, उत्तर खोजने में उनके साथ जोड़ी बनाएं। आप इसे वैसे भी Google करने जा रहे हैं, इसलिए उनके साथ बैठकर ऐसा करें। वे उठाएंगे कि यह उत्तर खोजने का तरीका है।

यदि आप उनके साथ मिलकर काम करते हैं, तो वे आईडीई का सही उपयोग करने का तरीका चुनेंगे; डेटाबेस को सामान्य कैसे करें; कैसे अपने कोड बाहर DRY ... जो भी आप जानते हैं कि जानने लायक है।

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


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

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

4

मुझे केवल एक बार एक जूनियर प्रोग्रामर को प्रशिक्षित करना पड़ा है। यह एक ऐसी प्रणाली को बनाए रखने में मदद करना था जिसे मैंने बनाया था। लक्ष्य को अंततः पूरी प्रणाली को उसके हवाले करना था।

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

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


3

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

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

एक बार उनके हाथ में, लेख और प्रलेखन उन्हें त्वरित उत्तर के लिए अन्य डेवलपर्स पर पंजे लगाने के बजाय समाधान के बारे में पढ़ने के लिए मजबूर करेगा।

यह निम्नलिखित को पूरा करेगा:

  • अनुभवी डेवलपर्स का कुछ बोझ उठाना।
  • नए डेवलपर को सीखने के लिए मजबूर करना।
  • सभी के लिए खुशियाँ।

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


3

मेरा सुझाव है कि आपके पास वास्तविक असाइनमेंट के कुछ हिस्से देने शुरू करें और उसके कोड का उपयोग करने में सक्षम होने के लिए सब कुछ करें। दूसरे शब्दों में उसे अपने लिए प्रतिस्थापन के रूप में प्रशिक्षित करें।

इस तरह आप जूनियर के साथ काम करने के लिए समय आवंटित करने के लिए खुद को प्रतिबद्ध करेंगे और वह "वास्तविक जीवन" देख पाएंगे। वास्तविक असाइनमेंट पर काम करने और जीवंत प्रतिक्रिया सुनने से वह तेजी से गति प्राप्त करने में सक्षम हो जाएगा।


1

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

लेकिन, जीवन में बहुत कम स्थितियां ऐसी होती हैं। जब तक आपकी नौकरी एक "मानसिक कारखाना" नहीं है, जिसमें टूल सी के साथ विजेट A को विजेट B से जोड़ा जाता है, तो आपको कुछ आइटम रखने होंगे:

  • कौशल और उपकरणों का एक टूलबॉक्स
  • एक समस्या को हल करने की विधि

उदाहरण के लिए, मेरे द्वारा पोस्ट किए गए इस उत्तर पर एक नज़र डालें । यह समस्या को हल करने की विधि को कवर करता है जो कई लोगों के पास नहीं है । CompSci कार्यक्रम में कॉलेज ने इसे किसी को नहीं पढ़ाया था, आप या तो पहले से ही जानते थे या यह पता लगा लिया था।

एक बार जब जूनियर देव समझ जाते हैं कि समस्याओं को हल करने के बारे में उन्हें क्या करना है, तो उन्हें ऐसे उपकरणों का एक सेट चाहिए, जिसके साथ ऐसा करना है।

  • डीबगर (कॉलेज ने कभी इसका उल्लेख नहीं किया)
  • profilers
  • पाठ संपादक
  • शेल (और संबद्ध बर्तन)
  • संसाधन (किताबें, गूगल, एसओ, मैनपेज)

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

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

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


1

आपका संगठन जैसा कि आप वर्णन करते हैं कि यह मेरा से बहुत अलग है। मैं अपने जूनियर्स के काम का विरोध कर रहा हूं, और मैं इसे जज की भूमिका के रूप में देखता हूं। तो बहुत कुछ अलग है।

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

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

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

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


1

अन्य उत्तर बहुत अच्छे हैं, लेकिन मैं इस एक वाक्य पर टिप्पणी करना चाहता था।

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

ज्यादातर लोग जानना चाहते हैं कि कुछ कैसे करना है। यह दृष्टिकोण शुरुआत में ठीक है जब आप नई चीजों को सीखने और अपना काम करने का तरीका सीखने से अभिभूत हो जाते हैं।

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

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


1

कनिष्ठ डेवलपर्स के लिए यह सब करने की संभावना पर उत्साहित होने वालों के लिए बाहर देखने की चीज: सुनिश्चित करें कि आपका प्रबंधन समझता है कि क्या हो रहा है।

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

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

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

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


1

मैं तुम्हें इस पर अपना लुक दूंगा।

मूल रूप से, मैं अच्छी तरह से सीखता हूं जब मैं:

  1. विषय का एक औपचारिक परिचय दिया। मैं कभी भी किसी के बिना कुछ नया नहीं सीख सकता (हाँ, एक व्यक्ति) मेरे पास नई अवधारणाओं के सभी सवालों का जवाब है। एक बार जब मैंने किया है कि मैं ...
  2. एक पुस्तक प्राप्त करें। मेरे गुरु के रूप में, आपके पास सटीक एक ही पुस्तक होनी चाहिए, इसलिए मैं हमेशा कुछ कह सकता हूं, "अरे, अध्याय चार, पृष्ठ 72, पैराग्राफ 6 में इसका क्या मतलब है ..." और आपको पता चल जाएगा कि मैं क्या बोल रहा हूं। के बारे में। एक बार जब मेरे पास एक पुस्तक होती है, तो मैं अधिक स्वतंत्र होता हूं, और वास्तव में केवल प्रश्न पूछता हूं। तब मैं...
  3. एक साथ एक परियोजना शुरू करो। यह प्रक्रिया का सबसे महत्वपूर्ण हिस्सा है। यह वह जगह है जहां आप मुझे सर्वोत्तम प्रथाओं, एल्गोरिदम, कठिन (लेकिन उपयोगी) भाषा सुविधाओं आदि के बारे में पढ़ाना शुरू कर सकते हैं।

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

इसके साथ ही कहा, आपको अभी भी नियमित रूप से उसके साथ काम करना है। एक सामान्य "टाइमलाइन" होनी चाहिए:

  • 1 महीना। बेसिक सिंटेक्स जानना चाहिए। अभी भी स्वतंत्र नहीं है जब कोडिंग।
  • 3 महीने। इस बिंदु पर उसे अपने हाथ के पीछे की तरह वाक्य रचना को जानना चाहिए, और सरल समस्याओं को आसानी से हल करने में सक्षम होना चाहिए। वह बहुत अधिक स्वतंत्र है, बस अभी तक वहाँ नहीं है।
  • 6 महीने। उन्हें पता होना चाहिए, बाकी सभी चीजों के ऊपर: सर्वश्रेष्ठ अभ्यास, सामान्य एल्गोरिदम, आदि। उन्हें एसओ की मदद से शायद खुद को एक परियोजना बनाने में सक्षम होना चाहिए।

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

यह जानने के बाद कि आप उसे क्या जानना चाहते हैं, उसे आज़ाद कर दें। उसे बंद होने दें और वह सीखें जो वह सीखना चाहता है (आप हमेशा कह सकते हैं कि आप उसे उस भाषा में काम करना चाहते हैं)।

आशा है कि ये आपकी मदद करेगा! वैसे, उसे यह पढ़ने दो: टेन योरसेल्फ प्रोग्रामिंग इन टेन इयर्स


0

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

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

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


0

मैंने यहां किसी को अपने निजी नायक रैंडी पॉश का जिक्र करते नहीं देखा ।

मुझे लगता है कि यह वास्तव में प्रोग्रामिंग करने, सिखाने या सलाह देने वाले (या सार्थक जीवन जीने के लिए भी) किसी के लिए भी फायदेमंद हो सकता है। आप और / या आपके सहकर्मी इन व्याख्यानों को उस समय के लायक देख सकते हैं, जैसा कि मेरे पास है


-4

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

Im भुगतान किया। मेरा नियोक्ता मुझे सीखने के लिए भुगतान करने की उम्मीद नहीं करता है। im दिन के अंत में एक नौकरी करने की उम्मीद है। कोई भी समय काम करने वाले वातावरण में समय बर्बाद नहीं करता है एक समाधान खोजने की कोशिश करें। कुछ ऐसा है जो मैं समय पर उठाऊंगा, उम्मीद है कि जल्दी से अगर मैं क्या करूं किसी भी अच्छे की नकल करता हूं।


9
एक तरह से या किसी अन्य नियोक्ता ने आपको सीखने के लिए भुगतान किया है
smp7d

13
यदि आप कभी भी जूनियर प्रोग्रामर के रूप में काम पर रखे गए थे तो आप अपने नियोक्ता से कम मूल्य के हैं।

10
अधिकतम, आप गलत हैं, जब तक कि आपके पास एक भद्दा नियोक्ता नहीं है। अच्छे नियोक्ता आपको नौकरी पर, या यहां तक ​​कि सम्मेलनों या कक्षाओं में भेजकर सीखने का भुगतान करेंगे। यदि आप अपने वर्तमान रवैये के साथ रहते हैं, तो कभी भी जूनियर डेवलपर होने की अपेक्षा नहीं करें। कनिष्ठ / वरिष्ठ जैसे टाइटल उस समय के आधार पर नहीं सौंपे जाते हैं, जब आप कुछ कर रहे होते हैं; यदि आपने एक ही समय में एक ही काम किया है, लेकिन सीखा नहीं है तो भी आपको जूनियर माना जाएगा।
एंडी

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

6
यदि आप एक समाधान "प्लेट पर" चाहते हैं तो आप कभी भी जूनियर डेवलपर के रूप में अपनी स्थिति से बाहर नहीं बढ़ेंगे। आपको दिए गए पूर्ण समाधानों से सीखना संभव हो सकता है लेकिन यह निश्चित रूप से प्रभावी नहीं है । यह मस्तिष्क कैसे काम करता है: यदि आप समाधान का रास्ता अनुभव करते हैं, न कि केवल समाधान ही, तो आप समाधान को केवल किसी और के सामने प्रस्तुत करने का अध्ययन करने की तुलना में बहुत अधिक सीखेंगे ।
पेरडियन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.