- सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर ऐसा senior archetype है जो मूल रूप से code changes को रोकता है, जटिल features को देर से लाता है, और कोशिश करता है कि जितना संभव हो उतना कम code लिखा जाए
- ZIRP के दौर में कम interest rates और hiring expansion की वजह से productivity loss कम महत्वपूर्ण था, और आक्रामक technical proposals को रोकने वाली यह भूमिका कंपनियों के लिए उपयोगी थी
- interest rates बढ़ने के बाद tech companies ने engineers के 5~20% को lay off किया, और stock price की बजाय revenue पर ज़ोर बढ़ने से “नहीं” कहने वाले इस protective layer की ज़रूरत कम हो गई
- LLM ने AI-generated PR और काफ़ी उपयोगी code के ज़रिए दबाव बढ़ाया, लेकिन असली बदलाव AI नहीं बल्कि ZIRP के अंत से बदले economic incentives हैं
- यह भूमिका पूरी तरह गायब नहीं होगी, लेकिन pure engineering वाले क्षेत्रों में ज़्यादा फिट बैठती है, और 2010s की तुलना में सीमित scope और कम visibility स्वीकार करनी होगी
“सिर्फ़ ‘नहीं हो सकता’ कहने वाले इंजीनियर” की भूमिका
- सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर senior और staff engineers के बीच मौजूद एक archetype है, जिसकी भूमिका feature development को धीमा करना, complexity बढ़ाने वाले changes को रोकना, और जितना हो सके उतना कम code लिखवाना है
- इसके उलट सिर्फ़ ‘हो जाएगा’ कहने वाला इंजीनियर तेज़ी से आगे बढ़ने को प्राथमिकता देता है, code changes को default approval देता है, MTTR को MTBF से ज़्यादा महत्व देता है, और ज़्यादा code deploy करने की प्रवृत्ति रखता है
- ज़्यादातर engineers इन दो अतियों के बीच कहीं होते हैं, लेकिन यहाँ फोकस उन engineers पर है जो “नहीं” कहने वाली भूमिका से बहुत गहराई से अपनी पहचान जोड़ते हैं
- AI युग में सिर्फ़ junior engineers के PR ही नहीं, बल्कि AI-generated code को भी बड़ी मात्रा में reject करना पड़ सकता है, और कभी-कभी manager या VP द्वारा लिखे गए code को राजनीतिक वजहों से reject करना और कठिन हो जाता है
- अपने career में पहली बार इन engineers पर standards कम करने और “हाँ” कहने का दबाव मज़बूती से आ रहा है, लेकिन इसकी मूल वजह AI से ज़्यादा ZIRP का अंत है
ZIRP ने कैसा माहौल बनाया
- ZIRP का मतलब “zero interest rate policy” है, और यह 2008 से 2022 के बीच के उस software development युग को दर्शाता है जब banks कंपनियों को लगभग 0 के आसपास interest rate पर पैसा उधार दे रहे थे
- investors इस उधार के पैसे को लगभग किसी भी चीज़ में लगा रहे थे, और tech companies के पास ऐसे projects के लिए engineers को लगातार hire करते रहने का बड़ा incentive था जिनमें कम risk और high reward की उम्मीद हो
- सफल कंपनियों ने engineers की संख्या दर्जनों से बढ़ाकर हज़ारों तक कर दी, और उन्हें peripheral open source projects, अंतहीन technical migrations, और दूसरी languages में rewrites जैसे काम दिए
- software engineers के लिए यह ऐसा दौर था जब उनकी bargaining power बहुत अधिक थी, और वे लगभग कोई भी काम करके भी ऊँचा compensation पा सकते थे
- management इतनी तेज़ी से बढ़ती teams की details पर ध्यान नहीं दे पा रहा था, और engineers की बढ़ती संख्या अपने-आप में stock price के लिए अच्छी मानी जाती थी, इसलिए कई तरह की गतिविधियों को बड़ा मुद्दा नहीं बनाया जाता था
- लेकिन अगर बहुत सारे engineers को खुली छूट मिल जाए तो system unmanageable हो सकता था, और यहीं सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर कंपनी के लिए उपयोगी बन जाता था
ZIRP के दौर में “नहीं” कहना क्यों मूल्यवान था
- क्योंकि productivity loss कोई बहुत बड़ा मुद्दा नहीं था, इसलिए कंपनी यह भी झेल सकती थी कि उसके आधे engineers changes propose करें और reject होने के loop में फँसे रहें
- इस तरीके का एक असर यह भी था कि engineers business-critical systems को छेड़ने से बचे रहें
- technical freedom के नशे में “चलो handcrafted database पर migrate करते हैं” जैसी आक्रामक proposals देने वाले 5% engineers को नियंत्रित करने में भी यह मददगार था
- बहुत ऊँचे technical standards वाली company की प्रतिष्ठा hiring के लिए सकारात्मक थी, और ZIRP के दौर में लगभग हर tech company हमेशा hiring mode में रहती थी
- “junior बहुत code बनाते हैं, senior थोड़ा कम बनाते हैं, और staff code हटाते हैं” जैसी बात आकर्षक लगती है, क्योंकि इससे लगता है कि experts को लगभग कुछ करना ही नहीं पड़ता, लेकिन यह पूरी तरह सही नहीं है; staff engineers को ज़रूरत पड़ने पर बहुत तेज़ी से काफ़ी working code भी बनाना आना चाहिए
ZIRP के अंत के बाद क्या बदला
- जैसे ही banks ने interest rates बढ़ाए, लगभग हर tech company ने तुरंत engineers के 5~20% को निकाल दिया
- फूले हुए engineering organizations को सिर्फ़ stock price support के लिए बनाए रखना अब profitable नहीं रहा, और कंपनियों को सच में पैसा कमाना पड़ा
- यहाँ “पैसा कमाना” का मतलब ज़रूरी नहीं कि profit ही हो, बल्कि कम-से-कम revenue तो आना ही चाहिए
- सैकड़ों engineers से non-profitable काम करवाने की बात मान लेना layoffs के लिए कोई अच्छा public explanation नहीं था
- ZIRP का अंत ChatGPT के उभार के लगभग साथ हुआ, इसलिए कंपनियाँ layoffs को AI की ताकत का नतीजा बताकर समझा सकीं
- “इस transformative new technology की वजह से हम आधे engineers के साथ 10x value deliver कर सकते हैं” यह संदेश ताकतवर लगता है, लेकिन अगर यह सच है तो engineers को बनाए रखकर 20x value क्यों न deliver की जाए, यह सवाल भी उठता है
ज़्यादा focused कंपनियाँ और कमज़ोर हुई protective layer
- tech companies पिछले 20 सालों में शायद पहले से कहीं ज़्यादा focused हैं, और अब वे बेतरतीब ढंग से कई चीज़ें करने की बजाय revenue ला सकने वाली नई capabilities और features के पीछे बेताबी से भाग रही हैं
- यह नया माहौल सिर्फ़ ‘नहीं हो सकता’ कहने वाले इंजीनियर के लिए साफ़ तौर पर प्रतिकूल है
- पहले ऐसे engineers को management का implicit support मिलता था, और अगर कोई शिकायत करता भी था तो बात अक्सर “वह engineer क्या कर रहा है, हमें पता है; अगर उसने ‘नहीं’ कहा है तो उस पर भरोसा करो” जैसी प्रतिक्रिया पर रुक जाती थी
- अब वह support कम हो गया है, और वही व्यवहार management की आलोचना झेल रहा है या सक्रिय रूप से पलटा जा रहा है
- उनसे ज़्यादा team player बनने, “हाँ” कहने का रास्ता ढूँढने, या बड़े फैसलों में अब सलाह के लिए न बुलाए जाने जैसी बातें हो रही हैं
- 2022 से पहले जिन व्यवहारों पर reward मिलता था, वे अब खराब performance reviews की वजह बन रहे हैं, और economic incentives बदलने के बाद cultural change कुछ साल की देरी से आता है
- यह बदलाव AI पर निर्भर नहीं है; अगर इस दशक में LLM उभरे ही न होते, तब भी कंपनियाँ engineers को निकालतीं, और “नहीं” कहने की भूमिका निभाने वाले engineers यही सोचकर उलझन में पड़ते कि वही व्यवहार अब दंडित क्यों हो रहा है
AI ने जो अतिरिक्त झटका दिया
- अगर ZIRP समाप्त न हुआ होता, तो LLM शायद सिर्फ़ ‘नहीं हो सकता’ कहने वाले इंजीनियर के लिए बहुत मज़बूत justification बन सकता था
- जो कंपनियाँ public या internal तौर पर AI-assisted coding पर खुलकर शक नहीं जता सकतीं, वे AI code की सुनामी को कंपनी पर हावी होने से रोकने के लिए इन engineers पर बहुत निर्भर हो सकती थीं
- लेकिन वास्तविकता में LLM पहले से मौजूद घाव पर और नमक छिड़कने जैसा काम कर रहा है
- अब उन्हें उन AI-generated PR को merge होते देखना पड़ रहा है जो पहले block कर दिए जाते, और उनसे खुद भी ऐसे tools इस्तेमाल करने को कहा जा रहा है
- और इससे भी बुरी बात यह है कि AI tools आम तौर पर काम कर जाते हैं
- वे अभी तक किसी खास तरह की आपदा पैदा नहीं कर रहे हैं, और भले code थोड़ा कम साफ़ हो और समझ थोड़ी कम हो, फिर भी वह काफ़ी उपयोगी है
- खासकर उन कंपनियों में जहाँ बहुत से नए प्रयोग किए जाते हैं और जो fail हो जाएँ उन्हें छोड़ दिया जाता है, वहाँ “काफ़ी अच्छा” code चल जाता है
- अगर हाल की incidents बढ़ी भी हों, तो भी यह संभव है कि यह धारणा गलत हो, या speed increase और layoffs जैसे ZIRP के अंत से जुड़े दूसरे factors ज़्यादा महत्वपूर्ण कारण हों
- सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर अब सिर्फ़ आजीविका ही नहीं, अपनी पहचान पर भी खतरा महसूस करता है
- उसे या तो यह स्वीकार करना होगा कि उसकी technical role tech industry की एक बहुत असामान्य economic situation पर निर्भर थी, या फिर यह कहते रहना होगा कि अंत बिल्कुल सामने है
pure engineering और impure engineering
- सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर पूरी तरह गायब नहीं होगा, लेकिन अब वह हर tech company के लिए उतना उपयुक्त नहीं है
- Pure and impure software engineering में अलग की गई pure engineering ऐसी चीज़ों पर लागू होती है जिनका scope अच्छी तरह परिभाषित हो और जिनके लक्ष्य मुख्यतः technical हों, जैसे compiler या language runtime
- impure engineering में scope अस्पष्ट होता है और लक्ष्य customer-driven होते हैं, जैसे ऐसे नए features की कोशिश जिनकी सफलता पहले से निश्चित नहीं होती
- ZIRP के दौर में tech companies React) जैसे pure काम बहुत ज़्यादा करती थीं, और impure कामों को भी pure की तरह treat करने की प्रवृत्ति थी
- सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर pure कामों के लिए बहुत अच्छी तरह फिट बैठता है
- इसकी वजह यह है कि pure codebases में बहुत ऊँचे quality standards चाहिए होते हैं और वे धीमे development cycle को सहन कर सकते हैं
- ज़्यादातर tech companies अब भी core infrastructure जैसे क्षेत्रों में किसी-न-किसी रूप में pure काम करती हैं
- यह काम ज़रूरी तो है, लेकिन इसे बहुत बड़ी engineering team की ज़रूरत नहीं होती, और इसे spotlight भी कम ही मिलता है
- अगर कोई सिर्फ़ ‘नहीं हो सकता’ कहने वाला इंजीनियर बने रहना चाहता है, तो उसे ऐसे roles की तरफ़ जाना चाहिए, लेकिन 2010s की तुलना में ज़्यादा सीमित scope स्वीकार करना होगा
बहस और पूरक दृष्टिकोण
- lobste.rs और Reddit पर यह आलोचना आई कि AI code का असर समय बीतने पर दिखेगा, इसलिए “आम तौर पर काम करता है” कहना अभी जल्दबाज़ी है
- “अभी कहना जल्दबाज़ी है” वाला प्रतिवाद खारिज करना कठिन है, लेकिन यह भी साफ़ दिखता है कि AI code तुरंत विनाशकारी साबित नहीं हो रहा
- यह प्रतिवाद भी आया कि सिर्फ़ ‘नहीं हो सकता’ कहने वाले इंजीनियर का archetype ZIRP से पहले के दशकों में भी मौजूद था, और Linus Torvalds को उदाहरण के रूप में पेश किया गया
- तर्क यह है कि archetype खुद ZIRP की उपज नहीं था, लेकिन ZIRP ने इस role की niche को कृत्रिम रूप से चौड़ा कर दिया था, जो अब फिर सिकुड़ गई है
- यह प्रतिवाद भी था कि dynamic languages का इस्तेमाल और immature observability तथा feature flag tools ने इस role की niche बनाई
- Hacker News पर कई लोगों ने कहा कि इस theory के लिए और ठोस evidence चाहिए
- यह दृष्टिकोण निजी अनुभव की एक छोटी खिड़की पर आधारित है, इसलिए ZIRP से पहले और बाद की industry कैसी थी, इस पर लोगों की generalization अलग-अलग हो सकती है
- इसे verify करने के लिए 2010 और 2026 में senior या उससे ऊपर के सैकड़ों engineers का survey किया जा सकता है, और पूछा जा सकता है कि वे हफ्ते में कितनी बार “नहीं” कहते थे और उनकी अस्वीकृति कितनी बार पलट दी जाती थी
- ZIRP से पहले और बाद, दोनों ही समय “नहीं” कहना ज़रूरी था, लेकिन ZIRP के बाद फ़र्क यह है कि management ने यह क्षमता तेज़ी से खुद विकसित कर ली, जिससे उसकी जगह “नहीं” कहने वाले अलग engineer समूह की ज़रूरत कम हो गई
1 टिप्पणियां
Hacker News की राय
कोड कर्ज है। इंजीनियर का “नहीं” कहना कोड क्वालिटी को लेकर किसी व्यक्तिपरक जुनून की वजह से नहीं, बल्कि complexity कम करने की कोशिश है
आजकल management अक्सर “quality” शब्द को गलत समझता है। quality का मतलब उस उचित मेहनत की मात्रा है जिससे product को जितनी जल्दी और जितनी कम लागत में हो सके बनाया जाए, साथ ही यह भी ध्यान रखा जाए कि engineering team कोड को आसानी से जोड़ और बदल सके
इसका बेहतर explanation यहाँ है: https://www.nair.sh/guides-and-opinions/communicating-your-e...
उस व्यक्ति ने क्या और क्यों किया, इसे कठोर नियमों में codify करने की कोशिश अंततः विफल ही होगी
इस तरह की armchair economics की समस्या यह है कि इससे दोनों तरफ की दलील बनाई जा सकती है
इसे “zero interest rate era का अंत और just-say-no engineer का उदय” भी कहा जा सकता है। capital की cost महंगी हो गई है, इसलिए companies को उस पैसे का इस्तेमाल ज़्यादा समझदारी से करना होगा, और उसे गैर-ज़रूरी चीज़ों पर बर्बाद होने से रोकने के लिए नहीं कहने वाले engineer के judgment की और ज़रूरत होगी
लेख पढ़ते-पढ़ते मुझे लगा, “इसमें सब plausible शब्दावली है, ZIRP era और just-say-no engineers जैसी बातें हैं, इसलिए यह insightful लगता है, लेकिन थोड़ा गहराई में जाओ तो यह उस दौर के software engineering field में मेरे अनुभव से बिल्कुल मेल नहीं खाता, और न ही यह आज AI से हो रहे बड़े बदलावों को सही तरह diagnose करता है।” यानी यह buzzword बकवास जैसा लगा, और अच्छा लगा कि लेख पर downvote button न होने के बावजूद community ने बात पकड़ ली
AI project fail भी हो जाए तो अगर वह काफ़ी जल्दी fail हो जाए ताकि कोई और काम किया जा सके, तो फर्क नहीं पड़ता। शुरू से सही करना सिर्फ़ उन long-term projects में महत्वपूर्ण हो जाता है जिनमें शुरुआती investment बड़ा होता है
“अगर company के आधे engineers लगातार बदलाव propose करते रहें और उन्हें reject किया जाता रहे, इस loop में फँसे हों, तब भी यह पूरी तरह ठीक था। वैसे भी productive होने की ज़रूरत नहीं थी, और इस तरीके से वे business-critical systems को प्रभावित नहीं करते थे” — हाँ, यह भी एक नज़रिया है। काफ़ी cynical है
पीछे मुड़कर देखें तो यह cynical लगता है, लेकिन उस समय लोग इसी fact set को दूसरे तरीके से समझाते थे ताकि भावनाएँ कम आहत हों
Facebook में Metaverse पर काम करने वाला कोई व्यक्ति नए business model का prototype बनाने वाला core contributor है या बस व्यस्त दिखने वाला काम कर रहा है, यह बाद में ही साफ़ होता है
यह काफ़ी extreme interpretation है। अगर ZIRP खत्म होने के बाद focus बढ़ा है, तो स्वाभाविक निष्कर्ष यह नहीं होना चाहिए कि कम नहीं बल्कि ज़्यादा चीज़ों को reject किया जाए?
अगर यह दावा करना है कि ZIRP ने तरह-तरह के fake काम पैदा किए, और फिर उन fake कामों को control करने के लिए layers भी बना दीं, तो उसके लिए काफ़ी ज़्यादा ज़ोर लगाकर तर्क करना पड़ेगा
“just-say-yes engineer” और “just-say-no engineer” का distinction, और MTBF से ज़्यादा MTTR को प्राथमिकता देने वाला दृष्टिकोण मुझे पसंद आया
मैं निश्चित रूप से “just-say-yes” तरफ़ हूँ, लेकिन यह भी एक संकेत है कि खराब architecture choices को बाद में ठीक करना बहुत दर्दनाक हो सकता है, और features को launch से पहले की तुलना में users आने के बाद ठीक करना कहीं ज़्यादा मुश्किल हो जाता है। इसलिए मैं थोड़ा “just-say-no”, या कम से कम “पहले थोड़ी देर सोचते हैं” वाली तरफ़ भी हूँ
“just-say-yes” और “just-say-no” का संतुलन काफी हद तक project पर निर्भर करता है। finance या healthcare हो तो default “no” बेहतर हो सकता है, लेकिन किसी अजीब startup idea के लिए तो YOLO है
चीज़ों को व्यवस्थित करने के लिए समय माँगना दरअसल नहीं कहने के बराबर है। development lead के पास यह अधिकार होना चाहिए, और उसे वास्तव में इस्तेमाल भी करना चाहिए। अगर वह कभी इसका इस्तेमाल ही नहीं करता, तो व्यावहारिक रूप से उसके पास यह अधिकार है ही नहीं
आपको ऐसा engineer नहीं बनना चाहिए जो बिना किसी alternative के सिर्फ़ “नहीं” कहता हो। वह अच्छा engineer नहीं, बल्कि आलसी होते हुए भी अच्छा दिखना चाहने वाला व्यक्ति है
legacy constraints की वजह से engineers अक्सर आदर्श नहीं, लेकिन ज़रूरी समाधान पेश करते हैं। और नहीं, आप पूरे system को फिर से लिखकर उसे “सही तरीके” से नहीं बना सकते। सिर्फ़ “नहीं” कह देने या यह बता देने से कि solution ideal नहीं है, कोई सुपरइंटेलिजेंट जीनियस नहीं बन जाता
business लोगों के साथ meetings में वह coding जानने के आधार पर दबदबा दिखाता था, और सबसे बुरी बात यह थी कि जब वह किसी proposal से सहमत नहीं होता था, तब कोई alternative देता ही नहीं था। उसके साथ काम करना मुश्किल था
यह लेख जिस ZIRP इंसान की बात करता है, क्या वह वही व्यक्ति है?
अगर LLM और agents में कमियाँ हैं, तो सुधार का इंतज़ार करने के बजाय मानक नीचे कर दो जैसी सोच भी चल रही है। बात कुछ ऐसी है: “MTTR पर फोकस करो”
कोड खराब है? उसे पढ़ो मत, review मत करो, और जो इंसान bottleneck है उसे loop से बाहर कर दो। ऐसी कहानी कई जगह फैल रही है
यह तकनीक काफ़ी उपयोगी है, इसलिए सिर्फ़ लक्षणों का इलाज करने के बजाय, tools के साथ बेहतर तरीके से काम करने और उसके मुताबिक process सुधारने पर ध्यान देना चाहिए
किए जा सकने वाले कामों की कोई सीमा नहीं है, लेकिन असली समस्या यह है कि वास्तविक project पर लगने वाला समय और ऐसे सुधारों पर लगने वाले समय को कैसे बाँटा जाए
कहा जा रहा है, “जितने ज़्यादा engineers, उतना stock price के लिए बेहतर… banks ने interest rates बढ़ाए… तब stock price को ऊपर रखने के लिए फूली हुई engineering organization बनाए रखना अब profitable नहीं रहा,” लेकिन software engineers की headcount और stock price को जोड़ने वाला कोई जाना-पहचाना mechanism है? या यह बस अनुभव के आधार पर देखा गया pattern है?
“पहले junior engineer के हाथ से लिखे PR पर बस ना कहना होता था, लेकिन अब AI-generated code की बाढ़ आ रही है, और उनमें से कुछ ऐसे managers और VPs ने बनाए हैं जिन्हें राजनीतिक वजहों से ठुकराना मुश्किल है”—हे भगवान
मैंने बड़ी tech companies में काम किया है, लेकिन InstructGPT वगैरह आने से पहले ही industry छोड़ दी थी, इसलिए अंदरूनी तौर-तरीकों में LLM code generation का अनुभव नहीं है। क्या सच में ऐसा हो रहा है? Senior managers और VPs, LLM से बने code changes propose कर रहे हैं? मुझसे तो शायद बर्दाश्त नहीं होगा
राजनीतिक दबाव भी सचमुच होता है। आप बस “यह नहीं चलेगा” नहीं कह सकते, लेकिन 25,000 lines के PR का meaningful review करना काफ़ी मुश्किल है, खासकर जब उसे डालने वाला व्यक्ति ठीक से यह भी न जानता हो कि वह क्या कर रहा है और सवालों के जवाब भी न दे पाए
निष्पक्ष होकर कहें तो, company के शुरुआती दिनों में उन्होंने liquid और Shopify के बड़े हिस्से खुद बनाए थे, इसलिए वह अनुभवहीन व्यक्ति नहीं हैं, लेकिन फिर भी बात तो है
यह एक ऐसी hypothesis लगती है जिसे verify करना मुश्किल है। अगर कोई company सच में कुछ हासिल करना चाहती है, तो क्या यह स्वाभाविक नहीं कि वहाँ ऐसे लोग हों जो बता सकें कि किस decision की long-term cost होगी और priority तय करने में मदद कर सकें?