अपने प्रोग्रामिंग कौशल को बेहतर बनाने के लिए आपने जो सबसे प्रभावी काम किया है, वह क्या है?


876

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

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

मैं यहां विभिन्न उत्तरों की उम्मीद करता हूं और कोई भी "एक आकार सभी को फिट नहीं करता है" उत्तर - मैं जानना चाहता हूं कि विभिन्न लोगों के लिए क्या काम किया।


18
अभ्यास, अभ्यास, अभ्यास। और मन में आने वाली पहली चीज से कभी संतुष्ट न हों।
मार्क रंसोम

2
मार्क रैनसम के लिए +1 ... कठिनाई तब आती है जब आप अभी भी 100 वीं चीज से संतुष्ट नहीं होते हैं जो दिमाग में आया था!
स्टिमुल

5
प्रोग्रामर्स स्टैक एक्सचेंज साइट पर मेरे किसी भी समय को बर्बाद नहीं करने से मुझे अपने कोडिंग कौशल में काफी सुधार करने में मदद मिली।
नौकरी '

3
@ मर्क ट्रैप यह कैसे रचनात्मक नहीं है?
राइटफोल्ड

1
@WTP - विवरण पढ़ें। "यह प्रश्न हमारे प्रश्नोत्तर प्रारूप के लिए अच्छा नहीं है।" - जैसा कि किसी ने यह सवाल पूछा, मैं सहमत हूं। यह अधिक आराम से समय में पूछा गया था।
ऊदबिलाव

जवाबों:


753

किसी विशेष क्रम में नहीं ...

  • अपने से कहीं ज्यादा स्मार्ट लोगों के साथ काम करना

  • हमेशा यह सुनना कि दूसरों को क्या कहना है, भले ही वे जूनियर, इंटरमीडिएट, सीनियर या गुरु हों। नौकरी शीर्षक का कोई मतलब नहीं है।

  • अन्य रूपरेखाओं / भाषाओं को सीखना, और यह देखना कि वे चीजें कैसे करते हैं, और उस सामान की तुलना करें जो मैं पहले से जानता हूं

  • पैटर्न, सर्वोत्तम प्रथाओं के बारे में पढ़ना, और फिर मेरे पुराने सामान की जांच करना और जहां आवश्यक हो, उन पैटर्न को लागू करना

  • जोड़ा प्रोग्राम तैयार करना

  • जोएल की हर बात से असहमत है। ;)


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

117
देखो कि कैसे लोग गलतियों को संभालते हैं - जब मैं उनसे सबसे अधिक सीखता हूं

82
यदि यह कोई विशेष क्रम में एक सूची है, तो क्या इसे एक आदेशित सूची के बजाय एक अव्यवस्थित सूची नहीं होनी चाहिए? : पी
जॉन डब्ल्यू

3
मैं mmyers से सहमत हूँ - सिर्फ इसलिए कि आप किसी से असहमत हैं इसका मतलब यह नहीं है कि आप उन्हें अनदेखा कर रहे हैं। वास्तव में, यह विपरीत है - उनसे असहमत होने के लिए आप वास्तव में उन पर ध्यान दे रहे हैं।
क्रिस्टियन रोमियो

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

557

निर्णय लेना करने के लिए एक 'जैक के- सभी ट्रेडों' होना

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

एकमात्र समस्या जो मैंने कभी भी कंपनियों के साथ की है, जो कि एक खास बात है, जब मेरी खासियत यह है कि मैं एक खासियत में हूं। [संपादित करें: एक पॉलीमैथ या पुनर्जागरण मैन या बहु-विशेषज्ञ के रूप में भी जाना जाता है । ]

कुछ ध्यान में रखना ... उच्च तकनीक में ज्ञान का आधा जीवन क्या है? यह मूर के नियम के साथ ट्रैक करता है: जो कुछ भी आप जानते हैं उसका आधा 18-24 महीनों में अप्रचलित हो जाएगा। एक विशेषज्ञ जो गलत अनुशासन चुनता है उसे आसानी से प्रौद्योगिकी के दबाव से कम किया जा सकता है; एक सामान्य व्यक्ति को केवल कुछ और कौशल जोड़ने होते हैं और उन कौशल को लागू करने में अतीत के पाठों को याद रखना होता है।


224
"सभी ट्रेडों के जैक, किसी का भी मालिक नहीं, हालांकि अक्सर किसी एक के मास्टर से बेहतर होता है।" -Adam सैवेज
jms

9
उत्कृष्ट सलाह, मतदान हुआ। मेरे अतीत में "अनाथ तकनीक" मेरी 8-बिट अटारी थी, जो C64 से हार गई। मैं हालांकि उसी नतीजे पर पहुँचा - हेनलिन को उद्धृत करने के लिए, "विशेषज्ञता कीड़ों के लिए है।"

17
हमेशा ट्रेडऑफ़ होते हैं, और एक दिन में केवल 86,400 सेकंड होते हैं - आपको यह तय करना होगा कि आप उन्हें कैसे खर्च करना चाहते हैं। मेरे मामले में, मैंने उन चीजों को सीखने के लिए अतिरिक्त घंटे (मेरे काम के घंटे के ऊपर) और उसके बाद खर्च करना चुना है, जो मुझे लगता है कि दिलचस्प थे या भविष्य में मांग में होने जा रहे थे; आपको अपनी पसंद बनाने की आवश्यकता होगी।
क्रेग ट्रेडर

74
"कीड़ों के लिए विशेषज्ञता है।" - हेनलिन
केली एस। फ्रेंच

31
आपका "जनरलिस्ट" बिल्ला कहाँ है? ^ ^
अर्निस लैप्सा

459

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

इसने मुझे सचेत रूप से सचेत किया कि मैं अपने आप को और विशेष रूप से कोड की गुणवत्ता को बेहतर बनाने की कोशिश करूँ।

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

मैंने हारून से जो सबसे महत्वपूर्ण बात सीखी, वह थी कि मैंने कभी सीखना बंद नहीं किया।

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

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

मुझे खुशी है कि मैं हारून से मिला। उसके बिना, मैं शायद अभी भी पुराने गिरोह के साथ पुरानी कंपनी में काम कर रहा हूं, कहीं नहीं जा रहा हूं, और खुद को बहुत अधिक सोच रहा हूं।


54
यह आमतौर पर दोनों तरीकों से काम करता है। मैं अब एक 'आरोन' के रूप में कुछ कंपनियों में आया हूँ और मैंने पाया है कि एक बार जब मैं अन्य कोडर्स को सक्रिय कर देता हूं तो वे मुझे अपने पैसे के लिए दौड़ना शुरू कर देते हैं और मुझे अपने स्वयं के प्रयासों को फिर से करने के लिए प्रोत्साहित करते हैं। महान पद!

28
+1 के लिए "हारून हमेशा इस बारे में बात कर रहा था कि मुझे पहले काम करने वाले संस्करण पर कभी भी कैसे रोकना चाहिए, लेकिन कोड सुरुचिपूर्ण होने तक रिफ्लेक्टर और परिष्कृत करें"

17
"पहले काम करने वाले संस्करण पर कभी नहीं रुकना" ??? - आप अपने बाकी काम कब करवाने वाले हैं? :)

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

27
समस्या बहुत से लोग सोचते हैं कि वे "हारून" हैं
CinqoTimo

257

दो चीज़ें:

  1. विभिन्न लोगों द्वारा लिखे गए कोड पढ़ें।
  2. अन्य लोगों द्वारा लिखे गए कोड के लिए दस्तावेज लिखें।

कोड लिखना बेहद आसान है; मुझे पता है कि हर दूसरा व्यक्ति ऐसा कर सकता है। लेकिन किसी और के कोड को पढ़ना और यह पता लगाना कि यह क्या करता है मेरे लिए एक पूरी नई दुनिया थी।


42
और सबसे अच्छे तरीकों में से एक यह जानने के लिए कि क्या नहीं करना है :)
AviD

9
आप देख सकते हैं कि वे कुछ कैसे करते हैं। शायद वे इसे आपसे बेहतर तरीके से करते हैं?

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

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

इतना सच है, यह लंबे समय तक मेरी नौकरी का सबसे कठिन हिस्सा था।

199

नियमित रूप से जिम मारो।

गंभीरता से, मेरा मस्तिष्क आकार में होने पर पूरी तरह से बेहतर काम करता है। समस्याएं आसान हो जाती हैं और कम हो जाती हैं, बंद करना बहुत कम होता है और प्रलोभन देना, और चीजों के माध्यम से कदम-दर-कदम काम करना इस तरह के कठिन काम की तरह प्रतीत नहीं होता है।


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

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

1
हाँ यह आज बड़ी समस्या है। हमारे पास विशेष रूप से पाकिस्तान में समय नहीं है जहां काम के घंटे बहुत अधिक हैं
maz3tt

2
+1 अधिक अभ्यास पाने के लिए अपने आप को एक अनुस्मारक के रूप में ।
एकलकरण

मुझे लगता है कि एक खेल एक महान प्रेरक है - मेरे लिए, यह बास्केटबॉल है।
Adel

181

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


4
मैं सहमत हूँ। किसी प्रोजेक्ट में मेरे हाथ गंदे होना शायद मेरे सुधार में सबसे बड़ा योगदान है। ; )
माइक ग्रेस

1
ठीक ठीक। एक बेहतर कोडर बनने के लिए सबसे अच्छा तरीका कोड है। आप किताबों, पॉडकास्ट और सहकर्मियों से सब कुछ सीख सकते हैं, लेकिन आपको इसे समझने से पहले इसे लागू करना होगा। कोड अधिक, और कोड अधिक भिन्न सामग्री। क्योंकि आप एक ही पुरानी चाल को दोहराने से बहुत कुछ नहीं सीखते हैं।

चुनौतीपूर्ण और पेचीदा परियोजनाओं का चयन करना। मुझे लगता है कि आपके कम्फर्ट जोन से बाहर निकलने का संघर्ष वास्तव में आपके कौशल को गति देता है। वे चाँद पर नहीं गए क्योंकि यह आसान था।
किम जोंग वू

172

मेरे विश्वविद्यालय में सीएस छात्रों को ट्यूशन देने के लिए अंशकालिक नौकरी ली। यह वास्तव में आपको कुछ अलग स्तर पर समझने के लिए मजबूर करता है जब आपको इसे किसी और को समझाना होता है।


1
मैं उसकी जिम्मेदारी ले सकता हूं।

1
विश्वविद्यालय में एक प्रशिक्षक ने मुझे उद्घाटन के बारे में बताया जब मैं अभी भी एक छात्र था। मैं स्नातक होने के बाद लगभग एक वर्ष (अंशकालिक) के लिए रहा।
छिपकली

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

2
बिल्कुल सही। टीचिंग फोटोग्राफी ने मुझे एक बेहतर फोटोग्राफर बनाया। बहुत सारे कोडर नहीं हैं :(
सीएडी

9
मंटू इस्सा फंट, एट होम्स डम डम डिसकंट

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

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

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

इन दो कामों को करने से स्पेक्ट्रम के दोनों सिरों को कवर किया जाता है। एक नई भाषा सीखना आपको बेहतर कोडर बना देगा। पालतू परियोजना आपको एक बेहतर डेवलपर बनाएगी: पी


मैं केवल सहमत हो सकता हूं; "एक पहले से अज्ञात भाषा में पालतू परियोजना" अच्छा है, मैं पुष्टि कर सकता हूं

आधे से कुछ जानने के लिए बहुत अच्छा सुझाव।

महान सुझाव "कुछ आप के साथ अनुभव है + कुछ तुम नहीं"! धन्यवाद
sica07

मुझे अब एक पालतू जानवर चाहिए।
एडेल

118

खुद विधानसभा का चुनाव किया। क्या यह एक पुरानी 6502 चिप पर था जब मैं 13 साल का था? 14? बहुत पहले। लेकिन मैं ऐसे किसी भी चीज के बारे में नहीं सोच सकता जो आपके विकास को बिट स्तर तक ले जाने से ज्यादा बेहतर बनाए।

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

65xx चिप में तीन रजिस्टर (संचायक, एक्स और वाई) थे और गुणा या विभाजित करने के लिए कोई मशीन स्तर निर्देश नहीं थे। मुझे याद है कि युद्ध के नुकसान की गणना करने के लिए एक दिनचर्या को कोड करना, पुस्तक के माध्यम से देखना, और अचानक यह महसूस करना कि मुझे अपना गणित पुस्तकालय लिखना होगा। मेरी नोटबुक पर 1 और 0 के सभी स्क्रिबलिंग के कुछ हफ़्ते बिताए, यह पता लगाने की कोशिश कर रहा था कि वास्तव में 'विभाजित' और 'दशमलव स्थानों' का क्या मतलब है।

मैंने तब से C ++, पास्कल, .NET, कई अन्य का अध्ययन किया है ... लेकिन उनमें से किसी ने भी मुझे उतना नहीं पढ़ाया है, जितना मुझे साज़िश किया है, या मुझे 'वाह' की भावना के साथ छोड़ दिया है जो कि मेरे पुराने कमोडोर पर असेंबली ने किया था ।


16
मैं तुम्हें सिर्फ अद्भुत यादें वापस लाने के लिए वोट देना होगा! शायद मैंने भी थोड़ा सा आंसू बहाया :)
चार्ली फूल

3
मैं अभी भी मानसिक रूप से C / C ++ का 68K असेंबली भाषा में अनुवाद करता हूं। यह आश्चर्यजनक है कि कैसे आपको किसी भी प्लेटफ़ॉर्म के लिए कुशल कोड लिखने में मदद मिलती है।
बॉब मर्फी

1
6502 आह, महान यादें वापस लाता है। मैंने इस चिप पर कोडांतरक के साथ बहुत कुछ सीखा।

5
प्रोग्रामिंग के हर छात्र को अपनी शिक्षा में जल्दी से कोडांतरक के लिए गहराई से संपर्क करना चाहिए!

2
मैंने एक नौजवान की तरह ही काम किया। यह वास्तव में सिखाता है कि कंप्यूटर कैसे काम करते हैं, उच्च स्तरीय भाषा की तुलना में मोरेसो कभी भी कर सकते हैं।
सीएडी

110

मैंने पुरानी बातों को देखा और महसूस किया कि वे कितनी बुरी थीं।


मैं दूसरा है कि ... मैं शायद ही अपने पुराने सामान को पढ़ सकता हूं।
Unkwntech

28
जब मैं अपना पुराना सामान ले कर जाता हूं तो मुझे पूरी फाइल को डिलीट करने के लिए लगभग अट्रैक्टिव आग्रह मिलता है। कभी-कभी पूरी निर्देशिका।
क्रिस्टोफर महान

निष्पक्षता के लिए +1। अपने पुराने कोड को देखने से आपको यह नहीं पता चलेगा कि आपको कैसे सुधार करना है, केवल अगर आपने सुधार किया है और कैसे - या इसके विपरीत, यदि आपने नहीं किया है।

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

3
@ क्रिसोफर महान: और वास्तव में बुरे मौकों पर, पूरी मात्रा।
थानाटोस

93

पढ़ना

  • किताबें, न सिर्फ वेबसाइट
  • आत्म-सुधार के लिए, न कि केवल नवीनतम परियोजना के लिए
  • अपने व्यापार को बेहतर बनाने के बारे में, न कि नवीनतम तकनीक के बारे में
  • कोड पढ़ें, न कि केवल आप पर काम कर रहे हैं।

बस पढ़ने की भूख विकसित करें।


2
प्लस, फ्रिकिन ', 1. मुझे आश्चर्य होने लगा था कि यह पसंद कहाँ है।
थानाटोस

87

प्रोग्रामिंग।

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


8
अगर आप किसी चीज में बेहतर होना चाहते हैं, तो उसे करने से बेहतर कुछ नहीं है।
जेफ सिवर

4
+1 - यह मुझे फाइंडिंग फॉरेस्टर की याद दिलाता है : "लिखने के लिए पहली कुंजी है ... लिखना है"
विजार्ड79

2
कोई और जवाब नहीं है। आप वास्तव में यह नहीं कह सकते कि आप क्या कर रहे हैं जब तक कि आपने कोड का एक गैर-तुच्छ ढेर नहीं लिखा है और व्यवसाय के लोगों + ग्राहकों के साथ कुछ उत्पाद पुनरावृत्तियों के माध्यम से इसके साथ चिपका हुआ है। जब तक यह नई आवश्यकताओं को पूरा करने के लिए परिवर्तन करने का समय नहीं है, तब तक आप अपना कोड कितना अच्छा है / वास्तव में नहीं जानते / जानते हैं।
blucz

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

1
मेरा अनुमान है कि प्रश्न "प्रोग्रामिंग के अलावा" ...
अंकलजीव

81

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

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

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


7
और उसके पास शायद कम कौशल है क्योंकि उसका कुछ ज्ञान अप्रचलित हो गया है ..

72

कई लोगों ने कोड लिखने का सुझाव दिया है। मेरा कहना है कि अन्य लोगों के कोड को पढ़ना ज्यादा फायदेमंद है।


11
दोनों का मिश्रण वास्तव में मेरे लिए सबसे अच्छा काम करता है; अन्य लोगों के कोड को पढ़ना और इसे और अधिक पठनीय बनाने के लिए इसे फिर से

पाठ्यक्रम का अच्छा कोड पढ़ना ... और इसे समझना। और इसे संशोधित करना, या इसके लिए परीक्षण लिखना।

4
कोड पढ़ना इंटरसेस्टिंग है, लेकिन यह वास्तव में आपकी त्वचा के नीचे नहीं आता है जब तक कि आप वास्तव में ऐसा नहीं करते हैं।

इसे सीखने के लिए आपको इसे अवश्य करना चाहिए। यह साइकिल की सवारी करने जैसा है ...

70

बहुत ही विविध और राय वाले लोगों के साथ जोड़ी-क्रमबद्ध


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

67

मूल बातें जो मुझे एक प्रोग्रामर के रूप में मदद करती हैं:

  • टच टाइपिंग सीखी।
  • शर्म को दूर करने और सवाल पूछने के लिए सीखा।

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

और यदि आप नहीं पूछते हैं, तो कोई भी आपको बताने वाला नहीं है।


15
टच टाइपिंग सबसे महत्वपूर्ण कौशल है। प्रोग्रामिंग में सबसे बड़े अपराध कुछ कीस्ट्रोक्स को बचाने की कोशिश करने वालों द्वारा किए गए हैं।

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

2
मैंने देखा है कि लोगों ने 2 कैरेक्टर कमांड को रिकवर करने के लिए 15 अप ऐरो मारा। बहुत दुख की बात है। यह बिना आईडीई के कुछ बच्चों की तरह है ... पूरी तरह से अक्षम।

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

2
हाथ की स्थिति महत्वपूर्ण नहीं है - महत्वपूर्ण बात यह है कि आप बिना देखे टाइप कर सकते हैं। अपने लैपटॉप पर मैं अपनी कलाई को आराम नहीं देता।

56

ओपन-सोर्स प्रोजेक्ट्स में भाग लेना / भाग लेना मेरे लिए सबसे बड़ी बात थी।


53

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

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

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


सच। आप अपने (अब तक) अंतिम संस्करण को उन लोगों का एक समूह बनाकर परीक्षण कर सकते हैं जिन्हें आप जानते हैं कि आप गैर-तकनीकी होने की कोशिश करते हैं, और इस पर उनकी टिप्पणियों को सुनते हैं (यह सुनिश्चित करने के लिए कि "यह अच्छा है!" नहीं कहेंगे, क्योंकि) यह आपको मामूली रूप से मदद नहीं करता है।)

48

सीखी योजना।


हाँ, यह मेरे लिए भी बड़ा था। इसके अलावा महत्वपूर्ण थे टच टाइपिंग और पेयर प्रोग्रामिंग।

46

लेखन कोड और इसके बहुत सारे।


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

कोड पढ़ना और इसके बहुत सारे।
स्टीफन

3
बहुत सारे कोड पढ़ना और लिखना ... खुला स्रोत हमारे लिए एक ऐसा वरदान है;)
ऊद

45

नियमित अभिव्यक्ति सीखना।


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

नियमित अभिव्यक्ति सिर्फ उपयोगी नहीं हैं, वे आपको एक अलग तरीके से सोचने के लिए भी मिलते हैं।
तिखन जेल्विस

+1। पूरी तरह से सहमत हूँ। मैं लोगों को आश्चर्यचकित करने के लिए आश्चर्यचकित हूं अक्सर vi, sed या grep में काफी बुनियादी चीजें कर रहा हूं।

39

TopCoder एल्गोरिथ्म प्रतियोगिता में प्रतिस्पर्धा ।


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

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

2
@hstoerr - इस तथ्य का उल्लेख नहीं करने के लिए कि प्रतियोगियों को उनके कोड को पढ़ने में मुश्किल बनाने के लिए पुरस्कृत किया जाता है (उनके समाधान को चुनौती देना मुश्किल है)
शेन फुलमर

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

2
TopCoder अपने आप को दिखाने का तरीका है कि आप कितना बेहतर बन सकते हैं।

38

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


36

मेरी आखिरी नौकरी छोड़ दो।


2
मैं भी! (कुछ और

6
अगर आप हमें बताएंगे कि ऐसा क्यों है, तो इसका जवाब भी हो सकता है। ;-)

2
सहायक परियोजना जो कि इनडोर फ्रेमवर्क के साथ बनाई गई थी (EJB2 पर आधारित) मेरे लिए मजेदार नहीं थी। कोई नया सामान नहीं, बस पुरानी बकवास। और नए काम में परिप्रेक्ष्य बेहतर नहीं हैं। :(
17

वहाँ किया गया था कि।
Allbite

+1 सौभाग्य एक ऐसा काम है जो एक मृत अंत नहीं है।
टोमेक एसपाकॉविकज़

29

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

ऐसा लगता है कि मैंने 2 या 3 बार ऐसा किया है जब मुझे लगा कि मेरा कोड सही है, तब मुझे एहसास हुआ कि मुझे जाने का लंबा रास्ता तय करना है।

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

और मेरा मतलब यह नहीं है कि "यह लाइन क्या करती है" को समझने का मतलब है, इसका मतलब यह पता लगाना कि "यह वर्ग अन्य सभी वर्गों के साथ कैसे फिट बैठता है" वर्ग इंटरफ़ेस को इतनी अच्छी तरह से बनाते हुए कि यह वास्तव में असंभव है इसका गलत इस्तेमाल करना।


29

वे कहते हैं कि अच्छे कोड का 70% त्रुटि जाँच और हैंडलिंग है। जब मैंने उस तरह से प्रोग्रामिंग शुरू की, तो मेरा कोड काफी बेहतर हो गया। इस बारे में सोचना कि क्या गलत हो सकता है और फिर इसे तुरंत संभालने से बहुत फर्क पड़ा है। ऐसा लगता है कि यह सब करना है कि चेकिंग केवल कोड प्राप्त करने और चलाने के तरीके से हो रही है, लेकिन यह 2 से 4 के कारक द्वारा शुरू से अंत तक का समय कम कर देता है।

बस ये लोग कौन हैं "वे" और कहाँ "वे" रहते हैं?


28

मेरे कोडिंग कौशल में बहुत सुधार हुआ जब मैंने कुछ को लागू करने से पहले यह सोचना शुरू कर दिया कि मैं इस चीज को कैसे दस्तावेज करने जा रहा हूं

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

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


28

जो आप सीखते हैं उसे लगातार सीखें और अभ्यास करें।

के माध्यम से:

  1. पर्सनल प्रोजेक्ट्स: जब से मैंने प्रोग्रामिंग शुरू की है तब से मैं पर्सनल प्रोजेक्ट्स कर रहा हूं। छोटे गेम से लेकर इमेज प्रोसेसिंग, स्टेग्नोग्राफ़ी, फ़ाइल प्रकार विनिर्देशों को लागू करना, स्क्रैच से विभिन्न प्रोटोकॉल को लागू करना या समय के साथ विभिन्न कार्यक्रमों को लागू करना।

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


10
पुस्तकों के उल्लेख के लिए +1। अगर यह सब गलत तरीके से काम कर रहा है तो बहुत अधिक अनुभव नहीं है।
mbillard

27

यह आमतौर पर किसी भी नई तकनीक को सीखने का मेरा कालानुक्रमिक क्रम है:

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

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

  3. मेरे द्वारा सीखी गई चीज़ का उपयोग करके एक खिलौना परियोजना या दो रोल करें । मुझे परियोजना की उपयोगिता की चिंता नहीं है। मेरा मकसद सिर्फ मेरी सीख का फायदा उठाना है। (जैसे OOP के लिए एक कैलकुलेटर प्रोजेक्ट ठीक रहेगा)

  4. मैं देखूंगा कि क्या मैं काम में सामान का उपयोग कर सकता हूं । (उदाहरण के लिए, हालांकि हम काम में तोड़फोड़ का उपयोग नहीं करते हैं, मैं इसे अपने स्थानीय भंडार के रूप में उपयोग करता हूं, मैंने रूबी का उपयोग एक ऐसे कार्य के लिए किया है जो अन्यथा बहुत नीरस होगा, और समय लगता है)

  5. यह सबसे अच्छा हिस्सा है जो मुझे लगता है कि ज्यादातर लोग याद करते हैं। ज्ञान साझाकरण सत्र । उदाहरण के लिए साथी टीम के सदस्यों के लिए एक सत्र या दो को दें। मेरा मानना ​​है कि शिक्षण वास्तव में तकनीक सीखने का सबसे अच्छा तरीका है। मैं गारंटी देता हूं कि प्रौद्योगिकी के बारे में आपकी समझ कई गुना हो जाएगी, चाहे आप दर्शकों को मिले या नहीं। :-)


24

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

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