एक अच्छा टीम प्लेयर कैसे बनें? [बन्द है]


19

मैं प्रोग्रामिंग (जुनूनी) कर रहा हूं क्योंकि मैं 12 साल का था। मैं विधानसभा से, सी ++, जावास्क्रिप्ट, हास्केल, लिस्प और क्यूई तक, वहां की भाषाओं के स्पेक्ट्रम के बारे में काफी जानकार हूं। लेकिन मेरी सभी परियोजनाएं स्वयं द्वारा की गई हैं।

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

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

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

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

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

प्रश्न: कुछ कदम क्या हैं जिन्हें मैं बाकी सभी के साथ "एकीकृत" करने के लिए शुरू कर सकता हूं?

धन्यवाद!


मैं कहता हूं कि पहला कदम प्रोग्रामिंग का अध्ययन करना है ताकि आप कम से कम एक ही भाषा बोल सकें।
रिग

क्या आपके द्वारा उपयोग किए जाने की तुलना में आप एक बड़े कोडबेस के साथ एक परियोजना को कैसे एकीकृत करेंगे, इस बारे में अधिक सवाल नहीं है?
लुई कोट्टमन जुएल

3
"... यह परियोजना बहुत यूनिक्स-वाई होने वाली है, इसलिए मैंने एक मैक खरीदा ..." क्या मुझे कुछ गलत समझा गया है, या यह एक टाइपो है?
स्टु पेग

4
@StuartPegg: मैक ओएस एक्स एक * निक्स है, जो शेल टर्मिनल में बनाया गया है, हालांकि मैं इस पर मैकप्रर्ट स्थापित करने की सलाह दूंगा यदि आप * निक्स पक्ष का भारी उपयोग करना चाहते हैं।
डेव शेरोहमान

1
मुझे याद है एक बार अमेरिकन पाई फिल्म में कहा गया था कि "जब तक आप स्कोर नहीं करते तब तक आप स्कोर नहीं करते"। तो जैसे तैलानी ने कहा कि एक टीम का हिस्सा बनें। :)
asakura89

जवाबों:


13

मुझे लगता है कि आप एक समूह के लिए काम करने में उत्सुक और उत्साहित दोनों हैं।

हम में से किसी ने पुस्तकों से किसी समूह या टीम में काम करना नहीं सीखा या किसी भी बच्चे को कदम या "डमीज़ गाइड टू वर्किंग टू टीम्स" दिया गया।

हम सिर्फ समूहों में काम करके समूहों के साथ काम करना सीखते हैं।

जो कुछ भी आपने पेशेवर प्रोग्रामर के बारे में सुना है, वह धीरे-धीरे टीम में काम करते समय गिर जाएगा .. आप उन सभी के बारे में एक-एक करके सीखेंगे जैसे कि संस्करण को नियंत्रित करना, यूनिट परीक्षण आदि।

मेरे लिए, नीचे की रेखा है

एक टीम का हिस्सा बनें।


8

मैं आपके कुछ वाक्य चुनने जा रहा हूँ और कुछ सामान्य बिंदु बना रहा हूँ:

(दूसरी ओर, उन्हें पता नहीं था कि लेक्सिकल स्कूपिंग या क्लोज़र क्या थे)। हमारे सभी कोड अच्छी तरह से काम करते थे, लेकिन वे मेरा नहीं समझते थे, और मैं उनकी समझ में नहीं आया।

...

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

...

मैं यह जानने की कोशिश कर रहा हूं कि ये सभी नामांकित निर्देशिकाओं और फाइलों को कैसे कनेक्ट करते हैं ... मुझे अक्सर लगता है कि कुछ लाइब्रेरी को विच्छेदित करने में घंटों बिताने की तुलना में खुद को कार्यक्षमता लिखना बहुत जल्दी है।

मुझे लगता है कि सबसे बड़ी एक चीज जो आपको सीखने की जरूरत है वह यह है:

डेवलपर की क्षमता की दी गई मानक के लिए, की एक टीम nडेवलपर्स करता है कम से nबार काम डेवलपर्स में से एक अकेले कर सकता है कि - लेकिन वे अभी भी कर किसी एक व्यक्ति कर सकता है और अधिक से अधिक करना

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

अन्य महत्वपूर्ण बात यह है:

आपके कुछ सहकर्मी आपसे कम सक्षम होंगे, निश्चित रूप से कुछ कौशल में; कुछ भी सभी कौशल में आप की तुलना में कम सक्षम हो जाएगा

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

वास्तव में, मुझे लगता है कि एक टीम में काम करने का एकमात्र तरीका वास्तव में यह करना है; लेकिन उम्मीद है कि उपरोक्त आपको मानसिक रूप से तैयार करने में मदद करेगा। सौभाग्य!


4

सबसे कुशल तरीका एक टीम का हिस्सा बनना है।

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

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

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

बेशर्म प्लग: आपका यहाँ बहुत स्वागत है !


1

मैं इस बात को नहीं दोहराऊंगा कि बाकी सभी ने पहले से ही इसके प्रभाव के बारे में क्या कहा है "just do it", लेकिन मैं एक अतिरिक्त बिंदु जोड़ूंगा, जिसका मैंने उल्लेख नहीं किया है: एक अच्छा प्रबंधक वास्तव में आपको टीम को एकीकृत करने में मदद करेगा।

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


0

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

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

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

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

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

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


0

एक अच्छी टीम का सदस्य होने का मतलब है कि निडरता से संवाद करें, अपने कॉलेजों पर भरोसा करें और एक टीम के रूप में एक परियोजना में बाधाओं को दूर करें औरdeliver project as a team.

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

यह अच्छे टीम सदस्य के कुछ पात्रों को उजागर करने में मददगार होगा ।

a) अच्छी टीम का सदस्य वह व्यक्ति होता है जो आत्म-उन्मुख होने के बजाय लक्ष्य -उन्मुख होता है।

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

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


0

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

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

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

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