काम पर कुछ भी न करना
(seangoedecke.com)- सॉफ़्टवेयर इंजीनियर की performance ज़्यादा समय या ज़्यादा code से नहीं, बल्कि सही समय पर किए गए high-impact काम से तय होती है; इसलिए सामान्य दिनों में लगभग 80% utilization, यानी दिन के करीब 20% समय कंप्यूटर से दूर बिताना, प्रभावी हो सकता है
- बड़े engineering organizations में बड़े contract support, incident mitigation, या major feature launch जैसे समय-निर्भर अवसर बहुत बड़ा मूल्य बना सकते हैं, और अगर आप पहले से ही व्यस्त हों तो ऐसे मौके आसानी से छूट जाते हैं
- अगर आप लगातार low-priority tickets निपटाते रहते हैं, तो दूसरे teams की स्थिति, team updates, और चल रहे incidents पर नज़र नहीं रख पाते, और manager के लिए भी आपको उपलब्ध व्यक्ति मानना मुश्किल हो जाता है
- कुछ न करने का समय stress recovery, incident response के दौरान शांत बने रहने, नए ideas, और महत्वपूर्ण काम पर focus बनाए रखने में मदद करता है
- सामान्य समय में जानबूझकर कुछ क्षमता खाली रखना, और केवल बहुत बड़े reward वाले समय पर ही 100% intensity से काम करना, high-performing engineer बनने के लिए बेहतर स्थिति बनाता है
high-impact अवसर
- बहुत से engineers को कम काम करना चाहिए; इसका मतलब code या changes कम करना नहीं, बल्कि दिन में वास्तव में काम करने का समय कम करना और काम करते समय भी थोड़ी धीमी गति से काम करना है
- default state में 80% utilization लक्ष्य होना चाहिए, और जब कोई high-pressure project न हो तो काम के समय का 20% कंप्यूटर से दूर बिताना चाहिए
- tech companies के परिणाम अक्सर असामान्य घटनाओं से बहुत प्रभावित होते हैं, और कई सबसे असरदार changes आश्चर्यजनक रूप से बहुत कम काम में किए जा सकते हैं
- software development में केवल मेहनत के लिए कोई अंक नहीं मिलते; असली बात है सही समय पर सही समस्या को हल करना
-
बड़े संगठन में संभव तीन उदाहरण
- जब कोई बड़ा enterprise contract finalize होने वाला हो, उस समय feature या bug fix में मदद करना contract बंद होने में सहायक हो सकता है
- feature का पूरी तरह शानदार होना ज़रूरी नहीं; कभी-कभी केवल specific change करने की इच्छा और क्षमता दिखाना ही काफी होता है
- incident को शुरुआत में रोक देना या कम करना, incident के दौरान होने वाले तुरंत revenue loss और बाद में customer churn या contract reject होने से होने वाले revenue loss, दोनों को घटा सकता है
- सिर्फ यह जानना कि कौन-सा feature flag बंद करना है, बहुत बड़ी रकम बचा सकता है
- जब company कोई महत्वपूर्ण feature launch करना चाहती है, तब सफलता और विफलता किसी छोटे लेकिन ढूँढने में कठिन change पर निर्भर हो सकती है
- जैसे user settings में जल्दी से कोई नया field जोड़ना, या कई वर्षों से छुआ न गया पुराना enterprise data export feature ठीक करना
- system familiarity यह अंतर बना सकती है कि कोई बदलाव कुछ घंटों में होगा या एक हफ्ता लेगा
-
समय-निर्भरता
- ये सारे अवसर समय-निर्भर होते हैं; सुबह login करके आप मनमाने ढंग से कोई बड़ा contract नहीं जीत सकते, incident mitigate नहीं कर सकते, या कोई major feature जल्दी से नहीं बना सकते
- सिर्फ सही जगह और सही समय पर होना काफी नहीं; आपका पहले से व्यस्त न होना भी ज़रूरी है
अपने आप को हल्का व्यस्त रखना
- अगर आप low-priority काम लगातार करते हुए खुद को 100% utilized रखते हैं, तो high-impact काम के मौके दो तरीकों से चूक जाते हैं
- पहला, बहुत व्यस्त होने पर आपको मौका दिखता ही नहीं
- दूसरे लोग क्या कर रहे हैं, उनसे बात करने, team updates पढ़ने, या चल रहे incidents देखने का समय कम हो जाता है
- high-impact काम में शामिल होने का सबसे अच्छा तरीका है अपनी expertise खुद offer करना
- दूसरा, अगर आप हमेशा व्यस्त दिखते हैं, तो manager के लिए आपको उसमें शामिल करना कठिन हो जाता है
- manager या product manager अगर यह समझें कि “यह व्यक्ति यहाँ मदद कर सकता है”, तो यह शामिल होने का दूसरा सबसे अच्छा रास्ता है
- manager और product manager अक्सर उन meetings में होते हैं जिनमें engineers नहीं होते, इसलिए उन्हें चल रहे high-impact कामों की बेहतर जानकारी होती है
कुछ भी न करना
- अगर high-impact काम के लिए समय खाली रखना है और केवल tickets निपटाते नहीं रहना, तो मिनट-दर-मिनट स्तर पर सचमुच कुछ भी न करना भी ठीक है
- software engineering एक high-stress पेशा हो सकता है, लेकिन यह आमतौर पर लगातार high-stress पेशा नहीं होता
- stress कभी-कभार होने वाले incidents, urgent high-pressure काम, या हाल की layoffs जैसी स्थितियों में आता है
- अगर अपेक्षाकृत कम दबाव वाले काम को भी आप हमेशा urgency के साथ करते हैं, तो जब सच में high-pressure स्थिति आएगी तब तक आप पहले से थके और चिड़चिड़े हो चुके होंगे
- high-pressure काम के दौरान भी कुछ न करने वाला रवैया मददगार हो सकता है
- जो engineers on-call के आदी नहीं हैं, उनके लिए बेहतर है कि जल्दबाज़ी न करें, call में जाने से पहले या बोलने से पहले कुछ गहरी साँस लें
- incident response में कुल मिलाकर “धीमी चाल में सोचना” ज़रूरी है
- ज़्यादातर incidents अपने आप सुलझ जाते हैं, और incident के दौरान जल्दी में डाला गया “शायद मदद करे” वाला change अक्सर स्थिति को बेहतर करने के बजाय और खराब कर देता है
- सामान्य रूप से, अगर आप panic से बच जाते हैं, तो incident response में आप पहले ही अधिकांश engineers से बेहतर काम कर रहे होते हैं
- कुछ न करने का समय, चीज़ों के होने के लिए जगह बनाता है
- जब दिमाग को आराम मिलता है, तो नए ideas आने की संभावना बढ़ जाती है
- जब कोई महत्वपूर्ण काम मिलता है, तो आप पीछे चल रही तीन दूसरी चीज़ों को साथ-साथ संभालने के बजाय उस पर पूरा focus दे सकते हैं
- जब आप व्यस्त नहीं होते, तो बस चीज़ों को देखने और नई जानकारी ग्रहण करने का समय मिलता है
जानबूझकर कुछ काम न करना
- बहुत से engineers के लिए यह असहज होता है कि करने योग्य काम दिख रहा है, फिर भी वे उसे न करें
- यह प्रवृत्ति बहुत से software engineers में पाई जाने वाली मनोवैज्ञानिक विशेषता है, और कुछ हद तक यही बात उन्हें इस काम के लिए उपयुक्त भी बनाती है
- कुछ न करने का समय बनाने के लिए कभी-कभी खुद को जानबूझकर बीच में न कूदने के लिए मजबूर करना पड़ता है
-
glue work से बचना
- engineers को सामान्य रूप से glue work से बचना चाहिए
- glue work में लोगों को आपस में बात करवाना, ऐसे काम की documentation update करना जिसे आप lead नहीं कर रहे, या technical debt के समाधान के लिए resources ढूँढना जैसी चीज़ें आती हैं
- ज़्यादातर glue work इस बात को दिखाता है कि organization ने उस काम को स्पष्ट priority नहीं बनाया है
- अगर organization ने उसे priority बनाया होता, तो किसी व्यक्ति को स्वयंसेवा करने की ज़रूरत नहीं पड़ती
- अगर organization ने उसे priority नहीं बनाया और वह वास्तव में ठीक बात है, तो उसे अपने ऊपर लेना समय की बर्बादी है और manager को परेशान भी कर सकता है
- अगर organization ने उसे priority नहीं बनाया और यह वास्तव में बड़ी गलती है, तब भी अगर कोई व्यक्ति उसे अपने दम पर ठीक करता है, तो company अपनी गलती के परिणाम भुगतने से बच जाती है और उसकी कीमत उस व्यक्ति के career और mental well-being को चुकानी पड़ती है
- यह उस व्यक्ति के लिए भी खराब सौदा है, junior colleagues के लिए भी खराब उदाहरण है, और burnout के बाद किसी और को वही भूमिका देने की खराब मिसाल बनाता है
- अगर परिणाम सचमुच गंभीर हैं, तो बेहतर है कि organization वह दर्द महसूस करे ताकि वह अपनी policy बदले
-
ज़रूरत से ज़्यादा मदद करना आपको असुरक्षित बनाता है
- बहुत ज़्यादा helpful बनने की प्रवृत्ति आपको उन लोगों के लिए uncompensated labor का आसान लक्ष्य बना देती है जो बिना reward के काम निकलवाना चाहते हैं
- tech companies में ऐसे बहुत लोग होते हैं जो software engineers से ऐसा काम करवाना चाहते हैं जिसका भुगतान नहीं होता
- यह उस काम से अलग है जो normal process से आता है और जिसका reward promotion, bonus, या सामान्य salary के रूप में मिलता है
- समस्या वाले काम अक्सर informal channels से आते हैं, और ऐसे लोगों से आते हैं जिनके पास उस काम को आधिकारिक रूप से आपके नाम पर दर्ज कराने की क्षमता या इच्छा नहीं होती
- उदाहरण के लिए, किसी दूसरे organization का product manager आपसे कहे कि आप data queries अच्छे करते हैं, इसलिए उसके लिए कोई खास statistic निकाल दें
- या किसी दूसरी team का engineer pair work माँगे, लेकिन वास्तव में आपसे सारा code लिखवा ले और change अपने नाम से submit कर दे
- इस तरह का कुछ काम करना ठीक है; जब संभव हो तो लोगों की मदद की जा सकती है
- लेकिन आपको pushback देना भी आना चाहिए, चाहे वह मना करके हो या कुछ घंटे या कुछ दिन बाद जवाब देकर
-
ऐसे काम में ज़्यादा निवेश न करें जो शायद गायब हो जाए
- ऐसे काम में बहुत ज़्यादा निवेश नहीं करना चाहिए जो शायद बाद में खत्म हो जाए
- अगर कोई product designer real time में अपनी इच्छा बदल रहा है, तो हर घंटे पूरा page फिर से नहीं लिखना चाहिए
- जैसे सुबह 9 बजे page header एक तरह चाहिए, 10 बजे बदलना है, और 11 बजे फिर से बदलना है
- ऐसे में बेहतर है कि आप टहलने चले जाएँ या कुछ न करें, और फिर दोपहर में सबसे नए design के आधार पर एक बार page दोबारा लिखें
- कम political momentum वाले manager के बड़े ideas भी इसका सामान्य उदाहरण हैं
- अक्सर आप समय को बस बीतने दे सकते हैं, जब तक project cancel न हो जाए
- हालाँकि अगर आप project के राजनीतिक support का गलत आकलन कर लें, तो आप आलसी दिख सकते हैं और फिर जल्दबाज़ी में नतीजा देना पड़ सकता है
निष्कर्ष
- software engineering की सलाह और tools अक्सर इस क्षमता पर केंद्रित होते हैं कि आप एक साथ ज़्यादा काम करें, बड़े दायरे के projects लें, और ज़्यादा code लिखें
- software engineering में सफलता उन बातों से तय नहीं होती
- सफलता इस क्षमता से तय होती है कि आप सही काम को सही समय पर करें, और इसके लिए रोज़मर्रा के काम में जानबूझकर कुछ effort बचाकर रखना पड़ता है
- 80% effort पर भी high-performing engineer बनना संभव है; बल्कि इससे stress से होने वाली मूर्खतापूर्ण गलतियाँ कम होती हैं और बड़े लाभ वाले high-impact काम में कूदना आसान हो जाता है
- ऐसे समय भी आते हैं जब 100% effort से काम करना चाहिए; साल में दो-तीन बार आप लंबे समय तक, गहरे focus के साथ, और पूरे दिन समस्या के बारे में सोचते हुए काम कर सकते हैं
- लेकिन इस तरह के काम करने का तरीका उन मौकों के लिए बचाकर रखना बेहतर है जहाँ reward सचमुच बड़ा हो, और बाकी समय अपेक्षाकृत आराम से काम करना बेहतर है
1 टिप्पणियां
Hacker News की राय
अच्छा लेख है, लेकिन आखिरकार फिर वही incentives समस्या बनकर सामने आते हैं
यह बात सही है कि अगर किसी समस्या को जल्दी रोक दिया जाए या उसका असर कम कर दिया जाए, तो बहुत सारा पैसा बच सकता है, लेकिन कई कंपनियों में बार-बार मैंने यही देखा है कि समस्या-रोकथाम को पहचान नहीं मिलती, जबकि पहले ढेर सारा ज्वलनशील सामान जमा करके फिर होने वाली आग बुझाने पर दो बार सराहना मिलती है। यह तथाकथित “अच्छी” संस्थाओं में भी सच था
जानबूझकर घटिया code जल्दी ship करके उसका श्रेय लेने वाली game-theory वाली राजनीति में मैं कभी पूरी तरह शामिल नहीं हो पाया। क्योंकि मुझे अपने काम पर बहुत ज़्यादा गर्व था
मैंने 5 साल से अधिक समय तक एक framework को संभाला और बढ़ाया, जिसका मकसद पिछले product version को परेशान करने वाली समस्याओं के पूरे समूह को खत्म करना था, लेकिन एक partner team जिसने घटिया code deploy करके outage पैदा किया और फिर उसे ठीक किया, उसे सार्वजनिक रूप से सराहा गया, जबकि हमारी team को इसलिए कोई श्रेय नहीं मिला क्योंकि हमारे यहाँ ऐसी outage हुई ही नहीं। क्योंकि यह मापा न जा सकने वाला prevention है
Thread.sleep(100000)डाल दो और फिर टूटने का इंतज़ार करो। उसके बाद release के बाद शुक्रवार आधी रात तक लंबी और बहादुरी भरी firefighting करने वाले इंसान बन जाओयह मत पूछो कि इसके लिए इनाम क्यों मिलता है, और हाँ, कभी-कभी संगठन इनाम के मानदंड बदल भी देते हैं
एक ईमानदार तरीका यह है कि कुछ जटिल लेकिन ज़रूरी tools बनाए जाएँ, ताकि दूसरे engineers बार-बार मेरे पास आते रहें। इससे मैं किसी खास tool के misuse को अच्छी तरह पहचानने लगता हूँ, और जब मैं कुछ ही सेकंड में दूसरे के code की bug पकड़ लेता हूँ, तो मैं वास्तव में जितना हूँ उससे कहीं ज़्यादा smart दिखता हूँ
आदर्श रूप से, tool भरोसेमंद, उपयोगी, लेकिन जटिल होना चाहिए। दूसरे developers जब उस tool का इस्तेमाल करते हुए bug से टकराएँ, तो वे बार-बार मेरे पास आएँ, और मैं उनकी गलती दिखा सकूँ। इस रणनीति के काम करने के लिए गलती लगभग हमेशा सामने वाले की होनी चाहिए, और मेरा code robust होना चाहिए
अगर मेरे code में सचमुच कोई bug मिल जाए, तो बेहतर होगा कि वह कोई छोटा edge case हो; तब मुझे बहुत विनम्र और खेदपूर्ण होना चाहिए, और team meeting में उस developer की तारीफ करनी चाहिए जिसने वह जटिल bug ढूँढ निकाला
यह अपने ही buggy code को ठीक करके श्रेय लेने से बेहतर है। वह तरीका manager या junior पर चल सकता है, लेकिन दूसरे senior engineers उसे नापसंद करेंगे
जटिल लेकिन स्थिर tools बनाने का तरीका बार-बार, और अक्सर दो बार से कहीं अधिक, पहचान दिलाता है, और दूसरे developers की मान्यता आखिरकार managers के कानों तक पहुँच ही जाती है। समझदार leaders जानते हैं कि यह संकेत चमकदार demo से बेहतर होता है
जो leaders सिर्फ इसलिए तारीफ बाँटते हैं कि कोई developer तेज़ी से prototype बना देता है, वे आखिरकार अपनी गलती सीखते हैं। युवा founders अक्सर इस चरण से गुजरते हैं जहाँ वे सतही चीज़ों की तारीफ करते हैं
product या features के समूह बनाना, उत्कृष्ट engineering जितना ही नहीं बल्कि कभी-कभी उससे अधिक exploration का काम भी होता है। कभी-कभी एक मजबूत feature बनाने से बेहतर यह होता है कि दो “काफी अच्छे” features बनाए जाएँ, ताकि पता चल सके कि users के लिए वास्तव में मूल्यवान क्या है
मैं हमेशा “पहले करके देखते हैं, फिर समझेंगे” वाले पक्ष में रहा हूँ। फिर भी, मेरे अलावा किसी और ने git बनाया, इसके लिए मैं आभारी हूँ
इसमें संतुलन है, और यह इस बात पर निर्भर करता है कि आप अभी जिस समस्या से जूझ रहे हैं वह कितनी exploration समस्या है। यहाँ “मजबूती” का मतलब शुद्ध engineering दृष्टि से availability, maintainability, या users की संवेदनशील photos leak होने की संभावना जैसी चीज़ों से है
“बिना इनाम वाले काम को निचोड़ लेने की कोशिश करने वाले लोग” वाला हिस्सा फ्रेम करवाकर रखने लायक है
खासकर वे हालात, जब किसी दूसरी organization का product manager कहे, “आप data queries अच्छे से कर लेते हैं, क्या X के लिए कुछ stats निकाल देंगे?” या किसी दूसरी team का engineer “pair” माँगे और आखिर में सारा code मैं लिखूँ, फिर वह चुपचाप अपने नाम से change submit कर दे
उसकी strategy थी लोगों की मदद करना और श्रेय सक्रिय रूप से आगे बढ़ा देना। 1:1 में या कई स्तर के managers वाली meetings में वह लगातार अपनी team के लोगों के काम का महत्व उजागर करता था, और इस वजह से उसे team की goodwill मिली
कुछ साल बाद, जब बहुत पैसे वाला एक project schedule से पीछे चल रहा था और कई key engineers नौकरी छोड़ चुके थे, तो उसने देर रात तक काम करके project को सफलता तक पहुँचाया, और अगले review में उसे title और salary increase मिला
वह project आखिरी push ज़रूर बना, लेकिन देर रात तक काम करने वाला अकेला वही engineer नहीं था। वह अपनी promotion का श्रेय अपने tenure के दौरान दूसरों को श्रेय देकर जोड़ी गई goodwill को देता है
मैं उन लोगों के साथ काम करना चाहता हूँ जो समस्या देखते हैं और उसका समाधान सुझाते हैं, चाहे वह उनके job description में हो या नहीं
अगर मेरे काम को पहचान नहीं मिल रही, तो वह leadership problem है। काम को सपाट तरीके से ठुकराना मुझे एक जड़ और धीमी organizational culture की ओर जाने वाला रास्ता लगता है
उसी तरह, किसी दिन मुझे भी किसी colleague से कुछ चाहिए हो सकता है, और उस समय अगर मुझे “formal channel से आइए” कहकर टाल दिया जाए तो उससे बेहतर होगा कि वह सक्रिय रूप से मदद करे। formal channel में कहीं ज़्यादा समय लग सकता है
lunch-table की बातचीत भी लोगों को कुछ समझने में मदद कर सकती है
लेकिन किसी के लिए कई घंटों का काम कर देना एक अलग मामला हो सकता है
यह तंज नहीं बल्कि एक अवलोकन है, लेकिन काफी बड़े या नौकरशाही वाले संगठनों में अगर आप किसी समस्या को पहले ही रोक भी दें, तो उसके लिए श्रेय या visibility पाना मुश्किल होता है. ऐसी उपलब्धियाँ अक्सर “जो वैसे भी किया ही जाना चाहिए” वाली श्रेणी में डाल दी जाती हैं
इसलिए office politics में माहिर लोग कभी-कभी समस्या होने देते हैं, और फिर follow-up action items में बहुत शोर-शराबे के साथ सक्रिय होते हैं. असली तरकीब यह होती है कि समस्या को आपदा न बनने दिया जाए, और यह काफी नाज़ुक काम है
अगर आप किसी sales contract को बचा लेते हैं, तो तालियाँ sales team को मिलती हैं, commission भी वही पाते हैं. मुझे उसका थोड़ा सा हिस्सा भी नहीं मिलता
अगर कुछ चीज़ें जलने दी जाएँ, तो बॉस के बॉस के बॉस को भी वह आग दिखेगी, और शायद सुधार हो सके. शायद उनसे communicate करने का यह सबसे आसान तरीका है
मैंने पहले भी इस दिशा में आधा-अधूरा कुछ लिखा था, जिसमें fantasy RPG की उपमा थी. ऐसे games में जब आप mana इस्तेमाल करने वाला character खेलते हैं, तो जल्दी समझ में आ जाता है कि हर छोटी लड़ाई में सारा mana खर्च कर देना और फिर खाली घूमते रहना, और असली ज़रूरत पड़ने पर कुछ भी न बचना, बुरा विचार है
काम में इस्तेमाल होने वाली मानसिक ऊर्जा भी इससे बहुत अलग नहीं है. अगर टैंक में थोड़ा बचाकर रखो, तो जब कोई अप्रत्याशित चीज़ सामने आए, तब आप अपनी सेहत, यानी burnout, को जोखिम में डाले बिना उसे रणनीतिक तरीके से इस्तेमाल कर सकते हैं
ऐसे games में अगर आप किसी ऐसे player के साथ party बनाते हैं जिसे mana management नहीं आता, तो यह भी समझ में आ जाता है कि वह बहुत अच्छा teammate नहीं है
किसी भी क्षेत्र में मेरी क्षमता का शिखर वह समय था जब मेरे सामने पर्याप्त काम होता था जिसे मैं मशीन की तरह लगातार निपटा सकता था, और लोग मुझ पर इतना भरोसा करते थे कि मैं लक्ष्य की ओर बिना बार-बार समझाते हुए, बिना बाधा के काम कर सकूँ. skills जंगल की आग की तरह बढ़ती थीं और काम उम्मीद से तेज़ पूरा हो जाता था
दुर्भाग्य से, ऐसी संरचना का लाभ उठाने वाली नौकरियाँ बहुत कम हैं. असली deep work में जाने से रोकने वाले अवरोध और interruptions बहुत ज़्यादा होते हैं
अगर आप किसी system को तोड़ना चाहते हैं, तो उसके baseline operation को 100% पर चला दीजिए. तब उसमें कोई slack नहीं बचेगा, नई demand लेने की capacity नहीं होगी, और system में छोटा सा disturbance आते ही वह स्थायी failure mode में चला जाएगा
ऐसी पोस्टों या Peopleware / Slack जैसी किताबों की समस्या यह है कि वे accounting वालों को कोई दूसरा approach आज़माने लायक़ पर्याप्त रूप से भरोसेमंद वास्तविक metrics नहीं देतीं
जिस उपमा ने मेरा नज़रिया बदला, वह “The Power of Full Engagement” की थी. मोटे तौर पर बात यह थी: “तुम एक विश्व-स्तरीय endurance athlete की तरह व्यवहार कर रहे हो जिसका कोई off-season ही नहीं है. यह बंद करो”
इसमें बहुत समझदारी है. सचमुच उच्च-मूल्य वाले काम के आने के लिए कुछ capacity बचाकर रखने के अलावा, मेरा मानना है कि software engineering ऐसा काम नहीं है जो सिर्फ लगातार व्यस्त रहकर अच्छी तरह किया जा सके
अगर आप जितनी जल्दी हो सके code लिखने की कोशिश करें, तो अच्छा design बहुत कम निकलता है. यह बात एक और महत्वपूर्ण पहलू को नहीं छूती: manager से डाँट खाए बिना 80% capacity पर कैसे काम किया जाए
इसके लिए communication और work estimation में थोड़ी सावधानी चाहिए. मेरी पहली असली programming नौकरी में मुझसे उम्र में बड़े अनुभवी developers ने जो अच्छी सलाह दी थी, वह आज तक याद है: किसी काम में कितना समय लगेगा इसका अनुमान लगाओ, और manager या user को बताने से पहले उसे दोगुना कर दो
अनुभव बढ़ने पर यह ratio 2x से घटकर शायद 1.5x हो सकता है, लेकिन सिद्धांत वही रहता है
जिसे optimize करना चाहिए और precedent बनाना चाहिए, वह यह है कि लंबे समय तक लगातार, sustainable pace पर delivery हो. यह लंबी दौड़ है, और overpromising सिर्फ trust को कम करता है. वही trust तो वह सबसे बड़ा साधन है जिससे developers को ज़रूरी space मिलता है
कम वादा करो, जो कहा है उसे पूरा करने की विश्वसनीयता बनाओ, और burnout से बचे रहने की जगह हासिल करो
जितने senior होते जाते हो, खासकर lead बनते हो, boundaries तय करना, अपनी attention बचाकर रखना, और burnout रोकना, यही काम का हिस्सा बन जाता है. क्योंकि अपने आपको तोड़ लेने के बहुत सारे तरीके हैं
Hofstadter's law को ध्यान में रखने पर भी, काम हमेशा उम्मीद से ज़्यादा समय लेता है
https://en.wikipedia.org/wiki/Hofstadter%27s_law
ग्राहक-सामना करने वाले काम बहुत करने के अनुभव से, सबसे बुरा जाल जो मैंने बार-बार देखा है, वह है पैसे देने वाले customer से बहुत घुल-मिल जाना. जब आपको एक expert के रूप में मदद करने के लिए रखा गया हो, और customer सचमुच अच्छा इंसान निकले, तो उसे मना करना पागलपन की हद तक मुश्किल हो जाता है
और उससे भी बुरा तब होता है जब वह decision-maker न होकर खुद किसी दबाव में हो कि मुझ पर कुछ थोपा जाए. एक trusted expert के रूप में जब customer खुद कोई बुरा idea देता है, तब मना करना आसान होता है, लेकिन जब उनका बॉस—जिससे मेरी कभी सीधी बात भी नहीं होती—कोई निर्देश देता है, तब मैं या तो बेकार खर्च जैसा दिखता हूँ, या फिर ऐसा yes-man बन जाता हूँ जो पीछे एक राक्षस छोड़ जाता है
कभी-कभी मुझे उन लोगों से ईर्ष्या होती है जिन्होंने ज़्यादातर internal काम किया है. कम से कम उनके पास ऊपर कहीं किसी को मनाने की संभावना तो होती
ग्लू वर्क वाला हिस्सा दिलचस्प है; जब मैं किसी बड़े enterprise में काम करता था, तब यह annual performance review का एक स्पष्ट हिस्सा था। Google इसे “citizenship” कहता था, और मुझे लगता है कि यह शब्द इसकी असल भावना को अच्छी तरह पकड़ता है। यानी, “आपने कंपनी के बाकी लोगों के लिए क्या बेहतर बनाया?”
एक तरफ यह थोड़ा अजीब था। यह मेरी job description में नहीं था, इसलिए तकनीकी रूप से यह unpaid work था, लेकिन साथ ही यह आधिकारिक expectations का हिस्सा भी था। दूसरी तरफ, ऐसी जगह काम करना अच्छा था जहाँ हर कोई थोड़ा समय और मेहनत लगाकर सबके लिए माहौल बेहतर बनाता था
इसे सभी के लिए एक स्पष्ट requirement बना देने से उस toxic culture को भी bypass करने की कोशिश होती है जिसमें “मैं एक rockstar engineer हूँ, मैं महत्वपूर्ण काम में व्यस्त हूँ, इसलिए ग्लू वर्क कोई और करे” जैसा रवैया रहता है। और वह “कोई और” आम तौर पर एक महिला होती थी, और लगभग तय है कि उसे उस rockstar engineer से कम वेतन मिलता था
मूल लेख यह संकेत देता है कि कंपनी को ग्लू वर्क करने के लिए औपचारिक रूप से किसी को hire करना चाहिए, लेकिन वास्तव में यह इतने विविध हिस्सों से बना होता है कि किसी एक व्यक्ति को रखकर यह सब कराना लगभग असंभव है। उदाहरण के लिए, “documentation, software engineer interviews, team offsite events organize करना” — इन सबको समेटने वाली job title क्या होगी
लेकिन ये सारे काम ज़रूरी थे, और citizenship requirement ने इस बोझ को अधिक न्यायसंगत तरीके से बाँटने में मदद की
मेरे हिसाब से बेहतर वाक्य यह नहीं है कि “ग्लू वर्क मत करो”, बल्कि यह है कि “बिना compensation वाला ग्लू वर्क करने वाले अकेले बेवकूफ़ मत बनो।” यानी, सभी लोग इसका कुछ हिस्सा लें, और ऐसी संस्कृति को बढ़ावा दें जहाँ इसे आधिकारिक रूप से काम के रूप में मान्यता मिले
80% utilization पर काम करना एक अच्छी आदत है, और तब मददगार होता है जब कोई supervisor-style micromanager हर दिन पूरे दिन 100% output की माँग नहीं कर रहा हो। ऐसे लोग अक्सर software engineer को चुपचाप और आराम से सोचते हुए देखकर उसे आलसी निष्क्रियता समझ लेते हैं
इसलिए remote work कुछ utilization reserve में छोड़ने और mental health बचाए रखने का सबसे अच्छा तरीका है
थोड़ा-सा ग्लू वर्क सबकी working life को बहुत बेहतर बना सकता है, और अगर किसी और को यह करना नहीं आता, तो यह टीम में मुझे indispensable या hero बना सकता है
जिस तरह मुझे सीखने, सोचने और शुरुआत करने में संघर्ष होता है, उसे देखते हुए मेरा 80% तकनीकी रूप से अधिक मज़बूत सहकर्मी के 80% जैसा बिल्कुल नहीं है
अगर neurodiversity की प्रवृत्तियों को थोड़ा भी ध्यान में रखें, तो एक व्यक्ति का 80 दूसरे व्यक्ति का 120 हो सकता है