सिर्फ पंपिंग कोडिंग आपको बेहतर डेवलपर क्यों नहीं बनाएगी

Techlead Skyeng Kirill Rogovoy ( flashhhh ) उन सम्मेलनों में बोलता है जिसमें वह उन कौशलों के बारे में बात करता है जिन्हें हर अच्छे डेवलपर को सर्वश्रेष्ठ बनने के लिए विकसित करने की आवश्यकता होती है। मैंने उसे हाबरा के पाठकों के साथ इस कहानी को साझा करने के लिए कहा, मैं शब्द को सिरिल को पास करता हूं।

एक अच्छे डेवलपर के बारे में मिथक कहता है कि वह:

1. साफ कोड लिखता है
2. बहुत सारी तकनीक जानता है
3. कोडिंग कार्य तेजी से
4. डिजाइन एल्गोरिदम और पैटर्न का एक गुच्छा जानता है
5. क्लीन कोड का उपयोग करके किसी भी कोड को रिफलेक्टर कर सकते हैं
6. गैर-प्रोग्रामेटिक कार्यों पर समय बर्बाद न करें
7. अपनी पसंदीदा तकनीक के 100% मास्टर

यह एचआर कैसे क्रमशः आदर्श उम्मीदवारों और रिक्तियों को देखता है, यह भी इस तरह दिखता है।

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

सबसे पहले, दो महत्वपूर्ण अस्वीकरण:
1) मेरा अनुभव उत्पाद टीम है, अर्थात अपने उत्पाद के साथ कंपनियां, आउटसोर्सिंग नहीं; आउटसोर्सिंग बहुत अलग हो सकती है;
2) यदि आप एक जूनियर हैं, तो सभी युक्तियां लागू नहीं होंगी, और मैं अभी भी आपकी जगह पर प्रोग्रामिंग पर ध्यान केंद्रित करूंगा।

अच्छा डेवलपर: वास्तविकता

1: कोडाइट औसत से बेहतर है

एक अच्छा डेवलपर जानता है कि एक शांत आर्किटेक्चर कैसे बनाया जाए, कूल कोड लिखें, और बहुत सारे बग न बनाएं; सामान्य तौर पर, उसके लिए औसत से सब कुछ बेहतर है, लेकिन वह विशेषज्ञों के शीर्ष 1% में नहीं है। सबसे अच्छे डेवलपर्स जो मुझे पता है कि इतने महान कोडर नहीं हैं: वे अपने क्षेत्र में अच्छी तरह से वाकिफ हैं, लेकिन वे सुपर-सुपर कुछ भी नहीं कर सकते हैं।

2: समस्याओं को हल करता है, उन्हें नहीं बनाता है

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

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

3: न्यूनतम प्रयास खर्च करने की कोशिश करता है, अधिकतम परिणाम प्राप्त करना, भले ही आपको बैसाखी लिखना पड़े

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

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

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

4. इसकी अपनी व्यवसाय प्रबंधन प्रणाली है, इसमें किसी भी जटिलता की परियोजनाओं को काम करने में सक्षम है।

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

5. किसी भी स्थिति और परिचयात्मक संदेह और स्पष्टीकरण

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

6. प्रक्रियाओं और अपने आसपास के लोगों को बेहतर बनाता है।

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

7. पूरी तरह से दूसरों का प्रबंधन करता है, भले ही वह प्रबंधक न हो

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

8. अपने ज्ञान को एक हठधर्मिता के रूप में अनुभव नहीं करता है, लगातार आलोचना के लिए खुला है

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

आमतौर पर स्वीकृत एक आदर्श डेवलपर के मेरे विचार की तुलना करें:

इस तस्वीर में आप देख सकते हैं कि ऊपर के कितने बिंदु कोड से संबंधित हैं, और कितने नहीं हैं। एक किराने की कंपनी में विकास केवल एक तिहाई प्रोग्रामिंग है, शेष 2/3 में कोड के साथ बहुत कम है। और यद्यपि हम बहुत सारे कोड लिखते हैं, हमारी प्रभावशीलता इन दो-तिहाई "असंबंधित" पर बहुत अधिक निर्भर है।

विशेषज्ञता, सामान्यता और नियम "80-20"

जब कोई व्यक्ति कुछ संकीर्ण समस्याओं को हल करने के लिए सीखता है, तो वह लंबे समय तक और कठिन सीखता है, लेकिन फिर वह उन्हें आसानी से और सरलता से हल करता है, लेकिन संबंधित क्षेत्रों में विशेषज्ञता नहीं है - यह एक विशेषज्ञता है। दूसरी ओर, सामान्यवाद वह है, जब प्रशिक्षण का समय किसी की क्षमता के एक क्षेत्र में निवेश किया जाता है, और संबंधित क्षेत्रों में एक और आधा। तदनुसार, पहले मामले में, मैं एक काम पूरी तरह से करता हूं, और बाकी - बुरी तरह से, और दूसरे में - मैं सब कुछ कम या ज्यादा अच्छी तरह से करता हूं।

80-20 नियम हमें बताता है कि परिणाम का 80% प्रयास के 20% के माध्यम से प्राप्त किया जाता है। 80% राजस्व 20% ग्राहकों द्वारा लाया जाता है, 80% लाभ 20% कर्मचारियों और इतने पर उत्पन्न होता है। प्रशिक्षण में, इसका मतलब है कि हम पहले खर्च किए गए समय के पहले 20% में 80% ज्ञान प्राप्त करते हैं।

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

कुल: आप एक निश्चित कौशल को सीमा तक सीखने के लिए 100% समय बिता सकते हैं, या आप पांच क्षेत्रों में एक ही समय बिता सकते हैं, प्रत्येक में 80% पंप कर सकते हैं। इस भोले गणित के बाद, हम एक ही समय में चार गुना अधिक कौशल प्राप्त कर सकते हैं। यह एक अतिशयोक्ति है, लेकिन यह विचार को दिखाता है।

आसन्न कौशल को 80% से नहीं, बल्कि 30-50% से प्रशिक्षित किया जा सकता है। 10-20 घंटे बिताने के बाद, आप संबंधित क्षेत्रों में विशेष रूप से पंप करेंगे, उनमें होने वाली प्रक्रियाओं की बहुत समझ प्राप्त करें और अधिक स्वायत्त बनें।

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

और अंत में, प्रशिक्षण एक निवेश है, और निवेश में विविधीकरण महत्वपूर्ण है।

क्या सिखाना है?

तो क्या पढ़ाया जाए और कैसे? एक मजबूत कंपनी में एक सामान्य डेवलपर नियमित रूप से उपयोग करता है:

• संचार
• आत्म संगठन
• आयोजन
• डिजाइन (आमतौर पर कोड)
• और कभी-कभी प्रबंधन, नेतृत्व, डेटा विश्लेषण, लेखन, भर्ती, सलाह और कई अन्य कौशल

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

कौन से क्षेत्र विकसित करने लायक हैं?

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

   
   

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

   
   

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

   
   

4. बुनियादी स्तर से संबंधित सभी क्षेत्रों। हर किसी के अपने विशिष्ट क्षेत्र होते हैं, लेकिन यह समझना महत्वपूर्ण है कि किसी भी प्रकार के "विदेशी" कौशल को पंप करने में 10-20 घंटे का समय व्यतीत करने से आप रोजमर्रा के काम में कई नए अवसरों और सामान्य आधार की खोज कर सकते हैं, और ये घंटे पर्याप्त हो सकते हैं। कैरियर का अंत।

   
   

क्या पढ़ना है?

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

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

2. स्टीफन आर। कोवे, "अत्यधिक प्रभावी लोगों के 7 कौशल । " तालमेल हासिल करने पर जोर देने के साथ विभिन्न कौशल का मिश्रण, सक्रियता से लेकर सॉफ्ट स्किल तक, जब आपको छोटी टीम को एक बड़ी ताकत में बदलने की जरूरत होती है। पढ़ने में आसान।

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

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

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