- काम की जगह पर भले ही आपको टॉप-टियर engineer माना जाए, असली高手ों से तुलना करने पर अंतर बहुत बड़ा हो सकता है, और यह अंतर आम तौर पर ठीक से सीखी गई मात्रा में दिखता है
- हाई स्कूल के बाद art छोड़ देने का अनुभव बताता है कि Drawing On The Right Side Of The Brain जैसी एक किताब और कुछ घंटों की practice ही “सही material” के जरिए barrier को कम कर सकती है
- engineering में भी किसी खास topic पर एक किताब या उससे ज़्यादा पढ़ चुके लोगों और लगभग कभी कोशिश न करने वालों के बीच बड़ा अंतर होता है; कई professions में दूसरा group ही majority है
- expertise, local·national·Olympic level fencing की तरह परत-दर-परत बंटी होती है, और जो लोग कई किताबें पढ़कर गहराई में जाते हैं वे सबसे ऊपरी jobs की competition के करीब पहुंचते हैं
- सिर्फ किताब पढ़ना काफी नहीं है; अच्छे material चुनने और खराब हिस्सों को छोड़ देने वाली meta skill न हो तो Scrum·Agile·leadership material पकड़े रहने पर भी परिणाम निकालना मुश्किल है
“टॉप-टियर हूं, फिर भी कम पड़ता हूं” वाला शुरुआती बिंदु
- लेखक अपने work environment में लगातार अच्छे engineer के रूप में पहचाने जाते रहे हैं
- वे कहते हैं कि वे अपने आसपास के average engineer की तुलना में कई गुना, कभी-कभी दो अंकों तक, ज्यादा study करते हैं
- उन्हें अपने state की सबसे अच्छी companies में से एक में senior level offer मिला था
- “Serious People” उन्हें फिर से hire करना चाहते हैं और आलसी commit messages पर नाराज़ होते हैं
- लेकिन उन्हें email भेजने वाले कई लोगों की तुलना में वे खुद को स्पष्ट रूप से कमतर मानते हैं
- उनका experience 3–4 साल का है और background psychology में है
- personal projects के अलावा उन्होंने लगभग कभी tests नहीं लिखे; जिन employers को उन्होंने देखा, उनके पास working tests या tests अपनाने की इच्छा नहीं थी
- उन्होंने अपने master’s thesis का code version control के बिना लिखा, और बताते हैं कि देश की top universities में से एक ने version control नहीं सिखाया
- वे इस contradiction को art, engineering और sports के उदाहरणों से समझाते हुए “थोड़ा ठीक से सीख चुके व्यक्ति” और “लगभग कोशिश ही न करने वाले व्यक्ति” के बीच का gap highlight करते हैं
art में अनुभव किया गया “सही एक किताब” का असर
- high school के समय वे art से सबसे ज्यादा नफरत करते थे, और खुद को artsy नहीं मानने के बाद करीब 10 साल तक doodle-level cubes के अलावा लगभग कुछ नहीं बनाया
- 2022 में उन्होंने Drawabox course try किया, लेकिन उन्हें यह बहुत boring लगा और उन्हें कोई progress भी नहीं दिखी
- बाद में Hacker News की recommendation से वे Betty Edwards की Drawing On The Right Side Of The Brain तक पहुंचे
- psychology छोड़ चुके लेखक को title असहज लगा, लेकिन recommendation और before/after examples मौजूद थे
- after drawings इतनी अवास्तविक लगीं कि वे weight-loss scam जैसी महसूस हुईं
- किताब का पहला task था अपनी hand को जितना हो सके उतना अच्छा draw करना, और लेखक ने 30–45 मिनट तक draw किया
- उस समय के हिसाब से वह उनके जीवन की best drawing थी, लेकिन वे फिर भी उसे insufficient मानते हैं
- इसके बाद उन्होंने upside-down image की lines को आंखों से follow कर draw करने जैसी practice की, और कुछ और drawings बनाने पर result देखकर हैरान हुए
- जब उन्होंने फिर से hand draw की, तो लगभग 6 घंटे की reading और practice भर से वह पहले से काफी बेहतर हो गई
- यह अनुभव एक ऐसा case बना जिसमें वे जीवनभर art का आनंद चूक सकते थे, लेकिन सही किताब उठा लेने के बाद barrier पार कर गए
“एक किताब का barrier” और engineers का distribution
- engineers मोटे तौर पर दो groups में बंटते हैं
- किसी खास topic पर 1 या उससे अधिक किताबें पढ़ चुके engineers आम तौर पर काफी capable लगते हैं
- यह literally किताब ही हो, जरूरी नहीं; पर्याप्त मात्रा में technical blogs या lectures भी efficiency में फर्क के बावजूद similar role निभा सकते हैं
- दूसरी तरफ ऐसे engineers और दूसरे professions के लोग हैं जो अपने पूरे career में लगभग कोशिश ही नहीं करते, और लेखक के अनुसार यही majority हैं
- expert engineer Seth Newman average professional को “working life को sleepwalk करते हुए गुजरने वाला व्यक्ति” जैसा बताते हैं
- movement तो है, लेकिन stairs से लुढ़कने से बचने लायक awareness की कमी है—ऐसी analogy दी जाती है
- लेखक खुद को ज्यादातर work-related topics में एक अच्छी किताब भर पढ़े व्यक्ति के करीब मानते हैं
- Pro Git से वे Git data model को पक्के तौर पर समझते हैं, लेकिन उसके नीचे के algorithms नहीं जानते
- फिर भी वे मानते हैं कि randomly चुने गए engineer पर भारी पड़ने के लिए यह काफी है
- Evennia जैसे projects देखकर वे मानते हैं कि उनसे कहीं ज्यादा गहरे level के लोग भी मौजूद हैं
- कई क्षेत्रों के high performers से बात करने पर, उन्हें लगभग हर field में ऐसे लोग बहुत दिखे जो ठीक से कोशिश तक नहीं करते—ऐसी प्रतिक्रिया मिली
expertise अनंत परतों में बंटी रहती है
- Seth के साथ बातचीत deep specialization आखिर कहां तक जाती है, इस पर पहुंची
- basketball example में वे एक video का जिक्र करते हैं जिसमें NBA के सबसे निचले स्तर के players में गिने जाने वाले व्यक्ति ने retirement के 10 साल बाद, खराब physical condition में भी amateurs और lower-pro level players को dominate किया
- लेखक का fencing experience भी इसी structure को दिखाता है
- Melbourne में लेखक को एक ठीक-ठाक sabre fencer माना जाता था, और वे ज्यादातर amateurs को हरा देते थे
- लेकिन state championship में जाने वाले कुछ players ने उन्हें पूरी तरह दबा दिया
- उनके साथ training करने वाला player बाद में Australian Nationals जीता, लेकिन Olympic qualifiers की कोशिश करने वाले player के खिलाफ एक point भी नहीं ले पाया
- Malaysia के Yu Peng Kean 2012 Olympics में उस साल के winner से 15–1 से हार गए
- यह hierarchy वैसी ही है जैसे Magnus Carlsen lifelong trained chess players को dominate करता है—अजनबी नहीं, लेकिन सीधे सामना करने पर बिल्कुल अलग महसूस होती है
- top players हमेशा थोड़ा ज्यादा दूर, तेज और accurate लगते हैं; opponent को ऐसा लगता है जैसे कोई बच्चा किसी adult पर दौड़ पड़ा हो
incentives और “tech industry में गलत जगह आ गए लोग”
- लेखक स्वीकार करते हैं कि piano जैसे क्षेत्रों में वे खुद भी sleepwalking state के करीब हैं
- उन्हें talent की कमी भी लगती है, लेकिन सच में वे पर्याप्त practice नहीं करते
- हालांकि वे piano को profession नहीं बनाते, और कोई उन्हें piano बजाने के पैसे नहीं देता
- tech field में वे मानते हैं कि society ऐसे लोगों को भी participate करने के incentives देती है जिनमें talent या interest नहीं है, और यह गलत है
- कई लोग sports, art, math जैसे दूसरे areas में जागरूक हो सकते हैं
- कुछ fields में बहुत पैसा है, बड़े organizations चलाना मुश्किल है, और corporate money को personal status में बदलने की कोशिशों की वजह से खराब programmers और खराब leaders को भी high salaries मिलती हैं—वे ऐसा मानते हैं
- वे PowerBI developer को average से ज्यादा salary पाने और दिन में 6 घंटे से ज्यादा आलस करने का आसान तरीका बताते हुए कड़ी आलोचना करते हैं
- Christopher Hitchens के पहले job experience को quote करते हुए वे जोर देते हैं कि वे किसी काम में इतने खराब थे कि उसमें टिके रहना संभव नहीं था, इसलिए वे किसी और रास्ते पर निकल सके
एक किताब से बनने वाली competitive advantage
- Dan Luu के article very little effort से जोड़ते हुए वे मानते हैं कि कई बार high performer बनने के लिए बहुत कम effort ही चाहिए
- high performer वह व्यक्ति हो सकता है जो backflip जैसे clear task कर सके, या वह जो दूसरों की तुलना में ज्यादा output दे
- एक किताब आम तौर पर आपको “technical debt बनाए बिना React app में नया feature जोड़ने” के level तक ले जा सकती है
- अगर आप समाज द्वारा reward किए जाने वाले काम को समझदारी से चुनें, तो ethical तरीके से livelihood चलाने के लिए यह काफी है
- कई किताबें पढ़ने पर आप highest-paying jobs की competition के करीब पहुंचते हैं
- ऐसे area में फर्क यह होता है कि वही काम एक दिन में कर सकते हैं या एक हफ्ते में
- अगर competitor N किताबें पढ़ता है, तो आपको N+1 किताबें पढ़नी होंगी—यह एक arms race बन जाता है
- क्योंकि Deloitte और average developers कोई किताब नहीं पढ़ते, लेखक मानते हैं कि उनका सामना करना आसान है
- full-time employee बनकर organization के भीतर बंध जाएं तो ऐसे लोगों के साथ काम करना पड़ता है, जिससे helplessness महसूस हो सकती है
- अगर ज्यादा mercenary तरीके से चलें, तो interviews और meetings में उन्हें dominate किया जा सकता है—वे ऐसा मानते हैं
- technical interviews में वे सुझाव देते हैं कि candidates से उनकी पसंदीदा technical book पूछी जाए, और केवल उन लोगों से आगे बात की जाए जिन्होंने ऐसी किताब बताई हो जिसकी सामग्री interviewer verify कर सके; इससे ज्यादातर dud candidates छांटे जा सकते हैं
- अगर candidate ने interviewer को न पता कोई बेहतरीन किताब पढ़ी हो, तो false negative हो सकता है
- वे अनुमान लगाते हैं कि false positive लगभग नहीं होंगे
मेहनत करते हुए भी result न पाने वाले लोग और material चुनने की क्षमता
- ज्यादा complex case उन team operators का है जो सचमुच मेहनत करते हैं लेकिन result नहीं निकाल पाते
- वे engineers को परेशान करते हैं, घबराते हैं, hiring नहीं जानते, अपनी ability को overestimate करते हैं, लेकिन sincere effort करते हैं
- वे लगातार Scrum को ठीक से करने की कोशिश करते रहते हैं, लेकिन अंत में झील में चलते चले जाने वाले sleepwalker जैसे दिखते हैं
- उनमें जो ability कम है वह है कौन-सी किताब पढ़नी है, यह जानने की meta skill
- Drawabox और Betty Edwards की किताब का अंतर इसका representative example है
- Drawabox ऊपर से plausible लगा, लेकिन लेखक के goal के लिए Edwards की किताब कहीं बेहतर थी
- लेखक के अनुसार Drawabox यह assume करता था कि Edwards ने जिस core trick पर जोर दिया, वह आपको पहले से आती है, और फिर mechanical skills पर चला जाता था
- उस missing piece की वजह से पूरा course खत्म करने पर भी शायद progress लगभग नहीं होती
- tech field में आम तौर पर लेखक ऐसे लोगों के material पर ज्यादा भरोसा करते हैं जिन्होंने खुद impressive चीजें बनाई हों
- open source maintenance या fake करना मुश्किल knowledge के signals हों तो वे ज्यादा score देते हैं
- “big company” जैसे ज्यादा धुंधले achievements को कम score मिलता है, क्योंकि वे luck या bluff से मिल सकते हैं
- code compile होता है या नहीं, इसे छिपाना मुश्किल है—वे ऐसा मानते हैं
- वे material evaluation के लिए कुछ loose rules भी देते हैं
- बहुत ज्यादा attention-grabbing names negative factor हैं
- अच्छी किताबों के covers अक्सर boring या polished होते हैं—वे ऐसा मानते हैं
- title में “leadership” हो तो आम तौर पर nonsense होने की संभावना ज्यादा मानते हैं
- author जितना ज्यादा awards का brag करे, उतना ही झूठ जैसा महसूस होता है
- conversational style negative है, लेकिन subject नाजुक हो तो यह fatal flaw नहीं मानते
Agile, The Phoenix Project और LinkedIn learning पर आलोचना
- workplace में Agile consultant आया, management को पसंद आया, लेकिन engineers से पूछा गया कि “Agile training को 1–5 points पर rate करें”
- लेखक के अनुसार यह सवाल ही meaningless है
- वे कहते हैं कि उस session को पसंद करने वाले लोगों और गलत किताबें पढ़ने वालों के बीच लगभग 100% correlation था
- किताब के भीतर भी worthless हिस्सों को छोड़ पाने की क्षमता होनी चाहिए
- The Phoenix Project में अच्छे ideas हैं, लेकिन organizational transformation story में केवल एक bad actor रखना और बाकी सबको बहुत capable और sincere दिखाना big-company reality से अलग है—वे ऐसा मानते हैं
- अच्छे ideas लेने चाहिए, लेकिन बाकी हिस्सा “leadership fanfic” के करीब है—यह पहचानना चाहिए
- यह selection ability न हो तो learning और self-improvement बहुत रुक जाते हैं
- जब executives अपनी reading material publicly बताते हैं, तो कई बार तुरंत दिख जाता है कि उस व्यक्ति के काम में अच्छा होने की संभावना कम है—वे ऐसा मानते हैं
- अगर कोई leader कहे कि वह LinkedIn से सीखता है, तो लेखक को तीव्र dislike महसूस होता है
निष्कर्ष: किताब खोलना असरदार है, लेकिन competitors को सलाह देने की जरूरत नहीं
- शुरू में यह लेख YouTube era में किताब खोलने के असामान्य रूप से बड़े असर पर पीछे मुड़कर देखने वाला होने वाला था
- असल निष्कर्ष ironic रूप से इस तरफ जाता है कि किसी भी स्थिति में लोगों को किताब पढ़ने की सलाह न दें
- अगर दूसरे लोग न पढ़ने की हालत में ही बने रहते हैं, तो किताब पढ़ने वाले के लिए यह easy money बन जाता है
- अंत में वे मजाक करते हैं कि अगला लेख anti-Git propaganda और Scrum material links से भरेंगे
2 टिप्पणियां
तकनीक का इस्तेमाल करना हो तो पहले यह जानना ज़रूरी है कि वह मौजूद भी है, तभी उसे आज़माने की कोशिश की जा सकती है, इसलिए सतही स्तर पर ही सही, उसके बारे में कुछ जानना महत्वपूर्ण है।
Hacker News की राय
लेख अच्छा लिखा गया है, लेकिन लगता है कि यह अनुभवी इंजीनियर के tacit knowledge को कम आंकता है, जो शुरुआती लोगों के पास नहीं होता
कभी-कभी वह बस common sense जैसा दिखता है, लेकिन असल में वैसा नहीं होता, और नतीजतन सहानुभूति की कमी में बदलना आसान होता है। बच्चों या बुज़ुर्गों के साथ समय बिताने से, या किसी मुश्किल में पड़े रिश्तेदार की उसी तरफ खड़े होकर मदद करने से ऐसी सहानुभूति बन सकती है। यह वैसा ही है जैसे किसी native speaker का बस सहजता से बोलना और भाषा सीखते हुए संघर्ष कर रहे व्यक्ति के बीच का फर्क
consistent indentation या compiler error messages को सचमुच पढ़कर debugging में इस्तेमाल करने जैसी बातें, जिन्हें मैं obvious मानता था, उनमें मेरे भाई को दिक्कत होती थी। उसे programmer के रूप में नौकरी पाने लायक स्तर तक पहुंचने में कई साल लगे, और सच तो यह है कि मुझे भी कई साल लगे थे; मैं बस अपना starting point भूल गया था
consulting company में सबसे बेहतरीन engineer severe ADHD की वजह से किताबें मुश्किल से पढ़ता है, लेकिन उसका hands-on experience जबरदस्त है और वह documentation और उच्च-स्तरीय blog posts काफी पढ़ता है, इसलिए कुछ हद तक बराबरी दिखती है। एक बेहद शानदार व्यक्ति ने कभी कहा था कि “किताबों से खास मदद नहीं मिली,” फिर भी उसने उसी साल पढ़ी पांच किताबों के नाम फटाफट गिना दिए। भले ही किताबें खुद उसके लिए बहुत उपयोगी न रही हों, उन पांच किताबों को खोलने का discipline ही शायद उसे शीर्ष पर ले गया
वह feel बहुत बड़े पैमाने की deliberate practice से आती है
“वे engineers जो पूरे career में कभी सचमुच ठीक से कोशिश ही नहीं करते” वाला हिस्सा मेरे अनुभव से 100% मेल खाता है
मैं कोई genius developer नहीं हूं; मुझे लगता है कि सौंपे गए छोटे-scale problems के लिए ठीक-ठाक solution बना सकता हूं और सही-गलत approach की समझ भी है, लेकिन यह भी पक्का नहीं कि मैं FAANG interview दे पाऊंगा या नहीं। काम करते समय मैं हमेशा alert रहता हूं, जैसे जरा-सा ध्यान हटते ही gremlins अंदर घुस आएंगे
जैसे दो senior engineers द्वारा पहले ही approve किए गए PR को 30 सेकंड देखकर ही गंभीर security flaw पकड़ लेना; या ऐसा loading pattern देखना जो test किए गए 5 records पर ठीक है लेकिन real dataset पर हर page के लिए 300 database queries चला देता है; या ऐसा code देखना जो तुरंत फेंक दिए जाने वाले timestamp से date object reconstruct करने में CPU time का 75% खर्च कर देता है। आखिरकार यह programming के प्रति जन्मजात curiosity, interest और passion की कमी जैसा दिखता है
मेरे लिए अच्छी programming craftsmanship के करीब है। business needs की वजह से अगर temporary patch deploy करना पड़े तो एक ऐसी बेचैनी होती है जिसे शब्दों में कहना मुश्किल है, और अगर काम मेरी बनाई हुई चीज़ है तो product से बहुत लगाव न होने पर भी मैं उसे अच्छा बनाना चाहता हूं। “मुझे नहीं पता था कि इसे कैसे काम कराना है, इसलिए बस ऐसा कर दिया” अक्सर सुनता हूं, लेकिन असल मतलब लगभग हमेशा “पहली कोशिश एक छोटी बाधा से टकराई तो आगे कोशिश नहीं की” होता है। codebase जितना खराब होता जाता है, वैसा योगदान देना उतना मुश्किल हो जाता है जिस पर गर्व किया जा सके
सोचता हूं कि क्या मैं सिर्फ असाधारण रूप से खराब कंपनियों में ही रहा हूं, या पूरी industry सच में इसी स्तर की है
उसे खुद नहीं पता, लेकिन हमारी team का rockstar वही व्यक्ति है। उदाहरणों को देखें तो लगता है कि सहकर्मियों को अपने काम की खास परवाह नहीं थी
जब कुछ टूटता है, जब मतभेद सुलझाने होते हैं, जब कोई चीज़ ठीक न हो पाने जैसी लगती है, जब कुछ पता लगाना होता है—हर कोई मुझे बुलाता है। मैंने कभी खुद को इसका हकदार महसूस नहीं किया, और Facebook जैसी जगह पर शायद एक दिन भी नहीं टिक पाऊंगा। team में fit होने और political structure झेलने की क्षमता नहीं है, इसलिए मुझे अंधेरे कोने पसंद हैं
अगर पूछा जाए कि क्या पूरी industry इसी स्तर की है, तो असल में यह इससे कहीं बदतर है। industry में लोग पहले से कहीं ज्यादा हो गए हैं, और सच में कुछ जानने वाले लोगों को खोजना लगभग असंभव है। 5–10 साल में भरोसेमंद लोगों की सूची बनाइए, और उन्हें कभी मत छोड़िए, रिश्ते बनाए रखिए
क्योंकि भीड़ में छिपना मुश्किल होता है, हालांकि हर size की company में smart और dedicated लोग होते हैं। लगातार आग बुझाने में मत लगे रहिए; ऐसे लोगों को खोजिए जो आपके principles share करते हों या उनका सम्मान करते हों, तो ठीक रहेगा
मैंने बहुत से ऐसे लोगों को देखा है जो issue पर बिना खास interest, care या curiosity के code फेंक देते हैं और उसे ठीक मान लेते हैं। मेरे पुराने manager “spark” वाले लोगों को खोजते थे, और मुझे hire किया, तो शायद उस समय मुझमें भी वह थी
जिन developers में ऐसी spark नहीं है, उनके लिए भी जगहें हैं; उल्टा, केवल ऐसे लोगों को इकट्ठा करने की कोशिश में परेशान हुए organizations भी देखे हैं। लेकिन पैसे या stable लगने वाली job की वजह से आए bootcamp graduates भी बहुत हैं, और अक्सर इसके अलावा उनमें खास interest नहीं होता
अगर 2025 में revenue इतना हो जाए कि 2026 में hiring कर सकें, तो consulting company को email भेजकर देखिए
“सही किताब” पढ़ना अहम है। हाई स्कूल में मैंने कुछ self-help किताबें पढ़ी थीं, और कुछ ही किताबें पढ़कर समझ आ जाता है कि लेखक जैसा कहते हैं, उनमें से ज़्यादातर fanfic के क़रीब होती हैं
पढ़ते समय आप खुद से लगातार पूछते रहते हैं, “क्या यह तो obvious है? क्या मैं यह पहले से जानता था?” उदाहरण और कहानियाँ बहुत होती हैं, और “skin in the game” जैसे साधारण रूपक या नारे को पूरी ज़िंदगी की philosophy तक फैलाने का pattern अक्सर दिखता है
दूसरे group ने जानकारी कहीं बेहतर याद रखी। इंसान कहानियों की ओर खिंचने वाला प्राणी है, और सबसे पुराने महाकाव्य कहानियाँ हैं, इसकी वजह है। self-help किताबें भी वही formula इसलिए अपनाती हैं क्योंकि वह काम करता है। किसी चीज़ को पढ़ना, समझना, लागू करना, और फिर उस application में महारत हासिल करना—ये सब एक-दूसरे से बहुत अलग हैं
मेरे हिसाब से ऐसी किताबों का सार यह है कि आप किसी idea, routine या process को पूरी तरह अपना लें, और स्थिति आने पर उसे लगभग instinct की तरह लागू करने की क्षमता बना लें। कुछ किताबों के लिए blog post ही काफ़ी होता, और कुछ में page count बढ़ाने के लिए सबसे खराब तरह की लंबी-चौड़ी बातें होती हैं, लेकिन बहुत-सी कहानियाँ और narratives इसीलिए होते हैं कि पाठक उनमें से किसी एक में खुद को देख सके और सबक को गहराई से याद रखे। किसी किताब को सिर्फ़ इसलिए दोष नहीं दे सकते कि उसे उपयुक्त title दिया गया है
मुझसे अक्सर पूछा जाता है कि क्या मैं Cal Newport पढ़ता हूँ, लेकिन अच्छे points और घिसे-पिटे points को मिलाकर फिर examples और stories पर टिकने का उनका तरीका मुझे पसंद नहीं, इसलिए सहना मुश्किल होता है। examples और stories की जगह होती है, लेकिन वह तरीका मुझे convincing नहीं लगता। अफ़सोस है कि लिखते समय ऊपर की तीन बातें याद नहीं आईं, और यह भी मज़ेदार है कि “Skin In The Game” खुद Taleb की किताब है। इसका मतलब यह नहीं कि वह किताब खराब है; बस मज़ा इस बात का है कि जिस लेखक ने मुझे ऐसे patterns से immune किया, उसकी किताब ही example में आ गई
आम तौर पर शुरुआत में एक-दो अच्छे ideas आते हैं, और बाकी repetition और filler होता है। यह समस्या इतनी आम है कि ज़्यादातर मामलों में सिर्फ़ YouTube summary video सुन लेना भी ठीक लगता है। एक और trick है कि हमेशा first edition ढूँढो, क्योंकि वे आम तौर पर छोटी और ज़्यादा स्पष्ट होती हैं
फिर से किताबें पढ़ना शुरू करने के बाद मेरी attention span और focus काफ़ी बढ़ गई, और doomscroll करने की इच्छा भी कम हो गई
बहुत-से लोग अपने अंदर जिन चीज़ों को ADHD जैसा समझते हैं, वे कम विकसित या जानबूझकर नज़रअंदाज़ की गई focus ability से भी overlap करती हैं। इसका मतलब यह नहीं कि हर किसी के साथ ऐसा है। अगर आपको खुद से या किसी specialist से ADHD diagnosis मिला है, तो यह देखना चाहिए कि क्या आप focus माँगने वाले काम करके नियमित रूप से अपनी focus muscles train करते हैं, और क्या आप खुद को doomscrolling या short videos जैसे कचरे से दूर रखते हैं। कहीं आप दर्द के सेवक की तरह मुश्किल चीज़ों से बचकर समस्या को और मजबूत करने वाले व्यवहारों में तो नहीं फँस रहे? focus हर किसी के लिए खर्च होने वाली क्षमता है
बात थोड़ी बढ़ा-चढ़ाकर कही गई है और reality ज़्यादा complex है, लेकिन general principle से सहमत हूँ। आप जो काम करते हैं उसकी सच में परवाह भर कर लें, तो सिर्फ़ salary लेने आने वाले लोगों से बहुत आगे निकल सकते हैं
“समाज में कुछ बहुत गलत हो गया है जब उसने ऐसे लोगों को tech field की ओर धकेलना शुरू किया जिनमें talent या interest नहीं है” — इस भावना से मैं काफी हद तक सहमत हूँ, लेकिन यह mindset दिलचस्प निष्कर्षों तक ले जाता है
पहला, tech hiring process पूरी industry के अंदर की complaints से भी कई स्तर ज़्यादा inefficient हो सकता है। entry-level talent खोजते समय भी शायद companies गलत चीज़ों को filter कर रही हैं
दूसरा, pro sports या arts जैसे long-tail careers में financial incentives बेहद खराब होते हैं। लेखक जिस समस्या को देख रहा है, उससे निपटना हो तो इस समस्या से भी साथ में निपटना होगा, और वह अपने आप में गहरा rabbit hole है
तीसरा, अगर हालत इतनी खराब है तो companies कर्मचारियों को on-the-job train क्यों नहीं करतीं
चौथा, हम शायद ही पूछते हैं कि क्या यह opportunity cost basic income से ज़्यादा महंगी है। क्योंकि आजकल private और public sector की decision-making एक-दूसरे से orthogonal चलती दिखती है
वे course किसी तरह पूरा कर भी लें, तो भी अगर मान लें कि उन्हें सच में software development job मिलती है, उनके career में आगे क्या होगा यह कोई नहीं जानता
ज़्यादातर जगहों पर हर employee को लगभग “fully trained” मान लिया जाता है, और अजीब तरह से job के दौरान training को employee पर किया गया एहसान समझा जाता है। यह संभवतः उस culture से जुड़ा है जिसमें tech workers company में कम समय के लिए रुकते हैं
tech field में wages का बढ़ना यह signal है कि programmers पर्याप्त नहीं हैं। अमेरिकी economic growth का अधिकांश हिस्सा अब programming और tech पर आधारित है
आखिरकार यह “dominant Matlab file driver” जैसी कहानी लगती है
अपनी life experience से कुछ भी उठा लो—एक से ज़्यादा किताब पढ़ना, guitar बजाना, कोई अजीब hobby रखना, semi-pro gymnast बनना—और उससे एक ऐसा story framework बना लो जो बिना खास मेहनत के यह justify करे कि आप कितने शानदार हैं या बाकी लोग कितने मूर्ख हैं, और फिर लंबा rant लिख दो
reading ज़्यादा से ज़्यादा catalyst और starting point है; जो चीज़ सच में fit करवाती है वह practice है। और इतना interest होना ज़रूरी है कि आप खोजें और कई चीज़ें खुद करके देखें
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
मैं इस आधार से पूरी तरह सहमत हूँ। मेरी skills तीन तरह की हैं: जो मैंने first principles से सीधे invent की हैं, जिन पर मैंने एक किताब पढ़ी है, और जो मैं नहीं कर पाता।
जिन चीज़ों में मैं अच्छा नहीं हूँ, उनमें से एक है अच्छी किताबें ढूँढना। किताबें हर जगह हैं और ज़्यादातर बेकार होती हैं, लेकिन जो किताबें मुझे recommend की गईं, वे सभी शानदार निकलीं। क्या अच्छी किताबें ढूँढने के तरीके पर कोई अच्छी किताब है?
https://www.gnooks.com/faves.php
सामान्य Gnod: gnod.com
https://www.literature-map.com/
किताबों की lists जमा करके रखने वाली sites भी हैं।
https://www.goodreads.com/review/list/21394355-william-adams...
https://www.goodreads.com/review/list/21394355-william-adams...
अगर recommendations अपने-आप नहीं मिल रहीं, तो जिन किताबों को पढ़कर पसंद किया उनके recommendations/reference lists, पसंदीदा authors की दूसरी किताबें, या किसी series की एक किताब पसंद आने पर उसी series की दूसरी किताबों से खोज सकते हैं।
Gemini जैसे tools इस्तेमाल करें, जो large language models को real-time data के साथ जोड़ते हैं, तो results और बेहतर हो जाते हैं।
यह इस वाक्य से जुड़ता है: “दूसरों ने जिस चीज़ पर लंबे समय तक सोचकर तैयारी की है, उससे सीखना, और मैं उसे कहीं कम समय में सीखने की कोशिश करता हूँ।”
https://news.ycombinator.com/item?id=40147526
क्या HN पढ़ना भी self-improvement में गिना जाएगा? इस site पर समय बिताते हुए मुझे कितनी skills या ideas की “clues” मिली हैं, यह गिन नहीं सकता।
अगर यहाँ की discussions न होतीं, तो शायद मैं नौकरी छोड़कर solo founder भी नहीं बनता। वह अच्छा फैसला था या नहीं, यह कहना अभी जल्दबाज़ी होगी।
बहुत-सा ज्ञान जो मुझे किसी और तरीके से नहीं मिलता, वह osmosis की तरह मिल जाता है। जिन technologies को मैंने सच में इस्तेमाल किया है वे बहुत कम हैं, लेकिन programming ecosystem के बारे में कुल मिलाकर काफी अच्छी समझ बन गई है। इससे “दुनिया में क्या-क्या है” और “क्या search करना चाहिए” जानने में मदद मिलती है।
हालांकि उस osmosis वाले ज्ञान का 95% शायद scrolling time के सिर्फ 10% में ही मिल सकता है। कुल मिलाकर HN समय का अच्छा उपयोग है, लेकिन आम तौर पर मैं जानबूझकर समय बर्बाद कर रहा होता हूँ।