विकास करते समय सहकर्मियों के साथ व्यवहार करना, सलाह की आवश्यकता है [बंद]


20

मैंने अपनी वर्तमान परियोजना वास्तुकला को विकसित किया और इसे अपने दम पर विकसित करना शुरू किया (जैसे कुछ तक पहुंचना revision 40)

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

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

अब, क्या किया गया था:

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

मैं 12 दिनों से अनुपस्थित था


अब हमारे पास क्या है (परियोजना टीम के 4 अन्य सदस्यों द्वारा विकसित की गई थी):

  • 3 अलग कोडिंग शैलियों सभी परियोजना से अधिक (मुझे लगता है, उनमें से दो एक ही शैली :) का उपयोग करने के लिए सहमत है, वही हमारे कपोल-कल्पना के नामकरण पर लागू होता है (उदाहरण के लिए CommonPathData.h, SubwaySchemeStructures.h) , जो मूल रूप से कुछ डेटा संरचनाओं की घोषणा हेडर हैं।
  • हाल ही में लागू किए गए भागों के लिए प्रलेखन की पूर्ण कमी।
  • क्या मैं हाल ही में कॉल कर सकता है single-purpose-abstractionअब कम से कम 2 अलग-अलग प्रकार की घटनाओं को संभालता है, अन्य भागों के साथ तंग युग्मन है और इसी तरह।
  • उपयोग किए गए इंटरफ़ेस में से आधे में अब सदस्य चर हैं (sic!)
  • कच्चे सूचक उपयोग लगभग हर जगह।
  • इकाई परीक्षण अक्षम किया गया, क्योंकि " (Rev.57) They are unnecessary for this project"।
  • ... (यह शायद सब कुछ नहीं है)

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

अब - परियोजना अभी भी केवल एक छोटी राशि का करती है कि उसे क्या करना है, हमारे पास गंभीर एकीकरण समस्याएं हैं, मुझे लगता है कि कुछ मेमोरी लीक हैं।


क्या इस मामले में कुछ भी संभव है?

मुझे एहसास है कि मेरे सभी प्रयासों का कोई लाभ नहीं हुआ, लेकिन समय सीमा बहुत जल्द है और हमें कुछ करना है। क्या किसी के पास भी ऐसी ही स्थिति थी?

मूल रूप से मैंने सोचा था कि एक अच्छा (अच्छा, मैंने वह सब कुछ किया जो मैं कर सकता था) परियोजना के लिए शुरू करना शायद कुछ अच्छा होगा, हालांकि, मैं समझता हूं कि मैं गलत हूं।


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

क्या आप कृपया अपने प्रश्न का शीर्षक सुधार सकते हैं? वर्तमान शीर्षक अस्पष्ट है और वास्तव में आपके प्रश्न की विशेषता नहीं है।
रॉबर्ट हार्वे

1
हाय Yippie- काई-यय, यह आपके प्रश्न से स्पष्ट नहीं है कि आप हमसे जो व्यावहारिक, हल करने योग्य समस्या पूछ रहे हैं। Programmers.SE एक चर्चा बोर्ड नहीं है जहां आप दिन की समस्याओं के बारे में शेख़ी कर सकते हैं : क्या आप उस विशिष्ट समस्या की पहचान कर सकते हैं जिसके लिए आपको एक विशेषज्ञ प्रोग्रामर की मदद चाहिए और उसके बारे में पूछना चाहिए?

1
@ मर्क मुझे लगता है कि अगर कम से कम 12 लोग सोचते हैं कि यह विषय उपयोगी है और चर्चा करने के लिए कुछ है, तो इसे बंद करना सिर्फ अजीब है।
यिप्पी-काई-याय

1
मुझे लगता है कि यह एक प्रासंगिक प्रश्न (केवल बंद होने के बजाय) में बन सकता है जो परियोजना प्रबंधन और टीम के काम से संबंधित है जो प्रोग्रामिंग और विकास के महत्वपूर्ण पहलू हैं।
रॉस

जवाबों:


18

गंदगी से बाहर निकलने के लिए निर्दयतापूर्वक रिफ्लेक्टर!

कोडिंग शैली को लें जो प्रयोग करने योग्य शैली के अधिकांश भाग के लिए जिम्मेदार है और इस परियोजना के लिए इसका उपयोग करें।

सबसे बुरी बात यह है, कि आपको 40 के संशोधन के लिए वापस रोल करना होगा, और आपके प्रोग्रामर के पास 12 दिन का प्रशिक्षण सत्र था, जिससे उन्हें विषय की बेहतर समझ मिली।

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


मुझे लगता है कि यह एकमात्र वास्तविक जवाब है, परिस्थितियों को देखते हुए।
रॉबर्ट हार्वे

जब मेरे पास ठोस परीक्षण होते हैं, तो बुरा कोड होने पर मैं सब कुछ तोड़ने में संकोच नहीं करता। यह परियोजना को बनाए रखने के लिए महत्वपूर्ण है।
deadalnix

@ डीड: उम्म, इसका क्या मतलब है?
रॉबर्ट हार्वे

@ रॉबर्ट खैर, सही ढंग से लिखे गए यूनिट-टेस्ट वास्तव में रिफैक्टरिंग के लिए बहुत अच्छे हैं, क्योंकि आप बहुत सारी चीजों को आसानी से बदल सकते हैं और फिर भी सुनिश्चित करें कि आपका प्रोग्राम सही है।
यिप्पी-काई-याय

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

10

आपके प्रश्न पर सवाल उठाते हुए - "मैं कुछ हफ़्ते के लिए दूर चला गया और अपनी टीम के साथ असहमत हो गया, जब मैं चला गया था, तो मैं उन्हें कैसे करूँ जो मैं यहाँ नहीं हूँ?"

मैंने इसे आपके सामने रखा है कि यह कोई तकनीकी समस्या नहीं है, यह एक प्रबंधन समस्या है। मेरा लेना (कृपया मुझे माफ कर दो अगर मैं गलत हूं) तो यह है कि आप तकनीकी समाधान को सेना की एक सेना के लिए निर्धारित करते हैं, जो किसी कारण से या तो आपके समाधान के साथ सहमत नहीं हो सकते हैं या नहीं समझ सकते हैं।

अगर 12 दिन में आपके डिजाइन को इतना नुकसान पहुंचता है, तो इसका एक कारण होना चाहिए। क्या डिजाइन नाजुक है? यह इंजीनियर पर है? या टीम ने सिर्फ इसे आउट ऑफ स्पिट किया? आपके डेडलाइन और डिलीवरी जैसे क्या हैं? तंग? क्या वे सिर्फ एक से मिलने की कोशिश कर रहे थे?

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

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


अच्छा विचार है, मुझे कुछ पुनर्विचार करना पड़ सकता है। धन्यवाद,।
यिप्पी-काई-याय

8

जोड़ी।

आप जो वर्णन कर रहे हैं, वह सही, तकनीकी रूप से, एकल करने का एक बहुत कुछ है । हां, आपने दस्तावेज़ बनाने की कोशिश की, मानकों को लागू करने की कोशिश की - लेकिन आप (जाहिरा तौर पर) संवाद करने में विफल रहे।

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


2
मैंने जोड़ी बनाने के बारे में बहुत सुना है, लेकिन मैंने कभी किसी को वास्तव में ऐसा करते हुए और लाभ प्राप्त करते हुए नहीं सुना है।
रॉबर्ट हार्वे

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

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

@ कार्ल मैनस्टर> यह सही जोड़े के साथ काम करता है। मैंने इसे कई बार सफलतापूर्वक किया, लेकिन अभी, मैं वास्तव में धीमा हूं और सोलो की तुलना में अपनी वास्तविक जोड़ी के साथ बदतर कोड का निर्माण कर रहा हूं। तो यह महत्वपूर्ण है, अगर पूंजी नहीं है, तो सही व्यक्ति के साथ जोड़ी बनाने के लिए।
deadalnix

@ कार्ल मैनस्टर - मुझे हमेशा आश्चर्य होता है कि लोग टीवी, रेडियो, मंचों, धार्मिक पंथों आदि पर कुछ करने की कोशिश करने पर जोर देते हैं , अन्यथा कोशिश को साक्ष्य के रूप में जाना जाता है, कुछ भी साबित करने का साधन नहीं है, यह एक तार्किक पतन है। पहले एक संगीन मामला बनाएं, फिर आप प्रयोगों के बारे में बात कर सकते हैं।
१v बजे जीन बुशुइव

7

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


3

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

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

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

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


2

एक बात जिसका मैंने उल्लेख नहीं किया है, लेकिन जो हाल ही में सामने आई है, जहां मैं काम कर रहा हूं "डेवलपर सिलोस" और "बाय इन"।

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

ठीक है, हम अभी उस पुस्तकालय के एक प्रमुख पुनर्लेखन के माध्यम से गए हैं जिसने यकीनन समग्र डिजाइन को बेहतर रूप से फिट करने के लिए सुधार किया है जो हम वर्तमान में कर रहे हैं, लेकिन फिर से एक डेवलपर ने पुस्तकालय को अपनी एकमात्र परियोजना के रूप में लिया, इस पर कई हफ्तों तक काम किया। तो बस इसे प्रस्तुत किया। "वोइला! यहाँ यह है! यह सुंदर नहीं है?"

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

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


1

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

यह देखते हुए कि आप एक तंग समय सीमा का सामना कर रहे हैं, आपको अपनी रिहाई के बाद कोड को फिर से भरना होगा, और रिफैक्टर (फिर से लिखना?) करना होगा।

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

संपादित करें:

मैं हाल ही में एक समान स्थिति में भाग गया। मेरी कंपनी के प्रबंधन ने जोर देकर कहा कि हम अपने आवेदन लिखने के लिए अनुबंध डेवलपर्स का उपयोग करते हैं। उनके द्वारा बनाया गया कोड भयानक था (कृपया इसे लगाने के लिए), लेकिन हम इसका इस्तेमाल करने के लिए मजबूर थे। आज तक, ठेकेदारों ने हमारे लिए लिखे गए कोड का 80% फिर से लिखा है। यह बग से भरा था और नई सुविधाओं के साथ विस्तार करना असंभव था। एक दो महीने में मेरी टीम ने इसे फिर से लिखा होगा, अनुबंध विकास में निवेश किए गए धन को प्रभावी ढंग से बर्बाद करने के लिए।

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


1

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.