प्रबंधक प्रोग्रामिंग भाषाओं का चयन कैसे करते हैं


23

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

खुद एक प्रोग्रामर होने के नाते, मैं इसे कभी समझ नहीं पाया।

लेकिन अब मुझे लगता है कि मैं करता हूं: मैंने अभी एक रहस्योद्घाटन किया है जब जोएल स्पोल्स्की ने पॉडकास्ट पर कहा था कि उन्हें क्विकबुक का उपयोग करना चाहिए क्योंकि "दुनिया में हर एकाउंटेंट इसे जानता है"। इसने मुझे "जावा को चुनने के लिए बहुत समान होने के कारण मारा क्योंकि दुनिया का हर प्रोग्रामर इसे जानता है"।

अब जब मैंने एक ही मुद्दे को दूसरे दृष्टिकोण से देखा है, तो मुझे लेखांकन के बारे में बहुत कुछ नहीं पता है, लेकिन मुझे प्रोग्रामिंग के बारे में कुछ पता है, मैं सोच रहा हूं कि कैसे एक प्रोग्रामर यह सुनिश्चित करने में मदद कर सकता है कि प्रोजेक्ट के लिए सही प्रोग्रामिंग भाषा चुनी गई है ?


हमेशा याद रखें एक प्रबंधक वह है जो मानता है कि नौ महिलाएं एक महीने में एक बच्चा दे सकती हैं!
घटाएँ

जवाबों:


29

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

यह प्रोग्रामिंग भाषा की पसंद से परे जाता है और लगभग हर तकनीकी निर्णय को विकृत करता है।

मैं आपको एक उदाहरण देता हूं: पीसी। जोएल का तर्क है (सही ढंग से) कि डेवलपर्स के पास शीर्ष पायदान मशीनें होनी चाहिए क्योंकि डेवलपर समय महंगा है। इसमें वह पूरी तरह से सही है। लेकिन आप यह कैसे तर्क देते हैं? सरल:

उदाहरण: मैं दिन में लगभग 20 बार कोड का निर्माण करता हूं। हर बार 3 मिनट लगते हैं। अगर मेरे पास तेज पीसी होता तो मैं इसे 1.5 मिनट में बना सकता था। तो हर दो साल में एक अतिरिक्त $ 1,000 के लिए मुझे एक अतिरिक्त आधा घंटा प्रति दिन मिल सकता है, जो कि एक प्रोग्रामर के लिए $ 100k (कम से कम 50% की अन्य लागत के साथ) अर्जित करता है, जो लगभग 10,000 डॉलर प्रति वर्ष के बराबर होता है।

लेकिन दूसरे छोर पर बहस एचआर एक आकार तय कर रही है जब यह नीति और पीसी के लिए फिट बैठता है तो एक कॉल सेंटर कार्यकर्ता $ 25k कमाता है और एक प्रोग्रामर चार बार कमाता है जो किसी कारण से एक ही पीसी होना चाहिए।

प्रौद्योगिकी प्लेटफॉर्म और भाषाओं में निर्णय मिश्रण में बहुत सारे कारक होंगे:

  • विशेष विक्रेताओं के साथ रणनीतिक संबंध। यदि आपकी कंपनी Microsoft गोल्ड पार्टनर है (या अब जो भी कहा जाता है) तो जावा या पायथन में अच्छी किस्मत मिल रही है;
  • आईटी विभाग एक विशेष कॉन्फिग्रेस पर बहस कर रहा है क्योंकि पीसी के लिए पैसा उनके बजट से बाहर आता है;
  • सभी को निर्णय लेने वाले आईटी को विंडोज 2000 चलाना चाहिए क्योंकि उनके पास लिनक्स चलाने वाले लोग नहीं हैं;
  • कंपनी के पास पहले से क्या अन्य प्रणालियाँ हैं (उदाहरण के लिए यदि वे जावा का उपयोग बाकी सब चीजों के लिए करती हैं, तो इसका उपयोग करने के लिए समझ में आता है, भले ही यह सबसे अच्छा विकल्प न हो);
  • अनुभव की कमी से बस विभिन्न प्लेटफार्मों या भाषाओं के लिए जोखिम;
  • डेवलपर्स को खुश करने की तुलना में ऊपरी प्रबंधन के साथ जोखिम पर बहस करने में अधिक रुचि;
  • कुछ प्रबंधक वे निर्णय लेते हैं जो वे केवल इसलिए करते हैं क्योंकि उनके हाथ बंधे होते हैं;
  • बजटीय कारण हालांकि यह आपके पक्ष में भी काम कर सकता है क्योंकि यह आपके घर से महंगे बून्डग्लॉग्स जैसे पीवीसीएस, रैशनल द्वारा निर्मित कुछ भी, आदि रखता है;
  • स्रोत लाइसेंस खोलने के लिए कानूनी विभाग का विरोध;
  • योजना और परियोजना के आकलन में तकनीकी कर्मचारियों को शामिल नहीं करना;
  • किसी विशेष प्लेटफ़ॉर्म के साथ प्रबंधक के हिस्से पर परिचितता (तकनीकी लोग इसके लिए भी दोषी हैं, लेकिन दोनों ही मामलों में यह आवश्यक रूप से एक बुरी बात नहीं है - कई उपकरणों के साथ जो आपके द्वारा जाने जाने वाले शैतान को बेहतर ढंग से काम कर सकते हैं)।
  • तकनीकी कर्मचारियों का अनुभव। यदि वे सभी C # बैकग्राउंड से हैं, तो वे Java, Python या Ruby का उपयोग क्यों करेंगे?
  • कई अन्य कारण

जो भी मामला आपको कारण समझने की आवश्यकता है (और मैं आपको गारंटी देता हूं कि कई कारण होंगे) और उन शर्तों में योग्यता का तर्क दें। कुछ प्रोग्रामर इस विभाग में काफी अनुभवहीन हैं और ऐसा लगता है कि ऐसे निर्णय अज्ञानता या यहां तक ​​कि अस्पष्टता से बने होते हैं जब लगभग हमेशा कई कारक खेल में होते हैं।


बहुत अच्छा और विस्तृत जवाब!

1
"आपके घर से महंगे बून्डॉग्लस जैसे पीवीसीएस, तर्कसंगत द्वारा उत्पादित कुछ भी"। हा! मजेदार है क्योंकि यह सच है;)
ऋग

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

16

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

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


क्यों डाउन वोट?

2
मैंने नीचे मतदान किया क्योंकि आपने वास्तव में मेरे प्रश्न का उत्तर नहीं दिया था। आपने सिर्फ सामान्यताओं का एक समूह कहा। अंतिम वाक्य को छोड़कर, जिसे उत्तर के रूप में देखा जा सकता है। लेकिन यह बहुत बेकार है।

14

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

प्रबंधक प्रोग्रामिंग भाषाओं का चयन कैसे करते हैं?

भारी संगठन और प्रबंधक के अनुभव के आकार पर निर्भर करता है, लेकिन आम तौर पर वर्तमान स्थिति और भविष्य के परिदृश्य और आवश्यकताओं का आकलन करना शामिल होगा। यह आमतौर पर PESTLE या इसी तरह के विश्लेषण के माध्यम से किया जाता है , और बस प्रत्येक श्रेणी में कुछ नमूने देने के लिए:

  • राजनीतिक
    • "आईबीएम खरीदने के लिए किसी को निकाल नहीं दिया गया" - सुरक्षित विकल्प।
    • सीईओ ने सुना कि जावा शांत है - प्रचार।
    • मुख्य वास्तुकार .NET - पालतू परियोजना से प्यार करता है।
    • भाषा एक शत्रुतापूर्ण प्रतियोगी द्वारा नियंत्रित की जाती है - Google C # पर निर्भर क्यों नहीं है।
  • किफ़ायती
    • लाइसेंस की लागत।
    • डेवलपर प्रशिक्षण की लागत।
    • कोड आधार माइग्रेशन लागत।
  • सामाजिक
    • टीम से खरीदें।
    • घर में कौशल की उपलब्धता (प्रशिक्षण की आवश्यकताएं, निरंतरता)।
    • बाजार पर कौशल उपलब्धता।
    • देव टीम के भीतर मौजूदा यथास्थिति के लिए खतरा।
    • अभ्यास के पर्याप्त बड़े समुदाय की उपलब्धता।
  • प्रौद्योगिकीय
    • उत्पादकता में सुधार।
    • गुणवत्ता में सुधार।
    • मौजूदा कोड आधार के साथ अंतर करने की क्षमता।
    • मानकों का पालन।
    • आयु वाले बच्चे।
  • कानूनी
    • लाइसेंस की शर्तें।
    • प्रौद्योगिकी नियंत्रण (कौन मालिक है और प्रौद्योगिकी को नियंत्रित करता है? भविष्य की लाइसेंसिंग रणनीति क्या है?)
    • कानूनी और नियामक अनुपालन।
  • पर्यावरण
    • कंपनी के भीतर मौजूदा बुनियादी ढाँचा।
    • कंपनी के भीतर मौजूदा कौशल।
    • बाहरी भागीदारों के साथ एकीकरण।
    • व्यापक पर्यावरण द्वारा प्रौद्योगिकी समर्थन का स्तर।

फिर मापदंड से मेल खाने वाली भाषाओं का एक समूह SWOT , लागत लाभ विश्लेषण या इसी तरह का उपयोग करके आगे मूल्यांकन किया जा सकता है ।

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

एक प्रोग्रामर कैसे सुनिश्चित कर सकता है कि प्रोजेक्ट के लिए सही प्रोग्रामिंग भाषा चुनी जाए

जैसा कि उम्मीद है, एक विशिष्ट प्रोग्रामर का प्रदर्शन सामान्य रूप से निर्णय लेने की प्रक्रिया में कुल इनपुट का सिर्फ 1/6 वां होगा। और एक नियम के रूप में वह या वह ज्यादातर भाषा क्षमताओं में ही दिलचस्पी रखती है!

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

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

  1. वर्तमान प्लेटफॉर्म अब पर्याप्त नहीं है।
  2. एक नया प्लेटफ़ॉर्म लाभ का वादा करता है जो अब तक परेशानी को दूर करता है।

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


5

प्रबंधक ए ग्रीष्मकालीन रिट्रीट में जाता है जहां वह प्रबंधक बी से मिलता है।

एक: तो आप अपनी कंपनी में किस भाषा का उपयोग करते हैं? B: ओह, हम CA विज़ुअल ऑब्जेक्ट का उपयोग करते हैं, यह ड्रोन को COBOL की तुलना में बहुत अधिक उत्पादक बनाता है।

और यह निर्णय कैसे किया गया था। सच्ची कहानी का अंत।


वह कौन सी कंपनी है?

3

हर मंच पर अच्छे और बुरे पक्ष होते हैं। .NET शांत और शक्तिशाली है, लेकिन आप विंडोज सर्वर के साथ बहुत अधिक फंस गए हैं। रूबी शांत लेकिन धीमी है। हास्केल के लिए डेवलपर्स खोजना मुश्किल होगा।

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


1
आप कुछ दिलचस्प बिंदु उठाते हैं, लेकिन आप हास्केल डेवलपर्स को खोजने के बारे में गलत हैं। हास्केल में प्रोग्राम करने वाले ज्यादातर लोग नौकरी में ऐसा नहीं करते हैं, लेकिन वे चाहते हैं (और वे आम तौर पर बहुत स्मार्ट होते हैं)

1
मुझे पता है कि वे स्मार्ट हैं :) लेकिन इसका मतलब है कि वे नौकरी का समर्थन नहीं करेंगे क्योंकि यह उबाऊ है या आपको उन्हें बहुत अधिक भुगतान करना होगा। यह वास्तव में COBOL की तरह है, आपको एक ऐसा व्यक्ति मिल सकता है जो इसे जानता है लेकिन आपको बहुत समय बिताने और अधिक भुगतान करने में खर्च करना होगा और फिर आप किसी अन्य व्यक्ति के लिए करेंगे।

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

2

चिंताओं को अलग करके। व्यवसाय को व्यावसायिक निर्णयों का प्रभारी और तकनीकी निर्णयों का प्रभारी होना चाहिए। मुझे "स्वीकृत जिम्मेदारी" शब्द पसंद है। अगर मैं जिम्मेदारी स्वीकार करता हूं तो मैं यह भी मांग करता हूं कि मुझे विकल्प मिलें जो समस्या के मेरे डोमेन की चिंता करते हैं। व्यवसाय मुझे और मेरे तकनीकी सहयोगियों को व्यवसाय की मांग देता है और हम एक या दो विकल्पों के साथ जवाब देते हैं कि हम कैसे डिलीवरी करने की जिम्मेदारी स्वीकार कर सकते हैं। ऐसा कभी नहीं होना चाहिए "हम इसे पायथन या सी # में करेंगे"। बल्कि;

"हम यहां दो अलग-अलग जिम्मेदारियों को स्वीकार कर सकते हैं: अगर हम इस तरह से जाते हैं, तो हम इस तेजी से वितरित कर सकते हैं और हम इन व्यापारिक मांगों को वास्तव में अच्छी तरह से पूरा करते हैं और ये थोड़ा कठिन हैं। हम इसे इस तरह भी कर सकते हैं और इन व्यापारों को ट्रम्प मांगता है। इन वैकल्पिक संसाधनों के लिए वैकल्पिक A कॉल और वैकल्पिक B का अर्थ है कि हमें यह करने की आवश्यकता है और यह ... "

तब व्यवसाय चुनता है, लेकिन ध्यान दें कि व्यवसाय व्यावसायिक चीजों पर प्रभाव के आधार पर चुनता है, न कि तकनीकी चीजों पर। और उन्हें उन विकल्पों में से चुनने की ज़रूरत नहीं है जहाँ टेक तकनीक की जिम्मेदारी स्वीकार करने के लिए तैयार नहीं है।


बहुत ही रोचक।

1

प्रबंधक बनें। (मुस्कराहट)

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


या यह आपके अपने संचार कौशल हैं जो विफल हो गए हैं और आपको उन लोगों को सम्मानित करना चाहिए।

वह भी है।

1

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


2
प्रोग्रामिंग, अधिक बार नहीं, प्रबंधकों के लिए एक मुख्य योग्यता नहीं है।

खैर, संभवतः, यह एक तरह से व्यवसाय या विभाग की एक मुख्य योग्यता है जो क्विकबुक की चर्चा से बहुत अलग है।

मैं पालन नहीं कर सकता। क्या आप सेब की तुलना संतरे से कर रहे हैं?

क्यों होता है पतन? मैंने सिर्फ आपके त्रुटिपूर्ण तर्क को इंगित किया। जहां तक ​​सेब और संतरे की बात है, मुझे लगता है कि पॉट केतली से मिलते हैं। जोएल wrt Quickbooks के बारे में बात कर रहा था, सिर्फ जावा चुनने वाले प्रबंधकों की तुलना में बहुत अलग है।

1

यह प्रबंधक के व्यक्तित्व पर बहुत निर्भर करता है:

वहाँ जो buzzwords के लिए जाते हैं। बस यह पता करें कि उन्हें कौन से buzzwords पसंद हैं और जब आप जिस भाषा का उपयोग करना चाहते हैं, उसके साथ बात करते समय उसका उपयोग करें।

अन्य केवल उन चीजों पर भरोसा करेंगे जो वे स्वयं जानते हैं (उदाहरण के लिए वीबी 6.0)। अपनी पसंद की भाषा को उनके लिए समझने में आसान बनाएं ('आप जानते हैं, इसकी तरह पुराने अच्छे VB में' - भले ही आप हास्केल के बारे में बात कर रहे हों ...)

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

दूसरे शब्दों में: उसे एक बुद्धिमान व्यक्ति की तरह व्यवहार करें (वह शायद है)।


1

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


दिलचस्प बिंदु। लेकिन मुझे लगता है कि सबूत का बोझ भाषा को थोपने वाले व्यक्ति पर होना चाहिए, न कि इसके विपरीत।

शायद एक परी की दुनिया में।
रेयन

1

प्रोग्रामिंग भाषा चुनना अक्सर एक व्यावसायिक निर्णय होता है। ग्राहक / उपयोगकर्ता परवाह नहीं करते। यहाँ संक्षिप्त उद्धरण ( http://www.ericsink.com/bos/Geeks_Rule.html से ) है:

प्रोग्रामिंग भाषाओं को मुख्य रूप से व्यावसायिक कारणों से चुना जाता है। मैं अपना ज्यादातर समय उन भाषाओं के साथ काम करने में बिताता हूं, जो मुझे वास्तव में पसंद नहीं हैं क्योंकि जिन भाषाओं को मैं व्यावसायिक नुकसान के साथ काम करना चाहता हूं जो उनकी तकनीकी खूबियों से परे हैं। यही खेल का स्वभाव है। मैं स्थिति (मेरी पसंद) को स्वीकार कर सकता हूं या एक नया नियोक्ता ढूंढ सकता हूं। मैं जावा या पायथन का उपयोग कैसे कर सकता हूं या काम पर जो भी हो बस एक विकल्प नहीं है।


मैं यहां सहमत हूं। लेकिन मुझे यह भी लगता है कि यह ध्यान रखना महत्वपूर्ण है कि दो भूमिकाएं व्यवसाय और टेक को देखते हुए, टेक के पास सबसे महत्वपूर्ण इनपुट होगा कि भाषा / रूपरेखा व्यवसाय की मांगों को पूरा करेगी। बहुत कम ही सूट को तकनीकी ज्ञान की आवश्यकता होती है।

1

सबसे पहले, प्रोग्रामिंग कला का दूसरा रूप है। कला का एक बहुत तार्किक रूप। यदि आपका प्रबंधक अपने असाधारण सॉफ्टवेयर प्रोजेक्ट्स के लिए उत्सुक है, जो कि कृति के कुछ विस्तार, कार्य हैं, तो उस उत्सुक प्रबंधक से पूछें:

कितना ऊर्जा और समय यह Rembrandt का खर्च आएगा अतिरिक्त करने के लिए अपने पसंदीदा ब्रश के साथ नहीं रंग, लेकिन एक ब्रश कि, प्रबंधन टीम के सावधानी से विचार करने के बाद, उसे सौंप दिया जाता है, 400 साल पहले और अपने काम करने से पहले प्रसिद्ध हो रहा। क्या उनकी पेंटिंग कमोबेश आपके सोचने लायक होगी?

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


पेस्टल बनाम तेल पेंट का उपयोग करके कला का निर्माण एक बेहतर सादृश्य होगा। हालांकि, पेशेवरों और विपक्ष अभी भी व्यावसायिक पक्ष पर झूठ बोलते हैं - भले ही कलाकार तेल पेंट पसंद कर सकते हैं, परियोजना को सस्ती सामग्री की आवश्यकता हो सकती है / कम तैयारी के समय की आवश्यकता हो सकती है / इस ग्राहक / आदि के लिए अधिक दीर्घायु की आवश्यकता हो सकती है। कहा कि, कलाकार को इस पसंद में इनपुट होना चाहिए, लेकिन उसे यह महसूस करना चाहिए कि अनुनय और सबूत का बोझ उसके कंधों पर है।
दोपहर का भोजन317 20

0

ये अलग-अलग अवधारणाएँ हैं।

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

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

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

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

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


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

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

0

मेरे अनुभव में यह हमेशा पर निर्भर है:

  1. क्या हमारे पास भाषा का उपयोग करने के लिए संसाधन हैं?
  2. क्या हमारे पास भाषा को बनाए रखने के लिए संसाधन हैं?
  3. यदि हमारे पास भाषा का उपयोग करने और बनाए रखने के लिए संसाधन नहीं हैं, तो उन संसाधनों को प्राप्त करना कितना मुश्किल / महंगा है?
  4. भाषा का "भविष्य" क्या है (क्या यह कुछ समय के लिए आस-पास और उपयोग में रहने वाला है?)

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

उम्मीद है कि आपके पास एक प्रोग्रामर है जो एक प्रबंधक भी है और जो इस प्रकार के निर्णयों में प्रोग्रामर का प्रतिनिधित्व कर सकता है। यदि नहीं, तो यह एक खतरनाक स्थिति है और आपको अपने प्रबंधक से बात करनी चाहिए यदि आपको पता है कि ऐसा निर्णय किया जा रहा है।

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