एक अग्रणी प्रोग्रामर के लिए विकल्प जो प्रोग्रामिंग को अग्रणी बनाना पसंद करते हैं? [बन्द है]


19

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

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

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

मैंने प्रबंधन में किसी के साथ इस बारे में चर्चा नहीं की है क्योंकि मुझे लगा कि मुझे कम से कम एक साल तक समायोजित करने की कोशिश करनी चाहिए।


"मैंने प्रबंधन में किसी के साथ इस पर चर्चा नहीं की है"। पृथ्वी पर क्यों नहीं ?? भागो, प्रबंधन और समझाने के लिए नहीं चलना। एक अच्छी कंपनी / अच्छा प्रबंधक हर किसी के लाभ को समझेगा और पुनर्व्यवस्थित करेगा - आपकी और उनकी। आप वैसे भी दूसरी तरह की कंपनी में काम नहीं करना चाहते हैं
मावग का कहना है कि मोनिका

जवाबों:


16

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

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

कुछ काम मैं करने की कोशिश कर रहा हूँ ...

  1. हर किसी को (प्रबंधन सहित) यह स्पष्ट करें कि मेरा और बाकी सभी का पद एक स्थायी कार्य नहीं है। सभी का प्लेट में कदम रखने, परियोजना के बारे में व्यापक विचार करने और वास्तुकला / डिजाइन निर्णयों में भाग लेने के लिए स्वागत है। मैं अंतिम (अब के लिए) कहूंगा कि अगर कोई संकल्प नहीं है, लेकिन अभी तक ऐसा नहीं हुआ है।
  2. अन्य लोगों को विकसित और विकसित होने में मदद करने पर ध्यान दें। कोडिंग और डिज़ाइन के बारे में अलग-अलग समय में अलग-अलग डेवलपर्स के साथ मैंने (लगभग दार्शनिक) चर्चा की है और चीजों को करने के लिए अलग-अलग दृष्टिकोण हैं। उन चर्चाओं में से कुछ वास्तविक काम से संबंधित हैं, अन्य शुद्ध विचार अभ्यास हैं। मेरे पास 20 से अधिक वर्षों के अनुभव वाला एक लड़का था, अपनी बुकशेल्फ़ पर वापस जाएँ और एक C ++ पुस्तक चुनें क्योंकि वह कुछ निम्न-स्तरीय सामानों के बारे में रुचि रखता था जो मैंने टेम्पलेट मेटा प्रोग्रामिंग के साथ किया था। ये चर्चाएँ कुछ हद तक संक्रामक हैं और जब आप इन विषयों को पर्याप्त रूप से उठाते हैं, तो लोग इस विषय पर स्वयं ही सोचना शुरू कर देते हैं।
  3. जितना मैं अन्य लोगों पर कर सकता हूं, उतना प्रतिनिधि करें। हालांकि मैं बहुत सी चीजों को देखता हूं, मैं हर एक कोड की समीक्षा में भाग नहीं लेता। इसके बजाय मैं अपने मध्यवर्ती लोगों के लिए कोड की समीक्षा करता हूं और मैं उन लोगों को कुछ हरियाणवी लोगों के लिए कोड की समीक्षा करने देता हूं। मैं कोड रिव्यू को एक नॉलेज ट्रांसफर टूल के रूप में देखता हूं, बजाय इसके कि "हम यह सुनिश्चित करें कि हम हर पंक्ति को पढ़ें और हर संभव बग को खोजें"।
  4. एक बार जब इंटरफेस परिभाषित हो जाते हैं और बुनियादी डिजाइन की जगह होती है, तो मैं नए लोगों को कक्षाओं की कोडिंग इंटर्नल के रूप में अधिक स्वतंत्रता देता हूं। हाँ, उस कोड का एक बहुत सही से दूर है, लेकिन यह परीक्षण किया जाता है और यह काम करता है। यदि यह "कोड गंध" के संदर्भ में एक निश्चित व्यक्तिपरक सीमा को पार कर जाता है और उन्होंने इसे वापस नहीं लिया है, तो मैं सुझाव दूंगा कि कुछ वर्गों को खंडित या पुनर्व्यवस्थित किया जाना चाहिए। यह कभी-कभी दर्दनाक होता है, लेकिन जब मैं कुछ दिनों बाद वापस जाँच करता हूं और एक प्रतिक्रिया मिलती है, "मुझे इसे स्वीकार करने से नफरत है, लेकिन यह कोड अब बहुत बेहतर लग रहा है", जो वास्तव में मुझे एक गर्म, फजी महसूस कराता है।
  5. लोगों को चुनौती दें। उन्हें उत्पाद में जोड़ने के लिए केवल सुविधा प्रदान करने के बजाय, उन सुविधाओं को जोड़ने के लिए कहें, लेकिन मौजूदा कक्षाओं में फ़ंक्शन / डेटा सदस्यों की संख्या में वृद्धि किए बिना ऐसा करें। यदि आपको कुछ नया करना है, तो आपको कुछ मौजूदा चीज़ों को लेना होगा, और यह जानने के लिए समय निकालना होगा कि यह क्या है। हर कोई रिफैक्टरिंग के बारे में जानता है, लेकिन शुरुआत में अतिरिक्त बल के बिना, ऐसा लगता है कि लोगों को वास्तव में इसे करने के लिए कूदने में मदद करने की आवश्यकता है। कम से कम, मैं इसे हर कोड समीक्षा के दौरान इस बिंदु पर जाने के लिए एक बिंदु बनाता हूं।
  6. सब कुछ BALANCE के बारे में है। आप टीम के एकमात्र वरिष्ठ व्यक्ति नहीं हो सकते जो बाकी सबको देख रहा हो। आप अपना पूरा सप्ताह बैठकों और समीक्षाओं में नहीं बिता सकते। आप उम्मीद नहीं कर सकते कि आप अपनी टीम की हर गलती को पकड़ लेंगे। दिन के अंत में, आपको अपने लीड होने के लिए समय आवंटित करने की आवश्यकता है, लेकिन आपको डेवलपर होने के लिए समय आवंटित करने की भी आवश्यकता है। अगर मैं कोड नहीं दे पाता तो मैं पागल हो जाता। यहां तक ​​कि सब कुछ के साथ, मैं अभी भी सुनिश्चित करता हूं कि मेरे पास कोड लिखने का समय है और न केवल कोड बल्कि कुछ वास्तव में, वास्तव में निफ्टी सामान। मैंने बस टेम्प्लेट मेटा प्रोग्रामिंग की किताबों पर हाथ डाला और बूस्ट के अंदर खुदाई शुरू कर दी। जो लोग उस सामान के साथ आए थे उन्हें पागल (एक अच्छे तरीके से) होना चाहिए। यदि आपका प्रबंधन आपको इस बारे में बताने में असमर्थ हो जाता है कि क्यों नहीं सब कुछ की समीक्षा की जा रही है या एक noob दूसरे नोब कोड की समीक्षा क्यों कर रहा है, आपको बस पूरी शेष बात समझाने की आवश्यकता है और यह कि टीम के पास पर्याप्त अनुभवी लोग नहीं हैं और दिन के अंत में "यह वही है जो यह है"। यदि आपकी टीम में वरिष्ठ लोग हैं, तो यह तब सशक्त होने का समय है और उन्हें अपने स्वयं के डिजाइन / समीक्षा / दूसरों की मदद करने की स्वतंत्रता दें और उन्हें केवल कोड जनरेटर के रूप में व्यवहार न करें। सशक्तिकरण के साथ स्वतंत्रता आती है और लोग स्वतंत्रता से प्यार करते हैं। यदि आपके पास ऐसे डेवलपर हैं जो स्वतंत्रता / सशक्तिकरण की परवाह नहीं करते हैं, तो यह ठीक है। हर टीम को अभी भी शुद्ध कोडर की आवश्यकता है, बस यह सुनिश्चित करें कि आप संतुलन के लिए प्रयास करते हैं। तब सशक्त होने और उन्हें अपने स्वयं के डिजाइन / समीक्षा / दूसरों की मदद करने और उन्हें केवल कोड जनरेटर के रूप में व्यवहार न करने की स्वतंत्रता देने का समय है। सशक्तिकरण के साथ स्वतंत्रता आती है और लोग स्वतंत्रता से प्यार करते हैं। यदि आपके पास ऐसे डेवलपर हैं जो स्वतंत्रता / सशक्तिकरण की परवाह नहीं करते हैं, तो यह ठीक है। हर टीम को अभी भी शुद्ध कोडर की आवश्यकता है, बस यह सुनिश्चित करें कि आप संतुलन के लिए प्रयास करते हैं। तब सशक्त होने और उन्हें अपने स्वयं के डिजाइन / समीक्षा / दूसरों की मदद करने और उन्हें केवल कोड जनरेटर के रूप में व्यवहार न करने की स्वतंत्रता देने का समय है। सशक्तिकरण के साथ स्वतंत्रता आती है और लोग स्वतंत्रता से प्यार करते हैं। यदि आपके पास ऐसे डेवलपर हैं जो स्वतंत्रता / सशक्तिकरण की परवाह नहीं करते हैं, तो यह ठीक है। हर टीम को अभी भी शुद्ध कोडर की आवश्यकता है, बस यह सुनिश्चित करें कि आप संतुलन के लिए प्रयास करते हैं।
  7. आपका समय मूल्यवान है। इसलिए टीम को उन सभी गैर-महत्वपूर्ण आलोचनात्मक प्रश्नों के ई-मेल करने के लिए कहें, जिनका उत्तर पाने से पहले वे कुछ घंटों तक प्रतीक्षा कर सकते हैं। जब सवाल पूछा जाता है, तो पूरी टीम को उस पर कॉपी किया जाना चाहिए। आखिरकार, जब आपके दिन का अवकाश होता है, तो आप इस मुद्दे पर एक नज़र डाल सकते हैं और उस व्यक्ति की मदद कर सकते हैं, लेकिन कई बार, कोई और आपको जवाब देने के लिए पहले ही पीट सकता है और आपको कुछ भी करने की ज़रूरत नहीं है। स्पष्ट रूप से नेतृत्व के रूप में, मैं अभी भी अपने आप को उपलब्ध कराता हूं और उस तथ्य को स्पष्ट करता हूं क्योंकि मेरा मानना ​​है कि मेरा एक उद्देश्य यह सुनिश्चित करना है कि टीम में से कोई भी लंबे समय तक प्रगति के बिना लंबे समय तक फंस रहा है।
  8. सुनिश्चित करें कि आपकी टीम संचार को अधिक प्रभावी बनाने के लिए यथासंभव अधिक से अधिक टूल का उपयोग करती है। उदाहरण के लिए हमारे पास एक विकी साइट है और किसी भी समय एक ही मुद्दे पर कई बार फसल होती है, मैं उस आखिरी आदमी से पूछता हूं जिसकी मैंने विकि पेज बनाने में मदद की है।

1
+1 उत्कृष्ट उत्तर, व्यावहारिक सलाह के बहुत सारे। प्रतिनिधिमंडल और संतुलन अत्यंत महत्वपूर्ण कौशल हैं, जिन्हें लगातार विकसित और परिष्कृत किया जाना है।
पेटर तोरॉक

बहुत बढ़िया सलाह। +1 विशेष रूप से # 4 के लिए; मैंने देखा है कि लोग इस तरह से नहीं सोचने के कारण बहुत समय बर्बाद करते हैं।
डैरनवे

मैं नए वर्ग के सदस्यों को जोड़े बिना सुविधाओं को जोड़ने के आपके विचार से अंतर्ग्रही हूं। क्या आप पाते हैं कि यह रणनीति अच्छी तरह से काम करती है?
मैक्सएम

@Maxpm: काम के बाहर मुझे कारों पर काम करना पसंद है। मैंने इलेक्ट्रॉनिक्स और हार्डवेयर में भी सेंध लगाने की कोशिश की है। मैं बहुत सारा सामान घर लाता हूं। कक्षाओं के लिए मेरा दृष्टिकोण, वह दृष्टिकोण है जो मेरी पत्नी मेरे साथ लेती है: "यदि आप कुछ लाते हैं, तो आपको कुछ लेना होगा"। मैं यह नहीं कह रहा हूं कि एक नया चर या तरीका कभी न जोड़ें, लेकिन एक निश्चित सीमा होती है जिसके ऊपर आप बस नहीं जोड़ सकते। यदि आपका कोड बड़ा हो जाता है, तो संभावना है कि आप एक बड़ा हिस्सा ले सकते हैं और इसे एक या अधिक स्टैंडअलोन इकाइयों में तोड़ सकते हैं। फिर बड़े मोनोलिथ के बजाय, आपके पास बिल्डिंग ब्लॉक होंगे और आप आवश्यकतानुसार स्थानांतरित कर सकते हैं और पुनर्व्यवस्थित कर सकते हैं
DXM

@Maxpm: जोड़ना भूल गए ... हाँ, यह रणनीति बहुत अच्छी तरह से काम करती है और यह बहुत ठोस सिद्धांतों के मूल में है, जो मैं सुझाऊंगा कि हर कोई परिचित हो। मुझे अपने कोड में सड़ांध से निपटने के लिए काफी समय हो गया है।
DXM

4

मैंने प्रबंधन में किसी के साथ इस पर चर्चा नहीं की है

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


3

जब आपकी परियोजना समाप्त हो जाती है, तो अपनी कंपनी में या उसके बाहर एक अधिक प्रोग्रामर ओरिएंटेड पोस्टिंग देखें।

प्रबंधन के साथ चर्चा करें कि आप कौशल पर कम प्रबंधन और अधिक तकनीकी "हाथ" पसंद करेंगे।

यह एक अग्रणी डेवलपर बनाम एक पीएम की स्थिति में आपकी तरह लगता है। मैं एक लीड डेवलपर को अधिक कोडिंग करने पर विचार करूंगा।


हाँ, मैं। दुर्भाग्य से कुछ परियोजनाएँ ऐसी हैं, मेरा बस ऐसा नहीं होना है। प्रबंधन करने के लिए पर्याप्त तकनीकी सामग्री है कि मुझे उस समय का 95% करना होगा। मैं भविष्य में इसे बदलने की कोशिश करूंगा।
विलियम फोंटेन

3

नियोक्ता परिप्रेक्ष्य :

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

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

उन्हें उत्तराधिकार योजना की स्थापना करके आपको वापस करने का रास्ता दें। मूल रूप से आपको वर्तमान टीम में कोई ऐसा व्यक्ति मिलता है जो उन चीजों को करने में रुचि रखता है जो आपको सिरदर्द देते हैं, अगले 6-9 महीनों में आप उन्हें प्रशिक्षित करते हैं, उन्हें अपने कार्यों को एक बार में देते हैं।

साप्ताहिक स्थिति अपडेट की तरह, पहले कुछ आसान चुनें:

  • स्टेटस अपडेट करते समय उन्हें अपने बगल में बैठाएं।
  • जैसे ही वे अगली स्थिति अपडेट करते हैं, उनके बगल में बैठें।
  • उन्हें अपने दम पर करने दें और फाइनल में जाने से पहले इसकी समीक्षा करें।

तब उत्तरोत्तर उन्हें अतिरिक्त कार्य दें, जब तक कि आप अपनी अतिरिक्त जिम्मेदारियों को नहीं सौंपते।

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

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

मुझे लगता है कि अगर आप 6-9 महीने की योजना के साथ अपने नियोक्ता को पेश करने वाले थे जो कहा था

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

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

सौभाग्य।


1

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


0

2 प्रश्न जो आपके पोस्ट से स्पष्ट नहीं हैं:

  • क्या आप एक ऐसी फर्म में हैं, जो सीधे आपके द्वारा लिखे गए सॉफ़्टवेयर (जैसे Google, Microsoft, या फ़ॉग क्रीक) से पैसा कमाती है या आप एक सहायक कार्य में हैं (जैसे बैंक या खाद्य कंपनी में)?

  • क्या सीईओ एक टेक्नोलॉजिस्ट है, या कोई है जो व्यावसायिक भूमिकाओं के माध्यम से उठ गया है?

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

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

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