मुझे याद आया कि कुछ समय पहले देखे गए Johnny Decimal नाम के एक organizing system के दस्तावेज़ों में भी ऐसा ही एक लेख था, इसलिए इसे साझा कर रहा हूँ। कोई बहुत बड़ी बात नहीं है; यह लेख कहता है कि किसी संगठन (और व्यक्ति) में knowledge management system लागू करने के लिए पूरे सिस्टम को समझने और खुद हाथ से व्यवस्थित करने वाले एक 'लाइब्रेरियन' की भूमिका की ज़रूरत होती है. 11.08 The Librarian • Johnny.Decimal
इस लेख से पता चलता है कि देखने के नज़रिए के अनुसार बातें अलग-अलग हो सकती हैं। मेरे मानदंड से senior और mid-level engineer के बीच फर्क करने का आधार सिर्फ scope है.
Ambiguity को ठोस रूप देना engineer की बुनियादी क्षमता है, और मुझे लगता है कि mid-level engineer से ही यह कर पाना ज़रूरी है ताकि उसे engineer का title देना उचित लगे। इसलिए मेरे लिए यह लेख mid-level engineer और शुरुआती (associate) engineer के बीच फर्क करने का एक मानदंड बन सकता है।
सीनियर डेवलपर टेस्ट में programming test तक तो फिर भी समझ आता है
लेकिन अगर algorithm problems दे दें तो बहुत हैरानी होती है (इतना अजीब लगा कि ठीक से याद भी नहीं है)
1. सवाल पूछने की कला और सामाजिक पूंजी (Social Capital)
रणनीतिक अज्ञानता: सीनियर के सवाल अज्ञानता से नहीं, बल्कि अनिश्चितता दूर करने की एक जानबूझकर की गई कार्रवाई से पैदा होते हैं। बुनियादी सवाल ("यह acronym क्या है?") बिना झिझक पूछ पाना एक मुख्य क्षमता है।
सामाजिक पूंजी का उपयोग: जूनियर के विपरीत, सीनियर के पास पहले से 'सामाजिक पूंजी (विश्वास)' बनी होती है, इसलिए "बेवकूफी भरे सवाल" पूछने पर भी उन्हें अयोग्य नहीं माना जाता। इस भरोसे का उपयोग करके मीटिंग की अस्पष्टता हटाना सीनियर की भूमिका है।
राजनीतिक संदर्भ पर विचार: स्पष्टता से बचने वाले मैनेजरों के लिए सीधा सवाल ख़तरे जैसा लग सकता है। इसलिए ऐसे सवाल चुनने की उच्च स्तर की समझदारी चाहिए जो राजनीतिक रूप से सुरक्षित हों और साथ ही प्रोजेक्ट को आगे बढ़ाएँ।
2. स्वायत्तता और risk management (Autonomy & Risk)
सुरक्षा-जाल के बिना समस्या-समाधान: बाहरी मदद या स्पष्ट निर्देश के बिना भी अपने दम पर समस्या को पार करना (Plough through) और उसे पूरा करना, सीनियर होने का मानदंड है।
Chaos पर नियंत्रण: हर हाल में स्पष्टता पाने के बजाय, सीनियर स्थिति के अनुसार 'रुकना' और 'आगे बढ़ना' तय करता है। परफ़ेक्ट spec का इंतज़ार करने के बजाय उपयुक्त assumptions बनाकर execution (Ship) करना, भ्रम कम करता है।
सोचा-समझा risk लेना: compile न होने वाले code को runtime में ठीक करना या बड़े पैमाने पर refactoring करना जैसी साहसी तकनीकी निर्णय लेना, जो जूनियर नहीं कर सकता, और उसके परिणाम की ज़िम्मेदारी लेना।
3. title inflation और hiring का संरचनात्मक विरोधाभास
Title Inflation: performance metrics हासिल करने के लिए तैयार न हुए जूनियरों को सीनियर प्रमोट कर देने की प्रथा व्यापक है। इससे title और वास्तविक क्षमता के बीच अंतर पैदा होता है।
hiring तरीकों की सीमा: कंपनियाँ अस्पष्ट requirements को ठोस बनाने की क्षमता के बजाय सिर्फ algorithm (LeetCode) problem-solving पर फोकस करके hiring करती हैं। नतीजतन, ऐसे 'सीनियर' बढ़ते हैं जो spec न हो तो कुछ भी नहीं कर पाते।
PM की भूमिका की जगह भरना: सीनियर इंजीनियर को आलसी PM द्वारा फेंकी गई अधपकी planning (Half-baked spec) को ठोस बनाने में समय लगाना पड़ता है। यह इंजीनियर की क्षमता भी है, लेकिन संगठनात्मक अक्षमता का सबूत भी।
4. केवल tenure बनाम जानबूझकर किया गया अभ्यास
अनुभव की गुणात्मक भिन्नता: "10 साल की growth" और "1 साल के अनुभव को 10 बार दोहराना" — इन दोनों में साफ़ अंतर होना चाहिए। असली सीनियर, परिचित क्षेत्र से बाहर निकलकर किए गए intentional practice और चुनौतियों से बनता है।
If vs What-if: जूनियर दिए गए conditions (If) को संभालने पर ध्यान देता है, जबकि सीनियर conditions बदल जाएँ तो (What-if) क्या होगा, यह मानकर पहले से तैयारी करता है।
growth stages की परिभाषा: इंडस्ट्री का सामान्य मानदंड है — 'मार्गदर्शन पाने का चरण (Junior)' → 'स्वतंत्र रूप से काम करने का चरण (Regular)' → 'दूसरों का मार्गदर्शन करने का चरण (Senior)'।
5. सीनियर title पर संदेहपूर्ण नज़रिया
सिर्फ pay grade: एक निंदक दृष्टिकोण यह है कि सीनियर जैसी उपाधि क्षमता का संकेतक कम, और HR द्वारा salary तय करने के लिए बनाई गई प्रशासनिक श्रेणी ज़्यादा है।
कंपनियों के बीच अंतर: Big Tech के सीनियर (उच्च अस्पष्टता और बड़े दायरे की समस्याएँ सुलझाने वाले) और सामान्य कंपनियों के सीनियर (सिर्फ लंबे समय से टिके हुए कर्मचारी) के बीच क्षमता और待遇 का अंतर बहुत बड़ा है।
Marchetti’s Constant (मार्केट्टी का स्थिरांक) वह अवधारणा है जिसके अनुसार, गुफाओं में रहने वाले मनुष्यों से लेकर प्राचीन यूनानियों और 21वीं सदी के लंदनवासियों तक, इंसान औसतन रोज़ लगभग 1 घंटा आने-जाने में खर्च करता है (30 मिनट दफ़्तर जाना, 30 मिनट वापस आना)।
सियोल और उसके महानगरीय क्षेत्र में रहने वाले नौकरीपेशा लोग इसे देखकर शायद काफ़ी उलझन में पड़ जाएँगे, हाहा
कोरिया में आमतौर पर मुर्गियों को लगभग एक महीने तक पाला जाता है, और सूअरों को 180 दिनों तक। यह सचमुच दिलचस्प है कि झींगों को मुर्गियों से भी ज़्यादा समय तक पालकर बाज़ार में भेजा जाता है। लगता है कोरिया में मुर्गी से बेहतर झींगा बनकर पैदा होना चाहिए 🥲
Fabrice Bellard के बारे में परिचय के लिए मैंने पहले जो कमेंट लिखा था, उसे देखें। यह शख्स वाकई लगातार कमाल करने वाला अद्भुत दिग्गज है.. https://news.hada.io/comment?id=51
पोस्ट लिखने वाले ashbyash जी से एक सवाल है, इसलिए यह टिप्पणी छोड़ रहा हूँ.
Anthropic Claude (3.5 Sonnet)
code generation और logic में सबसे मजबूत, Cursor integration की वजह से developers और professionals में 40% की पसंद. safety पर ज़ोर होने से enterprise adoption↑ (मूल पाठ: "Claude 3.5 multimodal integration").
आपने इसे इस तरह summarize किया है. लेकिन आपके द्वारा पोस्ट किए गए अनुवाद और मूल लेख, दोनों देखने पर भी "3.5 Sonnet" के बारे में कोई उल्लेख या सामग्री बिल्कुल नहीं दिखी. क्या आपने AI summary इस्तेमाल की थी, और hallucination की वजह से ऐसा हुआ? ज़्यादातर Foundation models का knowledge cutoff अगर पिछले साल के अंत या इस साल की शुरुआत तक मानें, तो Sonnet 3.5 सही लगती है, इसलिए ऐसा महसूस होता है कि AI ने खाली जगह भर दी हो. (मेरे साथ भी ऐसा हुआ था; जब मैं Gemini Library बना रहा था और AI से करवाया, तो उसने अपनी जानकारी के हिसाब से नया Gemini-1.5 इस्तेमाल करके बना दिया था TT)
मुझे याद आया कि कुछ समय पहले देखे गए Johnny Decimal नाम के एक organizing system के दस्तावेज़ों में भी ऐसा ही एक लेख था, इसलिए इसे साझा कर रहा हूँ। कोई बहुत बड़ी बात नहीं है; यह लेख कहता है कि किसी संगठन (और व्यक्ति) में knowledge management system लागू करने के लिए पूरे सिस्टम को समझने और खुद हाथ से व्यवस्थित करने वाले एक 'लाइब्रेरियन' की भूमिका की ज़रूरत होती है.
11.08 The Librarian • Johnny.Decimal
यह वह लेख है जिसे मैंने GeekNews के शुरुआती दिनों में शेयर किया था।
मैं इंटरनेट पर प्याज़ बेचता हूँ https://hi.news.hada.io/topic?id=3
अब भी देखें तो यह एक मज़ेदार लेख है।
बहुत बढ़िया मुख्य लेख और टिप्पणियाँ हैं।
इस लेख से पता चलता है कि देखने के नज़रिए के अनुसार बातें अलग-अलग हो सकती हैं। मेरे मानदंड से senior और mid-level engineer के बीच फर्क करने का आधार सिर्फ scope है. Ambiguity को ठोस रूप देना engineer की बुनियादी क्षमता है, और मुझे लगता है कि mid-level engineer से ही यह कर पाना ज़रूरी है ताकि उसे engineer का title देना उचित लगे। इसलिए मेरे लिए यह लेख mid-level engineer और शुरुआती (associate) engineer के बीच फर्क करने का एक मानदंड बन सकता है।
वाह..
समस्या को स्पष्ट रूप से परिभाषित किए बिना
तकनीकी उत्कृष्टता सिर्फ़ 'गलत समस्या को खूबसूरती से हल करना' भर है।
वाकई रोंगटे खड़े कर देने वाली पंक्ति
सीनियर डेवलपर टेस्ट में programming test तक तो फिर भी समझ आता है
लेकिन अगर algorithm problems दे दें तो बहुत हैरानी होती है (इतना अजीब लगा कि ठीक से याद भी नहीं है)
"अगर आप अपने सोच के मुताबिक नहीं जीते, तो आप अपने जीने के मुताबिक सोचना शुरू कर देंगे."
क्या Spotify नाराज़ हो जाएगा?
ठोस उपचार परिणामों का कोई उल्लेख नहीं है, सिर्फ उम्मीद जगाने वाली बातें हैं, इसलिए इस पर भरोसा नहीं होता।
Gödel, Escher, Bach को देखकर खुशी हुई। यह मानव बुद्धिमत्ता और recursion पर एक बेहतरीन किताब है।
1. सवाल पूछने की कला और सामाजिक पूंजी (Social Capital)
2. स्वायत्तता और risk management (Autonomy & Risk)
3. title inflation और hiring का संरचनात्मक विरोधाभास
4. केवल tenure बनाम जानबूझकर किया गया अभ्यास
If) को संभालने पर ध्यान देता है, जबकि सीनियर conditions बदल जाएँ तो (What-if) क्या होगा, यह मानकर पहले से तैयारी करता है।5. सीनियर title पर संदेहपूर्ण नज़रिया
सियोल और उसके महानगरीय क्षेत्र में रहने वाले नौकरीपेशा लोग इसे देखकर शायद काफ़ी उलझन में पड़ जाएँगे, हाहा
कोरिया में आमतौर पर मुर्गियों को लगभग एक महीने तक पाला जाता है, और सूअरों को 180 दिनों तक। यह सचमुच दिलचस्प है कि झींगों को मुर्गियों से भी ज़्यादा समय तक पालकर बाज़ार में भेजा जाता है। लगता है कोरिया में मुर्गी से बेहतर झींगा बनकर पैदा होना चाहिए 🥲
Fabrice Bellard के बारे में परिचय के लिए मैंने पहले जो कमेंट लिखा था, उसे देखें। यह शख्स वाकई लगातार कमाल करने वाला अद्भुत दिग्गज है..
https://news.hada.io/comment?id=51
यह कोई समस्या नहीं है
Gemini 3 फिर भी काफ़ी अच्छा लगा, हर महीने उससे बेहतर मॉडल आ रहे हैं, इसलिए कौन-सा चुनें यह भी सच में अपने आप में एक काम लगता है।
विस्तार से देखने के लिए धन्यवाद।
ओह, हाँ, लगता है कि यह सच में hallucination ही था। इतनी बारीकी से समीक्षा न कर पाने के लिए कृपया समझें, सिसकी
इसीलिए Mac Appa समस्या है।
पोस्ट लिखने वाले ashbyash जी से एक सवाल है, इसलिए यह टिप्पणी छोड़ रहा हूँ.
आपने इसे इस तरह summarize किया है. लेकिन आपके द्वारा पोस्ट किए गए अनुवाद और मूल लेख, दोनों देखने पर भी "3.5 Sonnet" के बारे में कोई उल्लेख या सामग्री बिल्कुल नहीं दिखी. क्या आपने AI summary इस्तेमाल की थी, और hallucination की वजह से ऐसा हुआ? ज़्यादातर Foundation models का knowledge cutoff अगर पिछले साल के अंत या इस साल की शुरुआत तक मानें, तो Sonnet 3.5 सही लगती है, इसलिए ऐसा महसूस होता है कि AI ने खाली जगह भर दी हो. (मेरे साथ भी ऐसा हुआ था; जब मैं Gemini Library बना रहा था और AI से करवाया, तो उसने अपनी जानकारी के हिसाब से नया Gemini-1.5 इस्तेमाल करके बना दिया था TT)