क्या एक वरिष्ठ प्रोग्रामर हमेशा किताबों का उपयोग करने के बारे में सलाह देते हैं? [बन्द है]

Question

मैं एक जूनियर डेवलपर हूं और केवल 5 साल से इंडस्ट्री में हूं। मेरी वर्तमान कंपनी में एक सीनियर है जिसे हम उसे Infestus कहते हैं। कभी-कभी मुझे खरोंच से बिल्कुल चमकने और कुछ नया करने का अवसर दिया जा रहा है।

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

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

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

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

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

Comments

क्या आँख बंद करके कुछ भी करना एक अच्छा विचार है?

— FrustratedWithFormsDesigner

आँख बंद करके किसी भी चीज़ का पालन करना एक बुरा विचार है, लेकिन "Infestus" को किताबों पर खट्टा न होने दें। किताबें पढ़ना आपके आराम क्षेत्र से बाहर निकलने और अपने प्रोग्रामिंग कौशल को फैलाने का सबसे अच्छा तरीका है।

— क्युरेलसा

ऐसा लगता है कि वरिष्ठ यह जान सकता है कि वह समस्याओं को हल करने के इन विशेष तरीकों का पालन क्यों कर रहा है - लेकिन शायद आपको यह समझाने का समय नहीं लेना चाहता कि आप क्यों, और यह आपको केवल उन संसाधनों की ओर इशारा कर रहा है जो इसे समझाते हैं। क्या आपने उन संसाधनों को पढ़ा है जो उसने आपको निर्देशित किया है? क्या वे बताते हैं कि चुना गया समाधान क्यों चुना गया?

— जॉरिस टिम्मरमन्स

5 साल में आप अब जूनियर नहीं हैं, आप जानते हैं कि? Infestus पता है कि?

— .लक्सा

...brushed it off as this is better and that's how this and this book about java says it is better. इससे तत्काल खतरे की घंटी बजनी चाहिए। यदि Infestus आपको एक स्टैंडअलोन स्पष्टीकरण नहीं दे सकता है, तो वह स्वयं इसे नहीं समझ सकता है। (या उसे बुरी दलीलों की एक इलस्ट्रेटेड बुक की एक प्रति की आवश्यकता है ।)

— ब्लर

Answer 1

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

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

बस इसके बारे में एक झटका मत बनो।

Answer 2

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

वह हमेशा मुझे पढ़ने के लिए किताबें देने की कोशिश कर रहा है ताकि मैं "सीख" सकूं जो प्रोग्राम करने के तरीके हैं।

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

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

Comments

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

— शिवन ड्रैगन

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

— Quill

@ क्विलियन - व्यक्तिगत रूप से मैं उनके नाम के साथ कॉल नहीं करूंगा। ऐसा लगता है कि आप हर चीज से बहुत तंग आ चुके हैं। मैं आपके प्रबंधक के साथ इस बारे में बात करने पर गंभीरता से विचार करूंगा, संभवतः एचआर भी। किसी के साथ दुर्व्यवहार करने के लिए जीवन बहुत छोटा है।

— webdad3

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

— webdad3

Infestus की भावनात्मक प्रतिक्रिया है जो वह गहरा कुरूपता के रूप में देखता है। वह शायद किसी से लाभ उठाकर उसे खुद को नियंत्रित करने के लिए कह सकता था।

— केविन क्लाइन

Answer 3

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

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

Comments

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

— रामधुन

Answer 4

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

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

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

विचार मूर्खतापूर्ण हो सकते हैं। हम सभी गलती करते हैं और चीजों को याद करते हैं, यहां तक ​​कि वरिष्ठ लोग भी। जब किसी डिज़ाइन में कोई खराबी होती है, तो सबसे अच्छा सवाल यह होता है कि "आप इसे इस तरह से क्यों कर रहे हैं? क्या यह स्थिति X, Y, Z में नहीं टूटेगा? डिजाइन बी बेहतर नहीं होगा?"

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

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

Comments

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

— १०

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

— गुस्ताव बर्तराम

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

— webdad3

Answer 5

जिस कंपनी में आप काम करते हैं, वह संभवतः है। यह वही है जो उन्हें आपको करने की आवश्यकता है।

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

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

Answer 6

IMHO, यहां 2 पहलू हैं, जिनसे आपको अलग से निपटना चाहिए:

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

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

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

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

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

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

Comments

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

— 15

ठीक है, हां, मैं देख रहा हूं कि आपका क्या मतलब है, लेकिन यह सब वास्तव में पुस्तक पर निर्भर करता है और उसने इसकी सिफारिश कैसे की। यानी अगर वह कहता है कि "यू ने बुरा किया, तो कुछ प्रोग्रामिंग किताबें पढ़ें" जो कि जाहिर तौर पर बुरा है, लेकिन अगर वह कहता है "देखो, प्रभावी जावा 2 डी संस्करण एक सरल और बेहतर उदाहरण देता है कि सिंग्लेट्स को कैसे करना है, इसे यहां देखें । safaribooksonline.com/book/programming/java/9780137150021/... "तो मुझे लगता है कि आप के लिए एक उपयोगी बात है कहेंगे (फिर से, प्रसव के स्वर पर चर्चा अलग छोड़कर)

— Shivan ड्रैगन

मैं इस व्यवहार को कभी "अनदेखा" नहीं करूंगा। या तो उसके बॉस के साथ बैठना होगा या सिर्फ अपने बॉस के साथ बात करना छोड़ना होगा अगर मैंने पहले ही उसे बता दिया कि कॉलिंग नाम नहीं उड़ जाएगा।

— रिग

Answer 7

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

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

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

Answer 8

आँख बंद करके किताबों का पालन करना एक बुरा विचार है, लेकिन वास्तव में किसी पुस्तक का अनुसरण करना और आँख बंद करके उसके बीच अंतर करना है ।

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

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

Answer 9

प्रोग्रामिंग में किताबें और ब्लॉग पोस्ट पढ़ना बहुत मददगार है। कुछ किताबें हैं, जिन्हें सभी डेवलपर्स को पढ़ना चाहिए।

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

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

Comments

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

— रामहुंड

Answer 10

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

Comments

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

— 18

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

— क्लेम

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

— क्लेम

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

— रामहुंड

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

— क्विल

Answer 11

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

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

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

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

Answer 12

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

इंटरनेट पर उक्त जानकारी की मात्रा अधिक है।

इसलिए मेरी सामान्य रणनीति है कि गहरी समझ पाने के लिए किताबों से सीखना और उसके बाद इंटरनेट से सीखकर अलग-अलग निहितार्थों से अवगत कराना और मेरे अनुभव को व्यापक करना। (और अक्सर देखें कि सामान कैसे नहीं करना है)।

Answer 13

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

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

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

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

कुछ अन्य तर्क जो एनमों का उपयोग करने के खिलाफ किए जा सकते हैं:

• यह एक हैक है - यह उन चीज़ों के लिए दुश्मनी का उपयोग कर रहा है, जिनके लिए उनका इरादा नहीं था
• यह उन पाठकों को भ्रमित कर रहा है जिन्होंने इसे पहले नहीं देखा है

Comments

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

— स्टीफन C

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

— डैनियल लुबरोव

इसके विपरीत, यह मुझे अजीब लगता है कि आप सिंगलेट्स और उन जटिलताओं से परेशान होंगे जो आपको ज़रूरत नहीं है। मेरे दिमाग में, "ट्रांसफॉर्मर" ऑब्जेक्ट बनाने, उपयोग करने और फेंकने के लिए सबसे सरल दृष्टिकोण है ... सिवाय इसके कि जब उन्हें पुन: उपयोग करने के लिए एक मजबूत कारण / प्रोत्साहन हो।

— स्टीफन C

Answer 14

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

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

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

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

Answer 15

अलग-अलग कार्यस्थल शिष्टाचार सेट करना, एक मेंटर की भूमिका की वास्तविकता को अलग करना जो कि वरिष्ठ डेवलपर्स के पास है, अपनी इच्छा का पता लगाने के लिए अलग-अलग सेटिंग करना, अपमानजनक व्यवहार को अलग करना, और पुस्तकों के लिए अलग सेट करना ...

किसी टीम में कोड समीक्षा के उद्देश्य कोड को मान्य करने के लिए 1) और 2) यह सुनिश्चित करने के लिए कि कोड लिखने वाला व्यक्ति कोड सुधार के अर्थ को समझता है। यह कहने का स्थान नहीं है कि "इसे बदल दें क्योंकि मार्टिन फाउलर ने गोफ पुस्तक में ऐसा कहा है"। हालांकि, यह कहने का स्थान है "इसे बदल दें क्योंकि [संक्षिप्त विवरण]; गोफ पुस्तक में इस पर चर्चा करने के बारे में अधिक विवरण है"।

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

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

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

Answer 16

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