ईई बनाम कंप्यूटर साइंस: डेवलपर्स के दृष्टिकोण, शैलियों पर प्रभाव? [बन्द है]

Question

कंप्यूटर विज्ञान के माध्यम से पेशे में प्रवेश करने वालों की तुलना में इलेक्ट्रॉनिक्स या अन्य इंजीनियरिंग पृष्ठभूमि के साथ सॉफ्टवेयर डेवलपर्स (sw इंजीनियरों, वास्तुकार, जो भी नौकरी का शीर्षक) के बीच कोई व्यवस्थित अंतर है?

इलेक्ट्रॉनिक्स पृष्ठभूमि से मेरा मतलब है कि एक ईई डिग्री, या एक स्व-सिखाया इलेक्ट्रॉनिक्स टिंकर, अन्य प्रकार के इंजीनियर और प्रयोगात्मक भौतिक विज्ञानी।

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

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

(Btw, मैंने कभी कोई कंप्यूटर विज्ञान की कक्षाएं नहीं ली हैं; मेरा वास्तव में वे जो कुछ भी कवर करते हैं, उसका आभास फ़र्ज़ी है। मैं एक इलेक्ट्रॉनिक्स / भौतिकी / कला प्रकार, स्वयं हूं।)

Answer 1

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

ईई लोग विवरणों पर ध्यान केंद्रित करते हैं, और वे सटीक कार्यान्वयन को जानते हैं। यदि यह 100% अनुपयुक्त नहीं है, तो वे इसे पसंद नहीं करते हैं। यदि वे कर सकते हैं तो ईई लोग अनावश्यक विवरणों को हटाने के लिए अनुकूलित करेंगे।

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

दोनों लोग सामान के बारे में जानते हैं जैसे कर्णघट नक्शे इसलिए उन क्षेत्रों में बहुत अधिक ओवरलैप है। तर्क में कमी, उस तरह की बात।

ठीक है, तो यह मेरा व्यक्तिपरक जवाब है। आशा है ये मदद करेगा।

Comments

यह उत्तर मुझे अपने वर्तमान प्रोजेक्ट की जानकारी देता है। मुझे करियर बदलने की जरूरत है!

— डैरनडब्ल्यू

कार्यात्मक प्रोग्रामिंग के बारे में भाग को छोड़कर, मैं लगभग 100% आपसे सहमत हूं। उदाहरण के लिए, मेरा मानना ​​है कि शुद्ध सीढ़ी तर्क लगभग 100% घोषणात्मक वाक्यविन्यास है। फ़ंक्शन ब्लॉक आरेख ईई के साथ भी लोकप्रिय है, जो स्पष्ट रूप से कार्यात्मक भी है।

— स्कॉट व्हिटलॉक

@Scott डब्ल्यू। ~ 2 विचार ... ;)यह एक व्यक्तिपरक उत्तर है, मुझे गलत होने की अनुमति है ... कार्यात्मक तर्क के संदर्भ में मेरा मतलब इस लिस्प कोड की तरह है ((lambda (arg) (+ arg 1)) 5)... वे वास्तव में "समान" कुछ का उपयोग करेंगे लेकिन होगा तर्क EE के समान है? मेरे व्यक्तिगत अनुभव में नहीं। दी, मुझे नहीं पता कि कई पेशेवर चिप डिजाइनिंग ईई, जिनमें से अधिकांश मुझे पता है कि अधिक सेवा कर्मी हैं। और सीढ़ी के तर्क जो वे एक कंप्यूटर टर्मिनल में रखते हैं, उनकी स्क्रीन पर शाब्दिक सीढ़ी की तरह दिखता है। जाओ पता लगाओ।

— jcolebrand

मुझे लगता है कि आप कार्यात्मक निर्माणों जैसे कि लंबोदर, आदि के बारे में बात कर रहे हैं, और मैं कार्यात्मक अवधारणाओं जैसे अपरिवर्तनीयता और घोषणात्मक वाक्य रचना के बारे में सोच रहा हूं। मैं मानता हूं कि भिक्षु जैसे और सामान बहुत सार होते हैं। मुझे नहीं लगता कि ईई सामान्‍यत: सामान की तरह चलेंगे।

— स्कॉट व्हिटलॉक

मुझे लगता है कि ईई एसई लोगों की तुलना में अधिक बार भिक्षुओं में चलते हैं। हास्केल के पास एक मोनाड विस्तार भी है जो भिक्षुओं को I / O ब्लॉक के रूप में मॉडल करने की अनुमति देता है, डीएसपी इंजीनियरों की रोटी और मक्खन।

— आदित्य

Answer 2

अगर मुझे सामान्य करना था, तो यहाँ मेरा अनुभव क्या रहा है:

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

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

जैसा कि मैंने कहा, यह मेरा सामान्यीकृत अनुभव है। यह हर मामले में सच नहीं है।

Comments

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

— डैरनवेन

Answer 3

मेरे अनुभव में - ईई प्रकार रेखीय कार्यक्रमों को डिजाइन करते हैं और अमूर्त परतों को शामिल नहीं करने के लिए सीएस प्रकार के साथ सहज लगते हैं।

गुणवत्ता अंतर या उसके अभाव के बारे में कोई टिप्पणी नहीं।

Answer 4

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

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

Comments

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

— डैरेन डब्ल्यू

Answer 5

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

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

सीएस में मेरी पृष्ठभूमि के बिना, मुझे लगता है कि मुझे अधिक अमूर्त अवधारणाओं को समझने में बहुत अधिक परेशानी होगी। कई अलग-अलग कोडांतरक भाषाओं के अलावा, मैंने C, C ++, C #, पास्कल, डेल्फी, पर्ल, PHP और कुछ लिस्प का उपयोग किया है। मैं फिलहाल रूबी और पायथन को सीखने की कोशिश कर रहा हूं। ऊ डिजाइन मैं के साथ बहुत सहज हूँ। कार्यात्मक प्रोग्रामिंग मैं (अभी तक) नहीं हूं।

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

मैं "देखना" करने में सक्षम होना चाहता हूं कि कंप्यूटर मेरे सिर में कार्यक्रम कैसे चलाएगा।

Comments

"मैं कुछ के साथ वास्तव में सहज नहीं हूं जब तक कि मुझे समझ नहीं आता कि हुड के नीचे क्या चल रहा है।" - यही जिम्मेदार इंजीनियरिंग की निशानी है। +1 आप को सर।

— luis.espinal