शुरुआत में यह बता दिया जाए कि इस लेख का बड़ा विषय या संदर्भ क्या है, तो अच्छा होगा... यह कोई रूपक है, सचमुच का महाकाव्य है, या फिर तंज कसने का तरीका...
मैंने Linux kernel के memory management हिस्से में भी contribution किया है, और मुझे लगता है कि low-level workings की कुछ हद तक समझ भी है, लेकिन आखिरकार मैं अनचाहे तौर पर development से काफ़ी दूर के काम कर रहा हूँ—यह सोचकर लगता है कि शायद इस लेख के उलट चलना ही एक सफल engineer बनने का रास्ता है.
नई technologies को तेज़ी से follow करना
निजी जिज्ञासा से ज़्यादा market के बारे में सोचना
self-criticism से ज़्यादा self-promotion अच्छी तरह करना
मूलभूत क्षमता/विकास से ज़्यादा coding test पर ध्यान देना
वापस आकर देखा तो Korea में market बहुत छोटा है और competition बहुत ज़्यादा, इसलिए ऐसे company या position कम हैं जहाँ development पर ध्यान केंद्रित किया जा सके; और उन कम जगहों के लिए सब एक-दूसरे से प्रतिस्पर्धा कर रहे हैं, इसलिए आखिरकार वही लगता है कि जो चीज़ें आसानी से नज़र आएँ, उन पर फोकस करना होगा, तभी शायद वह development कर पाएँगे जो वे सच में करना चाहते हैं.
कुछ समय पहले मैंने कंपनी में Kotlin language study के लिए एक सेमिनार किया था। जब मैंने इसे हमारे विभाग में मुख्य रूप से इस्तेमाल होने वाली C++ भाषा से तुलना करते हुए समझाया, तो प्रतिक्रिया अच्छी मिली थी। दिलचस्प बात यह थी कि मैं खुद C++ लगभग इस्तेमाल नहीं करता, और विभाग के लोग Kotlin से पहली बार परिचित हो रहे थे, लेकिन कई मायनों में यह हम सबकी growth के लिए मददगार लगा।
Hacker News राय-सार अनुवाद के आख़िरी बिंदु, 'यह मान लेना गलत हो सकता है कि सॉफ्टवेयर की उत्पादकता 5-10 गुना नहीं बढ़ी है', में शायद गलत अनुवाद हुआ है। मूल पाठ को देखें तो, 'यह कहना कि सॉफ्टवेयर की उत्पादकता 5-10 गुना बढ़ गई है, उत्पादकता वृद्धि के बारे में एक गलत धारणा पर आधारित है' जैसा सार थोड़ा अधिक उपयुक्त लगता है।
हाँ, मैं सहमत हूँ। व्यक्ति को खुद भी सामने आना चाहिए, और अगर givers एक-दूसरे को ज़्यादा shout-out दें तो अच्छा लगेगा। संगठन की संस्कृति भी मूल रूप से इसे प्रोत्साहित करती है।
> ज़्यादातर प्रोग्रामर यह नहीं जानते कि LLM टूल्स का प्रभावी ढंग से उपयोग कैसे करें, या उनमें उनकी रुचि ही नहीं है
आसपास के कई डेवलपर्स को हैरानी की बात है कि तकनीक में दिलचस्पी ही नहीं है। वे अपना ज़्यादातर समय नए या बार-बार दोहराए जाने वाले YouTube Shorts को मशीन की तरह देखते हुए बिताते हैं.
लगता है मूल लेख हटा दिया गया है, इसलिए ट्वीट भी नहीं है।
इसे इस्तेमाल करके देखना चाहता हूँ, लेकिन यह preview period में होने के बावजूद paid है और कोई trial period भी नहीं है, इसलिए थोड़ा निराशाजनक लगता है।
खोजने पर कुछ लोग कहते हैं कि कुछ ही queries में $5 लग गए, तो शायद यह project के codebase के size पर निर्भर करता है।
शुरुआत में यह बता दिया जाए कि इस लेख का बड़ा विषय या संदर्भ क्या है, तो अच्छा होगा... यह कोई रूपक है, सचमुच का महाकाव्य है, या फिर तंज कसने का तरीका...
अपने ही source code को उपलब्ध कराया था, वही manus!!
https://hi.news.hada.io/topic?id=19168
यह ऐसा शोध है जिसके बारे में लगा कि AI ने शायद कभी सोचा भी नहीं होगा।
मैं मुख्य लेख के सार से सहमत हूँ।
मुझे लगता है कि कोरिया में भी बहुत अच्छे इंजीनियर हैं, लेकिन बाज़ार के आकार की वजह से कुछ पहलुओं में कमी महसूस होती है।
काश FuriosaAI जैसी जगहें अच्छा कर पातीं।
दिलचस्प लगा, बहुत अच्छे से पढ़ा।
वाह... ऐसा ही एक व्यक्ति है जो इस लेख से बहुत मिलता-जुलता है, यह उसे ज़रूर साझा करना चाहिए।
अच्छा लेख, धन्यवाद।
मैं इससे सहमत हूँ। मैं भी अपने जूनियर्स को अक्सर सलाह देता हूँ कि वे अपना काम थोड़ा दिखाकर करें।
थोड़ा रिलेटेबल लग रहा है.. lol
क्या ये सिर्फ़ कोरियाई मार्केट में ही ऐसा है...
मुझे React-Native में काफ़ी दिलचस्पी है, तो यह भी दिलचस्प लग रहा है।
उपरोक्त सामग्री आधिकारिक परिचय लेख Lynx: Unlock Native for More से ली गई है।
मैंने Linux kernel के memory management हिस्से में भी contribution किया है, और मुझे लगता है कि low-level workings की कुछ हद तक समझ भी है, लेकिन आखिरकार मैं अनचाहे तौर पर development से काफ़ी दूर के काम कर रहा हूँ—यह सोचकर लगता है कि शायद इस लेख के उलट चलना ही एक सफल engineer बनने का रास्ता है.
वापस आकर देखा तो Korea में market बहुत छोटा है और competition बहुत ज़्यादा, इसलिए ऐसे company या position कम हैं जहाँ development पर ध्यान केंद्रित किया जा सके; और उन कम जगहों के लिए सब एक-दूसरे से प्रतिस्पर्धा कर रहे हैं, इसलिए आखिरकार वही लगता है कि जो चीज़ें आसानी से नज़र आएँ, उन पर फोकस करना होगा, तभी शायद वह development कर पाएँगे जो वे सच में करना चाहते हैं.
"हमें ऐसा A+ छात्र नहीं चाहिए जो हर सवाल का जवाब दे सके
हमें ऐसा B छात्र चाहिए जो वह देख सके और सवाल पूछ सके जिसे दूसरे लोग चूक गए हों"
यह देखते ही मुझे लगा कि मैं तो वही B छात्र हूँ, लेकिन बड़ी कंपनियाँ तो सिर्फ A+ छात्रों को देखकर ही भर्ती करती हैं।
मुझे नहीं लगता कि MCP को JSON जैसा माना जा सकता है; यह डेटा संचार के लिए कोई specification भी नहीं है, और मेरे हिसाब से यह ज़रूरत से ज़्यादा जटिल है।
कुछ समय पहले मैंने कंपनी में Kotlin language study के लिए एक सेमिनार किया था। जब मैंने इसे हमारे विभाग में मुख्य रूप से इस्तेमाल होने वाली C++ भाषा से तुलना करते हुए समझाया, तो प्रतिक्रिया अच्छी मिली थी। दिलचस्प बात यह थी कि मैं खुद C++ लगभग इस्तेमाल नहीं करता, और विभाग के लोग Kotlin से पहली बार परिचित हो रहे थे, लेकिन कई मायनों में यह हम सबकी growth के लिए मददगार लगा।
Hacker News राय-सार अनुवाद के आख़िरी बिंदु, 'यह मान लेना गलत हो सकता है कि सॉफ्टवेयर की उत्पादकता 5-10 गुना नहीं बढ़ी है', में शायद गलत अनुवाद हुआ है। मूल पाठ को देखें तो, 'यह कहना कि सॉफ्टवेयर की उत्पादकता 5-10 गुना बढ़ गई है, उत्पादकता वृद्धि के बारे में एक गलत धारणा पर आधारित है' जैसा सार थोड़ा अधिक उपयुक्त लगता है।
हाँ, मैं सहमत हूँ। व्यक्ति को खुद भी सामने आना चाहिए, और अगर givers एक-दूसरे को ज़्यादा shout-out दें तो अच्छा लगेगा। संगठन की संस्कृति भी मूल रूप से इसे प्रोत्साहित करती है।
टर्मिनल सच में...
> ज़्यादातर प्रोग्रामर यह नहीं जानते कि LLM टूल्स का प्रभावी ढंग से उपयोग कैसे करें, या उनमें उनकी रुचि ही नहीं है
आसपास के कई डेवलपर्स को हैरानी की बात है कि तकनीक में दिलचस्पी ही नहीं है। वे अपना ज़्यादातर समय नए या बार-बार दोहराए जाने वाले YouTube Shorts को मशीन की तरह देखते हुए बिताते हैं.
मुझे जिज्ञासा है कि क्या MCP, JSON बन सकता है।
लगता है मूल लेख हटा दिया गया है, इसलिए ट्वीट भी नहीं है।
इसे इस्तेमाल करके देखना चाहता हूँ, लेकिन यह preview period में होने के बावजूद paid है और कोई trial period भी नहीं है, इसलिए थोड़ा निराशाजनक लगता है।
खोजने पर कुछ लोग कहते हैं कि कुछ ही queries में $5 लग गए, तो शायद यह project के codebase के size पर निर्भर करता है।