आप कैसे समझाएंगे कि सॉफ्टवेयर इंजीनियरिंग अन्य इंजीनियरिंग क्षेत्रों की तुलना में अधिक विशिष्ट है? [बन्द है]


9

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

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

मैंने यह समझाने की कोशिश की, लेकिन उसने इसे नहीं खरीदा। इस पर किसी भी अलग विचार या विचार को समझाने में मदद करने के लिए कि एक चीज में मेरा अनुभव, सभी चीजों का अनुवाद नहीं करता है?


7
यदि आप नीचे जा रहे हैं, तो आप कम से कम क्यों टिप्पणी कर सकते हैं? विशेष रूप से चूंकि आपका इनपुट प्रश्न को रीफ़्रेज़ / रीफ़ोकस करने में मदद कर सकता है।
स्पेंसर कोरमोस

11
पहले यह एक शेख़ी है और एक सवाल नहीं है, और दूसरा यह एक दोषपूर्ण धारणा है, इसे वोट देने और बंद करने की आवश्यकता है ।

6
@JarrodRoberson यहाँ एक वैध प्रश्न है जो मुझे लगता है। यह एक अच्छी व्याख्या के लिए पूछ रहा है जो इस बात का स्पष्टीकरण देता है कि क्यों कुछ सॉफ्टवेयर इंजीनियरिंग अन्य इंजीनियरिंग क्षेत्रों की तुलना में अधिक या कम विशिष्ट हैं।
मेपल_शफ्ट

7
@SpencerK आप सवाल "कुछ यादृच्छिक दोस्त एक बुरा सादृश्य बनाया है, मैं कैसे प्रतिक्रिया करते हैं", और अच्छी तरह से, यह वास्तव में एक सवाल नहीं है। बस ठोस सबूत और / या संदर्भों के लिए पूछें जो उसकी स्थिति का समर्थन करते हैं, आप यहां खुद को साबित करने की जरूरत नहीं हैं।
यनीस

5
-1 क्योंकि मैं आपके आधार से असहमत हूं। सॉफ्टवेयर इंजीनियरिंग अन्य इंजीनियरिंग क्षेत्रों की तुलना में अधिक विशिष्ट नहीं है। वे दोनों अत्यधिक विशिष्ट और सामान्यीकृत हो सकते हैं । एक अच्छा इलेक्ट्रो-मैकेनिकल इंजीनियर एक अच्छा बायोमेडिकल इंजीनियर नहीं हो सकता है। दूसरी ओर, एक अच्छा इलेक्ट्रीशियन घरों और कारों दोनों पर काम कर सकता है।
zzzzBov

जवाबों:


23

लेकिन एक तरह से यह पेशे का भी तुच्छीकरण करता है, जैसे कि "कोडमेकिन, गोइंग कोड"।

मैं इसके विपरीत काफी बहस करूंगा। एक अच्छे सॉफ्टवेयर इंजीनियर के पास प्रौद्योगिकी की अवधारणा, वास्तुकार और डिजाइन गुणवत्ता सॉफ्टवेयर अज्ञेय की क्षमता होगी। इस स्पेक्ट्रम का विपरीत छोर .NET या जावा या PHP केवल "कोडनेम" है जो दिशा या विनिर्देशों को देखते हुए और सॉफ्टवेयर को लागू करने के लिए उपकरण का उपयोग करने में अच्छा है।

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

मुझे एक फोर्ड इंजीनियर पर भरोसा नहीं होगा जो मैकेनिक का काम करना नहीं जानता।

हालांकि, सॉफ्टवेयर इंजीनियरिंग इन क्षेत्रों में से एक है, जहां कई मामलों में हमें एक ही समय में इंजीनियर, बिल्डर और मैकेनिक होने की उम्मीद है।


8
मैं भाषाओं और उपकरणों पर अवधारणाओं और सिद्धांतों को समझने के महत्व पर भी जोर दूंगा।
ओड

+1 मेरे पालतू जानवरों में से एक लोग हैं, जो कहते हैं "मैं एक सी # डेवलपर हूं ..."। और फिर बस कूल-ऐड पीना और एमएस से कुछ भी सुसमाचार के रूप में स्वीकार करना। 10 साल की प्रोग्रामिंग मैंने 11 से अधिक प्रोग्रामिंग भाषाओं में सीखी है, और हर एक ने बड़े पैमाने पर सुधार किया है कि मैं अन्य भाषाओं में कैसे कार्यक्रम करता हूं। सॉफ्टवेयर इंजीनियरिंग जानें! ऐसे प्लेटफॉर्म नहीं जो 2 साल में चले जाएंगे।
टिमोथी बाल्ड्रिज

फोर्ड इंजीनियर संदर्भ के लिए +1। मैंने उस तरह से पहले सॉफ्टवेयर इंजीनियर्स बनाम प्रोग्रामर के बारे में नहीं सोचा है।
Dalin Seivewright

एक प्रोग्रामर एक इंजीनियर का सबसेट होता है, दूसरे तरीके के आसपास नहीं।
स्पेंसर रथबुन

11

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

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

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


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

@ मार्सीन: कुछ सिद्धांत हैं, हां। मैं जो कविता बना रहा था, वह यह है कि (उदाहरण के लिए) C या असेंबलर में एक एम्बेडेड सिस्टम डिजाइन करना उसी तरह के सिद्धांतों को नियोजित करता है, भले ही उपकरण अलग-अलग हों।
जेरेमीपीप

वे उपकरण अलग नहीं हैं, और वे बहुत ही समान समस्या वाले डोमेन को संबोधित करते हैं। यही कारण है कि यह पूरी तरह से अनपेक्षित है।
मार्सिन

1
@Marcin: आपने स्पष्ट रूप से या तो असेंबलर में प्रोग्राम नहीं किया है या सी में प्रोग्राम नहीं किया है। मैं आपको विश्वास दिलाता हूं कि आम मिथक के बावजूद, सी असेंबलर नहीं है और उन टूल्स में प्रोग्रामिंग सी और रूबी में प्रोग्रामिंग (कहना) के रूप में अलग है।
जेरेमीपप

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

5

TLDR संस्करण: अन्य इंजीनियरिंग विषयों को उन सामग्रियों के ज्ञान की आवश्यकता होती है जो वे उपयोग कर रहे हैं (जैसे आर्किटेक्ट को यह जानने की आवश्यकता है कि वे अपने डिजाइन में उपयोग की जाने वाली सामग्रियों को कितना लोड कर सकते हैं )। सॉफ्टवेयर इंजीनियरिंग के लिए हम जिन भाषाओं और रूपरेखाओं का उपयोग करते हैं, उनकी कुछ सीमाएँ होती हैं और उनके खिलाफ प्रभावी ढंग से डिज़ाइन और विकास करने के लिए हमें उनसे परिचित होना चाहिए।

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

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

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


5

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

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

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


अंतर्निहित सिद्धांत बहुत भिन्न हो सकते हैं।
मार्सिन

1
@ कर्क नहीं, वे नहीं। अगर तकनीक बदलती है तो कंप्यूटर विज्ञान नहीं बदलता है। गणित नहीं बदलता। सांख्यिकी नहीं बदलती। न तो आवश्यकताओं के विश्लेषण, प्रणाली डिजाइन, विन्यास प्रबंधन के तरीकों, सत्यापन और प्रमाणीकरण रणनीति, गुणवत्ता के सिद्धांतों ... करना
थॉमस ओवेन्स

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

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

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

4

उनकी सादृश्य यह था कि आपको उस उत्पाद का ज्ञान नहीं होना चाहिए जिससे यह पता चले कि असेंबली लाइन का निर्माण कैसे किया जाए जो उक्त उत्पाद बनाती है।

यह प्रायः निश्चित रूप से गलत है। विशेषज्ञ उत्पादन इंजीनियरों को उनकी देखभाल के तहत उत्पादों के बारे में काफी कुछ समझने की आवश्यकता है।

किसी भी मामले में, मैकेनिकल इंजीनियरिंग पाठ्यक्रमों के स्नातकों के साथ एक बेहतर सादृश्य है: भले ही हर कोई बहुत ही कंजूसी के साथ (mech और सॉफ्टवेयर दोनों में) शुरू करता है, कोई भी "मैकेनिकल इंजीनियर" नहीं रहता है, बल्कि इसके प्रकारों में माहिर हैं चीजों का निर्माण। इसी तरह, सॉफ्टवेयर विकास में भी बहुत अलग उप-क्षेत्र होते हैं।

असेंबली लाइन सादृश्य पर लौटने के लिए, प्रत्येक उत्पाद के लिए प्रत्येक असेंबली लाइन अलग होती है, और विभिन्न प्रकार के सॉफ़्टवेयर विकास के लिए अलग-अलग कार्यप्रणालियों की आवश्यकता होती है - आप अपने सुरक्षा सॉफ़्टवेयर को उसी तरह नहीं बनाएंगे जैसे आप गेम बनाते हैं।


1
एक ही स्तर पर सॉफ्टवेयर निर्माण सॉफ्टवेयर उत्पाद की परवाह किए बिना समान है। हम उन्हें विधानसभा लाइनों के बजाय केवल कार्यप्रणाली कहते हैं , लेकिन वे वैचारिक रूप से एक ही चीज हैं।

1
@JarrodRoberson सं। असेंबली लाइनें समान नहीं हैं, और कार्यप्रणाली आम तौर पर लागू नहीं होती हैं।
मार्सिन

2
मैं मार्सिन से सहमत हूं, आपके पास उत्पाद के लिए एक असेंबली लाइन को एक साथ रखने के लिए एक उत्पाद का ज्ञान होना चाहिए। आपको सही अंतिम परिणाम प्राप्त करने के लिए उपयोग किए जाने वाले उपकरणों का सटीक चयन करने में सक्षम होना चाहिए। सॉफ्टवेयर में एक कार्यप्रणाली एक विशिष्ट उपकरण या कार्य होगा। यदि आपका एक कार्य किसी विशिष्ट कार्य को पूरा करना है, तो आपको संपूर्ण ज्ञान की आवश्यकता नहीं हो सकती है। लेकिन तब आप एक ऑपरेटर हैं और एक इंजीनियर नहीं हैं। असेंबली लाइन बनाने के लिए कार्यप्रणालियों के सही सेट का चयन करना आपको अन्य इंजीनियरिंग की तरह ही इंजीनियर बनाता है। इसका कोई विशेष या अलग नहीं है।
RJay75

2

विभिन्न विशिष्टताओं के साथ एक सीखने की अवस्था शामिल है। मैं एंबेडेड / रियल-टाइम प्रोग्रामिंग, वेब-ऐप प्रोग्रामिंग, सिस्टम / ओएस प्रोग्रामिंग, थिक-क्लाइंट प्रोग्रामिंग, मोबाइल डेवलपमेंट आदि के बीच अंतर के बारे में बात कर रहा हूं।

एक व्यक्ति जो एक प्रकार की प्रोग्रामिंग में विशेषज्ञ है, वह अलग-अलग आवश्यकताओं के कारण दूसरे को तुरंत पार करने में सक्षम नहीं हो सकता है। ज़रूर, एक सॉफ्टवेयर इंजीनियर के पास ऐसा करने के लिए मूल बातें हैं, लेकिन किसी चीज़ में विशेषज्ञ होने में समय लगता है।


1

मैं सहमत हूं कि आपके सहयोगी का सुझाव है कि मैं एक चेतावनी जोड़ूंगा।

एक अच्छा सॉफ्टवेयर इंजीनियर किसी भी तकनीक में अच्छे सॉफ्टवेयर का निर्माण करने में सक्षम होगा ..... जब उन्होंने नई तकनीक में कुछ सीखने का काम किया है।

कुछ ऐसे प्रश्न हो सकते हैं जो पहले स्पष्ट नहीं हैं, लेकिन एक अच्छा सॉफ्टवेयर इंजीनियर जल्द ही उन्हें सीख लेगा।

मुझे लगता है कि वह वास्तव में इसका मतलब यह है कि सिर्फ इसलिए कि एक डेवलपर के पास 2 साल का ठोस C # अनुभव है, इसका मतलब यह नहीं है कि जावा बैकग्राउंड के साथ एक बेहतर सॉफ्टवेयर इंजीनियर, जिसने कभी भी C # साथ नहीं किया है, C # नहीं सीख सकता, और जल्दी से। पहले आदमी की तुलना में बेहतर C # डेवलपर बनें।

दूसरे शब्दों में, आपको जरूरी नहीं कि जावा पुरुष को नौकरी के लिए छूट दी जाए, सिर्फ इसलिए कि उसने "# समय" किया है।


मुझे लगता है कि यह एक दिया हुआ है, लेकिन यह वास्तव में ROI के बारे में है। मैं एक इंजीनियर को प्राथमिक जावा अनुभव के साथ काम पर नहीं रखूंगा, अगर मैं 6 मस्जिद में सी ++ प्रोजेक्ट को बाहर निकालना चाहता हूं। हालाँकि, यदि आपके पास एक स्विंग प्रोजेक्ट है, जिसे 6 मॉस में बाहर निकलने की आवश्यकता है, तो एक प्राथमिक सर्वर-साइड इंजीनियर अभी भी योग्य हो सकता है।
स्पेंसर कोरम्स

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

इसके अलावा, कठोर माइनस अगर यह तुम थे!
ओज

1
नहीं, मुझे नहीं। मैं बिना टिप्पणी किए नीचे नहीं जाता, क्यों। मेरे पास इससे बेहतर शिष्टाचार है!
स्पेंसर कोरम्स

1

बिंदु में मामला: सॉफ्टवेयर ढांचा जो आपको लगता है कि विशेष रूप से अनुभव के साथ विशेष रूप से 10 साल पहले मौजूद नहीं था, या यदि यह किया गया है तो महत्वपूर्ण परिवर्तन हुआ है। हमारे पेशे की बहुत ही प्रकृति किसी के करियर की संपूर्णता के लिए विशेषज्ञ बनाना असंभव बना देती है। आपके संबंधित कौशल स्तरों के आधार पर, आपकी विशेषज्ञता आपको किसी ऐसे व्यक्ति के लिए 1 से 6 महीने के बीच कहीं का लाभ देती है जिसने कभी आपके विशेष ढांचे का उपयोग नहीं किया है। उसके बाद, आप सममूल्य पर हैं।


2
वास्तव में? मुझे लगता है कि आप 6 महीने में खेल के लिए एक सुरक्षा इंजीनियर बनने और कोडिंग करने की उम्मीद करेंगे, और एक अनुभवी विशेषज्ञ से अप्रभेद्य रहें।
मार्सिन

मैं मार्सिन से सहमत हूं, यह केवल एक प्रोग्रामिंग भाषा या मंच का ज्ञान नहीं है। मैंने दो अलग-अलग क्षेत्रों में काम किया है और उनमें से प्रत्येक में कुछ साल बिताए हैं: इसमें कुछ समय लगता है जब तक आप एक क्षेत्र में वास्तव में पेशेवर और उत्पादक होने के लिए पर्याप्त रूप से परिचित नहीं होते हैं। बेशक, एक अनुभवी सॉफ्टवेयर विशेषज्ञ होने के नाते चीजों को गति मिलती है, लेकिन मैं 6 महीने के बजाय 2, 3 साल का अनुमान लगाऊंगा।
जियोर्जियो

1

मैं एक हेलिकॉप्टर कंपनी के लिए काम करता हूं और यहां के एविएशन इंजीनियर जिस तरह के एयरक्राफ्ट के साथ काम कर सकते हैं, उससे प्रभावित हैं। उन्हें "टाइप रेटेड" होने की आवश्यकता है। तकनीकी रूप से वे रॉबिन्सन R22 से जंबो जेट तक कुछ भी काम कर सकते थे, लेकिन रूपांतरण प्रशिक्षण के बिना नहीं।

मुझे लगता है कि यह सॉफ्टवेयर इंजीनियरिंग के समान है, सिवाय इसके कि "रूपांतरण प्रशिक्षण" सॉफ्टवेयर इंजीनियरों के लिए अधिक अनौपचारिक है।


1

एक चित्रकार से बात करते समय, क्या आप उसे बताएंगे कि उसे मूर्तिकला से कोई समस्या नहीं है?

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

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

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

सारांश और उदाहरण:

"कला" में मूर्तियां, उपन्यास, कॉमिक्स और पेंटिंग शामिल हैं। कौशल ओवरलैप में शामिल हैं:

  • शरीर का रूप और रंग सिद्धांत: मूर्तियां, कॉमिक्स और पेंटिंग
  • पाठ संचार: उपन्यास और कॉमिक्स

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

इसी तरह, प्रोग्रामिंग / सॉफ्टवेयर इंजीनियरिंग के विभिन्न क्षेत्रों में ओवरलैप है, लेकिन उनमें से ज्यादातर बहुत अलग हैं बस उदाहरण के लिए कूदने में सक्षम हैं:

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

मैंने हमेशा तर्क दिया है कि प्रोग्रामिंग और सॉफ्टवेयर डिज़ाइन उतना ही कला है जितना कि विज्ञान या इंजीनियरिंग। मुझे लगता है कि यह एक और उदाहरण है कि वे कैसे समान हैं।
इज़काता

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

0

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

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


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

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

0

इस तरह की बात बहुत होती है जहां मैं काम करता हूं।

मुझे अपनी पत्नी के चाचा के पेशे से तुलना करना पसंद है - एक कार मैकेनिक।

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

मैं कुछ भाषाओं में कार्यक्रम करता हूं, लेकिन इसका मतलब यह नहीं है कि मैं जानता हूं कि आपके मैकबुक पर सफारी हर बार जब आप टैब बदलते हैं (आज के अजीब तरीके) को फिर से लोड करते हैं। मैं कोशिश करूँगा और यह पता लगाऊंगा कि मैं अपने सिर के ऊपर से क्यों नहीं जा रहा हूँ क्योंकि कंप्यूटिंग क्षेत्र बहुत बड़ा है

दोनों मामलों में कुछ समय बिताने के बाद हमारे संबंधित क्षेत्रों में हम संभवत: इस सवाल का जवाब दे सकते हैं लेकिन दस सेकंड में नहीं जो लोग सोचते हैं क्योंकि "लेकिन आप कारों के साथ काम करते हैं" या "लेकिन आप कंप्यूटर के साथ काम करते हैं"।

क्या लोग अपने स्थानीय चिकित्सक से ऐसी बातें कहते हैं (जैसे "मुझे सिरदर्द है कि मुझे क्या बीमारी है?") - मुझे यकीन है कि वे ऐसा करते हैं क्योंकि ज्यादातर लोग वास्तव में यह नहीं समझते हैं कि उनकी तत्काल अपेक्षाओं की तुलना में किसी भी एक पेशे में अधिक है पेशे का।

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