सॉफ्टवेयर इंजीनियरिंग क्षेत्र में काम करने वालों की मानसिक स्वास्थ्य समस्याएं

• startup leader की भूमिका में code से ज्यादा अनिश्चित जिम्मेदारियां संभालनी पड़ती हैं, और panic attacks, anxiety व burnout काम के performance और पूरी जिंदगी को हिला सकते हैं
• पद बढ़ने के साथ स्पष्ट tickets की जगह बदलती requirements, overlapping deadlines, और 24/7 incident response जैसे अधूरे छोर वाले दबाव बढ़ते हैं
• “make it happen” जैसी culture अव्यावहारिक deadlines स्वीकार करवाने, micromanagement, रात में PR दोबारा लिखने, meals छोड़ने और meetings के ढेर से burnout बढ़ाती है
• हर deadline का risk एक जैसा नहीं होता; regulatory, contractual, और self-imposed deadlines में फर्क करने से negotiable pressure और वास्तविक risk अलग-अलग दिखते हैं
• recovery बड़े संकल्पों से ज्यादा early warning signals पहचानने, weekends बचाने, delegation, notifications बंद करने, और counselling जैसे छोटे, दोहराए जा सकने वाले actions से शुरू होती है

---

startup leader की भूमिका से शुरू हुई anxiety और burnout

• 2017 में Head of IT की भूमिका संभालते समय 5 लोगों की development team, partners से किए गए कई वादे, और “सब कुछ deliver करो, कुछ भी टूटने मत दो, और किसी को burnout मत होने दो” वाला दबाव साथ में आ गया
• उस समय मानसिक स्वास्थ्य के कारण sick leave लेना संभव है, ऐसा महसूस नहीं होता था; company handbook में mental health day होने पर भी engineers अब भी हिचकिचा सकते हैं
• जब anxiety बढ़ती थी, तो Reddit के r/Anxiety पर मिलते-जुलते symptoms खोजे; यह long-term solution नहीं था, लेकिन office से भागकर बाहर न निकलने में मदद करता था
• आखिरकार doctor से मिलकर formal diagnosis मिला और धीरे-धीरे baseline state में वापसी हुई; आज भी emergency checklist पास रखता हूं

control में लगने वाले development work से अनिश्चित leadership work तक

• शुरुआती development work में clear tickets, acceptance criteria, tests, merge जैसे अपेक्षाकृत controlled workflows ज्यादा थे
• पद ऊपर बढ़ने के साथ काम की definition धुंधली होती गई, deadlines overlap होने लगीं, stakeholders sprint के बीच में अपना मन बदलने लगे, और probabilistic judgment रोजमर्रा का हिस्सा बन गया
• infrastructure और SRE work में 24/7 pager के साथ जीना पड़ता है, इसलिए product deadlines से भी ज्यादा लगातार tension रहती है
• एक situation थी जहां CEO ने सबसे बड़े customer से promise किए गए feature को top priority बनाने को कहा, और अगले ही दिन उससे contradict करने वाले दूसरे feature को भी top priority बताया
  • जब कहा गया कि दोनों features एक साथ top priority नहीं हो सकते, तो जवाब था: “make it happen”

“make it happen” से हुआ cumulative damage

• burnout किसी एक बड़े incident से ज्यादा हजारों छोटे self-damages के जमा होने जैसा था
• मानसिक बोझ बढ़ाने वाली behaviors बार-बार दिखीं
  • sales team की इज्जत बचाने के लिए हर अव्यावहारिक deadline स्वीकार करना
  • team को protect करने के नाम पर खुद code में कूद पड़ना और micromanagement करना
  • रात 2 बजे bank account refresh करके यह देखना कि salary pay हो पाएगी या नहीं
  • अभी लगी आग बुझाते हुए साथ-साथ future architecture plan करने की कोशिश करना
  • juniors को coach करते हुए रात में चुपचाप PR दोबारा लिखना
  • back-to-back meetings, ठंडी coffee और छूटा हुआ lunch जारी रहना
• weekend सुबह के पहले 10 seconds ठीक लगते, फिर तुरंत anxiety गिरने जैसा एहसास बार-बार लौटता था

हर deadline का risk एक जैसा नहीं होता

• पहले हर release को Mars Rover landing जैसा treat किया जाता था, लेकिन पीछे मुड़कर देखने पर वास्तव में company के अस्तित्व को तय करने वाली deadlines कम थीं; बाकी ज्यादातर ego और expectations set करने में failure के करीब थीं
• company का cash flow बेहतर होने और customers stable होने के बाद work-life balance कम unrealistic दिखने लगा
• एक बार Friday night deployment टूट गया और 6 घंटे damage control में लगे; लगा कि customer contract cancel कर देगा, लेकिन Monday को पता चला कि customer sailing trip पर था और उसने staging link तक नहीं खोला था
• deadlines को तीन प्रकार में बांटा जा सकता है
  • regulatory deadlines: negotiable नहीं
  • contractual deadlines: जल्दी बता दें तो आमतौर पर negotiate हो सकती हैं
  • self-imposed deadlines: ज्यादातर ego से आती हैं
• कुछ companies 4-day workweek और office hours के बाद Slack ban को highlight करती हैं; burnout को badge of honor की तरह treat करने वाली companies में ही रुके रहना जरूरी नहीं है

जो personal coping methods काम आए

• यह medical advice नहीं है, लेकिन functioning बनाए रखने में कुछ actions मददगार रहे
• early warning signals खोजे
  • मेरे लिए doom-scroll insomnia और normally पसंद आने वाले code review के प्रति अचानक नफरत signals थे
  • ऐसे signals दिखें तो speed कम कर देता हूं
• “नहीं” साफ-साफ कहा
  • weekends protect होने चाहिए, और अगर pager alert नहीं है तो उसे Monday तक wait करना चाहिए
• सही तरीके से delegate किया
  • हर PR जिसे आप पकड़े बैठे हैं, mentoring का खोया हुआ मौका है और anxiety जमा करने का कारण भी
• caffeine कम किया
  • half-caf से होते हुए decaf पर switch किया और heart ज्यादा calm हुआ
• रोज 12,000 steps चला
  • किसी खास equipment की जरूरत नहीं; shoes और route ही काफी हैं
• phone notifications बंद किए
  • अगर production सचमुच जल रहा होगा, तो कोई call कर ही देगा

इंसान को पहले देखने वाली leadership

• emotional intelligence पढ़ना शुरू करने के बाद लोगों को merge conflict machines की तरह देखना बंद किया
• पहले सुनना और बाद में fix करना, कभी-कभी एक और sprint retrospective से ज्यादा मददगार होता है
• dental treatment के लिए professional मदद लेने में शर्म नहीं करते, लेकिन mental health को अकेले refactor करने की उम्मीद रखना सही attitude नहीं है
• expert से मिला समय सबसे high-ROI समयों में से एक था
• recovery एक repeated process है; अब भी कभी देर तक काम हो जाता है या lunch भूल जाता हूं, लेकिन अब उसे notice कर ठीक करता हूं और आगे बढ़ता हूं

code से ज्यादा महत्वपूर्ण asset

• code दोबारा लिखा जा सकता है, लेकिन इंसानों के साथ ऐसा नहीं किया जा सकता
• depression Kubernetes uptime की परवाह नहीं करता; अगर leadership लोगों को पीसती है, तो cluster चल सकता है, लेकिन उसे चलाने वाले लोग टिक नहीं पाएंगे
• सभी customer tickets खुद fix करने की इच्छा होने पर भी अब पहले पूछता हूं: “क्या यह मेरे control के दायरे में है?” और अगर नहीं, तो hand off कर देता हूं
• नतीजतन मैं थोड़ा ज्यादा calm engineer बना, और Apple Watch के अनुसार रात में 45 minutes ज्यादा नींद लेने लगा
• अगर आप कठिन दौर में हैं, तो आप टूटे हुए नहीं हैं और अकेले नहीं हैं; help मांगना, छोटे experiments करना और mental health leave लेना बेहतर है
• जो company आपकी value burnout hours से मापती है, वह उन hours के लायक नहीं है; सबसे बड़ा asset लिखा गया code नहीं, बल्कि वह इंसान है जो code लिखता है

[GN⁺]

Hacker News की रायें

• लगभग 30 साल तक software engineering करने के बाद, मैं इस निष्कर्ष पर पहुँचा हूँ कि ज़्यादातर deadlines पूरी तरह मनमानी होती हैं
  1 हफ्ते की देरी या यहाँ तक कि 6 महीने की देरी से कंपनी बंद नहीं हो जाती, और अगर सच में बंद हो जाए तो वह engineering की गलती भी नहीं है—जब तक कि engineering संगठन इस हद तक खराब न हो चुका हो कि वह बार-बार अपनी ही delivery estimates तोड़ता रहे
  regulation, customer proof-of-concept, delivery जैसी वास्तविक deadlines होती हैं, लेकिन किसी सामान्य engineering/business संगठन को ऐसी deadlines बहुत पहले से पता होती हैं, और असली सवाल यह होता है कि क्या उन्हें पर्याप्त buffer वाली timeline में implement किया जा सकता है
  मैंने बहुत कम देखा है कि ग्राहक सिर्फ इसलिए छोड़कर चले जाएँ क्योंकि product किसी तय चक्र में release नहीं हो रहा। उल्टा, कई ग्राहक upgrade को पसंद नहीं करते, जब तक कि वह उनके द्वारा माँगी गई problem को ठीक न कर रहा हो
  अंतहीन हफ्ते में 80 घंटे काम आमतौर पर उलटा असर डालता है, और ऐसे low-quality products बनवाता है जो लगातार टूटते हैं और जिन्हें फेंक देने का मन करता है

  • मेरे अनुभव में ज़्यादातर काम अपने-आप में भी मनमाना होता है
    पिछले 30 सालों को देखें तो कितने प्रतिशत काम ऐसे थे जिन्हें पूरी तरह छोड़ भी दिया जाता तो long term में कोई फर्क नहीं पड़ता? मेरे मामले में यह आसानी से 50% से ऊपर है, और अगर दिन खराब हो तो मैं कहूँगा कि 90% के करीब
  • यह industry पर निर्भर करता है
    video games अभी भी Target, Best Buy जैसे retail stores में बिकते हैं, और stores को महीनों पहले से shelf space coordinate करना पड़ता है। अगर आपने वादा किया कि 15 नवंबर तक packaged game logistics dock पर पहुँचा देंगे और चूक गए, तो आपके लिए खाली रखी गई shelf खाली ही रह जाएगी
    consumer electronics में भी ऐसा ही है, और advertising, खासकर TV ads, पहले बहुत पहले से book करनी पड़ती थी। अगर 6 महीने पहले ad slot न खरीदें तो वे बिक जाते हैं, और ad चलने के समय product खरीदने के लिए उपलब्ध न हो तो बहुत पैसा बर्बाद होता है
    सामान्य IT projects की deadlines काफी बकवास हो सकती हैं, लेकिन retail products में deadlines क्यों बनती हैं, यह समझ आता है
    समाधान यह होगा कि product 100% पूरा होने से पहले shelf space की negotiations शुरू न की जाएँ, लेकिन कंपनियाँ आमतौर पर ऐसा नहीं कर पातीं। order payments से salaries देनी होती हैं, और product पूरा होने के बाद ads और shelves सुरक्षित करके 6 महीने इंतज़ार करें तो उस दौरान employees के लिए काम अस्पष्ट हो जाता है; अगले product पर जाकर फिर पुराने product support पर लौटने की cost भी बड़ी होती है
  • VirtualBox, Docker जैसे कई software इस्तेमाल करने वाले व्यक्ति के रूप में, मुझे updates और तथाकथित upgrades सच में नापसंद हैं
    मैं बहुत कम बार update होने वाले stable versions को कहीं ज़्यादा पसंद करता हूँ
  • कंपनियाँ deadline से ज़्यादा तब परेशान होती हैं जब deadline miss होने वाली है, इसकी पर्याप्त advance notice नहीं मिलती
    बिना किसी warning के engineering अचानक announce कर दे कि आसन्न deadline पूरी नहीं होगी, या “लगभग खत्म है, बस एक sprint और” बार-बार दोहराया जाए—यह ज़्यादा frustrating होता है
    इसलिए “अब estimates नहीं देंगे”, “जब खत्म होगा, तब खत्म होगा” जैसी तात्कालिक प्रतिक्रियाएँ बिल्कुल मददगार नहीं होतीं
  • कई managers और leaders मान लेते हैं कि हर काम के लिए deadline ज़रूरी है
    वे अपना schedule भी time blocking और मनमानी deadlines से manage करते हैं और productive महसूस करते हैं, फिर उसी insight को पूरी कंपनी पर लागू कर देते हैं। इसके पीछे यह धारणा होती है कि time-bound threat न हो तो काम समय पर पूरा नहीं होगा
    किसी काम के किसी तय तारीख पर खत्म होने का एहसास मानवीय रूप से आकर्षक होता है, और well-oiled machine के predictable schedule पर चलने जैसा एक सुखद एहसास भी देता है
    लेकिन किसी व्यक्ति की anxiety और schedule obsession को manage करने के लिए बहुत-से लोगों पर forced schedules थोपना क्रूर है। वास्तविकता जटिल है, और उसे साफ-सुथरे boxes में फिट करने की इच्छा भ्रमपूर्ण और non-productive है

• मुझे इस बात पर बहुत भरोसा नहीं है कि software engineering, डॉक्टर, वकील, sales, engineer, professional athlete, teacher जैसे दूसरे white-collar पेशों की तुलना में मानसिक स्वास्थ्य के लिए ज्यादा खराब है
  इन सभी पेशों के अपने-अपने stress factors होते हैं, और ऐसे लेखों की भरमार है कि ये काम मुश्किल हैं इसलिए बहुत लोग छोड़ देते हैं। सीमाएँ तय न करें तो ये खाली समय खा जाते हैं, और deadlines की वजह से stress होना भी सबमें common है
  यह पढ़ना तकलीफदेह था कि कोई अपनी team से “मानसिक तौर पर मुश्किल हो रहा है, इसलिए एक दिन off लूँगा” कहकर sick leave नहीं ले सकता
  20 साल के career में मैंने ऐसा रवैया कभी नहीं देखा, और लोग मानसिक स्वास्थ्य की वजह से अक्सर sick leave लेते हैं। अफसोस है कि आपको लगा कि आप ऐसा नहीं कह सकते, लेकिन यह नियम नहीं, अपवाद के काफी करीब है
  पिछले 20 सालों में क्या कोई company मानसिक स्वास्थ्य के खिलाफ खड़ी हुई है?

  • सेना के माहौल में तो इसके उलट, ऐसी स्थिति को सक्रिय रूप से रोकने की कोशिश की जाती है
    मानसिक स्वास्थ्य समस्याओं वाले 18–20 साल के बहुत से बच्चे होते हैं, और उन्हें बहुत आसानी से छुट्टी दे देना अक्सर मददगार नहीं होता। विशेषज्ञ उन्हें घर पर शराब पीने और सिर्फ games खेलने देने के बजाय काम में लगे रखने की कोशिश करते हैं
    कुछ बच्चों ने काम का stress बढ़ने पर उल्टा बेहतर response दिया। training camp की तरह, मेहनत से काम करो और थककर घर जाओ तो नींद आ जाती है; लेकिन अगर बिना थके घर भेजो तो बात शराब और देर रात gaming तक पहुँचती है, और अगले दिन वे zombie की तरह काम पर आते हैं
    यह तरीका सबके लिए काम नहीं करता, लेकिन हमें यह स्वीकार करना चाहिए कि हम जरूरी नहीं कि अपने लिए सबसे अच्छे therapist हों। ज्यादा छुट्टियाँ मिलने पर कई लोगों में negative behavior बढ़ जाता है
    बेहतर जवाब “मुझे एक दिन आराम चाहिए” नहीं, बल्कि “कल 08:00 बजे मेरी counseling appointment है” के ज्यादा करीब है
  • medical field से आए व्यक्ति के रूप में देखें तो software engineers सचमुच अच्छी स्थिति में हैं। जो मिला है उसकी कद्र करनी चाहिए
    खराब management, अवास्तविक schedules, और boring projects को लेकर व्यक्तिगत अनुभवों को मैं मानता हूँ, लेकिन ऐसी चीजें हर जगह होती हैं
    इसके साथ यह जोड़कर देखिए कि आपको रोज मरीजों और उनके परिवारों के साथ उनके जीवन के सबसे बुरे दिन में मौजूद रहना है, high-pressure decisions लेने हैं, और पूरी shift में बैठने या bathroom जाने का मौका भी मुश्किल से मिलता है
    ऊपर से किसी दिन आपका performance अच्छा न होना लंबी-चौड़ी investigation या court case में बदल सकता है
    यह असंवेदनशील लग सकता है, लेकिन software engineering उतनी जटिल या stressful नहीं है जितनी कई medical professions हैं। यह मानसिक और शारीरिक, दोनों तरह से कम थकाने वाली है
  • मुझे नहीं लगता कि software engineering, वकील होने की तुलना में मानसिक स्वास्थ्य के लिए कम नुकसानदेह है
    मैंने लगभग 10 साल वकीलों के साथ काम करते हुए non-engineering professional services दी हैं, और software engineering व startup का भी दशकों का अनुभव है
    software engineering का pressure, legal environment में झेले गए pressure से बिल्कुल अलग और कहीं ज्यादा खराब था
    आम तौर पर वकील manager से ज्यादा वकील ही होते हैं। junior associate से top partner तक hierarchy होती है, लेकिन ऊपर-नीचे सभी वकील होते हैं। यह उस structure जैसा नहीं है जहाँ कोई वकील किसी manager के नीचे काम करता हो
    legal environment में भी pressure और लंबे working hours होते हैं, और जीवनसाथी शिकायत करते हैं कि वकील हमेशा office में रहते हैं या घर पर भी ध्यान कहीं और होता है, लेकिन वहाँ मुझे anxiety attacks या mental health issues नहीं हुए; software और startup environment में हुए
    legal side में सबको प्रक्रिया पता होती है और वे वही प्रक्रिया निभाते हैं, और boss भी वह प्रक्रिया कर चुका होता है
    software में अक्सर उस प्रक्रिया की समझ नहीं होती, और किसी ऐसे व्यक्ति को खुश करने के लिए लगातार पिसते रहना आसान है जो खुद कभी नहीं पिसा। जिस successful listed company में मैं पहले काम करता था, वहाँ ठीक इसी वजह से senior software engineer की job posting हमेशा खुली रहती थी
  • बहुत से लोग नहीं जानते कि manager से सिर्फ इतना कहना काफी है कि वे health/medical कारणों से leave ले रहे हैं, और यह बताने की जरूरत नहीं कि वजह flu है, back problem है या mental health
    अगर स्कूल में employment से जुड़े बुनियादी कानून पढ़ाए जाएँ तो बहुत लोगों को मदद मिलेगी
  • यह क्यों मायने रखता है कि किसने कहा software engineering ज्यादा कठिन है?
    चाहे आपने गंदगी पर पैर रखा हो या घुटनों तक धँस गए हों, आखिर आप गंदगी में ही हैं। किस पर ज्यादा लगा है यह मुकाबला करने के बजाय, क्या एक-दूसरे को साफ करने में मदद करना बेहतर नहीं होगा?
    तुलना बंद करनी चाहिए। अभी कोई triage वाली स्थिति नहीं है, और जो लोग औसतन बेहतर स्थिति में हैं उनके लिए भी हम सहानुभूति या empathy रख सकते हैं। हम सब इंसान हैं, और साथ रहें तो फायदा होता है

• पहले युवा college dropout CEOs के लिए कुछ हद तक awe था, लेकिन कुछ लोगों के नीचे काम करने के बाद मैंने तय किया कि जहाँ 20s के लोग शीर्ष पर हों ऐसे startups में काम नहीं करूँगा
  वे सचमुच management या leadership नहीं जानते। वे failure के डर से driven होते हैं, और अभी कुछ हासिल न करने के कारण दूसरों के साथ कचरे जैसा बर्ताव करते हैं। उनसे बचना बेहतर है

  • Stanford में जाकर किसी 21 साल के व्यक्ति से यह कहना कि तुम Jesus Christ हो और उसे लाखों dollars देने की पेशकश करना, अमेरिकी business culture का फोड़ा है, corporate raiders जितना ही
    यह college football/basketball recruiting का विचित्र version है
  • मुझे नहीं लगता कि कोई वजह है कि 25 साल का व्यक्ति शानदार startup CEO नहीं बन सकता
    मुश्किल मूल बात यह है कि 25 साल का व्यक्ति भले ही कुल मिलाकर smart हो, असाधारण self-awareness और humility रखता हो, और बड़ी समस्या पर काम कर रहा हो, फिर भी यह जानना कठिन है कि कब team या advisors की सुननी है और किसकी सुननी है, और कब अपने judgment के अनुसार उल्टा जाना है
    अगर उसमें सारी अच्छी qualities हों और अच्छी team व advisors का exposure मिले, तो कुछ हद तक संभव हो सकता है
    लेकिन यह मदद नहीं करता कि कई fields खराब practices और advice, तथा खुले deception और manipulation से भरी हैं। जब मैं पुराने PG essays पढ़ता था, तब उम्मीद की जा सकती थी कि एक fellow technologist और entrepreneur smart और नेकनीयत सलाह देकर आपकी सफलता चाहेगा, लेकिन अब यह बिल्कुल standard नहीं है
    आज जहाँ भी देखें, खराब सलाह मिलने की संभावना कहीं ज्यादा है, और individuals व institutions द्वारा manipulate करने की कोशिशें भी ज्यादा हैं। अगर आप खुद filter कर भी लें, तो उन smart और decent लोगों के जरिए second-hand प्रभाव भी आ जाता है जिन्हें आपने प्रभावित होने दिया
  • जो व्यक्ति दूसरों के साथ कचरे जैसा बर्ताव करता है, उसके लिए awe रखने की जरूरत नहीं, चाहे वह 20 साल का हो या 60 साल का
    मैं अभी-अभी 49 साल के founder/CEO के साथ अनुभव से निकला हूँ, और आगे से शायद हर तरह के घटिया संकेत ढूँढूँगा
  • युवा middle managers में भी कुछ सचमुच परेशान करने वाले लोग मिले। बहुत युवा भी नहीं, late 20s से early 30s के असुरक्षित workaholics सबकी जिंदगी खराब कर देते हैं
    वे promotion पाने के लिए पागलों की तरह काम करते थे, और अब सोचते हैं कि अपनी जैसी लोगों से team भर सकते हैं
    लेकिन ऐसा नहीं है। वे “उन जैसे लोग” या तो अपनी health खराब न करने जितने समझदार थे, या ऐसा करना नहीं चाहते थे, इसलिए promote नहीं हुए
    बधाई हो कि आपने बेहतर किया और ज्यादा पैसा व authority भी पाई, लेकिन अब सबको चादर हटाकर उस bed पर लेटना होगा जिस पर crumbs आपने गिराए हैं
  • सिद्धांत में तो सही है, लेकिन क्या वास्तव में भी ऐसा है? क्या Amazon और Oracle, Facebook और Stripe की तुलना में काम करने के लिए बेहतर जगहें हैं?

• किसी मोड़ के बाद बस एक queue बनानी पड़ती है, और फिर अगला सबसे ऊंची priority वाला काम शुरू करना पड़ता है
  अगर बहुत सारे काम साथ-साथ चल रहे हों तो बात बिगड़ जाती है

  • इसलिए Kanban मेरी पसंदीदा project management methodologies में से एक है
    “यह नया top-priority feature है। थोड़ा explore करने पर लगता है कि इस काम को 20 sticky notes में व्यक्त किया जा सकता है। हमारी टीम की पिछली throughput 2 हफ्तों में 10 sticky notes रही है। इसलिए अगर हम मौजूदा सारे in-progress काम उतार दें, तो शायद यह 4 हफ्ते बाद पूरा होगा। कृपया हर मौजूदा sticky note देखकर पक्का करें कि क्या उसे सच में रोकना ठीक है”
    stakeholders फिर भी निर्णय ले सकते हैं, लेकिन इसका असर यह होता है कि वे टीम से क्या मांग रहे हैं, इसका यथार्थवादी अंदाज़ा उन्हें हो जाता है
  • कुछ साल पहले मैं एक कंपनी में engineering director था और product के एक बड़े नए version की तैयारी कर रहा था
    कुछ हफ्तों बाद मैंने CEO से कहा कि मुझे लगता है कि अब हमें नई release के scope और कठिनाई की काफी अच्छी समझ हो गई है, तो CEO ने कहा, “नहीं, तुम्हें नहीं है”
    कारण पूछा तो कहा कि weekend में उनके दिमाग में एक नया “must-have” feature आया है, और वह साफ तौर पर technically बहुत कठिन था। फिर उन्होंने दावा किया कि कुछ भी 48 घंटे में बनाया जा सकता है
    हैरानी है कि मैं उस नौकरी में इतना लंबे समय तक टिका रहा
  • manager के तौर पर, ऊपर से priority बदल भी जाए, अगर मौजूदा काम लगभग खत्म है तो मैं उसे बस खत्म कर देता हूं
    बाद में जब वे मूल काम पर लौटते हैं तो हमेशा हैरान होते हैं कि वह पहले ही पूरा हो चुका है
  • मेरी पिछली नौकरी बिल्कुल ऐसी ही थी, और जो कोई ऐसी position में जरूरत से ज्यादा लंबे समय तक रहता है, उसे कोई दूसरा role तलाशना चाहिए
    आखिरकार यह burnout या उदासीनता की राह है
    उस समय मैं X-Files बहुत देखता था, इसलिए इसे “monster of the week” कहता था, और आज भी मुझे यह expression पसंद है
  • business से deal करने वाले developer के लिए सबसे शक्तिशाली skills में से एक है ना कह पाने की क्षमता

• बहुत थोड़े समय के लिए भी अपने काम से अलग हो पाने की क्षमता सच में जरूरी है
  टहल लें, coffee बना लें, या बस आंखें बंद करके सांस लें
  तनाव अक्सर कृत्रिम रूप से बनाया जाता है, performance को नुकसान पहुंचाता है और सोचने की क्षमता भी घटाता है
  कई बार ऐसी स्थितियां देखी हैं जहां कंपनी कोई contract या revenue जीत सकती है, इसलिए काम “urgent” हो जाता है, और अगर यह “crunch” निकाल लिया तो सब superstar बन जाएंगे
  2 महीने तक रातें काटकर और 3–4 घंटे की नींद पर project जल्दी deliver कर दें, तो management और decision-makers ऐसी “gift” जैसी crunch लगातार देते हुए सुन्न होने लगते हैं
  कंपनी की मदद करना और extra mile जाना हममें से ज्यादातर ने किया है और आगे भी कर सकते हैं, लेकिन अगर हर चीज urgent है और हर task अभी तुरंत करना है, तो कोई बड़ी समस्या है
  पैसे, समय और मेहनत की आम तौर पर सीमाएं और budgets होते हैं। उन सीमाओं और allowances का दुरुपयोग करेंगे तो लोग “भेड़िया आया” चिल्लाने वाले व्यक्ति का सम्मान करना छोड़ देंगे, और काम में भी कम मेहनत लगाएंगे

  • मेरे career में ऐसी चीजें कभी reward बनकर वापस नहीं आईं
    हर बार जब “यह deliver कर दिया तो बहुत बड़ा contract पक्का” जैसे नाटकीय urgent काम के लिए crunch किया, अंत में contract fail ही हुआ
    sales वाला किसी लंबे दांव पर पूरी R&D organization को महीनों तक घुमाकर लोगों को जला दे, फिर भी लगता नहीं कि उसे निकाला जाता है
    जाहिर है वह sales वाला भी उस पूरे समय हफ्तों तक overtime नहीं कर रहा होता
    अब मैं overtime लगभग मना कर देता हूं, सिवाय इसके कि अपनी गलती सुधारने के लिए extra काम करना हो। किसी और बेवकूफ की unrealistic deadline पूरी करने के लिए फिर कभी ज्यादा काम नहीं करूंगा
  • यह सीखने के लिए सबसे कठिन सबक है
    कभी-कभी company, product, customer के लिए “सही तरीके से” करने का मौका नहीं मिलता। आखिर में आज सबसे जरूरी क्या है, यह पूछकर वही काम करना, और काम खत्म होने पर पूरी तरह घर लौट जाना पड़ता है
    अर्थ और निजी संतुष्टि निजी जीवन में खोजनी चाहिए। exercise करें, volunteering करें, hobby रखें, या family पर ध्यान दें
    work-life balance पाने का सबसे अच्छा तरीका दोनों को अलग करना है। इसलिए work from home पसंद न करने की एक वजह यह भी है। office आना-जाना मेरे लिए शानदार separation mechanism और decompression tool है

• यह कहना सही नहीं कि “mental तौर पर कठिन लग रहा है, इसलिए एक दिन आराम करूंगा” कहकर sick leave नहीं ले सकते
  आप कह सकते हैं कि आपको mental health day चाहिए, और बड़े लोग समझते हैं

  • जिन ज्यादातर companies में मैंने काम किया, वहां “आज तबीयत ठीक नहीं है, एक दिन छुट्टी लूंगा” काफी था
    किसी ने details नहीं पूछीं
  • “बड़े लोग समझते हैं” कहना काफी bubble के अंदर का experience है
    ज्यादातर jobs में ऐसा नहीं होता
  • जहां आप काम करते हैं वहां ऐसा हो सकता है, लेकिन मैं तो बस कहता हूं कि मैं office नहीं आऊंगा
    अपने lead या boss से ऐसा कहूं तो वे पूछताछ करेंगे कि क्यों नहीं आ रहे
  • इसी वजह से wellness day भी इस्तेमाल कर सकते हैं

• मुझे यकीन होने लगा है कि software development की practice में ही कुछ ऐसा है जो mental illness पैदा करता है या कर सकता है
  दशकों में मैंने कुछ colleagues को बहुत गंभीर समस्याओं से गुजरते देखा है, और मुझे लगता है कि हमारी industry में यह सच में काफी गंभीर समस्या है

  • software engineering शायद neurodiversity वाले लोगों को आकर्षित करती है
    मैं ADHD वाला software engineer हूं, और असामान्य रूप से बहुत सारे ADHD software engineers को जानता हूं
    उस स्तर का executive function dysfunction और “catch up” करना समस्या बन जाता है
  • बेहतर महसूस करने के लिए जीत का अनुभव या किसी अंत वाला project चाहिए
    लेकिन कई projects साल-दर-साल अंतहीन चलते रहते हैं, जब तक company या व्यक्ति की ऊर्जा खत्म न हो जाए, या वह किसी दूसरी company में जाकर वही चीज दोहराने न लगे
    web development में launch date सबसे नजदीकी finish line है, लेकिन असली finish line नहीं। core metrics target हासिल करना भी कुछ हद तक ऐसा है, लेकिन table या pottery पूरी करने, या crop काटकर बेचने या dinner में परोसने जितना psychologically satisfying नहीं है
  • यह industry मूल रूप से conscious thought को capital में बदलने का काम जितनी efficiency से संभव हो, उतनी efficiency से करती है
    इसलिए इसका mind के लिए खराब होना समझ में आता है
  • stress का बड़ा हिस्सा इस जिम्मेदारी से आता है कि उस “कुछ” को काम करना ही है, जबकि colleagues की सनक, foresight की कमी, और खराब planning के कारण उस “कुछ” की परिभाषा अचानक बदल सकती है
  • आखिरकार हमारा ज्यादातर काम writing ही है
    देख लें कि दूसरे writers कितनी अच्छी तरह adjust करके जीते हैं। खासकर वे, जिन्हें rent की वजह से बहुत समय तक ऐसी writing करनी पड़ती है जिसे वे जानते हैं कि बेकार है

• 2017 में अपने आसपास की सारी uncertainty को control करने की कोशिश का वर्णन ऐसा लगता है जैसे किसी घटिया company के nightmare workplace में टिके रहने की कोशिश करते हुए खुद को ही दोष देना

• ऐसे व्यक्ति को leadership position में होना ही नहीं चाहिए था
  मैंने ऐसे type के व्यक्ति के under काम किया है; वे खुद एक बेहतरीन engineer थे, लेकिन lead के तौर पर बेहद खराब थे
  वे team पर भरोसा नहीं करते थे, हमेशा खुद ही सब संभालते थे, कोई चर्चा नहीं होती थी, back-channel से बातें करते थे, और management की इच्छा के आगे हमेशा झुक जाते थे। हर चीज़ “important” या “critical” होती थी, और यह सबसे खराब तरह की micromanaging थी
  साथ ही, अगर मुझे भी उस position में रखा जाता तो शायद मैं भी, भले कम हद तक, इसी तरह fail होता। Management अक्सर हमें असंभव स्थिति में धकेल देता है, बिना किसी अच्छे कारण के—सिवाय “X को impress करने” के
  अगर यह किसी नामहीन middle executive के सामने points score करने के लिए हो, तो और भी बुरा है
  इसलिए मुझे लगता है कि tech industry में union होना अच्छा होगा। इससे realistic expectations तय की जा सकती हैं और management के सामने collective perspective के साथ बात की जा सकती है
  अफसोस की बात है कि आजकल companies का लक्ष्य सिर्फ quick exit और IPO के जरिए venture capital वापस निकालना होता है। गिद्धों के बीच आम भावना शायद यही है कि union quick exit की संभावना कम कर देती है

  • यह organization की failure है
    क्योंकि organization ने किसी को leader के तौर पर train किए बिना ही promote कर दिया
    जब non-technical background वाले manager से यह उम्मीद नहीं की जाती कि वे बस coding शुरू कर दें, तो coder से यह उम्मीद क्यों की जाती है कि वे बस management शुरू कर दें?
  • “Team पर भरोसा नहीं करना और हमेशा खुद करना” मेरे लिए सीखने वाले सबसे कठिन lessons में से एक था
    संभावित leaders को coach करते समय भी यह अक्सर एक बाधा बनता है
    Leader role में जाने पर यह सीखना पड़ता है कि लोग काम उस तरीके से न करें जैसा मैं करता, तब भी ठीक है
    अगर subordinate का result लगभग पर्याप्त या पर्याप्त रूप से अच्छा है, तो उसे accept करना चाहिए। और उस “पर्याप्त” की acceptable range, सीखने से पहले जितनी लगती है उससे कहीं ज्यादा बड़ी होगी
  • मेरा भी ऐसा boss रहा है
    हो सकता है company खास तौर पर dysfunctional रही हो, लेकिन मुझे जो project और tasks दिए गए थे, उनका मुझे ज्यादा experience नहीं था और मैंने इसे छिपाया भी नहीं
    लेकिन जब मैं खुद समझने में समय लगाता, तो boss बस खुद ही कर देते और कोई feedback नहीं देते
  • “उसे कभी leader बनना ही नहीं चाहिए था” कहना बहुत ज्यादा oversimplification है
    असल में शायद उसे prioritization, delegation और emotional intelligence पर concrete training की जरूरत थी
    ऐसी training rarely दी जाती है। इसके बजाय high performers को गहरे पानी में फेंक दिया जाता है और देखा जाता है कि वे टिक पाते हैं या नहीं
  • “हमेशा खुद करना” leadership role के सबसे counterintuitive हिस्सों में से एक है
    आम तौर पर लोग individual contributor role में बहुत-सा काम खुद करके दिखाते हैं, इसलिए promote होते हैं। लेकिन leader बनने के बाद, जितना कम वे खुद करते हैं, उतना ही उनके लिए, company के लिए और team members के लिए बेहतर होता है
    इसलिए यह सीखना पड़ता है कि पहले की तुलना में खाली महसूस होना इस बात का संकेत नहीं है कि आप काम ठीक से नहीं कर रहे हैं

• यह संभव है कि team से “मानसिक रूप से मुश्किल लग रहा है, इसलिए एक दिन की छुट्टी लूंगा” कहकर sick leave नहीं ली जा सकती
  मैंने कुछ साल पहले से ऐसा करना शुरू किया था और कुल मिलाकर यह positive experience रहा। क्योंकि मैंने पहले अपनी struggles खुलकर बताईं, team के दूसरे लोगों ने भी अपनी परेशानियों के बारे में बताया