घरेलू कंपनियों में अक्सर board members की संरचना सिर्फ औपचारिकता पूरी करने जैसी होती है, और ऐसी बातें वास्तव में startup शुरू करके कंपनी को governance की ज़रूरत पड़ने लायक स्तर तक बढ़ाने के बाद ही समझ में आती हैं, लेकिन पहले से पढ़कर रखना अच्छा रहेगा इसलिए साझा कर रहा हूँ.
कंपनी और भी बड़ी हो सकती है, फिर भी निवेश की वसूली के लिए acquisition price प्रस्तावित करके exit की ओर धकेलने वाला व्यवहार
ऐसा एक बार झेल लो, तो निवेशकों पर से भरोसा तेजी से खत्म हो जाता है.
मेरे करियर का अनुभव छोटा है, लेकिन मुख्य लेख की बातों से सहमत होते हुए भी एक तरफ यह भी लगता है कि "चुपचाप" काम करना ऐसी चीज़ है जिससे बचना चाहिए। बहुत ज़्यादा दिखावटी या शोरगुल वाला होने की ज़रूरत नहीं है, फिर भी कम से कम अपने काम को थोड़ा सामने रखना अपने लिए बेहतर लगता है।
मेरे अनुभव में, बड़े पैमाने वाली कंपनियों में छंटनी को अपने-आप में निष्पक्ष तरीके से करना काफ़ी मुश्किल होता है — सचमुच सिर्फ़ वहीं सही कटौती करना आसान नहीं होता जहाँ उसकी ज़रूरत है.
इसलिए छंटनी के बाद की फ़ॉलो-अप कार्रवाई और भी ज़्यादा महत्वपूर्ण होती है. कर्मचारियों का मनोबल, संसाधनों का उचित पुनर्वितरण आदि. ज़रूरी लोगों की दोबारा भर्ती (इस पर आलोचना होगी, लेकिन यह अपरिहार्य है...)
PowerPoint का इस्तेमाल किए बिना slideshow बनाने की कोशिश की एक लंबी परंपरा रही है,
जो W3C slidy से शुरू होकर s3, s5, s6, s9… तक जाती है…
उससे भी एक कदम आगे बढ़कर… सीधे terminal में presentation करना काफ़ी दिलचस्प है। अफ़सोस की बात बस यह है कि… अभी तक terminal graphic protocol (?!) standardize नहीं हुआ है… इसलिए support करने वाले terminal सीमित हैं…
यह भी दिलचस्प लगा कि वे कभी-कभी invitation codes देते हैं, और सिर्फ़ #announcement और #use-cases जैसे 2 चैनलों वाले Discord में ही उन्होंने कई लाख लोगों को इकट्ठा कर लिया है।
Cursor अब पुराना-सा लगने लगा है, यह सुनकर इसे आज़माने का मन हो रहा है। लेकिन इसकी लागत काफ़ी ज़्यादा लगती है, इसलिए हिम्मत नहीं पड़ रही।
हूँ, लेकिन Hacker News की राय तो काफ़ी नकारात्मक लग रही है।
क्या यह सामान्यीकरण की भूल नहीं है कि कोई दावा परिस्थितियों के अनुसार सही भी हो सकता है और गलत भी, फिर भी उसकी पूर्वधारणाएँ छोड़ दी जाएँ? मुझे लगता है कि 'सभी छंटनियाँ बेकार हैं' / 'सभी छंटनियाँ कारगर हैं' — दोनों ही कथन झूठे हैं। अगर किसी कंपनी ने अपनी business plan की फिर से समीक्षा की और योजना से मेल न खाने वाले विभागों को समेट दिया, तो क्या छंटनी प्रभावी नहीं कही जाएगी? इसके उलट, अगर जिन विभागों में पहले से ही manpower की कमी है या काम का दबाव बहुत अधिक है, वहाँ भी cost cutting के नाम पर एकमुश्त छंटनी कर दी जाए, तो वह प्रभावी नहीं है.
लेखक किसी खास स्थिति की कल्पना कर रहे हैं, या फिर यह सब जानते हुए भी किसी और वजह से सामान्यीकरण की भूल कर रहे हैं—यह बात सिर्फ़ लेख पढ़कर समझ में नहीं आती।
आप लगातार कंपनी-मैनेजमेंट की ही पोज़िशन लेते दिखते हैं
अगर आप मैनेजर नहीं बल्कि IC हैं, और Great Depression जैसी स्थिति में भी यही बात कह सकें, तो फिर ठीक है..
Redis का उपयोग करना है या नहीं, इससे अलग domain और persistence के बीच एक caching layer रखना (जिसका basic implementation bypass हो) बिल्कुल भी over-engineering नहीं है। Logging, fake data, debugging, profiling, और शायद असली caching भी…
घरेलू कंपनियों में अक्सर board members की संरचना सिर्फ औपचारिकता पूरी करने जैसी होती है, और ऐसी बातें वास्तव में startup शुरू करके कंपनी को governance की ज़रूरत पड़ने लायक स्तर तक बढ़ाने के बाद ही समझ में आती हैं, लेकिन पहले से पढ़कर रखना अच्छा रहेगा इसलिए साझा कर रहा हूँ.
ऐसा एक बार झेल लो, तो निवेशकों पर से भरोसा तेजी से खत्म हो जाता है.
मेरे करियर का अनुभव छोटा है, लेकिन मुख्य लेख की बातों से सहमत होते हुए भी एक तरफ यह भी लगता है कि "चुपचाप" काम करना ऐसी चीज़ है जिससे बचना चाहिए। बहुत ज़्यादा दिखावटी या शोरगुल वाला होने की ज़रूरत नहीं है, फिर भी कम से कम अपने काम को थोड़ा सामने रखना अपने लिए बेहतर लगता है।
मेरे अनुभव में, बड़े पैमाने वाली कंपनियों में छंटनी को अपने-आप में निष्पक्ष तरीके से करना काफ़ी मुश्किल होता है — सचमुच सिर्फ़ वहीं सही कटौती करना आसान नहीं होता जहाँ उसकी ज़रूरत है.
इसलिए छंटनी के बाद की फ़ॉलो-अप कार्रवाई और भी ज़्यादा महत्वपूर्ण होती है. कर्मचारियों का मनोबल, संसाधनों का उचित पुनर्वितरण आदि. ज़रूरी लोगों की दोबारा भर्ती (इस पर आलोचना होगी, लेकिन यह अपरिहार्य है...)
PowerPoint का इस्तेमाल किए बिना slideshow बनाने की कोशिश की एक लंबी परंपरा रही है,
जो W3C slidy से शुरू होकर s3, s5, s6, s9… तक जाती है…
उससे भी एक कदम आगे बढ़कर… सीधे terminal में presentation करना काफ़ी दिलचस्प है। अफ़सोस की बात बस यह है कि… अभी तक terminal graphic protocol (?!) standardize नहीं हुआ है… इसलिए support करने वाले terminal सीमित हैं…
FYI, Markdown-आधारित presentation tools…
https://gist.github.com/johnloy/27dd124ad40e210e91c70dd1c24ac8c8
यह भी दिलचस्प लगा कि वे कभी-कभी invitation codes देते हैं, और सिर्फ़ #announcement और #use-cases जैसे 2 चैनलों वाले Discord में ही उन्होंने कई लाख लोगों को इकट्ठा कर लिया है।
Cursor अब पुराना-सा लगने लगा है, यह सुनकर इसे आज़माने का मन हो रहा है। लेकिन इसकी लागत काफ़ी ज़्यादा लगती है, इसलिए हिम्मत नहीं पड़ रही।
हूँ, लेकिन Hacker News की राय तो काफ़ी नकारात्मक लग रही है।
क्या यह सामान्यीकरण की भूल नहीं है कि कोई दावा परिस्थितियों के अनुसार सही भी हो सकता है और गलत भी, फिर भी उसकी पूर्वधारणाएँ छोड़ दी जाएँ? मुझे लगता है कि
'सभी छंटनियाँ बेकार हैं'/'सभी छंटनियाँ कारगर हैं'— दोनों ही कथन झूठे हैं। अगर किसी कंपनी ने अपनी business plan की फिर से समीक्षा की और योजना से मेल न खाने वाले विभागों को समेट दिया, तो क्या छंटनी प्रभावी नहीं कही जाएगी? इसके उलट, अगर जिन विभागों में पहले से ही manpower की कमी है या काम का दबाव बहुत अधिक है, वहाँ भी cost cutting के नाम पर एकमुश्त छंटनी कर दी जाए, तो वह प्रभावी नहीं है.लेखक किसी खास स्थिति की कल्पना कर रहे हैं, या फिर यह सब जानते हुए भी किसी और वजह से सामान्यीकरण की भूल कर रहे हैं—यह बात सिर्फ़ लेख पढ़कर समझ में नहीं आती।
धन्यवाद। लंबे समय से सत्यापित शोध का अध्ययन करके उसे AI में लागू करना काफ़ी दिलचस्प लगा।
आखिरकार क्या यह पहले वाली चीज़ों से अलग नहीं है? बेवजह टेस्ट सब्जेक्ट बनकर सिर्फ समय बर्बाद होगा ऐसा लगता है, इसलिए अब इसे आज़माने का मन नहीं करता।
लेख भी अच्छा है, लेकिन ऐसी चीज़ों में रुचि लेकर सीखने की आपकी कोशिश भी बहुत शानदार लगती है।
आप लगातार कंपनी-मैनेजमेंट की ही पोज़िशन लेते दिखते हैं
अगर आप मैनेजर नहीं बल्कि IC हैं, और Great Depression जैसी स्थिति में भी यही बात कह सकें, तो फिर ठीक है..
आइडिया बहुत अच्छा है!
यह बहस करना मुश्किल लेख है, लेकिन उससे अलग बात यह है कि यूरोप के पतन की राह पर चलने का मूल कारण आलस्य नहीं है।
यह वाकई बहुत दिलचस्प है, इसे देखकर मुझे भी इसे आज़माने का मन हो रहा है।
+1 मैं भी सहमत हूँ। सिर्फ़ एक layer जोड़ने से भी
leewayबनती है, और कई तरह की चीज़ों को सुलझाने के लिए जगह मिल जाती है।Redis का उपयोग करना है या नहीं, इससे अलग domain और persistence के बीच एक caching layer रखना (जिसका basic implementation bypass हो) बिल्कुल भी over-engineering नहीं है। Logging, fake data, debugging, profiling, और शायद असली caching भी…
>भयानक
अनुक्रमणिका को देखें तो यह तकनीक की टाइपो लगती है
बहुत शानदार है
वाह, दुनिया में ये क्या है hadedeodeo टर्मिनल स्लाइडशो...!!!