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

• 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 को भी जिसने "अभी इसकी ज़रूरत नहीं है" कहा और सही साबित हुआ