नए वरिष्ठ डेवलपर कार्य

Question

मुझे एक वरिष्ठ डेवलपर मिला है जो आठ साल के नेट अनुभव के साथ कल से 11,000-लाइनों के-कोड एप्लिकेशन पर काम करना शुरू कर रहा है। टीम में खुद और एक अन्य प्रोग्रामर है। हम दोनों को लगभग तीन साल का अनुभव मिला है।

यह एक प्रबंधक के रूप में मेरी पहली परियोजना है (मैं परियोजना पर एक डेवलपर भी हूँ) और यह पहली बार है जब मैंने कभी किसी को पहले से स्थापित कोड आधार से परिचित कराया है। जाहिर है मैं प्रत्येक मॉड्यूल, परिनियोजन प्रक्रिया, आदि पर जा रहा हूं, और उन्हें स्रोत नियंत्रण रिपॉजिटरी, प्रलेखन (जो सबसे अच्छा नहीं है), आदि का स्थान सौंप रहा हूं।

नई सुविधाएँ लिखने और बग को ठीक करने के लिए तैयार होने से पहले मुझे उन्हें कब तक देना चाहिए?

Comments

यह वास्तव में निर्भर करता है कि कोड की 11,000 लाइनें कितनी जटिल हैं। मैं 8 साल के साथ किसी से अपेक्षा करूंगा (इसका मतलब है कि उन्होंने 2003 में इसका इस्तेमाल शुरू किया था) एक सप्ताह के भीतर पूरी गति से चलने में सक्षम होने के लिए।

— रामहाउंड

डेटा बिंदु के रूप में, कुछ हफ्ते पहले, हमने एक डेवलपर को जावास्क्रिप्ट कोड की 13,700 लाइनों के साथ एक परियोजना के लिए आश्वस्त किया था और यह मान लिया था कि वह स्प्रिंट (एक सप्ताह) में उत्पादक होगा, इसके बारे में भी वास्तव में सोचने के बिना।

— रोबोट

@StevenBurnap: मुझे यह पसंद है :) अपने पैरों को आग पर जलाएं और देखें कि क्या वह घर को जला देता है।

— जोएल एथरटन

क्या मैं वास्तव में केवल एक है जो सोचता है कि 11k लाइनें ज्यादा नहीं हैं? मैं एक दिन दिया होगा, मेरे दिल की सरासर अच्छाई से बाहर।

— लुई कोट्टमन

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

— डेवलपर

Answer 1

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

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

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

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

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

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

Comments

यह एक महान जवाब है, विशेष रूप से कोड की समीक्षा और परियोजना की वर्तमान स्थिति पर देवों की राय के बारे में। सौभाग्य से यह एक विरासत परियोजना नहीं है, यह वास्तव में बहुत नया है, और बहुत तेज गति से आगे बढ़ रहा है।

— मृ.लिज़

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

— डंक

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

— डीजेकेवर्थ

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

— HLGEM

@ डंक: मेरे अनुभव में, यहां तक ​​कि दुनिया के सबसे बुरे लोग भी एक साक्षात्कार के दौरान कुछ घंटों के लिए खुद का व्यवहार कर सकते हैं, जब वे नौकरी के लिए बेताब होते हैं। यही कारण है कि नए हायर के साथ कॉन्ट्रैक्ट-टू-हायर, इंटर्नशिप और कोड नमूने इतने महत्वपूर्ण हैं।

— जॉर्डन

Answer 2

उन्हें छोटे कार्यों पर तुरंत शुरू करें - जिन चीजों के लिए बड़ी तस्वीर की आवश्यकता नहीं है।

जैसा कि वे कोडबेस के साथ अधिक आत्मविश्वास और परिचित हैं, उन्हें बड़े और बड़े कार्यों में स्नातक करें। कितनी तेजी से होता है यह ज्यादातर उन पर निर्भर करता है।

Comments

यह बहुत ज्यादा मैं क्या सोच रहा हूँ।

— MrBliz

+1, यह एक ब्रेनर है, खासकर जब से कोड आधार छोटा है।

— लुई कोट्टमन

Answer 3

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

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

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

Comments

+1 जितनी जल्दी नया भाड़ा परियोजना के माध्यम से स्थानांतरित करना शुरू कर सकता है, उतनी ही जल्दी नया किराया आरामदायक होगा (स्वामित्व / जवाबदेही लेने के लिए) जो वे कर रहे हैं।

— चाड हैरिसन

Answer 4

कितना लंबा?

रस्सी कब तक है?

जब वह सहज होता है: जब वह अपनी पहली बग को ठीक करता है -> वह तैयार है ।

Answer 5

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

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

Answer 6

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

मैंने कई बार नौकरियां बदली हैं और पहले सप्ताह के भीतर इन सभी में मेरा योगदान रहा है। सबसे कठिन कोड को संकलित करने के लिए मुझे एक सप्ताह का समय लगा (कम से कम कोड की 100k + लाइनें)। एक पूर्ण निर्माण में उस परियोजना के लिए 8 घंटे लगे।

मैंने पहले सप्ताह 80 घंटे की तरह कुछ काम किया (परियोजना गंभीरता से पीछे थी)।

Comments

दिलचस्प है कि हर कोई इसे एक आदमी मान रहा है ... :)

— MrBliz

1. मैं कहूंगा कि डिफ़ॉल्ट सर्वनाम पुल्लिंग है, टाइपिंग "वह या वह" हर समय उचित होगा लेकिन अधिकांश लोगों की तुलना में अधिक प्रयास करना चाहते हैं। 2. प्रोग्रामर कितने प्रतिशत महिला हैं? इस मामले में मर्दाना करने के लिए डिफ़ॉल्ट रूप से इसके पक्ष में आंकड़े हैं ... इसलिए मैं एक यादृच्छिक व्यक्ति को संदर्भित करने के लिए डिफ़ॉल्ट सरल तरीके का उपयोग करने की कल्पना करूंगा, विशेष रूप से यह नहीं मान सकता कि वे पुरुष या महिला हैं।

— थाइमिन

मैं एक लड़का हूँ और इसलिए हर किसी को बहुत :-) होना चाहिए। बस मेरे लिखने का तरीका, मैं इतना अनुशासित नहीं हूं कि वह हर समय लिख सकूं।

— बिल लीपर

Answer 7

एक ऐप के लिए जो छोटा है, और एक डेवलपर जो अनुभव करता है, मुझे लगता है कि एक दिन बुनियादी कीड़े के लिए पर्याप्त है। एक सप्ताह के करीब (एक बार समस्या डोमेन और वास्तुकला पर स्पष्ट होने पर) बग या छोटी विशेषताएं शामिल हैं।

Comments

मुझे लगता है कि मेरे मानक शायद बहुत अधिक हैं, लेकिन तुम्हारा ... 1 दिन ... और 1 सप्ताह वास्तव में उत्पादक होने के लिए? IME, यह बहुत यथार्थवादी नहीं है।

— डंक

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

— तेलस्टिन

हां गंभीरतापूर्वक। 11k एलओसी बहुत बड़ा नहीं है। उसे सेट अप करें ताकि यह डिबगर में बनता है और चलता है और फिर उसे दिखाता है कि यह कैसे काम करता है। इतना काफी होना चाहिए।

— gbjbaanb

Answer 8

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

यह वास्तव में उस कार्य पर निर्भर करता है जो आप उससे प्रदर्शन करने की अपेक्षा करते हैं।