प्रकाश को देखने के लिए कॉपी / पेस्ट / स्पेगेटी प्रोग्रामर कैसे बदलें?


35

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

तो मान लें कि आपके पास आपकी टीम (या शायद बहुमत) पर कोई है जो मानक संचालन प्रक्रिया को कॉपी / पेस्ट करना चाहता है और जो मानता है कि सब कुछ हल किया जा सकता है यदि केवल आप पर्याप्त फ़ंक्शन कॉल और चर जोड़ते हैं। जब वे काम में व्यस्त होते हैं, तो इस व्यक्ति ने टीडीडी, डीआरवाई या एसओएलआईडी और 40 घंटे के बाहर कभी नहीं सुना, वे कभी भी एक ही कार्यप्रणाली / प्रैटिस / डिजाइन बुक नहीं पढ़ते हैं।

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

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

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

क्या इन स्थितियों में कुछ भी किया जा सकता है? क्या कोई सफल हुआ है? या इस तरह की मानसिकता को परियोजना के गैर-महत्वपूर्ण हिस्सों में अलग करना और क्षति को कम करना सबसे अच्छा है?

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


यह कौन सा देश है?

3
@ ThorbjørnRavnAndersen - यूएसए। अब आपको एक प्रतिक्रिया लिखनी होगी क्योंकि मैं बहुत उत्सुक हूं कि उस जानकारी के टुकड़े ने इसे कैसे प्रभावित किया :) मैं हमेशा यद्यपि हम सभी मानव थे और इस प्रकार का सामान सार्वभौमिक था। और नहीं, इस सवाल का आउटसोर्सिंग से कोई लेना-देना नहीं है।
DXM

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

जवाबों:


18

आपने खुद को इसका कारण पाया: "मुझे पता है कि वे सीखने में सक्षम हैं, बस लगता है कि प्रेरणा की सामान्य कमी है।"

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

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

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

आप अपने सहयोगियों को स्वयं प्रेरित करने का प्रयास कर सकते हैं, लेकिन यह बहुत कठिन है। यदि आप उन्हें पढ़ने के लिए किताबें देते हैं, तो वे कुछ हफ्ते बाद उन्हें वापस लौटा देंगे। यदि आप उन्हें एक सलाह देते हैं, तो वे नहीं सुनेंगे, क्योंकि वे परवाह नहीं करते हैं।

आप ऐसा कर सकते हैं:

  • अपने बॉस को अपनी कंपनी में कई कठोर नियम निर्धारित करने के लिए मनाएं: स्टाइल दिशानिर्देश , आदि। यह उन लोगों को बेहतर काम करने के लिए प्रेरित नहीं करेगा, लेकिन कम से कम वे स्रोत कोड नहीं बना पाएंगे जो आवश्यकताओं से मेल नहीं खाते हैं ।

  • आवश्यकताओं, विशेष रूप से गैर-कार्यात्मक आवश्यकताओं पर काम करें । एक आवश्यकता के बारे में जो बताता है कि एक विशिष्ट परियोजना में IL कोड की 5 000 से कम लाइनें होनी चाहिए (नहीं, मैं अर्थहीन LOC की बात नहीं कर रहा हूं ) tells? चक्रवाती जटिलता या वर्ग युग्मन पर विशिष्ट परिणाम प्राप्त करने की आवश्यकता के बारे में क्या ?

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

  • [अधिक] जोड़ी प्रोग्रामिंग का उपयोग करें । यह कोड की गुणवत्ता में सुधार करने और कम प्रेरित सहकर्मियों को प्रेरित करने में मदद कर सकता है।

  • फॉग क्रीक में जो उपयोग किया जाता है, उसी के समान मुआवजा प्रणाली का उपयोग करें ।


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

Money वे वास्तव में परवाह नहीं करते हैं, भले ही वे कम पैसे हासिल करें। मैं अपने एक ग्राहक (मैं एक फ्रीलांसर हूं) के बहुत करीब हूं जो मानता है कि उसका काम अपने ग्राहकों के लिए वेबसाइट विकसित करना है। उनका एक डिजाइनर भी है। मैंने उन्हें कई बार उन तरीकों के बारे में बताया जिनसे वे अपनी उत्पादकता को 2 या अधिक बढ़ा सकते हैं। यदि वे किसी सक्षम व्यक्ति को काम पर रखते हैं, तो वे अपने राजस्व में कम से कम 3. की ​​वृद्धि करेंगे। लेकिन उनके पास पर्याप्त धन है, और वे किसी भी उत्पादक की तुलना में अज्ञानी ग्राहकों को गुणवत्ता या कितना खर्च करते हैं, इसकी परवाह नहीं करते हैं।

³ मेरा क्या अर्थ है IL कोड की पंक्तियों की संख्या जो आप विज़ुअल स्टूडियो में कोड मेट्रिक्स में देखते हैं , मीट्रिक जो वास्तव में कुछ का मतलब है। असली एलओसी कोई फर्क नहीं पड़ता है और आप इसे मापने के लिए नहीं है; यह अब तक के सबसे बेवकूफ मेट्रिक्स में से एक है। कोड की IL लाइनों को लागू करने का अर्थ है कि डेवलपर्स को वास्तव में रिफैक्टर कोड के लिए मजबूर किया जाएगा, और न केवल एक अपठनीय लाइन में कोड की दस पंक्तियों को संक्षिप्त करने के लिए।


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

5
@maple_shaft सही है: कुछ लोग 70 घंटे-सप्ताह काम करते हैं और बिना किसी परीक्षण के सबसे खराब मात्रा में स्पेगेटी कोड का उत्पादन करते हैं (उनके पास इस तरह के बकवास के लिए समय नहीं है!)। जबकि भावुक होते हैं और लगातार अपने कौशल में सुधार करते हैं, लेकिन 40 घंटे बाद घर जाते हैं, क्योंकि वे जानते हैं कि वे वैसे भी लंबे समय तक उत्पादक नहीं हो सकते हैं। दो चीजों को मत मिलाओ!
nikie 12

13
नहीं नहीं नहीं। एक नियोक्ता द्वारा शोषण किए जाने की इच्छा! गुणवत्ता कोड का उत्पादन करने की क्षमता। इस तरह से बहुत ज्यादा है "रहने के लिए 2:00 तक इसे पूरा करने के लिए" हमारे उद्योग में पहले से ही हमारे पौराणिक आदर्श डेवलपर के साथ यह कहे बिना बकवास हो रहा है। यदि आप 80 घंटे के सप्ताह में काम करना पसंद करते हैं, तो आपके लिए अधिक शक्ति है। मेरे पास ऐसी चीजें हैं जो मेरे लिए काम के अलावा महत्वपूर्ण हैं। यह निष्कर्ष निकालने के लिए कि मैं जो कुछ भी करता हूं, उस पर बुरा हूं क्योंकि यह सबसे अच्छा है। हमारे साथ जो मिलता है, उससे कोई दूसरा उद्योग नहीं हटता है, और अगर यह बदलने वाला है तो हमें इसे बदलना है।
दान रे

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

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

12

"मैंने कोडिंग की है, बस DXM को खुश करने के लिए रिफ्लेक्टर और कई वर्गों में विभाजित करने की आवश्यकता है"।

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

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

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

आप टीम को इंगित करके सर्वोत्तम प्रथाओं और मानकों का समर्थन करते हैं कि उन्होंने सॉफ्टवेयर विकास प्रक्रिया या सॉफ्टवेयर की गुणवत्ता में कैसे सुधार किया है।

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

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

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


1
सिद्धांतों के बजाय रिश्तों पर ध्यान केंद्रित करने पर जोर देने के लिए +1
सूर्यवुंग

5

अच्छा प्रश्न! मुझे लगता है कि उत्तर इस बात पर निर्भर करता है कि लोग अपने कौशल में सुधार क्यों नहीं करना चाहते हैं। संभावित उत्तर हैं:

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

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


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

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

3

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

बस! यह वास्तव में एक वास्तविक प्रश्न है।

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

तो सवाल है कि मैं उन्हें करने के लिए कैसे उन्हें सिखाने के लिए नहीं है - लेकिन उन्हें कैसे सीखें? अंतर सूक्ष्म है लेकिन यह है कि सभी अंतर बनाने जा रहा है।

मुझे नहीं पता कि क्या मैं सही हूँ; लेकिन अक्सर मैं एक मैट्रिक्स फिल्म के एक संवाद में विश्वास करता हूं - "यह सवाल है जो हमें ड्राइव करता है!" उन्हें सोचने के लिए सबसे महत्वपूर्ण क्या है, उनसे पूछें कि क्यों! और निश्चित रूप से, जो ज्यादातर सोचते हैं कि वे पहले से ही कुछ डिजाइन पैटर्न के बारे में सब कुछ जानते हैं क्योंकि उन्हें विश्वविद्यालय के पाठ्यक्रमों में अच्छे अंक मिले हैं - वहां सबसे कठिन हैं।

आप उनसे इस तरह के सवाल कैसे कर सकते हैं? मेरा सामान्य दृष्टिकोण "यह है कि यदि आप उन्हें तैरना सीखना चाहते हैं तो तालाब में फेंक दें" । मैं सहमत हूं कि लोग असहमत हो सकते हैं; और मैं ख़ुशी-ख़ुशी उनसे सहमत हो जाऊँगा। जब आप उन्हें तालाब में फेंकते हैं - वे वास्तव में स्वचालित रूप से तैरना नहीं सीखते हैं; लेकिन यह एक अस्तित्व वृत्ति को उगलता है जो उन्हें लगता है - एक बार ऐसा होता है कि वे स्वाभाविक रूप से HOW और WHY के बारे में क्या सोचते हैं।

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

यह थोड़ा चरमपंथी लग सकता है, यह संसाधनों की बर्बादी लग सकता है । और मुझे यकीन है, कई अन्य लोग हैं जो मुझे ऐसा नहीं करने की सलाह देंगे। लेकिन यह मेरे लिए काम किया है!

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

पुनश्च: बस संयोगवश मैंने यहाँ एक जवाब पोस्ट किया https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - और मैं सभी को कोसने लगा; मुख्य रूप से अधिकांश लोगों का मानना ​​है कि किसी भी तरह से व्यवसाय संसाधनों को बर्बाद नहीं कर सकते हैं! मुझे यकीन है, इस जवाब से यहां भी ऐसा ही इलाज हो सकता है। लेकिन सच्चाई यह है कि लोगों को काम करने के लिए और उन्हें एक अच्छा काम करने में विश्वास करने के लिए मानव मनोविज्ञान का विषय है कि पाठ्यक्रम के पाठ्यक्रम को कैसे तैयार किया जाए।

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


मैट्रिक्स लाने के लिए धन्यवाद, अब मुझे अपने जीवन के 2 घंटे इसे फिर से देखने में बिताना होगा :) यह मज़ेदार है लेकिन मैंने पाया कि "फ्रेशर्स" वे हैं जो आपके द्वारा फेंके गए किसी भी चीज़ को अवशोषित करेंगे। खुद सीएस प्रोग्राम के स्नातक होने के बाद, मैं यह स्पष्ट करता हूं कि मैं उनकी "शिक्षा" के बारे में क्या सोचता हूं और ज्यादातर वे मेरे साथ सहमत हैं। मुझे लगता है कि सबसे बड़े मुद्दे वे लोग हैं जो 10, 15, 20+ वर्षों से ऐसा कर रहे हैं। मैं आपके "आग से परीक्षण" दृष्टिकोण से भी सहमत हूं। ठीक इसी तरह मैंने सीखा कि क्या नहीं करना है। समस्या यह है कि) एक टीम को काम करने में ज्यादा समय नहीं लग सकता है और ख) एक टीम में काम कर सकती है ...
डीएक्सएम

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

@DXM मैं आपकी चिंताओं से सहमत हूं जो बेहतर है कि एक बार में पूरी टीम को तालाब में न फेंकें । हाँ। मुद्दा यह है कि उनमें से कुछ को एक-एक करके फेंकना शुरू करें! कम से कम हमारे बीच एक अच्छा समझौता है। मुझे लगता है कि जो मानसिकता कई वर्षों से बढ़ी है - उसे बदलने में कुछ समय और दृढ़ता लगेगी।
दीपन मेहता

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

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

2

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


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

1
खैर, फिर हर पेशे की तरह, हर कोई घंटी की वक्र के शीर्ष आधे पर नहीं जा रहा है। यह संभव है कि आपके पास केवल पेचेक के लिए कुछ लोग हैं।
ग्रैंडमास्टरबी

आप जानते हैं, हर साल हम एक टीम उद्धरण चुनते हैं और 2011 का "यह वही है जो यह है", लेकिन हम एक नया साल शुरू करने वाले हैं और कम से कम समय के लिए, मैं यह मानने से इनकार कर दूंगा कि यह क्या है, हालाँकि मैं आपसे सहमत हूँ कि अधिकांश समय यह वास्तव में है। मैं इस प्रश्न के बारे में अधिक सोच रहा हूं और वास्तव में एक विचार है जो संभावित हो सकता है। चूँकि मैं अपने स्वयं के प्रश्न (व्यक्तिगत चीज़, सिस्टम लिमिटेशन नहीं) का जवाब नहीं दे सकता, अगर 2 और लोग प्रोग्रामर को फिर से खोलने के लिए वोट देते हैं
।stackexchange.com

2

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

इसलिए, आप दावा करते हैं कि आप चाहते हैं कि टीम में सुधार हो, आप उनका समझौता करें कि यह एक अच्छी बात है (कि टीम, समग्र रूप से, अपने कोड की गुणवत्ता में सुधार करने के लिए काम करती है) और आप इसे बनाने के लिए एक कार्यक्रम शुरू करते हैं। ऐसा होता है - यह इतना आसान लगता है ... मुझे पता है कि यह नहीं है!

मुझे लगता है कि इसके दो भाग हैं - शिक्षा और काम करने के तरीके।

  • शिक्षा आप एक सप्ताह में एक बार शुरू कर सकते हैं - हर कोई एक साथ खाता है, आप क्यू एंड ए के साथ 20 ~ 30 मिनट की प्रस्तुति चलाते हैं। आप उन मूल बातों के साथ शुरू करते हैं जो आप चाहते हैं - SOLID पहले 2 ~ 4 सप्ताह तक कब्जा कर सकता है - समय के साथ आपको रोटेशन में बोलने के लिए टीम मिलती है और आप यह तय कर सकते हैं कि कैसे तय किया जाए कि आप दोनों के बीच क्या बातचीत है। वक्ताओं को काम के भीतर कुछ प्रस्तुत करने का समय दें। इससे परे कि स्थानीय उपयोगकर्ता समूहों की उपस्थिति को प्रोत्साहित करें (यदि संभव हो तो इसे कम से कम आंशिक रूप से सामाजिक चीज़ बनाकर)
  • काम करने के तरीके ... अच्छी तरह से यह निर्भर करता है कि आप अभी क्या करते हैं और आपको क्या टूल मिला है, लेकिन आप कोडिंग मानकों पर सहमत होते हुए देखना चाहते हैं, सहकर्मी कोड की समीक्षा (यह ठोस है), इकाई परीक्षण (जरूरी नहीं कि पहले परीक्षण करें) एक निरंतर एकीकरण सर्वर चलाने और अधिक स्वचालित परीक्षण (इकाई परीक्षणों के अलावा) को देख रहा है। लेकिन इन्हें सहमति / समझौते (बिल्ड / सीआई सर्वर नहीं!) के साथ पेश किया जाना है और आपको एक टीम के रूप में गुणवत्ता को आगे बढ़ाना है। वहाँ हमेशा चीजें हैं जो एक सुधार कर सकते हैं (Kaizen)

इसकी कीमत कानबन (जो कि परिवर्तन / सुधार के लिए एक चालक के रूप में देखी जाती है) को देखने लायक है।

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


0

मैं ~ 30 साल पहले दुर्घटना से प्रोग्रामिंग में गिर गया। मुझे अन्य लोगों के कोड को बनाए रखने / समर्थन करने के लिए सौंपे जाने से बुनियादी सॉफ्टवेयर इंजीनियरिंग सिद्धांतों को सीखने के लिए प्रेरित किया गया था। इन असाइनमेंट में, मैंने सीखा कि कैसे एक कोड रीडर कोड का अनुभव करता है - कोड रीडर के साथ सहानुभूति कैसे करें। मैं अपने खराब लिखे कोड के दर्द को दूसरों पर नहीं डालना चाहता था!

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


1
मैंने वैसे ही शुरुआत की, हालांकि दुर्घटना से नहीं। यह बहुत कुछ वैसा ही है जैसा दीपन मेहता ने अपने पोस्ट में कहा। आप एक व्यक्ति को तालाब में फेंक देते हैं, यह सुनिश्चित करते हुए कि यह बहुत गहरा नहीं है, और उन्हें तैरने दें। आप उनमें से एक थे जिन्होंने तैरना सीखा, लेकिन यह सार्वभौमिक नहीं है (उनके उत्तर w / टिप्पणियों को देखें)। इसके अलावा, मेरा मानना ​​है कि इस तरह का दृष्टिकोण नए लोगों के लिए बेहतर काम करता है, जिनकी पहले से ही आदतें हैं। फिर, न केवल उन्हें तैरने की आवश्यकता है, बल्कि यह स्थापित प्रथाओं की वर्तमान स्थिति के भी खिलाफ है।
DXM
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.