वास्तविकता बनाम स्नातक अपेक्षाएं [बंद]


50

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

मेरे दो सबसे बड़े झटके (या मुझे कहना चाहिए, टूटी हुई उम्मीदें) अब तक सॉफ्टवेयर में शामिल रखरखाव के काम की मात्रा है, और व्यावसायिकता की कुल कमी:

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

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

क्या किसी और को भी इसके समान अनुभव थे? ऐसे कौन से तरीके हैं जिनसे आपकी अपेक्षाएँ कि हमारा पेशा कैसा होगा, वास्तविकता से भिन्न थे?


4
विश्वविद्यालय से लगभग एक छात्र के रूप में, यह एक बहुत ही दिलचस्प सवाल है! कुछ जवाब देखने के लिए इंतजार नहीं कर सकता
माइक42

8
अब जो आप देख रहे हैं वह वास्तविकता है। अन्य मज़ेदार तथ्य जो वास्तविकता से भी संबंधित हैं: अरबों लोग बिना भोजन, अनपढ़, युद्ध के निरंतर खतरे के तहत, वित्त बाजार के पतन के करीब, आदि। दूसरे शब्दों में, कॉलेज एक अद्भुत वास्तविकता-विरूपण क्षेत्र है, और लोग कर सकते हैं इस क्षेत्र की सुरक्षा के अंदर बहुत सी पाठ्यपुस्तक ज्ञान सीखें।
4

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

1
मुझे प्रोग्रामिंग पसंद है। मुझे वास्तविकता से नफरत है कि सॉफ्टवेयर को "वास्तविक" दुनिया में कैसे विकसित किया जा रहा है। आप जो वर्णन करते हैं वह सॉफ्टवेयर उद्योग में मामलों की स्थिति का काफी सटीक खाता है।
कप्तान संवेदनशील

बतौर फ्रेश जूनियर सेवर इंजीनियर, मैं भी यह अनुभव कर रहा हूं, मुझे लगा कि यह केवल मेरे देश में है, अब मुझे इसकी सॉफ्टवेयर डेवलपमेंट की अनटाइटेड सुविधा मिल रही है।
परमानंद

जवाबों:


27

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

जिन चीजों की मुझे उम्मीद नहीं थी:

स्कूल का तनाव और काम का तनाव एक जैसा नहीं है - दोस्तों के साथ स्कूल प्रोजेक्ट पर काम करने का या एकल काम करने का तनाव, यहाँ तक कि थीसिस की समय सीमा या विशेष प्रोजेक्ट डिफेंस की तुलना में अनुचित रूप से अनुचित काम की समय-सीमा, संचार समस्याओं के तनाव की तुलना नहीं की जाती है , (कार्यालय की राजनीति का एक छोटा सा) और कुरकुरे समय।

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

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

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


5
+1 संचार का महत्व। # 2 के लिए, यह सर्वोत्तम प्रथाओं की कमी नहीं है; यह (i) बहुत अधिक सर्वोत्तम प्रथाएं हैं, और (ii) किसी का अनुसरण करने में प्रचलित अभाव है।
6

1
आइसबर्ग की नोक के लिए +1! इतने सारे स्नातकों को लगता है कि वे सब कुछ जानते हैं, अब मुझे लगता है कि मैं पहले से कम जानता हूं!
billy.bob

+1 यहाँ कुछ अच्छे अंक। अक्सर सर्वश्रेष्ठ प्रथाओं / प्रणालियों / प्रक्रियाओं की कमी का कारण अप-फ्रंट 'कॉस्ट' है (यानी खरीद के लिए पूंजीगत व्यय की आवश्यकता होती है) - लेकिन उनके न होने की कीमत रखरखाव में वृद्धि या खराब, उत्पाद की विफलता के कारण भगोड़ा बग सूचियों या आवश्यकताओं को संतोषजनक नहीं है .. जो अच्छा संचार :-) से बचने में मदद कर सकता है
JBRWilkinson

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

1
यदि संभव हो तो मैं हिमशैल बिंदु की नोक के लिए एक अतिरिक्त +1 देता हूँ!
डेरेनडब्ल्यू

18

आप जो भी काम करते हैं, उनमें से ज्यादातर ग्राउंड-ब्रेकिंग नहीं है

जब यूनी पर, मैंने फुटबॉल खेलने वाले रोबोट को नियंत्रित करने के लिए एआई रूटीन पर काम किया, मैंने कंपाइलर का निर्माण किया और ऑपरेटिंग सिस्टम गुठली पर हैक किया।

लेकिन वास्तविक दुनिया में, 99% * सॉफ्टवेयर विकास वास्तव में बहुत उबाऊ है। मैंने हमेशा वास्तुकारों या बिल्डरों की प्रशंसा की है, जब उनसे पूछा गया कि "आप जीवन यापन के लिए क्या करते हैं?" एक इमारत या जो कुछ भी को इंगित और कहते हैं कि "मैंने किया था कर सकते हैं कि "। लेकिन अधिकांश सॉफ्टवेयर डेवलपर्स ऐसा नहीं कर सकते। यह पूछे जाने पर कि "आप जीवनयापन के लिए क्या करते हैं?" सबसे पास जो कि मैं कभी भी आ सकता था, जब मैं एक ऐसी कंपनी के लिए काम करता था, जिसने सॉफ्टवेयर बनाया था जो रेडियो स्टेशनों और इस तरह के लिए एसएमएस संदेशों को संसाधित करता था ... मैं कह सकता था, "आप जानते हैं कि आप कब पाठ करते हैं एक गीत के लिए मतदान करने के लिए एक रेडियो स्टेशन, अच्छी तरह से मैंने सॉफ्टवेयर लिखा जो उन वोटों और सामानों को संसाधित करता है। " फिर भी ऐसा नहीं है जहाँ किसी इमारत की ओर इशारा करने में सक्षम होने के साथ-साथ शांत हो और कहे "मैंने बनाया है।"

बेशक, कर रहे हैं ऐसा कह सकते हैं "मैं विंडोज पर काम किया" या जो कुछ भी है, लेकिन मुझे यकीन है कि वे वास्तव में किसी को भी नहीं बताया है कि अगले ही सवाल किया जा रहा है "के डर से मैं अपने प्रिंटर काम करने के लिए नहीं मिल सकता हूँ, क्या तुम मुझे ठीक कर सकते हो? "


* और सभी आँकड़ों का 62% मौके पर ही बनता है


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

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

1
@JBRWilkinson: +1। मेरे द्वारा किए गए "री-फ्रेमन" का सबसे अच्छा मामला पिछली नौकरी के साथ था जहां मैंने नर्ससेलर अस्पताल बीपर सॉफ्टवेयर पर काम किया था। आप इसके बारे में कुछ सामान्य कह सकते हैं जैसे "मैंने बीपर्स चलाने वाले प्रोग्राम लिखे"। OTOH, आप यह भी कह सकते हैं "मैंने सॉफ्टवेयर लिखा है जिससे अस्पतालों को बेहतर तरीके से चलाने में मदद मिली और मैंने शायद जान बचाई !!"। अब तक ऐसा नहीं सोचा था ... लेकिन सांख्यिकीय रूप से यह शायद सच है। मैं वास्तव में उस नौकरी के बारे में बहुत बेहतर महसूस करता हूं। यानी वह सॉफ्टवेयर मेरे प्रयास के कारण पहले उत्पादन में निकल गया, आदि ने शायद जीवन बचा लिया। :)
बॉबी टेबल्स

1
@ गुज़िका: कि आप दैनिक आधार पर जीवन बचाने के लिए योगदान दे सकते हैं / कर सकते हैं, शायद सबसे अच्छी नौकरी से संतुष्टि किसी को भी हो सकती है - अच्छी तरह से!
JBRWilkinson

1
Haha, उत्कृष्ट उत्तर और +1 हास्य की भावना रखने के लिए!
कप्तान संवेदनशील

17

यदि आप आज इंजीनियरिंग के इतिहास के लेंस के माध्यम से सॉफ्टवेयर को देखते हैं, तो यह निश्चित रूप से एक प्रकार का इंजीनियरिंग है - लेकिन यह इंजीनियरिंग का एक ऐसा प्रकार है, जो बिना आर्क की अवधारणा के लोगों ने किया। अधिकांश सॉफ्टवेयर आज एक मिस्र के पिरामिड की तरह है, जिसमें लाखों ईंटें एक दूसरे के ऊपर ढेर हैं, जिसमें कोई संरचनात्मक अखंडता नहीं है, लेकिन बस ब्रूट बल और हजारों दासों द्वारा किया जाता है। -अलन के, 2004

पूर्ण साक्षात्कार: http://queue.acm.org/detail.cfm?id=1039523

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

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


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

1
संपूर्ण रूप से सॉफ्टवेयर विकास एक विकासवादी प्रक्रिया है, न कि क्रांतिकारी। निश्चित रूप से, आप सिद्धांत रूप में कार्बन नैनोट्यूब से एक पिरामिड संरचना का निर्माण कर सकते हैं जो सिद्धांत में मिस्र के पिरामिड की तुलना में अधिक मजबूत, अधिक टिकाऊ और अधिक हल्का है। लेकिन ऐसा करना व्यावहारिक या व्यावहारिक नहीं है। यदि आप जिस स्थान पर काम कर रहे हैं वह वास्तव में खराब है, तो एक नया काम खोजें। अन्यथा, बहुत अधिक पूर्णता में नहीं फंसना चाहिए क्योंकि वास्तविक प्रोग्रामिंग नौकरियों में वास्तविक बाधाएं होती हैं (जैसे समय / धन)। याद रखें कि "सिद्धांत, सिद्धांत और व्यवहार में समान हैं। व्यवहार में वे नहीं हैं।"
इवान प्लाइस

>>> हमें एक नए तरीके की जरूरत है। मुझे नहीं पता कि वह क्या है। - न ही किसी और को, इस प्रकार यह जारी है!
गैरी विलोबी

5

मुझे डिग्री नहीं मिली, लेकिन मैंने कॉलेज और विश्वविद्यालय के पुस्तकालयों और प्रयोगशालाओं में थोड़ा सा उठाया।

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

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

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


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

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

पीछे मुड़कर देखें, तो मेरा एक सबसे अच्छा हिस्सा दूसरों को सीखना और सिखाना है


"कॉलेज आपको अत्याधुनिक तकनीकों को नहीं सिखाता है।": हाँ और नहीं। कुछ क्षेत्रों में शिक्षा उद्योग से 20-30 साल आगे है, और आपको कॉलेज में कुछ सीखने को मिलता है।
जियोर्जियो

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

जोड़ा गया

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

जोड़ा गया

मेरे दो सेंट: बस इसकी आदत डाल लें।


8
फिक्सिंग कीड़े की तुलना में घर का निर्माण, हम्म? "अरे, मैंने अपना डोरबोन गलत दिशा में घुमाया, और घर ही गायब हो गया!"
xor_eq

3

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


1
@ गुज़िका: जिन कंपनियों के लिए मैंने काम किया उनमें से एक काफी इंजीनियरिंग-उन्मुख थी। Iso9001 प्रमाणित नहीं है, लेकिन काफी कठोर रूप से इन-हाउस प्रक्रियाओं का पालन करता है। जैसा कि कहा गया है, अन्य - सीएस छात्रों के एक समूह की तुलना में अधिक संगठित नहीं हैं जो एक साथ अंतिम वर्ष की परियोजना कर रहे हैं।
बॉबी टेबल्स

2

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

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

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


1

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

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

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


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

1

बहुत सारे सॉफ्टवेयर बस उस बिंदु पर नहीं बनते हैं जहाँ इसका उपयोग किया जाता है / पर्याप्त खरीदा जाता है। जब कोई इसे बनाता है, तो यह चारों ओर चिपक जाता है और रखरखाव में केवल "गड़बड़" होता है।

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

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

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