क्या लगातार कोड उदाहरणों की तलाश में एक बुरा डेवलपर का संकेत है? [बन्द है]

Question

मैं C और C ++ में कई वर्षों के अनुभव के साथ एक CS छात्र हूं, और पिछले कुछ वर्षों से मैं जावा / ऑब्जेक्टिव सी के साथ लगातार ऐप डेवलपमेंट कर रहा हूं और अब मैंने वेब डेवलपमेंट पर स्विच कर लिया है और मुख्य रूप से माणिक पर केंद्रित हूं रेल और मुझे इस बात का एहसास हुआ कि (ऐप डेवलपमेंट के साथ, वास्तव में) मैं अन्य कोड तरीका बहुत ज्यादा संदर्भित करता हूं। मैं लगातार कई चीजों के लिए Google कार्यक्षमता की कल्पना करता हूं जो मुझे खरोंच से करने में सक्षम होना चाहिए और यह वास्तव में मेरे आत्मविश्वास को थोड़ा दरार कर रहा है।

बुनियादी बुनियादी तत्व एक मुद्दा नहीं है, मैं इसे एक उदाहरण के रूप में उपयोग करने से नफरत करता हूं, लेकिन मैं जावा / अजगर दोनों पर स्प्रिंट में चला सकता हूं - जाहिर तौर पर एक उपलब्धि नहीं है और लेकिन मेरे कहने का मतलब यह है कि मेरे पास बुनियादी बातों के लिए एक मजबूत आधार है मुझे लगता है?

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

क्या एक व्यक्ति एक बुरा डेवलपर है जो लगातार जटिल कार्यों के लिए उदारवादी कोड उदाहरणों की तलाश कर रहा है?

Comments

यह निर्भर करता है कि मैं क्या काम कर रहा हूँ, सामान मैं बहुत मुश्किल से किसी भी लुकअप पर काम करता हूँ। कुछ और अपरिचित, मैं हर समय उदाहरण देखता हूं।

— Jaydee

इस पर निर्भर करता है कि क्या आपको वास्तव में कुछ कोड लिखने के लिए चारों ओर मिलता है।

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

— maple_shaft

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

— SSumner

अनुसंधान महत्वपूर्ण है। बस मैं BSDD (ब्लॉग-स्पैम ड्रिवेन डेवलपमेंट) में क्या शामिल नहीं करता

— थॉमस डिगन

Answer 1

कॉपी-पेस्ट नेत्रहीन: बुरा।

एक बेहतर समझ पाने के लिए दस्तावेज़ीकरण देखें, कोड उदाहरण पढ़ें: अच्छा।

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

Comments

@NewlyInsecure Thats ठीक है ... कुछ सॉफ्टवेयर डेवलपर खुद सोचते हैं कि जो लोग हैकाथॉन में जाते हैं वे हास्यास्पद हैं। उनमें से अधिकांश महान प्रोग्रामर हैं, लेकिन भयानक सॉफ्टवेयर डेवलपर्स हैं जिन्होंने एक बहुत अधिक लाल बैल पिया है।

— maple_shaft

एक डेवलपर के पास यह जानने के लिए दिमाग होता है कि किसी ने हाथ से पहले कुछ किया है और उदाहरणों की तलाश करें और उन्हें अनुकूलित करें। एक डेवलपर दीवार पर कपलिंग को नष्ट करने में समय बर्बाद नहीं करता है।

— डेविड

@NewlyInsecure तुलना मारता है। गंभीरता से, जितना अधिक आप अपने आप की तुलना दूसरों के साथ करते हैं, उतने ही निर्विकार, निर्लिप्त और भयभीत हो जाते हैं। सत्य के आधार पर अपने स्वयं के विश्वासों को बनाएं, न कि हर कोई जो करता है। अगर हैकेथॉन के लोग अधिक कोड को तेजी से बाहर कर सकते हैं, तो कौन परवाह करता है? यहां तक ​​कि अगर वह कौशल का एक संकेतक था, तो हमेशा आपके मुकाबले वहां के लोगों को होशियार किया जाएगा , चाहे आप कितने भी कुशल हों।

— फिल

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

— सूफलेर

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

— ब्लरफुल

Answer 2

यदि आप अपने समाधानों को एक रखरखाव योग्य तरीके से कोड करते हैं और वास्तव में UNDERSTAND को कॉपी या पेस्ट / संशोधित करते हैं तो कोई समस्या नहीं है।

मैं हर बार अंदर मर जाता हूं, मैं एक वरिष्ठ डेवलपर से सवाल पूछता हूं कि उसने क्यों किया और इसका जवाब है "मुझे नहीं पता, मैंने कोड पेस्ट किया और यह उस समय काम किया"।

Comments

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

— 18

@ TheJug, याद रखें, आप एक बेहतर डेवलपर और बदतर डेवलपर दोनों हैं, जितना कि आप खुद के होने की कल्पना करते हैं।

— जो

Answer 3

जैसे API डॉक्यूमेंट के साथ प्रोग्राम करने के लिए कौशल के साथ , कोड उदाहरणों की तलाश करना एक बुरे प्रोग्रामर का नहीं बल्कि एक ऐसे व्यक्ति का संकेत है, जिसके पास प्रवाह की कमी है ...

... यहाँ, मैं प्रवाह के बारे में बात कर रहा हूँ। न केवल कुछ के बारे में बल्कि धाराप्रवाह होने में सक्षम होने के बारे में ।

क्या आप जानते हैं कि धाराप्रवाह होना क्या है? यह तब होता है जब कोई आपके लिए देख रहा है ऐसा प्रतीत होता है जैसे आप कोड करते हैं ...

• ... जैसे कि सही कोड बस आपकी उंगलियों से स्क्रीन पर बहता है। जैसे कि आप एपीआई डॉक्स, ट्यूटोरियल और मैनुअल की जांच नहीं करते हैं। असल में, आप कर उन सब की जांच, लेकिन यह अपने सिर में सब है, क्योंकि वह अदृश्य है। आपको वह सारा ज्ञान मिल गया है जिसकी आपको अपने मस्तिष्क में आवश्यकता है - आवेशित, भरी हुई और उपयोग करने के लिए तैयार।

... वह धाराप्रवाह ज्ञान है। यह तब होता है जब आपको नौसिखिया करने में एक मिनट लगता है। यह प्रयास के लायक है, वास्तव में। इसमें जीत जैसी खुशबू आती है।

... और अभ्यास मुझे प्रवाह प्राप्त करने का एकमात्र विश्वसनीय तरीका है।

Comments

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

— dwwilson66

@ dwwilson66 हालांकि यह है कि दैनिक स्तर पर मुझे चार "भाषाओं" को याद रखने की आवश्यकता है - सर्वर-साइड प्रोग्रामिंग भाषा, क्लाइंट-साइड स्क्रिप्टिंग भाषा, क्लाइंट-साइड मार्कअप सिंटैक्स और क्लाइंट-साइड स्टाइल सिंटैक्स। मैं बस अपने सिर में यह सब नहीं रख सकता - यह एक ही समय में इतालवी, चीनी, अंग्रेजी और क्लिंगन में बातचीत करने की कोशिश कर रहा है।

— ताकारॉय

@ टैकोरो - बिल्कुल! प्रवाह के बिना, आपको मदद करने के लिए संसाधनों की आवश्यकता है। यह आपको क्लिंगन स्पीकर का "कम" नहीं बनाता है यदि आपको कभी-कभी केवल एक शब्द के बजाय पूर्ण वाक्यांशों को देखने की आवश्यकता होती है - बस दूसरों की तरह धाराप्रवाह नहीं।

— dwwilson66

अंतिम वाक्य हाइलाइट किए जाने के योग्य है, जो सबस्क्रिप्ट में छिपा नहीं है। विसर्जन से ज्यादा धाराप्रवाह बनने का कोई और तरीका नहीं है।

— जमलाने j

@ dwwilson66 ध्यान दें कि ऐसी चीजें हैं जो COBOL की तुलना में जावा में बहुत भिन्न होनी चाहिए । ऑब्जेक्ट कॉपी-किताबों के समान नहीं हैं।

Answer 4

सीखने का एक सिद्धांत है जिसे कॉलब चक्र कहा जाता है (जिस व्यक्ति ने इसे वर्णित किया है)। इस चक्र में प्रविष्टियाँ हैं:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

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

अन्य लोग अलग-अलग तरीकों से सीखेंगे: कुछ लोग कोशिश करके शुरुआत करना पसंद करते हैं (यानी प्रयोग के साथ) फिर जो सही या गलत हुआ उस पर चिंतन करना। मुद्दा यह है कि ये सीखने की चीजों पर हमला करने के सिर्फ अलग तरीके हैं: इनमें से कोई भी गलत नहीं है।

Comments

+1 दिलचस्प। वास्तव में, मैं उम्मीद करूँगा कि किसी को कम से कम कुछ चरणों के माध्यम से प्रगति करने के लिए सीखना चाहिए, है ना? यही है, बस अवलोकन करना संभवतः वास्तविक सीखने के लिए पर्याप्त नहीं है - आपको यह सोचने की ज़रूरत है कि आपने क्या देखा है और इसे आज़माएं।

— कालेब

मुझे वास्तव में पसंद है। मैं ज्यादातर भाषाओं में चिंतनशील अवलोकन शुरू करता हूं, लेकिन

— पावरशेल

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

Answer 5

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

समय के लिहाज से सब कुछ अक्षम है। यह किसी ऐसे व्यक्ति का लक्षण भी है जिसके पास ज्ञान की अधिक गहराई नहीं है। नॉलेज की गहराई वाले लोग उन लोगों की तुलना में तेजी से कोड लिख सकते हैं जो चीजों को देखे बिना किसी समस्या को हल करना नहीं जानते हैं। तो यह लगातार चीजों को देखने के बिना अधिक चीजों को संभालने के लिए सीखने के लिए लायक है।

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

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

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

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

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

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

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

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

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

Comments

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

+1 @JonofAllTrades ..man, काश मैं बीस साल पीछे जा सकता और एक लाख रुपये कमा सकता था क्योंकि मुझे पता था ..FoxPro। केवल। लेकिन नहीं, आजकल आपको एक नियमित नौकरी के लिए प्रतिस्पर्धा करने के लिए एक छोटी आकाशगंगा प्रौद्योगिकियों में सक्षम होने की आवश्यकता है। क्या आप Apache, IIS, दोनों को सेटअप और कॉन्फ़िगर कर सकते हैं? क्या आप एक एसक्यूएल बोली या दो में सहज हैं, SPROCs लिखने में सक्षम हैं और कम से कम प्रकाश प्रवेश? क्या आप युगल सर्वर-साइड भाषाओं में सक्षम हैं और डेटा हेरफेर के लिए कम से कम एक कार्यात्मक स्क्रिप्टिंग भाषा है? ..और अगर आप वेब के लिए प्रोग्राम करते हैं, तो क्या आपका सामान प्रमुख ब्राउज़रों, और मोबाइल उपकरणों पर काम करेगा ?

— एलोबिस

यह तर्क केवल तकनीक के लिए समझ में आता है जो पहले से ही 20 साल पहले से मौजूद है। और हाँ, आप बहुत ही भाग्यशाली SQL (अपने "यार्ड") के ज्ञान के साथ नौकरी करने के लिए भाग्यशाली हैं, जो आज के मानकों से अपर्याप्त है।

— प्रिस्वान

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

— HLGEM

Answer 6

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

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

लेकिन जब तक आप उस कोड को समझते हैं जिसे आप एक उदाहरण से कॉपी कर रहे हैं, तो यह काम को तेजी से पूरा करने का एक वैध तरीका है, और यह आमतौर पर एक बात है।

Comments

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

— नवनियुक्त असुरक्षित

और आपको अपने स्वयं के प्रोजेक्ट में कोड उदाहरण कॉपी और पेस्ट करने से पहले दो बार सोचना चाहिए। यह उन्हें एक कक्षा में अलग करने और उनका पुन: उपयोग करने के लिए अधिक समझ में आ सकता है।

— स्ट्रालसी

@SilviuStraliciuc: मुझे लगता है कि यह 1 या 2-लाइन उदाहरणों के बारे में अधिक है। जो कार्यों में लपेटने के लिए समझ में नहीं आता है। लेकिन मैं आमतौर पर ctrl-c + ctrl-v का उपयोग करने के बजाय उन को फिर से टाइप करता हूं, इसलिए मैं सही फॉर्मेटिंग लागू करता हूं और पहचानकर्ताओं और जैसे कि मक्खी पर प्रतिस्थापित करता हूं।

— Jan Hudec

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

— डेविड के

Answer 7

ये उत्तर बहुत अच्छे हैं। लेकिन आप कॉपी / पेस्ट या "कौशल" की कमी की तुलना में बहुत गहरी समस्या से ग्रस्त हैं।

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

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

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

एक और बात: लोगों द्वारा आपके अस्वीकृति का डर जिसे आप "श्रेष्ठ" मानते हैं, वही है जो आपको बेहतर डेवलपर्स के साथ कंधों को रगड़ने और उनसे सीखने से रोक रहा है। इसलिए आपका डर आपको बढ़ने से रोकता है, जो आपके डर को बनाए रखता है। जो आपको बढ़ने से रोकता है। चक्र देखें? आपको कहीं न कहीं चक्र को तोड़ना होगा।

Comments

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

— कालेब

Answer 8

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

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

मुझे हैकथॉन के बारे में पता नहीं है। वे फोटोग्राफिक यादों के साथ प्रोग्रामर के सबसेट पर आकर्षित हो सकते हैं। मैं इसे आज़मा कर देखता हूँ। यदि एक बेवकूफ आपको पसंद करता है, तो आपको प्रोग्रामिंग नहीं करनी चाहिए।

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

Comments

Psst, जब तक आप SELECT, या कॉम्प्लेक्स बूलियन लॉजिक में सबक्वेरी नहीं कर रहे हैं, तब तक न तो किसी को कोष्ठक की आवश्यकता है। ;)

— इज़काता

@ इज़काता: नहीं? मुझे कुछ पुराने कोड देखें। ओह, यह एक INSERT बयान है जिसे कोष्ठक की जरूरत है।

— राल्फचैपिन

Answer 9

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

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

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

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

क्या एक व्यक्ति एक बुरा डेवलपर है जो लगातार जटिल कार्यों के लिए उदारवादी कोड उदाहरणों की तलाश कर रहा है?

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

Answer 10

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

क्या आप हर बार व्यापक समाधान की तलाश में हैं: एक वेब ग्रिड को डेटाबेस टेबल से जोड़ने की पूरी प्रक्रिया या कनेक्शन स्ट्रिंग को प्रारूपित करने जैसा एक छोटा सा हिस्सा (मुझे यह देखना होगा कि हर बार जब मैं लगभग चार साल लिखता हूं। )?

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

Comments

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

— क्रिश सी

Answer 11

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

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

Comments

"मैं ऐसी किसी भी चीज़ को याद करने के लिए प्रतिबद्ध नहीं हूं जिसे आसानी से किताब में देखा जा सके।" - अल्बर्ट आइंस्टीन, 1922.

— gbjbaanb

19 फ़रवरी में @gbjbaanb अल्बर्ट आइंस्टीन ने संस्करण नियंत्रण का इस्तेमाल किया? वाह, वह वास्तव में बहुत बढ़िया था।

— svick

Answer 12

यदि आप उस समस्या को समझते हैं जिसे आप हल करने की कोशिश कर रहे हैं, और यह समझें कि आप इसे कैसे हल करना चाहते हैं, तो सही सिंटैक्स को देखना मेरी राय में कोई बड़ी बात नहीं है।

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

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

Answer 13

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

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

Answer 14

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

यदि आप समाधान A सोचते हैं, और कोई अन्य व्यक्ति समाधान B को सोचता है, जब आप में से प्रत्येक अपना समाधान साझा करता है, तो आप समाधान C का एहसास कर सकते हैं जो A या B से भी बेहतर हो सकता है।

Comments

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

— cjmUK

Answer 15

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

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

आज, उस कार्य के लिए एक भाषा को जानना, एक प्रणाली को जानना, एक प्रतिमान को जानना, एक प्रोग्रामिंग मॉडल और कम से कम एक एपीआई सेट की आवश्यकता होती है, जो सभी लक्ष्य निर्धारण कर रहे हैं।

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

क्योंकि Microsoft, Google, और कुछ हद तक, Apple, सभी "समुदाय" पर भरोसा करते हैं, जो कि बहुत वास्तविक कमी के लिए बनाते हैं, जिसके बारे में पूछना सिर्फ महत्वपूर्ण नहीं है, यह महत्वपूर्ण है। और एक व्यक्ति होने के नाते जो पूछा जा सकता है और जो आज के परिवेश में ठोस जवाब और प्रतिक्रिया दे सकता है, उतना ही महत्वपूर्ण है। यही कारण है कि इस तरह के stackexchange.com साइटों के रूप में साइटों के रूप में वे कर रहे हैं के रूप में उपयोगी हैं।

इसलिए प्रश्न पूछें, (नमूने के लिए समझदारी से पूछें!), और जवाब देने वाले लोगों का सम्मान करें, और ऐसा करने पर "बुरे डेवलपर" के संकेत के रूप में नहीं देखा जाएगा।

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

और, कृपया, पूछने वालों का मजाक न उड़ाएं।

Answer 16

यह मेरे लिए समस्या की तरह लगता है कि आप समझने में कम हैं कि आप क्या संदर्भित कर रहे हैं, और सुविधा और स्मृति के मुद्दों के साथ और अधिक। यदि यह आपके आत्मविश्वास को बढ़ा रहा है, तो हाँ यह एक समस्या है - लेकिन इसे निश्चित रूप से संबोधित किया जा सकता है!

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

प्रोग्रामिंग के साथ मेरा अनुभव भी ऐसा ही रहा है। मुझे लगता है कि चाबियाँ हैं:

1. भाषा का अभ्यास करें - इसे टाइप करें, इसे चलाएं, इसे बोलें यदि यह मदद करता है; बार-बार करो।
2. अपनी सुविधा का निर्माण करें - विभिन्न स्थितियों में एक ही सुविधा या पैटर्न का उपयोग करें; सुविधाओं को एक साथ रखना; कार्यक्रम बनाओ।
3. दोहराव के बीच पर्याप्त समय दें यह सुनिश्चित करने के लिए कि चीजें वास्तव में आपकी दीर्घकालिक स्मृति में अपना रास्ता बना रही हैं।

ये सिद्धांत वास्तव में किसी भी भाषा को सीखते समय लागू होते हैं! उदाहरण के लिए नए शब्द कैसे याद रखें देखें । Pimsleur विधि भी इस तरह काम करता है।

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

आपकी कहानी से, यहाँ कुछ विशिष्ट ठोकरें हैं जो मुझे लगता है कि आप में भाग रहे होंगे।

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

Answer 17

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

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

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

जब इंटरनेट पर चीजों को देखना चाहते हैं तो इसे देखें।

Answer 18

यह जानने का सबसे अच्छा तरीका कि आप क्या नहीं जानते: इसे गूगल करें! मुझे लगता है कि आप ज्यादातर डेवलपर्स के बराबर हैं। अपने बैकपैक में हीन भावना डालें और खुले दिमाग के साथ अंदर जाएं।

सवाल पूछने से डरें नहीं, गूगल पर रिसर्च करें, कोशिश करें और असफल रहें। यह सब इसका हिस्सा है।

Answer 19

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

बेशक, सॉफ्टवेयर विकास में सफल होने के लिए कीबोर्ड से एक ब्रेक की भी आवश्यकता होती है, ताकि आप पढ़ सकें और समझ सकें कि वास्तव में क्या चल रहा है। कोई भी वेब फ्रेमवर्क लें। आपको पता होना चाहिए कि क्या चल रहा है इसलिए आप समझ रहे हैं कि आप जो कोड लिख रहे हैं, लेकिन आपको कभी भी अपने आप को स्क्रैच करने वाला वेब फ्रेम लिखना नहीं पड़ेगा।

आपको बस कोड लिखना होगा जो फ्रेमवर्क के प्रकार का लाभ उठाता है (जैसे कि घटक-आधारित फ्रेमवर्क के लिए एक निश्चित शैली की आवश्यकता होती है) और यह बड़े चित्र को समझने से आता है। बड़ी तस्वीर सीखें और आप ठीक हो जाएंगे।

Answer 20

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

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

आपको खुद को थोड़ा चुनौती देने की कोशिश करनी चाहिए: आप कहते हैं कि आप हमेशा ऐसे वाक्यविन्यास को देख रहे हैं जो आप पहले से जानते हैं; इसलिए सिंटैक्स को देखे बिना कुछ कोड लिखने के लिए अपने आप को मजबूर करें, और आप (जल्द ही, यदि तुरंत नहीं) यह पता लगा लें कि आप बिल्कुल ठीक कर रहे हैं।

Answer 21

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

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

Answer 22

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

मुझे नहीं पता कि इस प्रश्न को पूछने के लिए आपके क्या कारण हैं, शायद आप मेरी स्थिति को पढ़ने के बाद स्वयं इसका जवाब दे सकते हैं क्योंकि मैं बहुत सारे कोड उदाहरणों का संदर्भ देता हूं।

मुझे कभी भी विश्वविद्यालय जाने का मौका नहीं मिला क्योंकि मैं 16 साल की उम्र में सड़क पर था। 24 साल की उम्र में मैं पत्राचार कॉलेज के माध्यम से अध्ययन करने और एससीजेपी, एससीजेडी, एससीबीसीडी और एससीडब्ल्यूसीडी के रूप में विक्रेता प्रमाणपत्र देने की स्थिति में था। मुझे यह स्वीकार करना चाहिए कि कई बार मैंने संघर्ष किया और उदाहरण के लिए ऑनलाइन मोड़ लिया। अनजाने में हालांकि इस समय मेरे सिर में ब्रेन ट्यूमर बढ़ रहा था (2010 तक यह एक नारंगी का आकार था)। मेरी 5 ब्रेन सर्जरी के बाद, 6 सप्ताह केमो / रेडियोथेरेपी और 10 महीनों के कीमो को मिलाते हैं, मैं अभी भी हाथ से लिखी गई कोडित साइटों के साथ प्रोग्रामिंग कर रहा हूं जो मेरे प्रोफ़ाइल से देखने योग्य हैं।

हां मुझे मस्तिष्क क्षति के साथ कोड उदाहरणों की बहुत आवश्यकता है, तो क्या यह मुझे एक बुरा प्रोग्रामर बनाता है?

Comments

आपके पास एक अच्छा कारण है। पाठ्यक्रम, कोई भी आसानी से बहस कर सकता है (अपनी खुद की कहानी का उपयोग करते हुए, यहां तक ​​कि!) यह केवल एक कमी प्रोग्रामर है जो बिना किसी को दिए उन्हें प्राप्त नहीं कर सकता है। सवाल यह है कि क्या यह उचित मूल्यांकन है।

— cHao

Answer 23

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

हालाँकि, इससे अच्छी चीजें निकलती हैं, आप: A) LEARN बग परीक्षण के दौरान इतना (जोर से रोना भी) B) उस तरह का कोड कभी नहीं जानना और बेहतर कोडिंग प्रथाओं को सीखना। इसके अलावा, हैकथॉन में आप ऐसे लोगों से मिलेंगे जो आपको कई नई चीजें सिखा सकते हैं जिनके बारे में आप कभी नहीं जानते थे, और आप उन चीजों को करेंगे जो आप स्कूल में कभी नहीं करेंगे।

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

Answer 24

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

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

Answer 25

यदि कोई डेवलपर / छात्र अपनी परियोजना में कोड कॉपी / पेस्ट करने के लिए .. विकिपीडिया .. को कहने जाता है, तो बस इसे "काम" करने की कोशिश करता है, फिर इस व्यक्ति को विकसित करने का एकमात्र कौशल 'हाउ टू गूगल' है। वहाँ पर परासरण की कुछ प्रक्रिया हो सकती है, लेकिन एक पूर्ण गुच्छा नहीं। (आप विश्वास नहीं करेंगे कि कितने लोग कॉलेज के पाठ्यक्रमों में ऐसा करते हैं)

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

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

मैं अक्सर मजाक करता हूं कि मैं अपनी मूल अंग्रेजी भाषा की तुलना में कंप्यूटर भाषाओं की जानकारी और बहिष्कार जानता हूं। जो प्रश्न पूछता है; "क्या आप मुझे समझाएंगे कि जावा plz में?"

Answer 26

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

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