आजकल लग रहा था कि Gemini की Time to first token स्पीड बेहद तेज़ है, तो उसके पीछे यही वजह थी...

मैं इससे पूरी तरह सहमत हूँ कि आधिकारिक दस्तावेज़ ज़रूर देखने चाहिए।

जब मैं पहली बार coding सिखाता हूँ, तो यह बात कि कोई व्यक्ति error messages को ध्यान से पढ़ सकता है या नहीं, वहीं से पहली बार यह दिखने लगता है कि उसमें programmer बनने की योग्यता है या नहीं।

सभी नहीं, लेकिन ज़्यादातर बिंदु ऐसे हैं जिनसे सहमति बनती है।

मैंने कभी नहीं सोचा था कि यह हस्तशिल्प जैसा हो सकता है, लेकिन इससे बहुत सहमति महसूस होती है।
इस नज़रिए से सोचने पर लगता है कि कई घटनाएँ समझ में आ जाती हैं।

Hyperlight - हल्का Virtual Machine Manager (VMM) | GeekNews

Hyperlight WASM: तेज़, सुरक्षित और OS-Free | GeekNews

आलोचनात्मक टिप्पणियाँ देखकर मैंने बहुत सोचा। कुछ हिस्सों से सहमति है और कुछ पर मेरी अलग राय है।

• अभी डेवलपर्स की स्थिति को लेकर कुछ हद तक बुलबुला हो सकता है, लेकिन मुझे लगता है कि यही बात दूसरे पेशों पर भी लागू होती है। अल्पसंख्या से बहुसंख्या की ओर। यानी जैसे-जैसे इस क्षेत्र में काम करने वालों की संख्या और विविधता बढ़ती है, यह एक स्वाभाविक घटना है। मैं यह नहीं कह रहा कि यह दिशा हमेशा सही ही है, लेकिन मुझे नहीं लगता कि सिर्फ डेवलपर्स के साथ ही ऐसा खास तौर पर हो रहा है।
• सीखना आसान है। यह मानता हूँ, लेकिन प्रवेश बाधा कम होने का मतलब यह नहीं कि पेशेवर विशेषज्ञता भी कम है। दूसरे उद्योगों, खासकर manufacturing के अन्य तकनीकी पदों की तुलना में development सीखना अपेक्षाकृत आसान लगने का कारण शायद यह नहीं कि development खुद आसान है, बल्कि open source संस्कृति और कम जोखिम है। जैसा ऊपर डेवलपर्स की विविधता के बारे में कहा, वैसे ही कुछ काम ऐसे हैं जो जल्दी सीखकर किए जा सकते हैं, और कुछ काम ऐसे हैं जिनके लिए विशेषज्ञता की मजबूत बुनियाद चाहिए।
• माहौल बदल गया है। मुझे नहीं लगता कि पहले की तुलना में बाज़ार में डेवलपर्स से अपेक्षाएँ और उन्हें मिलने वाला प्रतिफल सिर्फ उनकी तकनीक, कौशल या विशेषज्ञता की वजह से बढ़ा है। जितना IT मानव जीवन में गहराई से प्रवेश करता गया है, उतना software अधिक महत्वपूर्ण हुआ है, और वही बहुत-सी infrastructure को संभाले हुए है। हर डेवलपर की व्यक्तिगत क्षमता बढ़ने से प्रतिफल नहीं बढ़ा, बल्कि मुझे लगता है कि काम खुद ही महँगा हो गया है। क्योंकि अब यह पहले से कहीं अधिक महत्वपूर्ण है।
• क्या manufacturing से सीधी तुलना सचमुच सार्थक है? उद्योग के पर्याप्त परिष्कृत न होने के नज़रिए से देखें तो तुलना का आधार manufacturing लगता है। अगर software उद्योग को manufacturing के paradigm से समझने की कोशिश करेंगे, तो वह हस्तकला या hobby development जैसा दिख सकता है। लेकिन उलटे, मुझे लगता है कि यही पहलू software development की अपनी लचीली और रचनात्मक संस्कृति बनाते हैं, और उसी के आधार पर यह क्षेत्र आगे बढ़ रहा है।
• किसी चीज़ में हद से ज़्यादा डूब जाना खतरनाक है। इससे मैं पूरी तरह सहमत हूँ। दुनिया में सिर्फ development ही ऐसी चीज़ नहीं है जिसे पढ़ना-समझना चाहिए, और आज भी हम अपने पेशे के खाने में "कंपनी कर्मचारी" ही लिखते हैं। अगर समाज के माहौल में किसी पेशे को लेकर बुलबुला बन भी जाए, तब भी यह सोचने से बचना चाहिए कि वह दूसरे पेशों से बहुत अलग है। लेकिन यह बात किसी भी पेशे पर लागू होती है।

Toss के लिए UX सीधे तौर पर survival से जुड़ा है
लेकिन इस लेख से अलग नज़रिए से देखें, तो मुझे नहीं पता कि वह कंपनी revenue को अच्छी तरह pursue करती है या नहीं

जन्मदिन मुबारक। बड़ों की बात मानो और लंबे समय तक स्वस्थ रहो।

मुझे लगता है कि इस तरह का feedback, व्यक्ति के स्वभाव, cultural background और व्यक्तिगत अंतर के अनुसार, सुनते समय बुरा लग सकता है या गुस्सा भी आ सकता है। लेकिन मूल रूप से यह सोचकर आगे बढ़ना कि "वह व्यक्ति मुझे जानबूझकर परेशान नहीं कर रहा है" मानसिक रूप से भी और growth के नज़रिए से भी बेहतर लगता है। जब ऐसी स्थिति आए, तो इस लेख को याद करके "शायद यह manager भी?" ऐसा सोचकर देख सकते हैं। अच्छा लेख है।

अगर कोई आपकी वर्तनी की गलती सुधार दे, तो "धन्यवाद, मुझे पता नहीं था" कह देने भर की बात है; मुझे नहीं लगता कि यह गुस्सा करने की वजह है। मुझे लगता है कि जैसा आपने महसूस किया, वैसा ही दूसरे लोग भी महसूस करेंगे, यह मान लेना एक खतरनाक सामान्यीकरण है। और "स्वीकार करना" नहीं, बल्कि "अपनाना" है।

AI को अपनाने को डेवलपमेंट स्पीड के नज़रिए से नहीं, बल्कि सोच के विस्तार के नज़रिए से देखना चाहिए, लेकिन लगता है अब भी ऐसे मैनेजर हैं जो सिर्फ स्पीड की ही रट लगाते हैं। जो प्रोडक्ट AI की वकालत करते दिखते हैं, वे कुल मिलाकर कोई खास अलग नहीं हैं और बीच-बीच में बस मार्केट वैलिडेशन करने भर के स्तर पर हैं; क्या वे अपने खुद के बनाए प्रोडक्ट का स्तर भी वहीं तक ही सीमित कर रहे हैं?

लगता है वे CTO के हाथ-पैर जैसे हैं

जन्मदिन मुबारक हो ^^

वाह.. यह काफ़ी मायने रखता है, है ना? टैक्स से जुड़े काम भी कहीं ज़्यादा आसान हो जाएंगे, और आँकड़ों की सटीकता भी बढ़ेगी।

XE1 के शुरुआती दौर से लेकर Rhymix तक, इसे दसियों साल से इस्तेमाल कर रहे एक यूज़र के नज़रिए से देखें तो यह बात काफ़ी relatable लगती है.

मेरे हिसाब से सबसे बड़ी समस्या यह है कि Rhymix जिस बाज़ार को target करता है, उसमें बड़ी संख्या में ऐसे लोग हैं जिनके पास खुद development करने की पर्याप्त क्षमता नहीं है.

और जिन लोगों के पास खुद development करने की क्षमता है, वे अक्सर XE या Rhymix की कमज़ोर documentation, अस्पष्ट structure और legacy चीज़ों को सहने के बजाय Laravel वगैरह अपनाने का चुनाव करते हैं.

मूल पोस्ट के लेखक की तरह, मैं भी

1. ऐसा admin page जिससे बहुत से लोग सहज रूप से परिचित महसूस करें
2. कुछ कमियाँ होने पर भी CMS के रूप में कम न पड़ने वाली functionalities
3. नई suggestions को सक्रिय रूप से अपनाने वाली core development team
4. लंबे समय से इस्तेमाल करने से बना लगाव
   आदि वजहों से कुछ नए projects में Rhymix अपना रहा हूँ, लेकिन हर बार यह सोचने पर मजबूर होना पड़ता है कि क्या यह चुनाव सही है.

Rhymix को framework के विकल्प की तरह इस्तेमाल करते हुए जो कमियाँ महसूस हुईं, उन्हें पूरा करने के लिए मैं निजी तौर पर कई तरह के प्रयोग कर रहा हूँ.
https://github.com/nemorize/rx-make (develop branch / PoC project, production की कोई योजना नहीं)

जैसे Rhymix को पूरी तरह framework/library बना देना, legacy API तक पहुँच को न्यूनतम करना, और थोड़ा अधिक modern API को (legacy के साथ मोटे तौर पर compatible रहते हुए) फिर से बनाना—ऐसे कई तरह के प्रयास कर रहा हूँ, लेकिन... सच में इस पर बहुत ज़्यादा सोच-विचार करना पड़ता है, हाहा..

मैंने इस दुविधा को पहले कभी साफ़ तौर पर व्यवस्थित करके नहीं देखा था, लेकिन इस मौके पर इसे एक बार स्पष्ट रूप से整理 करके देखना चाहिए.

Toss के लिए UX में भिन्नता ही सीधे revenue और survival का मतलब है।
अगर वह commercial banks या दूसरे fintech apps के समान स्तर की संतुष्टि पर ही रुक जाए, तो उसे सफल नहीं कहा जा सकेगा.

नीचे वाली बात को छोड़कर:
“अर्थपूर्ण काम करते हुए स्थिरता भी पाने का तरीका
अगर आप जो काम करना चाहते हैं उसका profitability से सीधा संबंध नहीं है, तो किसी बहुत अधिक profitable बड़ी कंपनी में काम करना महत्वपूर्ण है
छोटी और कम मुनाफ़े वाली कंपनियों में value-based काम restructuring का निशाना बनना आसान होता है”

मुझे यह बात ज़्यादा persuasive लगती है

“जब कोई कंपनी एक निश्चित आकार तक पहुँच जाती है, तो पैसा कमाना एक social construct बन जाता है. how to get promoted नाम का लेख बड़े संगठनों की वास्तविकता को ज़्यादा अच्छी तरह समझाता है”

क्या यह इसलिए नहीं है कि Toss की conversion rate सीधे performance में बदलती है? साथ ही, कंपनी अभी listed भी नहीं है, इसलिए फिलहाल अगर आप growth में योगदान दे रहे हैं, तो आपका काम सीधे revenue से जुड़ा न हो तब भी चलता है.

शायद इसी वजह से लेख के बीच में यह कहा गया था कि कंपनी पैसा कैसे कमाती है, इसे देखना चाहिए.