सिर्फ सादगी से प्रमोशन नहीं मिलता

• software engineering culture में जटिल सिस्टम बनाने वाले लोगों को ज़्यादा मान्यता मिलती है, जबकि सरल समाधान चुनने वाले लोगों के काम का अक्सर सही मूल्यांकन नहीं होता
• प्रमोशन evaluation, interview, design review आदि में complexity को अक्सर “impact” समझ लिया जाता है, जिससे गैर-ज़रूरी abstraction और scalability जोड़ने की प्रवृत्ति मजबूत होती है
• सरल implementation अक्सर “अदृश्य उपलब्धि” बनकर रह जाती है, जबकि जटिल संरचना को चमकदार narrative और documentation के साथ promotion packet में भरना आसान होता है
• असली कौशल ज़्यादा tools इस्तेमाल करने में नहीं, बल्कि कब complexity को हटाना चाहिए यह जानने वाली judgement और confidence में है
• engineers और leaders दोनों को सादगी को visible बनाना होगा और उसे औपचारिक रूप से मान्यता देने वाली evaluation और reward systems बनानी होंगी

---

सादगी बनाम जटिलता: प्रमोशन narrative की असमानता

• एक ही टीम के दो engineers का उदाहरण: Engineer A ने 50 lines के संक्षिप्त code से कुछ ही दिनों में feature लॉन्च कर दिया, जबकि Engineer B ने नया abstraction layer, pub/sub system और configuration framework जोड़कर 3 हफ्तों में काम पूरा किया
• Engineer B के काम को promotion packet में "scalable event-driven architecture design, reusable abstraction layer की शुरुआत, configuration framework का निर्माण" के रूप में लिखा जा सकता है
• Engineer A के काम को सिर्फ "feature X implement किया" इन तीन शब्दों में समेट दिया जाता है
  • जबकि असल में वही बेहतर काम था, लेकिन क्योंकि उसे सरल दिखने लायक बनाया गया, वह अदृश्य योगदान बन गया
• "टाली गई complexity" के आधार पर किसी को प्रमोशन नहीं मिलता — complexity इसलिए smart लगती है क्योंकि evaluation system उसी को reward देने के लिए बना है

interview और design review में complexity को बढ़ावा देने वाली संरचना

• system design interview में अगर आप सरल solution (single database, सहज API, caching layer) सुझाते हैं, तो interviewer दबाव डालता है: "अगर 1 करोड़ users आ जाएँ तो?"
  • जैसे-जैसे आप services, queues, sharding जोड़ते जाते हैं, interviewer ज़्यादा संतुष्ट दिखता है
  • candidate को मिलने वाला सबक: "सरल जवाब पर्याप्त नहीं था"
• interviewer के ऐसा करने के पीछे तर्कसंगत वजह हो सकती है — दबाव में सोचने की क्षमता और distributed systems की समझ परखना — लेकिन candidate तक पहुँचने वाला संदेश यही होता है कि "complexity प्रभावशाली है"
• design review में भी "future-proof करना चाहिए न?" जैसे सवालों के जवाब में लोग बार-बार गैर-ज़रूरी layers और abstractions जोड़ देते हैं
  • क्योंकि समस्या को उनकी ज़रूरत नहीं थी, लेकिन meeting room की अपेक्षा वही थी
• कुछ lines की code duplication से बचने के लिए बनाई गई abstraction कई बार समझने और maintenance को और कठिन बना देती है
  • code ज़्यादा "professional" दिखता है, लेकिन users को feature जल्दी नहीं मिलता, और अगला engineer बदलाव करने से पहले आधा दिन abstraction समझने में लगा देता है

उचित complexity बनाम गैर-ज़रूरी complexity (Unearned Complexity)

• complexity अपने-आप में समस्या नहीं है — लाखों transactions को संभालने के लिए distributed systems चाहिए, और अगर 10 teams एक ही product बना रही हों तो service boundaries की ज़रूरत होती है
• समस्या है गैर-ज़रूरी complexity: "database अपनी limit पर पहुँच गया है इसलिए sharding चाहिए" और "3 साल बाद limit आ सकती है, इसलिए अभी sharding कर लेते हैं" — इन दोनों में फर्क है
• इसे समझने वाले engineer का code और architecture ऐसा लगता है जैसे "हाँ, यही तो स्वाभाविक है"; उसमें न कोई जादू दिखता है, न दिखावटी चतुराई, और न ही उसे न समझ पाने पर खुद को मूर्ख महसूस होता है
• senior बनने का असली रास्ता ज़्यादा tools और patterns सीखना नहीं, बल्कि यह जानना है कि कब उनका उपयोग नहीं करना है — complexity जोड़ना कोई भी कर सकता है, लेकिन उसे हटाने के लिए अनुभव और आत्मविश्वास चाहिए

engineers के लिए व्यवहारिक तरीके

• सादगी को visible बनाना होगा — काम अपने-आप नहीं बोलता, क्योंकि evaluation system उसे सुनने के लिए बना ही नहीं है
• "feature X implement किया" लिखने के बजाय "event-driven architecture और custom abstraction layer सहित तीन approaches का मूल्यांकन किया, फिर यह तय किया कि simple implementation वर्तमान और अनुमानित दोनों requirements को पूरा करती है; 2 दिनों में लॉन्च किया और 6 महीने तक बिना incident के चलाया" जैसा लिखें
  • कुछ न बनाने का निर्णय भी एक निर्णय है, और कई बार बहुत महत्वपूर्ण निर्णय — इसलिए उसका भी documentation होना चाहिए
• design review में "future-proof करना चाहिए न?" सुनकर तुरंत झुकने के बजाय कहें: "इसे बाद में जोड़ने में इतना समय लगेगा, अभी जोड़ने पर इतनी लागत आएगी, इसलिए इंतज़ार करना बेहतर है"
  • यह विरोध नहीं, बल्कि यह दिखाना है कि आपने विकल्पों की सही समीक्षा की है
• अपने manager से सीधे बात करें: "मैं चाहता हूँ कि मेरे काम का documentation सिर्फ code नहीं, बल्कि मेरे निर्णयों को भी reflect करे" — इससे manager को भी आपके पक्ष में बोलने की भाषा मिलती है
• अगर यह सब करने के बाद भी टीम सिर्फ सबसे जटिल system बनाने वाले को ही प्रमोशन देती है, तो वह भी उपयोगी जानकारी है — कुछ organizations सादगी को सच में महत्व देती हैं, और कुछ सिर्फ कहती कुछ हैं, reward कुछ और करती हैं

engineering leaders के लिए व्यवहारिक तरीके

• incentives तय करना leaders की ज़िम्मेदारी है — ज़्यादातर promotion criteria complexity को reward करने के लिए बने होते हैं, और "impact" को अक्सर बनाई गई चीज़ की scale और scope से मापा जाता है
  • सिर्फ बनाई गई चीज़ ही नहीं, बल्कि जिससे बचा गया उसे भी evaluation में शामिल करना चाहिए
• design review में "क्या scalability के बारे में सोचा गया है?" पूछने के बजाय "सबसे सरल कौन-सा version है जिसे लॉन्च किया जा सकता है, और कौन-से ठोस संकेत बताएँगे कि अब ज़्यादा जटिल solution की ज़रूरत है?" पूछें
  • यह एक सवाल ही खेल बदल देता है: सादगी default बन जाती है, और complexity पर प्रमाण का भार आ जाता है
• promotion discussion में प्रभावशाली systems की सूची वाले packet को देखकर यह भी पूछना चाहिए: "क्या यह सब वास्तव में ज़रूरी था? क्या pub/sub system सच में चाहिए था, या सिर्फ कागज़ पर अच्छा दिख रहा था?"
• जब कोई team member साफ-सुथरी और सरल चीज़ लॉन्च करे, तो उसकी कहानी लिखने में मदद करें — "कई approaches का मूल्यांकन किया और समस्या हल करने वाला सबसे सरल विकल्प चुना" तभी एक मजबूत promotion case बनता है जब leader वास्तव में उसे वैसे ही मान्यता दे
• team channels में सार्वजनिक रूप से किसे celebrate किया जाता है, इस पर ध्यान दें — अगर सिर्फ बड़े और जटिल projects की तारीफ़ होगी, तो लोग उसी दिशा में optimize करेंगे
  • code हटाने वाले engineer को भी मान्यता दें, और उस engineer को भी जिसने "अभी इसकी ज़रूरत नहीं है" कहा और सही साबित हुआ

[goathead]

resume driven design...

[GN⁺]

Hacker News की राय

• एक इंटरव्यू सवाल में ऐसी स्थिति दी गई थी जहाँ दो लोग spreadsheet को ईमेल से एक-दूसरे को भेज रहे थे
  मैंने जवाब दिया कि इसे Google Sheets में ले जाऊँगा, लेकिन इंटरव्यूअर शायद चाहते थे कि मैं खुद कोई टूल डिज़ाइन करूँ
  उस समय यह अजीब लगा था, और आज भी समझ नहीं आता कि इससे क्या सीख लेनी चाहिए

  • मुझे लगता है कि ऐसी स्थिति इंटरव्यूअर ट्रेनिंग की विफलता है
    अच्छे जवाब को स्वीकार करना चाहिए था, फिर कहना चाहिए था, “यह technical design evaluation के लिए एक hypothetical situation है, तो आइए एक नया system design करते हैं”
    अगर उम्मीदवार उस premise को स्वीकार न करे, तो उसे अलग संकेत की तरह आंका जा सकता है
    मैं होता तो पूछता, “क्या हम मान लें कि existing solution उपलब्ध नहीं है और नया design करें?”
    यह वैसा ही है जैसे इंटरव्यूअर सिर्फ वही जवाब सुनना चाहता हो जो वह चाहता है — algorithm बहस का system design version
  • मेरे co-founder ने Stripe acquisition discussion के दौरान system design interview दिया था, requirements सुनकर उसने जवाब दिया, “मैं इसे बस Postgres में डालूँगा”
    वास्तव में वही सही निर्णय था, लेकिन Patrick Collison ने खुद फोन करके पूछा, “तुम interview clear नहीं कर पाए, लेकिन क्या तुम उसका उद्देश्य समझते हो?”
    आखिरकार उसने दोबारा interview दिया और पास हो गया
    यह एक ऐसा किस्सा था जो दिखाता है कि इंटरव्यू का उद्देश्य समझना कितना महत्वपूर्ण है
  • मैंने इस विषय पर एक दोस्त के साथ बहस की थी
    एक बड़ी ferry company Google Sheets से जहाज़ों की location और staff assignment संभाल रही थी, और मेरे दोस्त ने कहा, “यह किसी बड़े enterprise का काम करने का तरीका नहीं है”
    लेकिन मुझे लगा कि पहले से proven tool से समस्या हल करना शानदार है
    इसकी वजह से बिना internal dev team या महंगे outsourcing के काम चल सकता है
    यह ऐसा अनुभव था जिसने मेरे अहम को गहराई से दफ़ना दिया
  • ऐसे इंटरव्यू सवाल में मुझे लगता है कि पहले पलटकर यह पूछना बेहतर है, “यह समस्या क्यों है?”
    सामने वाला पहले यह बताए कि ठीक-ठीक क्या mismatch है, उसके बाद ही technical design शुरू करना चाहिए
  • सही जवाब यह है कि पूछो, “आप Google Sheets इस्तेमाल क्यों नहीं कर रहे और ईमेल से क्यों भेज रहे हैं?”
    Sheets न इस्तेमाल कर पाने के कई कारण हो सकते हैं — feature limitation, चीन के भीतर access restriction, company policy, network issue वगैरह
    ग्राहक शायद पहले से ही इन्हीं कारणों से custom solution चाहता हो
    यानी सिर्फ “Google Sheets इस्तेमाल कीजिए” नहीं, बल्कि ग्राहक के context को समझना ही developer की भूमिका है

• AI coding tools इस समस्या को और भी सूक्ष्म तरीके से बदतर बना रहे हैं
  अब complex architecture 5 मिनट में बनाई जा सकती है, लेकिन maintenance cost वही रहती है
  नतीजे में ज़्यादा चमकदार structure बहुत तेज़ी से बन जाते हैं, और promotion के लिए documentation भी तुरंत तैयार हो जाती है
  लेकिन असलियत में उस code को कोई पूरी तरह समझता ही नहीं
  सच्ची simplicity का पैमाना यह है: “क्या अगला व्यक्ति इसे बिना सवाल के समझ सकता है?” और AI-generated code इस कसौटी पर पूरी तरह खरा नहीं उतरता

  • सच तो यह है कि LLM से पहले भी रात 3 बजे बुलाए गए on-call engineer अक्सर system को ठीक से नहीं जानते थे
    अब बस यह और बदतर होगा
    इसलिए मैं organization की code understanding culture को career चुनने का एक मानदंड मानता हूँ
    ऐसी स्थिति फिर नहीं देखना चाहता जहाँ किसी को system की समझ ही न हो
  • इसी वजह से आगे चलकर software product खुद का मूल्य कम होता दिखेगा
    अगर लक्ष्य problem solving है, तो AI से बना tool हो या खरीदा हुआ tool, अंततः उसे समस्या हल करनी चाहिए
    लेकिन अगर ready-made product फिट नहीं बैठता, तो custom generated solution बढ़ेंगे
    बस अगर उन्हें कोई समझ ही न पाए, तो अगला व्यक्ति फिर से नया बना देगा
    फिर भी user और maker के बीच दूरी कम होने के लिहाज़ से यह सुधार हो सकता है
  • AI tool इस्तेमाल करते समय maintainability principles को document करना महत्वपूर्ण है
    उदाहरण के लिए AGENTS.md में “KISS”, “YAGNI” जैसी guidelines लिख देना मददगार हो सकता है
  • मैं भी AI के साथ coding करते समय simplicity बनाए रखने की कोशिश करता हूँ
    समस्या यह है कि “अगला व्यक्ति” आख़िरकार 6 महीने बाद वाला मैं खुद ही होता हूँ
    AI भी context window की सीमा के कारण उसी समस्या से जूझता है
  • AI द्वारा बनाए गए code की operational cost को भी नज़रअंदाज़ नहीं किया जा सकता
    बहुत से developer सिर्फ popular stack के पीछे भागते हैं और operations की आसानी पर ध्यान नहीं देते
    AI भी यह नहीं कहता, “यह over-engineering है”
    अगर आप Kubernetes और ElasticSearch चाहते हैं, तो वह वही बना देगा

• FAANG और startup दोनों का अनुभव रखने के नाते, complexity और simplicity के बीच संतुलन ही मुख्य बात है
  बड़े enterprise में अस्थायी जुगाड़ हज़ारों लोगों की productivity को नुकसान पहुँचा सकता है,
  और startup में बेवजह का infrastructure कंपनी को डुबो सकता है
  सचमुच skilled engineer वही है जो इन दोनों स्थितियों में फर्क समझे और अनुभव के आधार पर उचित trade-off चुन सके

  • जब team का आकार 5 हो और जब 500 हो, तब defect rate बिल्कुल अलग होता है
  • self-managed project managing की क्षमता सचमुच सीखने में बहुत कठिन skill है

• Amazon (2005~2008) में काम करते समय, कंपनी culture के प्रतीक दो awards थे
  “Just Do It” award स्व-प्रेरित problem solving का प्रतीक था, और “Door Desk” award frugality और simplicity का
  एक किस्सा यह भी है कि एक employee ने बेकार पड़े TV को हटाया, तो उसे award मिला, और इनाम में वही TV दे दिया गया

  • लेकिन वह door desk वास्तव में Ikea से भी महँगा था और assemble करना भी मुश्किल था
    रूपक के तौर पर simplicity, व्यवहार में थोड़ी अस्पष्ट थी
  • आज भी “Just Do It” award दिया जाता है

• simplicity की वकालत करनी है तो उसे business language में व्यक्त करना होगा
  जैसे “incident 80% कम”, “cost 40% कम”, “performance 33% बेहतर”
  simplicity अपने आप में rarely evaluate होती है, लेकिन उसके results को बहुत महत्व मिलता है

  • लेकिन “क्योंकि हमने कुछ complex नहीं बनाया” वाले असर को मापना मुश्किल होता है
  • अगर आपने शुरू से fast system design किया, तब भी अक्सर आपको उस व्यक्ति से कम credit मिलता है जिसने पहले slow system बनाया और फिर उसे 80% improve किया
  • simplicity का P&L में दिखाई न देना ही वजह है कि उससे promotion मिलना कठिन होता है
    मैंने refactoring को cost model में बदला, KPI मापा, और MTTR को 60% घटाया
    ऐसे numbers खुद दिखाने पड़ते हैं, तभी मान्यता मिलती है
  • ज़्यादातर executives “और तेज़” चुनते हैं, “और सरल” लगभग कभी नहीं

• manager के तौर पर मैं simple code को पसंद करता था
  लेकिन इसकी वजह यह थी कि team skilled लोगों से बनी हुई थी
  कम अनुभव वाली team में The Parable of The Toaster जैसी स्थिति हो सकती है

• उम्र बढ़ने के साथ complexity के प्रति प्रतिरोध बढ़ता है
  लेकिन leadership अक्सर इसे “समझ नहीं पाया इसलिए विरोध कर रहा है” मान लेती है
  सबसे लंबे समय तक टिके projects वही थे जो simple थे और जिन्हें replace करना आसान था
  AI tools इस approach को और आसान बनाते हैं — independent sample project में component पर experiment करो, और verified code को main project में integrate करो
  अंदरूनी नेटवर्क वाले environment में मैं AI को सीधे connect नहीं करता, लेकिन यह तरीका बहुत उपयोगी है

  • leadership अक्सर simple approach को आलस्य समझ लेती है
    इसलिए मैं कहता हूँ, “हम complex version भी बना सकते हैं, लेकिन पहले simple version से शुरू करते हैं”
    ज़्यादातर मामलों में वही simple version आख़िरकार सालों तक चलने वाला production code बन जाता है
  • ऐसे सबक आख़िरकार खुद झेलकर ही सीखे जाते हैं

• जिसने simple solution जल्दी दे दिया, वह बचे समय में कई और features implement कर सकता है
  दूसरी ओर, complex solution में उलझा व्यक्ति एक ही feature पर हफ़्तों खर्च कर देता है
  आखिरकार productivity metrics में simple approach ज़्यादा आकर्षक दिखती है
  मैंने भी “बड़े idea” वाले व्यक्ति की बजाय लगातार परिणाम देने वाले इंसान के रूप में अपना career बनाया है

  • लेकिन अगर चीज़ बहुत simple हो, तो यह जोखिम भी है कि आप “सिर्फ छोटे features” करने वाले व्यक्ति जैसे दिखें
  • और किसी ने “male-centric expression” पर आपत्ति की, लेकिन मूल बात result-driven culture थी

• हमारी कंपनी के एक इंटरव्यू में public library system design का सवाल होता है
  यह पहले छोटे शहर की library से शुरू होता है, फिर national scale तक बढ़ने वाले scenario पर जाता है
  सबसे अच्छा जवाब यह था कि “अधिकतम scale पर भी mid-range server और Postgres काफ़ी हैं”

  • लेकिन कुछ interviewers “10,000 requests per second” जैसी अवास्तविक scale माँगते हैं
    हक़ीक़त में 10 हो या 10,000, फ़र्क उतना बड़ा नहीं होता; अक्सर अनुभवहीन interviewer बस prompt पढ़ रहा होता है
  • यह नहीं भूलना चाहिए कि “हर कंपनी Spotify-level system design नहीं करती”
  • शुरुआती web में server room के एक कोने में रखे hardware से भी सैकड़ों requests संभल जाती थीं
    बाद में बेवजह infrastructure और resume-driven development ने समस्या बढ़ाई

• मुझे लगता है AI आखिरकार user की क्षमता को amplify करने वाला tool है
  skilled developer के लिए यह productivity बढ़ाता है, लेकिन कमज़ोर व्यक्ति के लिए यह confusion को तेज़ी से फैलाने वाला tool बन जाता है

  • मैं simplicity पसंद करने वाला engineer हूँ, लेकिन AI मेरे code को ज़्यादा simple नहीं बना पाया
    उलटे यह अनावश्यक wrapper functions और type conversions जोड़ने की प्रवृत्ति रखता है
    मुझे AI ज़्यादा “और code जोड़ने” वाली चीज़ लगता है
  • लेकिन कम अनुभव होने पर भी अगर critical learning attitude के साथ AI इस्तेमाल किया जाए, तो PR से पहले अपना code खुद बेहतर बनाने में मदद मिल सकती है
  • मुझे भी ChatGPT Codex के कारण ऐसा काम शुरू करने में मदद मिली जिसे शुरू करना मुश्किल था
    लेकिन गहराई के बिना बढ़ती “vibe coding” चिंता की बात है

[roxie]

मुझे नहीं लगता कि इस लेख में दिए गए सुझाव बेकार हैं, लेकिन मुझे लगता है कि वे "grand design" को मात देने के लिए बहुत कमज़ोर हैं। क्योंकि उस पक्ष को समझाना बहुत, बहुत आसान है :(

[yangeok]

जिन इंटरव्यूअर्स से मैं मिला, वे भी जटिलता को पसंद करते थे।

[botplaysdice]

मैं तो यह उम्मीद भी नहीं करता कि सादगी को अच्छी चीज़ मानकर सराहा जाएगा। हक़ीक़त यह है कि लोग चीज़ों को बेवजह जटिल बनाकर गड़बड़ कर देते हैं, और फिर उसी गड़बड़ी को संभाल लेने के आधार पर प्रमोशन भी पा लेते हैं।

[beoks]

सेवा के लिए डिज़ाइन करने के बजाय, अपनी क्षमता बढ़ा-चढ़ाकर दिखाने के लिए की जाने वाली overengineering हर जगह फैली हुई है।

[shakespeares]

मेरा मानना है कि मूल्यांकन करने वाले की समझ अच्छी होनी चाहिए।
और यह भी सही है कि स्पष्टीकरणों को पर्याप्त रूप से सुना जाना चाहिए।

[botplaysdice]

अगर ऐसे लोगों का आकलन करने लायक लोग ऊपर बैठे हों तो सब ठीक है, लेकिन शुरुआत से ही वह संभव नहीं होता, इसलिए ऐसी चीज़ों का निष्पक्ष मूल्यांकन नहीं हो पाता, और इसलिए ऐसे लोग ऊपर नहीं जा पाते...

यही दुष्चक्र है...

कंपनी के नज़रिए से देखें तो, लगता है कि balanced engineer के रूप में सफल होकर ऊपर जाना चाहिए, तभी अच्छे engineer/engineering principles को भी बनाए रखा जा सकता है.

[aa1567]

ज़्यादातर हक़ीक़त में बात क्या यही नहीं होती कि कोई सिर्फ़ साधारण तरीके से फीचर implement कर पाता है, जबकि कोई दूसरा scalability को ध्यान में रखकर design कर सकता है और trade-off को भी अच्छी तरह समझता है?

[devsepnine]

काम जटिल तरीके से किया हो, तब भी उसे feature X का implementation ही कहा जा सकता है.
आखिर फर्क इस बात का है कि आप evaluator के सामने उसे किस तरह पेश करते हैं.