मैंने एक हेज फंड के लिए प्लेटफ़ॉर्म देने के लिए 80 घंटे हफ्ते काम किया, फिर उन्होंने मुझे निकाल दिया
एक हेज फंड इंजीनियर का दावा है कि उन्होंने 70–80 घंटे हफ्ते काम करके अकेले एक ट्रेडिंग प्लेटफ़ॉर्म बनाया, लेकिन लाइव होने के 48 घंटे बाद ही उन्हें निकाल दिया गया और अपेक्षित बोनस भी खो दिया। टिप्पणीकार कहानी की विश्वसनीयता पर बहस करते हैं, लेकिन बड़े पैमाने पर अति-कार्य, शोषण, और हाई फाइनेंस में कर्मचारियों की आसानी से बदली जा सकने वाली स्थिति जैसे विषयों पर सहमत होते हैं। कई लोग मौखिक बोनस वादों पर निर्भर न रहने, किसी और की इक्विटी के लिए “हीरो” घंटे न करने, और ऐसी भूमिकाओं को सख्ती से लेन-देन आधारित या अनुबंध-आधारित मानने का सबक दोहराते हैं.
कहानी की विश्वसनीयता
- कई टिप्पणीकार शाब्दिक विवरणों पर संदेह करते हैं, खासकर लाइव होने के 48 घंटे बाद अकेले OMS डेवलपर को निकाल देना; उनका तर्क है कि यह सबसे जोखिमभरा समय होता है और रखरखाव महत्वपूर्ण होता है।
- अन्य लोग जवाब देते हैं कि तर्कहीन या अल्पकालिक सोच वाला प्रबंधन आम है; वे महत्वपूर्ण लॉन्च के दौरान या तुरंत बाद प्रमुख कर्मचारियों की छंटनी के किस्से साझा करते हैं।
- कुछ लोग नोट करते हैं कि UK के रोजगार मानदंड और सुरक्षा तत्काल बर्खास्तगी को थोड़ा संदिग्ध बनाते हैं, लेकिन अन्य बताते हैं कि पहले दो वर्षों में वैधानिक सुरक्षा कमजोर होती है।
- कुछ का मानना है कि लेख में संदर्भ की कमी है (जैसे, सिस्टम की गुणवत्ता, आंतरिक राजनीति, नया प्रबंधक, या पहले से ही निकालने की योजना चाहे परिणाम कुछ भी हो)।
काम के घंटे, शोषण, और करियर रणनीति
- व्यापक सहमति है कि किसी नियोक्ता के लिए 70–80 घंटे हफ्ते काम करना हानिकारक है और आमतौर पर उसका कोई प्रतिफल नहीं मिलता; कई लोग कहते हैं कि वे इतना केवल अपने प्रोजेक्ट्स के लिए करते हैं।
- सलाह: “हीरो” मत बनो, बोनस या मौखिक वादों पर जीवन की योजनाएँ मत बनाओ, और अपनी नौकरी से प्रेम मत करो—इसे एक अनुबंध की तरह समझो, उससे अधिक नहीं।
- कई टिप्पणीकारों का तर्क है कि यह “प्रभावी काम” नहीं बल्कि अस्थिर क्रंच और बर्नआउट की ओर जाने वाला रास्ता था।
- कुछ सुझाव देते हैं कि नायक को अपनी उपलब्धियों के आधार पर खुद को सीनियर या कॉन्ट्रैक्टर के रूप में पेश करना चाहिए।
हेज फंड, पूँजीवाद, और संस्कृति
- कई लोग हेज फंड्स और हाई फाइनेंस को विशेष रूप से निर्मम और लेन-देन आधारित बताते हैं; अनादर, मुकदमेबाज़ी, और “इस्तेमाल करो फिर फेंक दो” वाले व्यवहार की कहानियाँ साझा की जाती हैं।
- पूँजीवाद पर व्यापक चर्चा: लालच बनाम महत्वाकांक्षा, शेयरहोल्डर-वैल्यू की विचारधारा, और व्यवसायों का उत्पाद, रखरखाव, या लोगों की तुलना में लाभ को प्राथमिकता देना।
- दृष्टिकोण यह है कि कई व्यवसाय जितना हो सके उतना कम देकर भी खुशी-खुशी मुनाफ़ा कमाएँगे, और कर्मचारी बड़े पैमाने पर “सिर्फ़ संख्या” होते हैं।
प्रबंधन प्रथाएँ और डिलीवरी के बाद बर्खास्तगी
- अन्य कंपनियों के कई उदाहरण: बड़े क्रंच, लॉन्च, फिर वेतन वृद्धि से बचने के लिए बड़े पैमाने पर छंटनी या खराब मूल्यांकन।
- एक पैटर्न नोट किया गया: एक बार v0.9/v1.0 “काफ़ी अच्छा” हो जाए, कुछ प्रबंधक डेवलपर्स को कॉन्ट्रैक्टर की तरह मानते हैं और चल रहे खर्च को बचाने या भविष्य के बोनस/इक्विटी दायित्वों से बचने के लिए उन्हें काट देते हैं।
- अन्य लोग bus-factor और इस दृष्टिकोण के दीर्घकालिक जोखिमों पर ज़ोर देते हैं, लेकिन नोट करते हैं कि कई प्रबंधक रखरखाव की ज़रूरतों को कम आँकते हैं।
तकनीकी चुनाव और जोखिम
- नौकरी के दौरान Rust सीखने पर बहस: कुछ कहते हैं कि यदि आप अन्य typed भाषाएँ जानते हैं तो Rust इतना कठिन नहीं है; अन्य लोग उच्च-जोखिम वित्तीय सॉफ़्टवेयर बनाते समय किसी के नई भाषा सीखने को लेकर चिंतित हैं।
- सवाल उठाया गया कि एक हेज फंड अपना custom OMS क्यों बनाए, बजाय off-the-shelf खरीदने के; एक उत्तर है कि एक अकेले डेवलपर को कम वेतन देकर शॉर्ट टर्म में यह सस्ता पड़ सकता है।
- कुछ लोग अनुमान लगाते हैं कि फंड ने प्रारंभिक build पूरा होने के बाद नायक को अधिक अनुभवी engineer से बदल दिया होगा।
कानूनी/नैतिक प्रतिशोध
- कुछ लोग कोड में “time bombs” या छिपी shutdown logic रखकर leverage वापस पाने की बात सोचते हैं; भारी बहुमत इसे अनैतिक, जोखिमभरा, और संभवतः कानूनी परेशानी की ओर ले जाने वाला मानता है।
- सुझाया गया सबक: sabotage के बजाय, शुरुआत में ही over-commitment सीमित करें और मान लें कि गैर-अनुबंधित वादे कभी भी वास्तविक रूप नहीं ले सकते।