सीनियर डेवलपर अपनी विशेषज्ञता समझाने में क्यों असफल होते हैं

• सीनियर डेवलपर और non-developers, AI agents डेवलपर्स की जगह ले लेंगे—इस एक ही वाक्य को, stability और market learning जैसे अलग-अलग मानकों से समझते हैं
• business organizations जल्दी launch करके feedback लेना और uncertainty कम करना चाहती हैं, जबकि senior developers उस बढ़ती complexity से सावधान रहते हैं जो system को तोड़ सकती है
• ग्राहक आने के बाद market exploration और service continuity के दो चक्र साथ-साथ चलते हैं, और senior developers की मुख्य ज़िम्मेदारी complexity management में बदल जाती है
• persuasion सिर्फ़ “complexity समस्या है” कहने से पूरी नहीं होती; Google Forms या existing UI buttons जैसे तेज़ experiments से सामने वाले की speed की ज़रूरत भी पूरी करनी होती है
• AI launch की speed बढ़ाता है, लेकिन understandability, modifiability और debuggability को नुकसान पहुँचा सकता है, और ज़िम्मेदारी नहीं लेता; इसलिए senior developers Speed और Scale को अलग कर सकते हैं

---

एक ही वाक्य को अलग मानकों से सुनने की वजह

• सीनियर डेवलपर और non-developers, “AI agents software development का future हैं और डेवलपर्स की ज़रूरत ख़त्म हो जाएगी” जैसे एक ही वाक्य को अलग तरह से ग्रहण करते हैं
• copywriting में message को audience के अनुसार होना चाहिए, और एक ही वाक्य audience के हिसाब से अलग अर्थ ले लेता है
• senior developers की instinct, AI optimism से इसलिए अलग हो जाती है क्योंकि problem की definition इस बात पर बदलती है कि focus market learning पर है या service stability पर

सीनियर डेवलपर किस चीज़ से सावधान रहते हैं

• कुछ सीनियर डेवलपर ऐसे होते हैं जो नए tools, दूसरी companies के तरीके, या Hacker News की best practices के आधार पर कुछ अपनाना चाहते हैं
• ज़्यादा पसंद किए जाने वाले senior developers पहले पूछते हैं, “क्या यह सच में ज़रूरी है?”, “अगर न करें तो क्या होगा?”, “क्या अभी के लिए इसे टाला जा सकता है और बाद में ज़्यादा महत्वपूर्ण होने पर फिर देखा जा सकता है?”
• यह प्रकार development को जितना हो सके टालने, घटाने और reuse करने की कोशिश करता है
• professional software development में senior developers जिस चीज़ से सबसे ज़्यादा सावधान रहते हैं, वह है complexity
• special cases, conditionals, नई database tables, और नए components—ये सब system में complexity जोड़ते हैं
• जो developers running systems की ज़िम्मेदारी लेते हैं, वे अंततः complexity बढ़ने से डरने लगते हैं
• नए और creative designs में अच्छे senior developers भी जब running system की ज़िम्मेदारी लेते हैं, तो complexity से सावधान हो जाते हैं

business organizations किस चीज़ से सावधान रहती हैं

• marketers, salespeople, product managers और CEOs उस cycle में होते हैं जहाँ वे market में कुछ जारी करते हैं, feedback लेते हैं, और सीखते हैं कि उसमें value है या नहीं
• इस cycle का लक्ष्य learning है, और इसका सबसे बड़ा ख़तरा uncertainty है
• कोई भी strategy success की guarantee नहीं देती, इसलिए uncertainty बहुत कठोरता से काम करती है
• जब marketing/sales incentives, founders की salary, और product manager का data समय के साथ जुड़ते हैं, तो deadline से पहले uncertainty कम करने का एकमात्र रास्ता यही लगता है कि चीज़ को जितनी जल्दी हो सके market में उतार दिया जाए
• market में जितना अधिक उतारेंगे, उतना अधिक feedback मिलेगा, और संभव है कि uncertainty उतनी ही कम हो
• हर company इसी cycle से शुरू करती है, और यह cycle शुद्ध speed के इर्द-गिर्द चलती है

ग्राहक आने के बाद दूसरा चक्र

• जब ग्राहक पैसे देना शुरू कर देते हैं, तो एक दूसरा cycle बनता है जिसका लक्ष्य service की continuity और assurance होता है
• system को लगातार चलना चाहिए, समझ में आने योग्य होना चाहिए, debug किया जा सकना चाहिए, modify किया जा सकना चाहिए, सिखाया जा सकना चाहिए, और stable होना चाहिए
• senior developers stability को महत्व देते हैं क्योंकि उन्हें ग्राहकों को लगातार service देने की business responsibility दी जाती है
• इन सबको फिर से complexity ही ख़तरे में डालती है
• complexity system को कम understandable, कम debuggable, कम modifiable, कम teachable, और अंततः कम stable बना देती है
• complexity बढ़ती है तो stability घटती है, senior developers अपनी ज़िम्मेदारी ठीक से नहीं निभा पाते, और payment failures जैसी समस्याएँ पैदा हो सकती हैं
• अगर पहले cycle का लक्ष्य uncertainty को घटाना है, तो दूसरे cycle का लक्ष्य complexity management है

communication कहाँ विफल होती है

• ग्राहक आने के बाद market exploration और service continuity—ये दोनों cycles एक साथ चलते हैं
• business को possibilities तलाशते हुए साथ ही ग्राहकों को service भी देते रहना होता है
• आप किस cycle पर समय लगा रहे हैं, उसके अनुसार वही समस्या अलग दिखाई देती है
• business organizations uncertainty कम करने के लिए चीज़ें और जल्दी बनाकर market में उतारना चाहती हैं
• senior developers, requests बढ़ने के साथ complexity, maintenance cost, understandability, sustainable development speed, और समय के साथ productivity की चिंता करते हैं
• लेकिन सिर्फ़ complexity management की भाषा में बात करने से दूसरे departments की uncertainty कम करने की इच्छा का समाधान करना मुश्किल है
• persuade करने के लिए senior developers को अपने solution को सामने वाले की problem के solution की तरह भी व्यक्त करना होगा
• communication तब विफल होती है जब problem को complexity management के नज़रिए से बताया जाता है, लेकिन solution को uncertainty reduction के नज़रिए से नहीं बताया जाता

सीनियर डेवलपर की वास्तविक ताकत

• senior developers की सबसे उपयोगी क्षमता यह है कि वे अनावश्यक चीज़ें न बनाकर, पहले से बनी चीज़ों को reuse करने के मौके ढूँढते हैं
• अगर survey data collect करना है, तो Google Forms इस्तेमाल किया जा सकता है
• पूरी नई feature बनाकर test करने के बजाय, existing UI में एक button जोड़कर देखा जा सकता है कि लोग click करते हैं या नहीं
• नई analytics service लाने से पहले यह पूछा जा सकता है कि analytics किस सबसे महत्वपूर्ण decision के लिए चाहिए, और एक decision, एक chart, एक metric से शुरुआत की जा सकती है
• पूरा birthday cake बेक करने के बजाय, sandwich में एक candle लगाकर भी काम चलाया जा सकता है
• senior developers सीखते हैं कि existing software का इस्तेमाल करके लोगों को उनकी ज़रूरत की चीज़ कैसे दी जाए
• इसे संक्षेप में कहने वाला वाक्य है: “Can we try something quicker?”
• “quicker” इस बात को स्वीकार करता है कि सामने वाला वास्तव में speed चाहता है
• “something” यह संकेत देता है कि लक्ष्य हासिल करने के दूसरे तरीके भी हो सकते हैं
• “try” में यह संभावना शामिल है कि चीज़ perfect न हो, फिर भी पर्याप्त अच्छी हो सकती है
• यह वाक्य company की चाही गई uncertainty reduction की speed को स्वीकार करते हुए भी senior developers को अपनी reduce, reuse, and avoid वाली expertise दिखाने की जगह देता है

AI जो दबाव बदलता है और जो ज़िम्मेदारी बाकी रहती है

• AI कम समय में बहुत कुछ बना सकता है, इसलिए reduce, reuse, and avoid वाला रवैया अर्थहीन लग सकता है
• लेकिन AI अभी भी senior developers के एक काम, यानी ज़िम्मेदारी लेना, नहीं कर पाता
• senior developers system की understandability को इसलिए महत्व देते हैं क्योंकि समस्या आने पर उसे ठीक कर पाना ज़रूरी है
• understandability system को बढ़ने के समय intelligently scale करने और paid customers को लगातार stable service देने में मदद करती है
• AI market में उतारने की speed को बहुत बढ़ाता है, लेकिन senior developers जिस stability cycle के लिए ज़िम्मेदार हैं, उस पर भी असर डालता है
• जब AI agents, junior developers, non-developers, investors, और उनके आसपास के लोग system में code जोड़ते हैं, तो system speed को ज़रूरत से ज़्यादा reward करने लगता है और stability छोड़ देता है
• AI understandability, modifiability, debuggability, teachability, और assure करने की क्षमता को खराब कर सकता है
• AI system को unstable बना सकता है, लेकिन उसकी ज़िम्मेदारी नहीं लेता
• यही senior developers की सबसे बड़ी चिंता है

लेखक से ज़्यादा संपादक के करीब सीनियर डेवलपर

• senior developers के पास एक तरीका है: decoupling
• लंबे समय तक केवल software developers ही software बना सकते थे, इसलिए developers market learning और service stability—दोनों cycles की ज़िम्मेदारी उठाते थे
• एक ही system ऐसा ढाँचा था जो दोनों लक्ष्यों को एक साथ संभालता था
• अगर दोनों लक्ष्यों के लिए अलग systems हों, तो speed और stability को अलग किया जा सकता है
• यह वैसा है जैसे कोई novelist जल्दी से first draft पूरा करे, फिर बाद में जो हिस्सा काम करता है उसे चुने और जो नहीं करता उसे हटा दे—एक editing process के ज़रिए
• editor का काम उन हिस्सों को लेकर उन्हें एक coherent whole में ढालना होता है जो अच्छे से काम कर रहे हों
• Speed version speed के लिए बना system है, जहाँ AI agents, generated but unreviewed code, junior developers, और marketing तेज़ी से ideas को वास्तविक रूप दे सकते हैं
• Speed version का लक्ष्य understandability नहीं, बल्कि market feedback पाने लायक पर्याप्त अच्छी स्थिति है
• Scale version stability के लिए बना system है, जिसे senior developers stable, understandable, और scalable ढंग से design करते हैं
• Speed version business को market से लगातार सीखने देता है, और senior developers उसके पीछे एक अच्छी तरह reviewed और understandable system बनाते हैं
• Scale version की design, Speed version में क्या काम किया और क्या नहीं किया, इससे प्रभावित होती है
• features पहले Speed में बनती हैं, फिर बाद में Scale में stabilize की जाती हैं
• implementation का वास्तविक रूप स्पष्ट न भी हो, लेकिन मुख्य बात यह है कि speed के लिए किया जाने वाला काम और stability के लिए किया जाने वाला काम स्पष्ट रूप से अलग किए जाएँ
• जब कोई ambitious request आए, तो यह कहा जा सकता है: “Speed version 3 दिन में तैयार कर दूँगा, और Scale version लगभग 6 हफ़्ते बाद”
• सामने वाले को speed और momentum मिलते हैं, और senior developers को observation और design के लिए समय मिलता है
• इस नज़रिए से senior developers, “senior software writers” से ज़्यादा senior software editors के करीब हो सकते हैं

[GN⁺]

Hacker News की राय

• विशेषज्ञता का सबसे महत्वपूर्ण हिस्सा आंतरिक world model से आता है, और उसे उससे अलग नहीं किया जा सकता
  आम तौर पर लोग मानते हैं कि किसी भी बात को शब्दों में व्यक्त किया जा सकता है, और अगर शब्द पहुँचा दिए जाएँ तो सुनने वाला बोलने वाले का मतलब ज्यों का त्यों समझ लेगा। इसी विश्वास की वजह से डेवलपर की विशेषज्ञता को दूसरों तक “transfer” करने की माँग पैदा होती है
  सच यह है कि ज्ञान काफी हद तक शब्दों में दिया जा सकता है, लेकिन वह world model जिसमें सारा ज्ञान आपस में जुड़कर ठोस हो गया हो, वैसा नहीं है। AI बहुत ज़्यादा तथ्य जान सकता है, फिर भी अभी वह उस ज्ञान का इस्तेमाल इस तरह नहीं करता कि उससे हैरान कर देने वाली हद तक अक्सर सही साबित होने वाली अंतर्दृष्टि निकले
  विशेषज्ञता का संचार असल में ज़्यादा से ज़्यादा किधर जाना है और क्या सीखना है, इस बारे में संकेत देने जैसा है, और पाने वाले को उसी तरह की विशेषज्ञता हासिल करने के लिए खुद उसे आत्मसात करने की मेहनत और सही प्रोजेक्ट्स से गुजरना पड़ता है

  • प्रतिभाशाली दिखने वाले और जल्दी “sense” पकड़ लेने वाले जूनियर और ऐसे न कर पाने वाले जूनियर के बीच बड़ा फर्क यह होता है कि वे सही world model जल्दी बना पाते हैं
    सॉफ़्टवेयर के “भौतिक नियमों” को समझकर लागू करने वाले और केवल प्रक्रिया लिखते चले जाने वाले, बिना हर चरण की मूल प्रकृति समझने की कोशिश किए, अलग नज़र आते हैं
    object-oriented पृष्ठभूमि वाले किसी व्यक्ति को functional programming सिखाते समय यह खास तौर पर दिखता है; कुछ लोगों का मॉडल टूट जाता है, जबकि कुछ जल्दी समझ लेते हैं कि variables की दुनिया से monads की दुनिया में अपेक्षाकृत आसानी से अनुवाद किया जा सकता है
  • संयोग से कल Peter Naur का 1985 का यह लेख देखा https://pages.cs.wisc.edu/~remzi/Naur.pdf, और तब से उसके बारे में सोच रहा हूँ
    लगभग 30 साल से ज़्यादातर समय एक बड़ी कंपनी में काम किया है, और हर हफ्ते काफी समय नए लोगों की समस्याओं के जवाब देने में जाता है। कई बार सिर्फ सवाल सुनकर ही तुरंत समझ में आ जाता है कि समस्या की जड़ उनके world model में है, या Naur के शब्दों में उनकी Theory अधूरी या विकृत है, जिससे सही निष्कर्ष निकालना कठिन हो जाता है
    चुनौती यह है कि अपनी theory को text और diagrams जैसे प्रतीकात्मक रूपों में बदला जाए, ताकि पर्याप्त अनुभव और बुद्धि वाला कोई व्यक्ति उससे मिलता-जुलता mental model बना सके। यानी मैं अपनी theory को किसी और के दिमाग में install करना चाहता हूँ
    Naur जिस प्रकार की theory की बात करते हैं, उसे सीधे transplant नहीं किया जा सकता, लेकिन मेरा मानना है कि senior developer का काम, चाहे classroom में हो या field में, ऐसे अनुभव उपलब्ध कराना है जिनसे ऐसी theory दोबारा बन सके। इसलिए communication skill महत्वपूर्ण है, और दूसरों से working theory पाने की प्रक्रिया कई बार झेलने पर ही प्रभावी instinct बनती है
    अब यह मेरे काम का सबसे संतोषजनक हिस्सा बन गया है, और जब तक मुझे लगेगा कि मैं यह भूमिका अर्थपूर्ण ढंग से निभा रहा हूँ, तब तक जल्दी retire नहीं होना चाहूँगा
  • अगर सबके पास एक जैसा आंतरिक world model होता, तो शायद innovation बहुत कम होती, इसलिए मैं इसे अच्छी बात मानता हूँ
    जूनियर्स को train और mentor करते समय मैं यह दिखाने की कोशिश करता हूँ कि क्या संभव है और कौन से पैटर्न विफलता की ओर ले जाते हैं, लेकिन यह training आम तौर पर टुकड़ों में और अधूरी होती है
    जहाँ तक हो सके, मैं यह समझाता हूँ कि काम इस तरह क्यों किया जाता है, लेकिन ऐसी बातें बहुत कम हैं जिन पर मैं साफ़ कहूँ कि यह बिल्कुल मत करो। जिन लोगों को मैंने सिखाया है, वे समस्याएँ किस तरह हल करते हैं, इससे मैं अक्सर चौंक जाता हूँ, और मैं खुद भी बहुत कुछ सीखता हूँ
    जो लोग अपने योगदान में रुचि नहीं रखते और काम को सिर्फ वेतन का साधन मानते हैं, उनके साथ training कम सफल रहती है। इसका मतलब यह नहीं कि ऐसा सोचना गलत है, लेकिन उदासीनता के आधार पर काम की worldview बनाने पर training को भीतर तक आत्मसात करना कठिन हो जाता है
  • मैंने देखा है कि इस दृष्टिकोण को, जिसमें माना जाता है कि शब्दों में ज्ञान भेज दिया तो वह जस का तस पहुँच गया, Transmissionism कहा जाता है
    https://andymatuschak.org/books/
  • https://en.wikipedia.org/wiki/Tacit_knowledge

• एक senior developer के रूप में मुझे एक ही फ़ॉर्मूले वाली sweeping generalizations से सच में नफ़रत है
  “क्या यह सच में ज़रूरी है?”, “अगर न करें तो क्या होगा?”, “क्या अभी काम चला सकते हैं और बाद में ज़रूरी होने पर वापस आ सकते हैं?” जैसी सोच के कारण मैंने उतनी ही असफलताएँ देखी हैं जितनी अत्यधिक प्रयोगधर्मी लोगों की वजह से
  हर system अलग होता है, हर product अलग होता है। अगर आप CT scanner firmware बना रहे हैं, तो नई चीज़ों के साथ आपका रवैया 100 ग्राहकों वाले CRUD SaaS जैसा नहीं होना चाहिए
  यह भी सच है कि कुछ उत्साही और ज़रूरत से ज़्यादा खुले senior systems को ऐसे कोनों में धकेल देते हैं जहाँ से निकलना मुश्किल होता है, लेकिन कुछ लोग अब भी कहते हैं कि PHP5 काफ़ी है

  • मैं भी लगभग यही कहने आया था। कभी ऐसे seniors अच्छे होते हैं जो development को जितना हो सके टालना चाहते हैं, और कभी सक्रिय रूप से सुधार लाना सबसे अच्छा विकल्प होता है
    अच्छे senior को यह पहचानना आना चाहिए कि कौन-सा समय कौन-सा है
  • यह एक तरह का survivorship bias है। एक VP ने कहा कि पिछली कंपनी में Elasticsearch सफल रहा था, इसलिए हमें भी वही इस्तेमाल करना चाहिए, और वह हमारे लिए भी ठीक बैठ गया
    फिर नतीजा यह होता है कि तकनीकी फैसले लेते समय VP की सुनो और Elasticsearch इस्तेमाल करो
  • यह मुझे सिर्फ विरोध के लिए विरोध जैसा लगता है, जबकि मूल पोस्ट का आशय संदर्भ में साफ़ था
    स्वाभाविक है, कुछ मौकों पर कार्रवाई करनी पड़ती है, लेकिन आज संतुलन ज़रूरत से ज़्यादा हर चीज़ को जटिल बनाने की तरफ झुका हुआ है
    इसका मतलब यह नहीं कि नए products और services मत बनाओ, बल्कि यह कि बनाते समय पूरे entropy को सबसे कम रखने वाला रास्ता खोजो। यही बात operations और technical debt घटाने पर भी लागू होती है
    premature optimization सभी बुराइयों की जड़ है
  • सहमत। context महत्वपूर्ण है। Senior developer को complexity, risk, trade-offs, और business पहलुओं को समझना चाहिए
    यह फैसला कि product की core functionality बदली जाए या नहीं, startup और पहले से मज़बूत cash flow वाली बड़ी कंपनी में अलग होगा
  • लगता है आपने मूल लेखक का संदेश मिस कर दिया। जिन गुणों पर ज़ोर दिया गया था, वे सब बेहतर stability की ओर ले जा सकते हैं, इसलिए उनका ज़िक्र था

• लेख मज़ेदार लगा, और उसके मुख्य संदेश जिससे बात कर रहे हों उसके मुताबिक बेहतर communication पर मैं सहमत हूँ
  लेकिन framing ऐसा लगा जैसे सही दिशा से शुरू होकर थोड़ा दूसरी तरफ मुड़ गई हो
  बताए गए दोनों loops, जितने ज़्यादा घने और तेज़ हों, उतना लाभ है। एक system को जल्दी “stable” और maintainable equilibrium तक ले जाता है, और दूसरा uncertainty से निपटता है
  systems को AI के अनुकूल बनाने के लिए बाँटने वाली अतिरिक्त अंतर्दृष्टि भी ऐसी बात है जिसे मैं AI के mainstream बनने से बहुत पहले से spikes के ज़रिए समझाता आया हूँ

• मुझे पता चला है कि अपनी विशेषज्ञता communicate और share करने की मेरी इच्छा की आम तौर पर junior developers में माँग ही नहीं है
  अधिकांश developers को mentor ढूँढने में दिलचस्पी नहीं होती। वे LinkedIn profile तक नहीं देखते, न ही मुझे ज्ञान और विशेषज्ञता के संभावित स्रोत के रूप में देखते हैं
  30 साल के industry experience के बाद ऐसा नहीं कि मेरे पास बाँटने के लिए कुछ नहीं है, बल्कि बाँटने वाला कोई नहीं है

  • मेरी मौजूदा नौकरी में यही सबसे बड़ी निराशा है। बहुत सी मूर्खतापूर्ण चीज़ें हो रही हैं और कोई उनसे बचना नहीं चाहता
    एक कम अनुभवी developer ने URL validator को AI magic से बदलने का सुझाव दिया, और मैंने AI-prepopulated cache-based fuzzy matching solution सुझाकर इसका विरोध किया, लेकिन किसी ने परवाह नहीं की। अब AI model अचानक बंद हो गया और system टूट गया। पूरे system को फिर से validate करना पड़ेगा
    मुझसे पहले promote हुआ एक युवा developer इसे ठीक करने के तरीके पर document लिख रहा था और बोला, “Dan, क्या तुम इसमें मदद कर सकते हो?” उसे promotion इसलिए मिला क्योंकि आगे बढ़ने का तरीका समझदारी से काम करना नहीं, बल्कि documents लिखना और meetings करना है, और अब वह मेरे काम का इस्तेमाल करके अपनी leadership दिखाना चाहता है
    जितना मैं बेहतर solutions सुझाता हूँ, उतना ही कम अनुभवी developers के लिए मैं खतरे जैसा लगने लगता हूँ, और चूँकि चीज़ें किसी तरह चल ही जाती हैं, managers भी परवाह नहीं करते। शायद मैं इसे बेहतर तरह से संभाल सकता था, लेकिन बकवास से लड़ते-लड़ते बहुत थक गया हूँ और बस अच्छा code लिखना चाहता हूँ
  • जिन senior developers के साथ मैंने काम किया, वे office आते थे, juniors के साथ नज़दीक से काम करते थे, और लोगों से बात करने को लेकर लगभग allergic थे
    दूसरी तरफ juniors बात करना, साथ में lunch करना और अपना काम share करना चाहते हैं। Seniors रक्षात्मक और अकेले रहते हैं
    शायद यह सिर्फ हमारी workplace की बात हो, लेकिन office महत्वपूर्ण है
  • जब IBM में मेरी पहली engineering job थी, काश वहाँ आपके जैसे कोई होते
    वहाँ कुछ senior developers juniors के सवाल पूछने पर नाराज़ हो जाते थे। 20 साल से काम कर रहे किसी व्यक्ति से कुछ पूछना ही हिम्मत माँगता था, और 50% संभावना रहती थी कि वह बुरा व्यवहार करेगा
    यह एक अच्छा learning experience बना, और अब मैं जानबूझकर mentoring करने की कोशिश करता हूँ
  • यह सुनकर दुख हुआ कि आपका अनुभव ऐसा रहा, लेकिन senior से सीखना चाहने वाले लोग निश्चित रूप से मौजूद हैं
    पिछले कई दशकों में मैंने रुक-रुककर mentoring की है, और मुझे कुछ बेहतरीन mentees मिले। उनमें से कुछ को लगभग 10 साल तक बढ़ते देखा है और आज वे बहुत अच्छा कर रहे हैं
    उन्हें कैसे ढूँढा जाए, इस पर मेरे पास बहुत उपयोगी सलाह नहीं है, लेकिन वे लोग मौजूद हैं
  • अपनी पहली नौकरी में startup में मैं किसी तरह system administrator की राह पर चला गया था, और सीखने के लिए लोग कम थे, इसलिए मैं दूसरे राज्य की एक कंपनी में चला गया जहाँ interview लेने वाला वही बेहद सक्षम system administrator था जिससे मैं सीखना चाहता था
    लेकिन मेरे पहुँचने के तुरंत बाद उसने कहा कि उसे replacement मिल गया है और इस्तीफ़ा दे दिया, इसलिए अंत में वह मेरे लिए अच्छा नहीं रहा

• मैंने जो अधिकांश proofs of concept देखे हैं, वे traction मिलते ही production बन गए
  कई बार सबने वादा किया कि “अगर यह चल पड़ा तो शुरुआत से दोबारा लिखेंगे”, लेकिन ऐसा कभी नहीं हुआ
  लेख accountability और responsibility को छूता है, लेकिन जो लोग risk लेते हैं, उनके लिए ऐसी चीज़ें अक्सर होती ही नहीं। वे पागलपन भरे ideas जल्दी से launch करते हैं और उम्मीद करते हैं कि ग्राहक काट लेंगे, और इससे उन्हें फ़ायदा मिलता है। यह कैसे चलेगा, scale कैसे होगा, और operating cost बिक्री मूल्य से ज़्यादा न हो, यह उनका मसला नहीं होता
  कुछ कंपनियाँ इस right loop को चरम तक ले गई हैं, और आज उनमें से दो बहुत मशहूर हैं। वे कुछ जल्दी ship करती हैं, बस linear scaling होती है, फिर पैसा जुटाने निकल पड़ती हैं। कंपनियाँ सफल कहलाती हैं, users असंख्य होते हैं, कुछ पैसे भी देते हैं। ऐसे में जो senior developers या समझदार लोग पूछते हैं “क्या यह sustainable है, बाहर निकलने का रास्ता क्या है”, उन्हें निकाल दिया जाता है, और सिर्फ़ आस्थावान लोग बचते हैं

  • इसी वजह से पर्याप्त senior engineering leadership चाहिए। इसमें individual contributor leadership और manager leadership दोनों आते हैं
    अगर engineers चुपचाप वही करते रहें जो non-technical stakeholders कहें, तो accountability gap पैदा होता है, और किसी दिन सब कुछ आपदा की तरह फूटता है, फिर उसी व्यक्ति को दोष मिलता है जो अपना बचाव सबसे कम कर पाता है
    इसके उलट, अगर आप पर्याप्त व्यापक नज़र रखें और पर्याप्त बार “क्यों” पूछें, तो लगभग हर business problem को ऐसे उचित तरीके से हल किया जा सकता है जो system को किसी भयानक one-way door में न धकेले
    हर जगह engineering को यह अधिकार नहीं मिलता, लेकिन जहाँ नहीं मिलता, वहाँ senior लोग टिकते नहीं; वे वहाँ चले जाते हैं जहाँ उनके निर्णय का सम्मान हो। कभी-कभी technical debt business के लिहाज़ से सही चुनाव होती है, लेकिन पर्याप्त senior engineer हमेशा एक escape hatch बना सकता है
    फिर भी system की शुद्धता को business problem से ऊपर नहीं रखा जा सकता। System की cost business देता है, और अगर आप यह भूल जाएँ, तो अपने influence की नींव भी खो देते हैं
  • जैसा पुरानी कहावत कहती है, temporary hack से ज़्यादा permanent कुछ नहीं होता
  • यह समस्या AI coding agents से बहुत पहले की है, हालाँकि AI इसे और बदतर बना सकता है
    लेख का निष्कर्ष मूलतः वही पुरानी सलाह है: “एक ऐसा बनाओ जिसे फेंकने की योजना हो।” मैंने भी Mythical Man-Month पढ़ी है, लेकिन समस्या यह है कि decision-makers को कैसे मनाया जाए
  • यह company culture की समस्या भी हो सकती है। एक बार हमने तेज़ और गंदे solution से शुरुआत की थी और हालत बुरी हो गई, इसलिए हमने मज़बूत policy बनाई कि हर quick and dirty feature के साथ अगले 1~2 sprint में आने वाली follow-up story ज़रूर जुड़ी होगी
    अगर चीज़ें उम्मीद पर खरी नहीं उतरतीं, तो feature disable या delete कर दिया जाता था, और अगर टिकता था, तो review के बाद ठीक से refactor किया जाता था
    team autonomy बहुत ऊँची थी और schedule को लेकर शिकायतें लगभग नहीं थीं, क्योंकि ज़्यादातर दूसरे विभाग पीछे चल रहे थे। बस marketing के पास हमेशा “ideas” होते थे
  • अगर कोई काम करने वाला “prototype” माँग सँभाल रहा है, ज़रूरी features भी हैं, और उसे फिर से बनाने की ज़रूरत सिर्फ़ developer की रुचि संतुष्ट करने के लिए है, तो समय और मेहनत क्यों लगाएँ?
    यह कि वह prototype है या proof of concept, अपने-आप में तब तक महत्वपूर्ण नहीं है जब तक आप गिना न सकें कि असली समस्याएँ क्या हैं
    कई teams को technical debt में फँसा होने, बड़े जोखिम में होने और धीमी होने की शिकायत करते देखा है, लेकिन incident logs में घटनाएँ ज़्यादा नहीं थीं, और न ही production में चल रहे risky code को उनका कारण ठहराया जा सकता था। Risk register में भी “यह code पुराना, खराब है और end-of-support dependency रखता है” जैसा कुछ नहीं होता, और कोई team ठीक से समझा नहीं पाती कि technical debt उन्हें कैसे और कितना धीमा कर रही है
    दूसरी तरफ, मैंने ऐसी teams भी देखी हैं जिन्होंने launch से पहले app को और “बेहतर” बनाने के नाम पर महीनों refactor किया। सारी value delivery टल गई, leadership का नाराज़ होना स्वाभाविक था, और भरोसा लगभग खत्म हो गया
    अगर team और stakeholders के बीच delivery पर अच्छी बातचीत हो, तो सब संतुष्ट रह सकते हैं, लेकिन अगर वह न हो, तो stakeholders हमेशा जीतते हैं

• आप मूल समस्या incentives को मिस कर रहे हैं। “कंपनी” क्या चाहती है, यह उतना महत्वपूर्ण नहीं; महत्वपूर्ण यह है कि खास फैसले लेने वाले लोग क्या चाहते हैं
  कुछ लोग सिर्फ़ नई feature या app launch करके कंपनी के किसी metric में दिखाई देने भर से अपनी नौकरी बचाए रखते हैं। अगर senior developer कहे कि यह बुरा idea है, तब भी वे लोग सुनेंगे नहीं या परवाह नहीं करेंगे, क्योंकि उनकी अपनी नौकरी दाँव पर होती है

  • इसका एक क्लासिक उदाहरण researchers हैं, जिनका मूल्यांकन papers और नई चीज़ें निकालने से होता है
    लेकिन product side पर, features को customer needs के अनुसार ढालना पड़ता है, इसलिए researchers से push करना बंद करने को कहना चाहिए

• सच में सक्षम senior वही है जो समझे कि मौजूदा कंपनी की dominant culture क्या है और पाँच साल बाद क्या ज़रूरत होगी, फिर उसी के मुताबिक खुद को ढाले
  5 लोगों के startup को शायद ऐसी अतिरिक्त complexity की ज़रूरत न हो जो उसकी runway कम कर दे। 500 लोगों की company को शायद हर business decision के second-order effects को कम करना पड़े, इसलिए उसे वही complexity चाहिए हो
  यह “हमेशा complexity से बचो” वाली black-and-white सोच नहीं है, बल्कि “जब अर्थपूर्ण हो तब complexity जोड़ो” वाली बात है, और जब business को कुछ महीनों और टिके रहना हो तब यह सवाल खुद बहुत सूक्ष्म हो जाता है

  • सही कहा। priorities और transparency हों, तो लोग समस्या हल करते समय इस्तेमाल किए जाने वाले variables बदल सकते हैं
    अगर तूफ़ान आने में दो घंटे बचे हों, तो architecture के बारे में सोचने के बजाय आप पूछते हैं, “क्या पानी इतना भर जाएगा कि हम उसे बाहर ही न निकाल पाएँ?”
    मेरी नज़र में समस्या यह है कि management खेल खेलती है; वह नहीं बताती कि वास्तव में कितना पैसा बचा है, या असली timeline क्या है। उन्हें डर रहता है कि महत्वपूर्ण पल से पहले contributors छोड़कर चले जाएँगे। फिर लोग उसी संदर्भ में मूर्खतापूर्ण फैसले लेते रहते हैं और अंत में सब नई नौकरी ढूँढने लगते हैं

• मैं भी पिछले कुछ दिनों से अपनी team तक लगभग यही भावना पहुँचाने की कोशिश कर रहा था, यहाँ तक कि यह पंक्ति भी लगभग वैसी ही थी: “क्या हमें पूरी नई feature बनाकर test करनी है? या पहले existing UI में एक button डालकर देख लें कि लोग उसे दबाते भी हैं या नहीं?”
  ऐसा लगता है कि product side ने तय कर लिया है कि अब उन्हें अपनी मानसिक क्षमता इस्तेमाल करने की ज़रूरत नहीं, और engineers सामूहिक रूप से उसकी पीड़ा झेल रहे हैं। पहले बना लो, user persona और usefulness बाद में, या शायद कभी नहीं, समझ लेंगे
  पहले हम domain, users, और product किस प्रक्रिया में फिट होता है, इसे समझने में समय लगाते थे; अब बस वह चीज़ ship कर देते हैं जो हमें लगता है कि कोई काल्पनिक user चाहता होगा, और सफलता मिलने तक experiment करते रहते हैं
  ठीक वही समस्या पैदा होती है जो मूल पोस्ट कहती है। vibe coding से बनी हर मनमानी feature instability और risk का स्रोत बन जाती है, और क्योंकि उस चीज़ का working mental model किसी के पास नहीं होता, उसका maintenance भी और ज़्यादा vibe coding से ही हो सकता है

• भले ही आप complexity को मापने की एक ही dimension में घटा सकें, वह solution space के कई तत्वों में से सिर्फ़ एक है
  maintainability, scalability, reliability, resilience, antifragility, extensibility, generality, durability, composability जैसी दूसरी properties भी हैं, और वे हमेशा हर स्थिति में लागू नहीं होतीं
  मेरा मानना है कि single dimension की जगह इसे solution space के trade-offs के रूप में समझा पाने की क्षमता ही senior और Staff+ developers को अलग करती है

  • अगर जूनियर “complexity” को किसी मनमानी एक झलक से बनी पहली छाप की तरह समझे, तो वह हमेशा बुरी और ज़रूरत से ज़्यादा लगेगी
    लेकिन अगर इसे आने वाले 10 person-years तक इस system के development को आसान और तेज़ बनाने वाले तत्व के रूप में समझें, तो इसका मतलब होता है ऐसा चुनाव करना जो वहाँ बगल से निकल जाए जहाँ naïve approach सीधे सिर के बल घुसना चाहती है
    खरगोश और कछुए की कहानी की तरह, शुरुआती 2 हफ्तों में जल्दी-जल्दी low-hanging fruit, दिखने वाली उपलब्धियाँ और MVP ले लेने के बाद, अपरिपक्व design और development के दौरान maintainability की वजह से गति लगातार घटती जाती है—इस प्रवाह को समझना कठिन है। कुछ हफ्तों तक सब “तेज़” दिखता है, लेकिन अंत में schedule 6 महीने खिसक जाता है
  • trade-offs ही कुंजी हैं। Non-programmers कल्पना करते हैं कि trade-offs होते ही नहीं
    प्रोग्रामर होने का मतलब आखिरकार यह समझना है कि design के लगभग हर संभावित पहलू में trade-offs होते हैं
  • इन तत्वों में से काफ़ी कई complexity से सीधे प्रभावित होते हैं
  • आपने सबसे महत्वपूर्ण एक चीज़ छोड़ दी: usability