प्रोग्रामिंग से प्यार, लेकिन प्रोग्रामिंग इंडस्ट्री से नफ़रत करने वाला डेवलपर

• प्रोग्रामिंग अपने आप में आनंददायक है, लेकिन software workplace ऐसा माहौल लगता है जहाँ डिज़ाइन के उद्देश्य और सफलता के मानदंड पूछने के बजाय और ज़्यादा code लिखने की मांग की जाती है
• 2023 में कुछ हफ्तों तक job postings देखने के अनुभव ने “कहीं बेहतर जगह होगी” जैसी उम्मीद तोड़ दी, और खासकर startup culture ने “सवाल कम करो, उत्पादन बढ़ाओ” वाला रवैया खुलकर दिखाया
• बड़े tech companies में भी डेवलपर्स को backend stack के आकार, interview score, performance review score जैसे numbers से आंका जाता है, और code कैसे लिखा जाए इस पर व्यक्तिगत निर्णय और भी अर्थहीन हो जाता है
• “ज़्यादा बनाओ, कम पूछो” वाला रवैया code की मात्रा बढ़ा सकता है, लेकिन इससे software और खराब हो जाता है, और trend तथा inertia language, library, framework और code pattern तक में घुस जाते हैं
• लेखक जिस काम की तलाश में है, वह समाज में पहले से मौजूद ज़रूरतों से शुरू होने वाली engineering problems को हल करना है, और system का “क्यों” ही language, paradigm, architecture और syntax तक तय करना चाहिए

---

software की नौकरियों में महसूस हुई असंगति

• लेखक कहता है कि उसने अब तक जिन software engineering भूमिकाओं में काम किया, उनमें से कोई भी उसके लिए सही नहीं लगी
• codebase की आंतरिक तर्कशैली को कुछ हद तक समझ लेने के बाद तकनीकी पक्ष उबाऊ लगने लगा, और उसके बाद वह ज़्यादा करने के बजाय अलग तरीके से करने की इच्छा रखने लगा
• design decisions और उनके उद्देश्य को लेकर उसके मन में लगातार ये सवाल उठते रहे
  • हम यह काम क्यों कर रहे हैं
  • हम इसे इसी तरीके से क्यों कर रहे हैं
  • क्या इससे बेहतर तरीका नहीं है
  • सफलता मापने के लिए कौन-से metrics हैं, और हम वही क्यों इस्तेमाल करते हैं
• वह हमेशा ये सवाल ज़ोर से नहीं पूछता था, लेकिन उसे कहा जाता था कि जिस समय में वह और code लिख सकता था, उसमें वह “बहुत ज़्यादा सोचता है” और “बहुत ज़्यादा परवाह करता है”
• यह सिर्फ talent और role के mismatch की बात नहीं थी; उसे संगठनों के चलने के तरीके से ही असहमति थी, और वह उसे बनाए रखने के बजाय बदलना चाहता था

startup job postings और “ज़्यादा बनाओ, कम पूछो”

• 2023 में कुछ हफ्तों तक job postings देखने के अनुभव ने “कहीं बेहतर जगह होगी” जैसी उम्मीद तोड़ दी
• उसके आकलन में job descriptions का 90% ऐसे code की ओर इशारा करता था जो न मानवता की अहम समस्याओं से जुड़ा लगता था, न व्यक्ति के जीवन की महत्वपूर्ण ज़रूरतों से
• startup culture को इंडस्ट्री के “और ज़्यादा code बनाओ, कम सवाल पूछो” रवैये का सबसे खुला उदाहरण बताया गया है
• कई startups पर आरोप है कि वे investors का पैसा इधर-उधर घुमाते हैं और सीमित उपयोगिता वाले products को users के लिए ज़रूरी बताकर paid users हासिल करना चाहते हैं
• startups अक्सर असफल होते हैं, और उनके पीछे ऐसा मुश्किल से maintain होने वाला spaghetti code बचता है जिसे महीनों नहीं बल्कि हफ्तों के भीतर लिखने का दबाव होता है
• ऐसे code को फिर शायद ही कभी देखा जाता है, सिवाय खराब coding practices के उदाहरण के तौर पर; engineers का समय बर्बाद होता है, और venture capital फिर पहले से काफी पूंजी रखने वालों के पास लौटकर दूसरे startups में लगाया जा सकता है
• लेखक की आलोचना है कि job ads इस तरह के काम को लोगों की जिंदगी समृद्ध करने वाला और engineering growth को प्रेरित करने वाला रोमांचक काम बताकर पेश करती हैं

बड़े tech companies में भी घटती autonomy

• स्थापित tech companies संगठन और वित्तीय संरचना में startups से अलग हैं, लेकिन सांस्कृतिक रूप से बहुत अलग नहीं
• FAANG में लिखा गया code वास्तविक users तक पहुँच सकता है, लेकिन code लिखने के किसी भी पहलू पर व्यक्ति की राय और भी कम मायने रखती है
• लेखक की आलोचना है कि डेवलपर इस तरह मशीन के पुर्ज़े बन जाते हैं
  • product पूंजीवाद के सबसे बुरे पहलुओं को और अधिक धूर्त तरीकों से automate कर सकता है
  • व्यावहारिक स्तर पर इंसान backend stack के आकार, technical interview score और performance review score जैसे numbers में बदल जाता है
• समस्या सिर्फ यह वास्तविकता नहीं है, बल्कि यह भी है कि engineers से उम्मीद की जाती है कि वे इस खाली और अपमानजनक दोहराव वाले श्रम को दूसरे कामगारों की तुलना में ज्यादा चाहें, और उसके किसी भी पहलू पर सवाल उठाने से उन्हें और कड़ाई से रोका जाए

आलोचनात्मक सोच से बाहर की गई engineering

• programmers को सिर्फ कैसे पर ध्यान देने की स्थिति में रखा जाता है; वे क्या बनाया जाए इसमें कम ही शामिल होते हैं, और यह क्यों बनाया जा रहा है, यह तो लगभग पूछ ही नहीं सकते
• जो डेवलपर अपने बनाए जा रहे systems की आलोचना कर सकते हैं और करना चाहते हैं, उन्हें भी यह संदेश दिया जाता है कि ऐसी सोच workplace के बाहर रखो
• डेवलपर को लगता है कि role में निहित autonomy और creativity की कमी को पहचानना तक मानो मना है; वे ज़्यादा बना तो सकते हैं, लेकिन अलग या बेहतर चीज़ बनाना मुश्किल है

code की मात्रा बढ़ती है, लेकिन software बिगड़ता जाता है

• tech industry का do-more-ask-less रवैया ज़्यादा code तो बनवा सकता है, लेकिन साथ ही और खराब software की ओर ले जाता है
• जब पूंजी और बाहरी परिस्थितियाँ टिकाऊ, सकारात्मक या कम-से-कम व्यावहारिक रूप से उपयोगी software बनाने की गुंजाइश देती भी हैं, तब भी inertia के कारण अक्सर ऐसा नहीं किया जाता
• trends का पीछा करना और मौजूदा स्थिति को दोहराना ज्यादा आसान होता है, और आमतौर पर ज्यादा संभव भी
• यही inertia पूरे tech stack में भी समाया रहता है, जिस पर सामाजिक रूप से बेकार products खड़े किए जाते हैं
  • language
  • library
  • framework
  • code pattern
• वास्तविक innovation के बजाय novelty और gimmick को प्राथमिकता देने की प्रवृत्ति पूरी industry को परेशान करती है, और अगर समस्याएँ गैर-पारंपरिक नहीं हैं तो non-traditional engineering की भी जरूरत नहीं पड़ती

वांछित engineering के मानदंड

• सबसे दिलचस्प engineering problems वे हैं जो केवल तकनीकी प्रगति को ही लक्ष्य न बनाएं या कृत्रिम रूप से ऐसी market demand पैदा न करें जो वास्तव में मौजूद नहीं है, बल्कि वे हों जो समाज के भीतर स्वाभाविक रूप से पैदा होती हैं
• सामाजिक ज़रूरत innovation को आगे बढ़ाने वाली सबसे अच्छी ताकत है, और शुरुआती computing की ऐतिहासिक उपलब्धियाँ भी बड़े सार्वजनिक हित के लिए हुई थीं
• लेखक जिस तरह काम करना चाहता है, उसमें system बनाने का क्यों ही हर कैसे को दिशा दे
  • programming language
  • paradigm
  • architecture
  • code की हर line
  • syntax का हर तत्व
• वह “क्यों” अपने आप में मौजूद business metrics नहीं होना चाहिए, बल्कि किसी वास्तविक, पहले से मौजूद ज़रूरत को प्रतिबिंबित करना चाहिए

समान मूल्यों वाले लोगों की तलाश

• लेखक कहता है कि उसे अब तक कोई ऐसा व्यक्ति नहीं मिला जिसने इन मूल्यों को गंभीरता से साझा किया हो और इस तरह का engineering work करना चाहा हो
• industry के साथ अपने अनुभवों में वह अक्सर अलग-थलग महसूस करता है, लेकिन अपने काम के मूल्यों और जो बात कहनी है उसकी अहमियत को लेकर आश्वस्त है
• वह ऐसे लोगों से संपर्क करने का आग्रह करता है, जानना चाहता है कि क्या ऐसी कोई जगह पहले से मौजूद है, और अगर नहीं है तो उसे मिलकर बनाना उपयोगी होगा
• वह अपने रुचि क्षेत्रों में, और अपने मूल्यों से उचित रूप से मेल खाने वाले consulting work के लिए खुला है

[GN⁺]

Hacker News की राय

• OP को जिस चीज़ से नफ़रत है, वह “प्रोग्रामिंग इंडस्ट्री” से ज़्यादा कॉर्पोरेट दुनिया है। मैंने ऐसे डेवलपर्स के साथ काम किया है जिनकी यह उम्मीद हक़ीक़त से मेल नहीं खाती थी कि “वास्तविक दुनिया” डेवलपर्स से क्या चाहती है, और मैं ख़ुद भी कभी ऐसा रहा हूँ
  कंपनियों को refinement, abstraction, witty या सुंदर code में दिलचस्पी नहीं होती। उन्हें ऐसे डेवलपर्स चाहिए जो business requirements के मुताबिक features निकालकर दे सकें
  मैनेजर, executives, और सहकर्मी जैसे इस मशीनरी के भीतर के लोग कह सकते हैं कि वे तुम्हें प्रोग्रामिंग की “कला” करने देंगे, लेकिन अगर तुम कंपनी के लिए आर्थिक योगदान नहीं दे रहे हो, तो आख़िरकार तुम्हें बोझ माना जाएगा
  कॉर्पोरेट दुनिया के बाहर प्रोग्रामिंग की ख़ुशी और कलात्मकता ढूँढना बेहतर है, और यह उम्मीद न करना ही अच्छा है कि “इंडस्ट्री” को इस बात की परवाह है कि प्रोग्रामिंग कैसे या क्यों की जाती है। वे सिर्फ़ यह देखते हैं कि स्क्रीन पर टाइप किए गए अक्षर नकद में बदल रहे हैं या नहीं। इसे स्वीकार कर लो, तो ज़िंदगी काफ़ी कम घुटनभरी लगती है और काम में भी मज़ा मिल सकता है। बस ज़रूरी नहीं कि वह “कला” ही हो

  • मेरे हिसाब से “इंडस्ट्री” शब्द का मतलब काफ़ी मज़बूती से कॉर्पोरेट दुनिया ही है
    लेकिन “कंपनियों को refinement, abstraction, wit, या सुंदर code में दिलचस्पी नहीं होती” वाली बात पर, तब तो लगता है कि शायद मैं ही कॉर्पोरेट दुनिया हूँ
    मैं अपने सहकर्मियों से कहना चाहता हूँ कि refinement, abstraction, wit, या सुंदरता की कोशिश करने से पहले चीज़ को spec के मुताबिक काम करने वाला बनाओ। वरना वह सब बेकार है
    किसी चीज़ को सही तरह काम कराने में कुछ हद तक माहिर हो जाने के बाद ही उसे सही ढंग से बनाना, और शायद तेज़ बनाना भी, संभव होता है
  • और सरल रूप में कहें तो, हैरानी की बात है कि काम शौक़ से कम मज़ेदार होता है
    अगर आप अपनी पसंद की चीज़ को अपना business भी बना लें, मान लीजिए फर्नीचर बनाते हैं, तब भी ग्राहक “ग़लत” चीज़ चाहेंगे या बेहतर दुर्लभ materials के लिए पैसे नहीं देना चाहेंगे
    इसलिए किसी ऐसी चीज़ को, जिसे आप सच में पसंद करते हैं, काम के तत्वों से मुक्त एक hobby के रूप में करना हमेशा बेहतर होता है
  • “कॉर्पोरेट दुनिया के बाहर प्रोग्रामिंग में सांत्वना ढूँढो” — यही पिछले 10 साल में इंडस्ट्री से सीखा गया कड़वा सच है
    आपको पैसे डिलीवर करने के लिए मिलते हैं। यह efficient था या नहीं, समस्या हल हुई या नहीं, पैसे कमाए या नहीं, checkboxes भरे गए या नहीं — यह मेरी चिंता या मेरे नियंत्रण की चीज़ नहीं है। बस अपना काम plan करो, करो, लोगों के साथ विनम्र रहो, और 5 बजे घर निकल जाओ
    इसका मतलब यह नहीं कि बुरा code लिखो या फ़ैसलों के downstream impact की परवाह ही न करो। लोग इस वजह से निकाले भी जाते हैं
    ज़्यादा अहम बात यह है कि हद से ज़्यादा मत करो। यह मत सोचो कि product कैसे evolve होगा और हर scenario को पहले से cover करने लगो, यह मत करो कि साफ़ तौर पर बेहतर design को ज़बरदस्ती आगे बढ़ाओ, और जल्दी डिलीवर करने के लिए ख़ुद को मत झोंको, और अपने assigned काम के दौरान मिले दूसरे bugs को भी ठीक करने मत लग जाओ। promotion के पीछे भागना, अपने ऊपर लाए गए सबसे बुरे stress में से एक था
    आपको समझना चाहिए कि आपका project high-intensity है, high-growth है, mature stage में है, या आप जल्द निकाले जा सकते हैं, और उसी हिसाब से व्यवहार करना चाहिए
    और श्रेय लेना और दिखाई देना भी ज़रूरी है। हर quarter में एक बार demo करो, दूसरों के code review करो, design meetings में जाकर सवाल पूछो, शाम 5 बजे से पहले आए email या messenger का जल्दी जवाब दो, और जो करने का कहा है उसे डिलीवर करो। अपने आपको एक useful resource की तरह दिखाओ, लेकिन जैसे ही delivery pressure की हल्की-सी भी आहट मिले, उसे अपने व्यवहार से पीछे धकेलो
    आख़िर में, हमेशा 2 हफ़्तों के भीतर अगला interview देने के लिए तैयार रहना अच्छा है
    नौकरी बस नौकरी है। वह परिवार नहीं है, और न ही कोई talent agency
  • मुझे लगता है कि यही सोच आख़िरकार चीज़ों को ठीक Boeing जैसा बना देती है
    जैसे उड़ान के दौरान पंख जुड़े रहना किसी key performance indicator को नहीं बढ़ाता, तो ऐसी असंबंधित चिंताओं पर समय लगाने वाले सब लोगों को निकाल देना चाहिए
  • अगर यह काफ़ी relevant लगे और self-promotion माफ़ हो, तो इन्हीं कारणों से मैं Handmade conference को पेशेवर रूप से चलाता हूँ, और यह बिना sponsor के मुफ़्त है https://handmadecities.com/about
    इसका implicit goal यह है कि यह इतना mainstream हो जाए कि programmers सामूहिक रूप से इस बात पर सहमत हो सकें कि उन्हें “कॉर्पोरेट दुनिया” में bargaining power मिलनी चाहिए। उदाहरण के लिए, नए features “निकालने” की रफ़्तार कम करने और software quality में ज़्यादा निवेश की माँग करने जैसी बात

• मैं 30 साल से ज़्यादा समय से डेवलपर के तौर पर काम कर रहा हूँ, लेकिन दुख की बात है कि OP की बातों का ज़ोरदार खंडन करने लायक मेरे पास बहुत कुछ नहीं है। काश मैं ऐसा कर पाता।
  युवाओं को सिखाया जाता है कि टेक्नोलॉजी और सॉफ्टवेयर बनाना एक रचनात्मक काम है, जहाँ वे अपने जन्मजात जुनून को व्यक्त कर सकते हैं। एक खास तरह की सोच, जो symbols, abstraction और दोहराव वाले कामों की ओर खिंचती है, इस पेशे में आती है। समय बीतता है और shareholders और मोटे होते जाते हैं।
  सच यह है कि software development लगभग पूरी तरह एक आर्थिक गतिविधि है, और उसका स्वभाव भी शोषणकारी है। काम का माहौल सोना या bauxite खनन करने से निश्चित ही बेहतर है, लेकिन ज़्यादातर लोग असल में किसी और को अमीर बनाने के लिए code seam से code खोद रहे होते हैं। वे लोग जो corner office में बैठे हैं, और उनके ऊपर वे लोग जिनके पास yacht है।
  उन्हें इस बात से कोई मतलब नहीं कि हम क्या करते हैं, या हम इसे कला या craftsmanship समझकर जो आडंबर करते हैं, या जो चीज़ें हमें महत्वपूर्ण लगती हैं। असल में वे ज़्यादातर हमें समय बर्बाद करने वाले हारे हुए लोग समझते हैं https://ribbonfarm.wpenginepowered.com/wp-content/uploads/2009/10/hughMcLeodCompanyHierarchy.jpg
  जैसा यहाँ दूसरों ने कहा, मूल गलती corporate काम में अर्थ खोजने की कोशिश करना है। लेकिन इंसानों को अर्थ चाहिए, और अपनी एकमात्र ज़िंदगी का बहुत बड़ा हिस्सा काम में देना पड़ता है, इसलिए विकल्प भी ज़्यादा नहीं हैं। जवाब क्या है, मुझे नहीं पता।

  • “वे हमें समय बर्बाद करने वाले हारे हुए लोग समझते हैं” — यह सच में कई जगह दिखने वाली चीज़ है।
    software के “निचले तबके” को loser समझने वालों में कम से कम दो तरह के लोग होते हैं।
    एक वे हैं जो मानते हैं कि यह काम skill मांगता है, काम करने वालों के पास मूल्यवान expertise है, और उनकी बात सुनने लायक है। फिर भी उनकी नज़र में वे सिर्फ salary पर बिकने वाला commodity हैं, और उनके जैसे “कमरे का सबसे स्मार्ट इंसान” या “leader” बनकर बड़ा reward पाने वाले असली खिलाड़ी नहीं हैं, इसलिए वे loser हैं।
    दूसरी तरह के लोग software के काम को low-skill छोटा-मोटा काम मानते हैं, workers को अस्थायी आवश्यक बुराई समझते हैं, और compensation तथा loyalty के मामले में उन्हें घमंडी और अपनी औकात न जानने वाला मानते हैं। उनकी नज़र में इन लोगों की राय की कोई कीमत नहीं। और हाँ, business की दुनिया में software workers असली खिलाड़ी की तरह चालें नहीं चलते और निजी फायदा नहीं बटोरते, इसलिए वे loser माने जाते हैं।
    दूसरी स्थिति कहीं ज़्यादा खराब है।
  • “किसी और को अमीर बनाने के लिए code seam से code खोदना” वही चीज़ है जिसे आम तौर पर काम कहा जाता है। वही काम जो हम अच्छी चीज़ें और समाज बनाने के लिए करते हैं।
    अगर मेरे बनाए हुए से कोई और अमीर होता है, तो यह अच्छी बात है। इसका मतलब है कि मैंने जो बनाया उसकी कुछ कीमत है। मैं चाहता हूँ कि जो कुछ भी मैं बनाऊँ, उसमें मूल्य हो।
    कभी न कभी, अगर मैं पर्याप्त अभ्यास, सीख, अनुभव और बचत जमा कर लूँ, तो मैं भी उम्मीद करता हूँ कि दूसरों को जिम्मेदारी से नौकरी पर रख सकूँ।
    अगर मेरे पास अच्छा idea हो और मैं उसे सही तरह से कर दिखाऊँ, तो मेरे पास भी वह yacht होने की संभावना है। हम इसे economic incentive, या प्रेरणा कहते हैं।

• मेरे हिसाब से “industry किस दिशा में जा रही है” इसका मतलब बहुत पहले से ठगों के घुसपैठ करने की प्रक्रिया रहा है। software लिखकर जो मूल्य पैदा किया जा सकता है वह बहुत बड़ा है, और tech industry की ऊँची salaries उसी को दिखाती हैं। वही दौलत हर तरह के ठगों को खींच लाती है।
  योग्य engineers को चुनने वाले cat-and-mouse game में यह सबसे खुलकर दिखता है। hiring funnel के ऊपर और नीचे का अनुपात पहले से कहीं ज़्यादा हो गया है।
  कम स्पष्ट तरीके से, product manager, scrum master जैसी पूरी “ठग भूमिकाएँ” पैदा हो गई हैं। एक बार अंदर आ जाने पर, उनकी संख्या जितनी ज़्यादा हो उतनी सुरक्षा, इसलिए और ज़्यादा लोगों को अंदर लाया जाता है।
  जो स्मार्ट लोग innovation कर सकते हैं, उन्हें अब creativity, innovation, research, discovery और engineering की प्रक्रिया में अयोग्य लोगों का हाथ पकड़कर मार्गदर्शन करना पड़ता है। क्योंकि अक्सर वही अयोग्य लोग अंतिम फैसला लेते हैं कि स्मार्ट लोग अपना समय कहाँ खर्च करेंगे।
  अगर आपने वह meeting झेली है जहाँ engineers पहले 10 मिनट में ही समझ जाते हैं कि customer की समस्या कैसे हल होगी, और फिर product managers को बारी-बारी से उसी निष्कर्ष तक हाथ पकड़कर पहुँचाना पड़ता है, तो वही इसका रूप है।

  • ठगों की घुसपैठ का एक और सूक्ष्म असर भी है। ऊपर से शानदार दिखने वाला, लेकिन असल में संभालने में बेहद खराब software बनता है। क्योंकि उसे शानदार दिखाकर पेश करना ही बनाने वालों की असली ताकत थी, अच्छा software बनाना नहीं।
    नतीजा होता है performance issues, security holes, observability की कमी, खराब scalability, और बेतुकी configuration या dependency समस्याएँ।
    खासकर FAANG कंपनियाँ ऐसे कचरे से भरी हुई हैं। यह वह code है जो promotion के लिए “शेखी बघारने वाली पोस्ट” के काम आए, इस इरादे से लिखा गया, और सस्ते shortcuts खुलने से पहले लोग कहीं और निकल गए, इसलिए उसे लगभग छोड़ ही दिया गया।
    ठोस design से ज़्यादा चिकनी-चुपड़ी बात करने की कला software engineer की सबसे मूल्यवान skill बन गई है, और उसका नतीजा हर जगह दिख रहा है।

• 10 साल से ज़्यादा enterprise software development करने के बाद अब मुझे न तो नतीजों की परवाह है, न इस सर्कस की दिशा की।
  अब मैं बस उस absurdly high salary वाले paycheck की परवाह करता हूँ।

  • और stress को कम से कम रखना भी ज़रूरी है। आम तौर पर मैं जितना संभव हो उतना कम करता हूँ, लेकिन बाद के stress से बचने के लिए कभी-कभी थोड़ा extra भी कर लेता हूँ।
    मैं इसे अभी उतनी ही परवाह करने वाला development, ताकि बाद में बहुत ज़्यादा परवाह न करनी पड़े कहता हूँ।

• मैंने 40 साल programmer के तौर पर बिताए हैं, लेकिन हमेशा creativity और imagination इस्तेमाल करने के तरीके खोजे, और सिर्फ मशीन की तरह code टाइप करने वाला इंसान बनने से बचने की कोशिश की।
  अपनी आख़िरी नौकरी में मैंने एक छोटी टीम लीड की, रणनीतिक रूप से महत्वपूर्ण code बनाया, और सफलता भी मिली। हालत यह थी कि अगर वह code हर समय काम न करे, तो रोज़ 1 लाख लोग गुस्सा होते, और उनके साथ कई नाराज़ executives भी खड़े हो जाते।
  आखिरकार बहुत ज़्यादा मेहनत करते-करते थक गया और retire होने का फैसला किया।
  अगर काम आपको प्रेरित नहीं करता, तो programmer बने रहने का कोई नया तरीका या नई जगह तलाशनी होगी। जैसे अपनी कंपनी शुरू करना या कुछ नया आज़माना। नहीं तो कोई दूसरा पेशा ढूँढ़ना होगा।
  खुद को फिर से गढ़ना आसान नहीं है, और आजकल तो पहले से भी कठिन है, लेकिन अगर आप सच में पर्याप्त चाहें, तो यह किया जा सकता है।

• कॉर्पोरेट मालिकों के लिए काम करते समय भी programming ऊर्जा देती है। मशीनों को अपनी मर्ज़ी के मुताबिक चलाने के लिए मनाना कभी उबाऊ नहीं लगता। इसे पूरे दिन भी किया जाए तो भी थकान नहीं होती
  कभी-कभी जब programming की ज़रूरत बहुत ज़्यादा होती है, तब बाद में एहसास होता है कि मैं लगातार 15 घंटे तक इसमें डूबा रहा। लगभग 20 साल से ऐसा ही है
  अफ़सोस की बात है कि programming काम का सिर्फ़ एक छोटा हिस्सा है। करियर बढ़ने के साथ यह और भी साफ़ होता जाता है। कई बार हफ़्ते में असल coding सिर्फ़ एक-दो घंटे ही होती है
  बाकी समय बेकार बैठकों, उन लोगों का हाथ पकड़कर समझाने में जो पढ़ते ही नहीं, दूसरों को यह समझाने में कि वे मशीनों को ज़रूरत के मुताबिक कैसे मनाएँ, “planning”, और ऐसे ही शोर में निकल जाता है। इसका एकमात्र संतोषजनक हिस्सा युवा programmers को mentor करना है
  जारी रखने की वजह बस यह है कि यह retirement तक पहुँचने का सुरक्षित रास्ता है, और मैं लगभग वहाँ तक पहुँच चुका हूँ। retirement के बाद की योजना है कि सिर्फ़ शुद्ध आनंद के लिए वही चीज़ें program करूँ जिन्हें मैं बनाना चाहता हूँ

• मुझे लगता है कि समस्या का एक हिस्सा यह है कि बहुत से developers चाहते हैं कि वे अभी $FAANG में जो salary पा रहे हैं या $STARTUP में जो equity मिल सकती है, उसे बनाए रखते हुए अर्थपूर्ण projects और अच्छे लोगों के साथ काम करें
  वास्तव में कर्मचारी meaning, autonomy, ownership, और work-life balance को भी मुद्रा की तरह मानते हैं, और अर्थपूर्ण काम पाने के लिए salary cut भी स्वीकार कर लेते हैं
  बेहतर jobs मौजूद हैं। मैंने भी ऐसी नौकरी पाई है। लेकिन अगर आप अभी ad tech company या AI startup में काम कर रहे हैं, तो आपको लगभग तय मानकर चलना होगा कि familiar स्तर से काफ़ी कम salary दिखेगी

  • मैं ऐसा इंसान हूँ जो mental health के लिए 10 में से 9 बार काफ़ी बड़ा salary cut भी खुशी से स्वीकार कर लेगा
    मैं कम-आय वाले परिवार में बड़ा हुआ हूँ, और adult होने के बाद भी कई बार बहुत कम पैसों में जी चुका हूँ, इसलिए यह मुझे स्वाभाविक लगता है। कुछ मायनों में तो मैं इसे लगभग पसंद ही करता हूँ
    मेरी mental health तंग budget की तुलना में ज़्यादा आसानी से अत्यधिक stress या अर्थहीनता से प्रभावित होती है
    ऐसा काम करते रहना, जिसे लेकर मैं बहुत अच्छा महसूस नहीं करता, या उससे भी बुरा, जो सिर्फ़ नकारात्मक भावनाएँ देता है, तभी समझदारी है जब ज़्यादा कमाए गए पैसे के लिए कोई बहुत ठोस योजना हो और उस योजना को सच में लागू करने की संभावना बहुत अधिक हो
    यह जीवन-शैली हर किसी के लिए सही नहीं है, लेकिन अगर आप औसत से कम materialistic हैं या ज़्यादा सादगी से जीने से नहीं डरते, तो मैं इसे गंभीरता से सोचने की मज़बूती से सलाह दूँगा। खासकर अगर आप आजकल हफ़्ते में एक से ज़्यादा बार खुद से पूछते हैं कि “इस अच्छी नौकरी” में टूटे बिना और कितने समय तक टिक सकता हूँ
  • मैं एक बड़ी construction company में software engineer हूँ, और मेरा काम गहराई से अर्थपूर्ण है
    हमारे बनाए tools की वजह से असली चीज़ें बनाने वाले लोग ज़्यादा सुरक्षित और कुशलता से काम कर पाते हैं। आँखों के सामने, हाथ से छू सकने लायक projects को बनते देखना सच में शानदार है
    सही है कि FAANG compensation इससे कहीं ज़्यादा है, लेकिन जहाँ मैं अभी काम करता हूँ वह जगह सच में बहुत अच्छी है, और कई सालों में पहली बार मुझे यह महसूस नहीं हो रहा कि कुछ समय बाद फिर कहीं और जाना पड़ेगा
  • सहमत। छोटी companies बहुत हैं। शुरुआती startups भी हैं, और वे कंपनियाँ भी जो product-market fit खोजने से पहले के चरण में हैं या अभी-अभी वहाँ पहुँची हैं
    ज़्यादातर के पास बड़ी salary देने की क्षमता नहीं होती। उन्हें ऐसे लोग चाहिए जो genuinely interested हों और self-motivated हों। कई मायनों में flexible रहने की इच्छा भी चाहिए, और छोटी companies में कहीं ज़्यादा चीज़ें negotiate की जा सकती हैं
    ऐसी companies आसानी से सामने नहीं आतीं, इसलिए आपको उन्हें खुद ढूँढना पड़ता है

• समाधान है स्वतंत्र होकर अपने ideas बनाना और उन्हें consumers को बेचना। यह आपका अपना startup हो सकता है, लेकिन मेरे मामले में इसका मतलब indie game developer बनना था
  मेरे games में से एक, YOYOZO, Ars Technica की “Best Video Games of 2023” सूची में चुना गया, इसलिए मुझे लगता है कि मेरा फ़ैसला सही था

  • जिज्ञासा है, game बनाते समय आपने वित्तीय रूप से कैसे संभाला? जैसे क्या आपने freelance काम किया, या savings इस्तेमाल कीं?
  • जिज्ञासा है कि आपने यह transition कैसे किया। और game के feature होने से पहले आप अपने फ़ैसले को लेकर कैसा महसूस करते थे, यह भी जानना चाहता हूँ। मैंने भी इस रास्ते के बारे में सोचा है, लेकिन इसमें कूदने में बहुत हिचकिचाहट होती है
  • जानना चाहता हूँ कि आप कौन-सा game development stack इस्तेमाल करते हैं

• यह वैसा है जैसे sex पसंद हो लेकिन sex worker बनना पसंद न हो। आप जो भी करें, अगर उसे अपनी शर्तों पर नहीं कर सकते, तो वह आपको दुखी कर सकता है

  • industry के बारे में अपनी भावना समझाने के लिए मैं भी लगभग हमेशा यही रूपक इस्तेमाल करता हूँ

• LeetCode को लेकर भी कुछ ऐसा ही महसूस होता है
  software engineering पसंद है, लेकिन LeetCode software engineering से नफ़रत करा देता है
  मैं बस cool चीज़ें बनाना चाहता हूँ। मैं 40 मिनट में LRU cache या कोई और upper-mid LeetCode problem रटकर implement नहीं करना चाहता

  • बस मना कर दीजिए। मैंने LinkedIn पर खुलकर, और अब GitHub पर भी, यह नोट जोड़ दिया है कि मैं LeetCode-style interviews या ऐसी मिलती-जुलती चीज़ें स्वीकार नहीं करता, और उसके बाद से मैं ज़्यादा खुश हूँ https://github.com/mihaitodor
    हाँ, इससे कुछ companies शायद मुझसे बात ही न करें, लेकिन मुझे उससे फ़र्क नहीं पड़ता। वैसे भी मैं ऐसे interviews कभी पास नहीं कर पाया, और मुझे हमेशा ऐसी jobs लेनी पड़ीं जहाँ interview के दौरान live coding ज़रूरी न हो
  • Linktree clone side project में आपने आख़िरी बार bubble sort कब इस्तेमाल किया था?
  • इन interviews की समस्या यह है कि ये यह भी ठीक से test नहीं करते कि आप किसी समस्या पर कितना अच्छा सोच सकते हैं और उसका solution design कर सकते हैं
    अपेक्षा असल में यह होती है कि आप optimal solution को पूरी तरह याद करके आएँ। और वह optimal solution संभव है कि algorithms पर शोध करने वाले किसी PhD-स्तर के व्यक्ति ने निकाला हो
    अंत में आपको तो बस 1,000 monthly active users वाले CRUD के लिए endpoint implement करना होता है