सोलो .NET प्रोग्रामर एक टीम में जा रहा है [बंद]

Question

मैं पिछले 8 वर्षों से छोटे स्टार्टअप के लिए सोलो .NET प्रोग्रामर हूं। मैंने कुछ बहुत अच्छे सॉफ्टवेयर को एक साथ रखा है, और मैं हमेशा अपने आप को बेहतर बनाने का प्रयास करता हूं और सर्वोत्तम नियंत्रण के अनुरूप हूं, जिसमें स्रोत नियंत्रण (एसवीएन / एफएफएस) शामिल है। मैंने अन्य विषयों के इंजीनियरों की एक टीम के साथ मिलकर काम किया, लेकिन जब सॉफ्टवेयर में कमी आई तो मैं केवल एक प्रोग्रामिंग थी। मैं प्रोग्रामिंग के शिल्प को प्यार करता हूं और अपने टूल को तेज करने के लिए नई चीजें सीखना पसंद करता हूं।

2 सप्ताह में मैं 20 .NET डेवलपर्स की टीम में एक नया काम शुरू करूंगा। मेरी स्थिति मध्यम स्तर की होगी, और मैं अविश्वसनीय रूप से प्रभावशाली पृष्ठभूमि वाले कुछ प्रोग्रामर के तहत काम करूंगा। फिर से, विकास का टीम पहलू मेरे लिए नया होगा, इसलिए मैं कुछ सामान्य "नए आदमी" युक्तियों की तलाश कर रहा हूं जो मुझे गेट-गो से यथासंभव प्रभावी और आसान बनाने में मदद करेंगे।

कुछ भी हो जाता है, जिसमें उच्च स्तरीय युक्तियां, और संचार के बारे में दिन-प्रतिदिन की चीजें शामिल हैं।

Answer 1

ज्यादातर सामान्य ज्ञान लेकिन मेरी सलाह होगी:

तकनीक के बजाय लोगों के साथ पहले सप्ताह में ज्यादा से ज्यादा खर्च करें। अपने डेस्कटॉप या किसी और चीज़ को कस्टमाइज़ करने वाले पहले दिन को बर्बाद न करें जो आपको टीम से अलग कर देगा। जितनी जल्दी हो सके उतने साथियों के बारे में जान लें।

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

पहले कुछ हफ्तों में किसी भी सामाजिक कार्यक्रम में भाग लें, भले ही काम या दोपहर के भोजन के बाद सिर्फ एक बीयर।

चीजों को सुनो और लिखो, साथियों से पूछें कि प्रक्रियाओं का वर्णन दोहराने के लिए उन्हें क्या करना होगा।

पहले 3-6 महीने परिचित होने में बिताएं, जब तक कि किसी विशेष समस्या पर विशेष रूप से नहीं पूछा जाता है, प्रक्रियाओं / वास्तुकला / आदि में परिवर्तन दोबारा न करें। वे आपके लिए अलग तरह से काम करेंगे, और कुछ तत्व खराब हो सकते हैं - लेकिन इसके कारण भी होंगे और वे लापरवाही या अज्ञानता के कारण शायद ही कभी हों।

मुझे संदेह है कि प्रोग्रामिंग पक्ष वास्तव में एक समस्या होगी।

Comments

दोपहर के भोजन पर बीयर? आपको यूरोपीय होना चाहिए: पी ज्यादातर लोग सोचते होंगे कि मैं किसी तरह का शराबी हूं अगर मैंने यहां प्रशांत तट अमेरिका में ऐसा किया।

— एडवर्ड स्ट्रेंज

@ क्रेजी एडी: मैं कैनेडियन हूं, और मेरी कंपनी बीयर के लिए भुगतान करती है और इसे हर शुक्रवार को कार्यालय में लाती है ...

— स्टीवन एवर्स

@SnOrfus - मैंने वास्तव में कनाडा में दोनों चरम सीमाओं का अनुभव किया है। मुझे लगता है कि "स्वीकार्य बीयर" गिरावट में है।

— स्कॉट व्हिटलॉक

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

— maple_shaft

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

— एडवर्ड स्ट्रेंज

Answer 2

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

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

• कोड युद्ध धार्मिक युद्ध हैं। सिंटैक्स वहाँ पर कुछ हद तक अलग हो सकता है (क्या आप कोष्ठक कथनों को जोड़ने के लिए कोष्ठक जोड़ते हैं?) लेकिन यह शायद ही कभी लड़ने लायक हो।

• सामूहीकरण। अगर वे हर हफ्ते ड्रिंक कर रहे हैं तो इसमें शामिल होना सुनिश्चित करें। यह एक साथ खाने के रूप में सरल हो सकता है ।

Answer 3

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

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

Comments

ईमानदारी से मैं इसके चारों ओर उद्धरण जोड़ना नहीं चाहता था, क्योंकि मेरा दृढ़ विश्वास है कि सॉफ्टवेयर लिखने का एक सही और गलत तरीका है, लेकिन मुझे उस पुराने तर्क को खारिज करने का मन नहीं था :)

— वेन मोलिना

Answer 4

जोनो के अलावा, मैं कहूंगा:

बदलाव के लिए तैयार रहें। हर टीम अलग काम करती है। गुड SW टीमों में कोडिंग नियम होते हैं। उन्हें स्वीकार करने के लिए तैयार रहें, भले ही शुरू में वे अजीब लगें।

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

Answer 5

बात करने से ज्यादा सुनो।

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

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

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

जब तक आप व्यक्तित्व और इतिहास को शामिल नहीं करते तब तक कोड की आलोचना न करें। आप नहीं जानते कि आप किसका अपमान कर रहे हैं।

Answer 6

प्रश्न पूछें और उत्तर सुनें। अगले प्रश्न पूछने से पहले पिछले प्रश्नों के उत्तर के बारे में सोचें ताकि आप उत्तर का अनुमान लगाने की कोशिश कर सकें।

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

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