- बेहतरीन इंजीनियर वे नहीं होते जो सबसे अच्छे programmer हों, बल्कि वे होते हैं जिन्होंने code के आसपास के लोगों, राजनीति, समन्वय और अस्पष्टता को समझकर आगे बढ़ना सीख लिया हो
- यह लेख तकनीक से ज़्यादा project और team में बार-बार दिखने वाले patterns पर केंद्रित है, और user problems, team collaboration, code quality, career management आदि को समेटता है
- यह दिखाता है कि clarity senior engineer की मुख्य पहचान है, जबकि cleverness सिर्फ overhead है, और यह भी कि जो code लिखा ही नहीं गया वही सबसे अच्छा code है
- बड़े संगठनों में alignment की विफलता ही गति धीमी होने का मुख्य कारण होती है, और जब metrics ही लक्ष्य बन जाते हैं तो वे विकृत हो जाते हैं — यह संगठन संचालन की एक आम भूल है
- लंबे समय के नज़रिए से समय, पैसे से अधिक मूल्यवान संसाधन बन जाता है, और network हर नौकरी से ज़्यादा लंबा चलता है, इसलिए career को सोच-समझकर डिज़ाइन करना ज़रूरी है
1. सबसे अच्छे इंजीनियर user problems हल करने को लेकर जुनूनी होते हैं
- पहले किसी तकनीक से प्रभावित होकर उसके लिए उपयोग ढूँढना आकर्षक लगता है, लेकिन सबसे अधिक value बनाने वाले engineer उल्टा काम करते हैं — वे user problem को गहराई से समझते हैं और वहीं से solution निकालते हैं
- user obsession का मतलब है support tickets पर समय लगाना, users से बात करना, उनकी कठिनाइयों को देखना, और जड़ तक पहुँचने तक "क्यों" पूछते रहना
- जो engineer समस्या को सचमुच समझते हैं, वे अक्सर पाते हैं कि elegant solution अनुमान से अधिक simple होता है
- जो engineer solution से शुरुआत करते हैं, वे उसे सही ठहराने के लिए complexity खड़ी करने की ओर झुकते हैं
2. सही होना आसान है, लेकिन साथ मिलकर सही निष्कर्ष तक पहुँचना ही असली काम है
- आप हर technical debate जीतकर भी project हार सकते हैं, और ऐसे बेहतरीन engineers को देखा गया है जो हमेशा कमरे में सबसे smart व्यक्ति बनकर चुपचाप नाराज़गी जमा कर लेते हैं
- इसकी कीमत बाद में "रहस्यमय execution issues" और "अजीब resistance" के रूप में सामने आती है
- असली skill सही होना नहीं, बल्कि problem alignment के लिए चर्चा में भाग लेना, दूसरों के लिए जगह बनाना, और अपनी ही certainty पर संदेह बनाए रखना है
- मजबूत राय, कमजोर आसक्ति — इसलिए नहीं कि विश्वास कम है, बल्कि इसलिए कि अनिश्चितता में लिए गए फ़ैसलों को अपनी पहचान से नहीं बाँधना चाहिए
3. action bias के साथ ship करो। खराब page को edit किया जा सकता है, खाली page को नहीं
- perfection की चाह अक्सर paralysis पैदा करती है, और ऐसे engineers दिखते हैं जो किसी ऐसी चीज़ की ideal architecture पर हफ्तों बहस करते रहते हैं जिसे उन्होंने कभी बनाया ही नहीं
- perfect solution सिर्फ सोचने से नहीं, बल्कि reality के संपर्क में आने से उभरता है, और AI इसमें कई तरीकों से मदद कर सकता है
- पहले करो, फिर ठीक करो, फिर बेहतर करो — users के सामने एक बदसूरत prototype रखो, design document का गंदा draft लिखो, और थोड़ा शर्मिंदा करने वाला MVP ship करो
- एक हफ्ते की real feedback से उतना सीखते हैं जितना एक महीने की theoretical बहस से नहीं, क्योंकि momentum clarity बनाता है और analysis paralysis कुछ भी नहीं बनाता
4. clarity seniority की पहचान है, cleverness overhead है
- clever code लिखने की प्रवृत्ति लगभग हर engineer में होती है और यह अपनी क्षमता साबित करने जैसा महसूस होता है
- software engineering तब पैदा होती है जब समय और दूसरे programmers जुड़ते हैं, और उस माहौल में clarity कोई style preference नहीं बल्कि operational risk कम करने का तरीका है
- code दरअसल उन अजनबियों के लिए एक रणनीतिक memo है जिन्हें रात 2 बजे outage के दौरान इसे maintain करना होगा, इसलिए optimization elegance के लिए नहीं बल्कि उनकी समझ के लिए होना चाहिए
- सबसे सम्मानित senior engineers वे हैं जिन्होंने हर बार cleverness के बदले clarity चुनना सीख लिया है
5. novelty एक कर्ज़ है, जिसकी कीमत outages, hiring और cognitive overhead से चुकानी पड़ती है
- technology choices को ऐसे लो जैसे संगठन के पास छोटे "innovation token" budget हों, और हर बार जब आप कोई सचमुच non-standard चीज़ अपनाते हैं तो एक token खर्च हो जाता है — आप बहुत ज़्यादा नहीं झेल सकते
- बात यह नहीं कि "कभी innovate मत करो", बल्कि "सिर्फ वहीं innovate करो जहाँ unique innovation के लिए reward मिलता हो"; बाकी जगह boring होना default होना चाहिए
- boring चीज़ों के failure modes पहले से जाने-पहचाने होते हैं
- "काम के लिए best tool" अक्सर "कई कामों में least-worst tool" निकलता है — क्योंकि tool zoo चलाना खुद एक real tax है
6. code आपकी तरफ़दारी नहीं करता, लोग करते हैं
- career की शुरुआत में लगा कि अच्छा काम खुद बोलेगा, लेकिन यह ग़लत निकला; code बस repository में चुपचाप पड़ा रहता है
- manager मीटिंग में आपका ज़िक्र कर सकता है या नहीं, और colleague project के लिए आपका नाम आगे बढ़ा सकता है या किसी और का
- बड़े संगठनों में वे लोग फ़ैसले लेते हैं जिनके पास 5 मिनट और 12 priorities होती हैं, ऐसी meetings में जिनमें आपको बुलाया नहीं गया, और उन summaries के आधार पर जिन्हें आपने खुद नहीं लिखा
- अगर जिस कमरे में आप नहीं हैं वहाँ कोई आपके impact को बयान नहीं कर सकता, तो वह impact व्यवहार में वैकल्पिक बन जाता है; यह self-promotion नहीं बल्कि value chain को अपने सहित सभी के लिए readable बनाना है
7. सबसे अच्छा code वह है जिसे लिखना ही न पड़े
- engineering culture creation का जश्न मनाती है, लेकिन अक्सर deletion addition से ज़्यादा system सुधारती है, फिर भी code delete करने पर किसी को promotion नहीं मिलता
- code की हर अनलिखी line ऐसी line है जिसे debug, maintain या explain नहीं करना पड़ेगा
- build करने से पहले इस सवाल को अंत तक पूछना चाहिए: "अगर हम बस... यह न करें तो क्या होगा?" — कभी-कभी जवाब होता है "कुछ बुरा नहीं होगा", और वही solution है
- समस्या यह नहीं कि engineers code नहीं लिख सकते या AI से नहीं लिखवा सकते, बल्कि यह कि वे इतना अच्छा लिख सकते हैं कि यह पूछना भूल जाते हैं कि क्या इसे लिखना भी चाहिए
8. scale पर bugs के भी users बन जाते हैं
- जब users काफ़ी ज़्यादा हों, तो हर observable behavior dependency बन जाता है, चाहे वह official promise हो या नहीं — कोई API scrape कर रहा होता है, कोई edge case automate कर रहा होता है, कोई bug को cache कर रहा होता है
- इससे career-level insight मिलती है: compatibility work को "maintenance" और नई features को "real work" नहीं कहा जा सकता, क्योंकि compatibility ही product बन जाती है
- deprecation को migration की तरह design करना चाहिए — समय, tools और empathy के साथ
- ज़्यादातर "API design" असल में "API retirement" भी होता है
9. ज़्यादातर "slow" teams वास्तव में misaligned teams होती हैं
- जब project delay होता है, तो instinct execution को दोष देती है — लोग काफ़ी मेहनत नहीं कर रहे, technology ग़लत है, engineers कम हैं — लेकिन अक्सर असली समस्या यह नहीं होती
- बड़ी companies में team concurrency की unit होती है, लेकिन teams जितनी बढ़ती हैं coordination cost उतनी ही गुणात्मक रूप से बढ़ती है
- ज़्यादातर slowness दरअसल alignment failure होती है — ग़लत चीज़ बनाना, या सही चीज़ को असंगत तरीकों से बनाना
- senior engineer "तेज़ code लिखने" से ज़्यादा समय direction, interfaces और priorities clear करने में लगाते हैं, क्योंकि असली bottleneck वहीं होता है
10. जो आपके control में है उसी पर ध्यान दो, बाकी को छोड़ दो
- बड़ी companies में बहुत-सी variables आपके control से बाहर होती हैं — org changes, management decisions, market shifts, product pivots — और इन पर अटकना agency के बिना anxiety पैदा करता है
- जो engineers sane और effective रहते हैं, वे अपने influence के दायरे पर focus करते हैं — reorg होगा या नहीं यह आप control नहीं कर सकते, लेकिन अपने काम की quality, अपनी response और अपनी learning control कर सकते हैं
- uncertainty के सामने समस्या को टुकड़ों में तोड़कर उन specific actions की पहचान करनी चाहिए जो आप कर सकते हैं
- यह passive acceptance नहीं बल्कि strategic focus है; जिसे आप बदल नहीं सकते उस पर खर्च ऊर्जा, जिसे बदल सकते हैं उससे चुराई हुई ऊर्जा है
11. abstraction complexity हटाती नहीं, उसे उस समय तक टाल देती है जब आप oncall पर हों
- हर abstraction एक शर्त है कि आपको नीचे क्या है यह समझने की ज़रूरत नहीं पड़ेगी, और कभी-कभी यह शर्त जीत भी जाती है
- लेकिन कुछ न कुछ हमेशा leak होता है, और जब leak होता है तो आपको यह जानना पड़ता है कि आप किस पर खड़े हैं
- senior engineers stack ऊँचा होने पर भी "lower-level" चीज़ें सीखते रहते हैं — nostalgia में नहीं, बल्कि उस सम्मान में कि abstractions fail होती हैं और कभी रात 3 बजे आप system के साथ अकेले होंगे
- stack का उपयोग करो, लेकिन उसके default failure modes का working model भी बनाए रखो
12. लिखना clarity को मजबूर करता है। किसी चीज़ को बेहतर सीखने का सबसे तेज़ तरीका है उसे सिखाने की कोशिश करना
- writing clarity को मजबूर करती है, और जब आप किसी concept को दूसरे को समझाते हैं — docs, talks, code review comments, यहाँ तक कि AI के साथ chat में — तब आप अपनी understanding के gaps पकड़ते हैं
- किसी चीज़ को दूसरों के लिए readable बनाना, उसे अपने लिए भी अधिक readable बना देता है
- इसका मतलब यह नहीं कि आप surgeon बनना सिखाकर surgery सीख लें, लेकिन software engineering के दायरे में यह बात अधिकतर सही बैठती है
- यह सिर्फ knowledge share करने की generosity नहीं, बल्कि एक self-serving learning hack भी है — अगर लगता है कि आप कुछ समझते हैं, तो उसे सरल शब्दों में समझाने की कोशिश करें; जहाँ अटकें, वहीं समझ उथली है
- teaching अपने mental model को debug करना है
13. वह काम जो दूसरे काम को संभव बनाता है, मूल्यवान होता है लेकिन अक्सर अदृश्य रहता है
- glue work — documentation, onboarding, team coordination, process improvement — ज़रूरी है, लेकिन अगर इसे बिना सोचे-समझे किया जाए तो यह technical trajectory रोक सकता है और burnout ला सकता है
- जाल यह है कि इसे सिर्फ "helpful" बनाकर करना, न कि intentional, bounded और visible impact के साथ करना
- इसे time-box करना चाहिए, rotate करना चाहिए, और deliverables में बदलना चाहिए: docs, templates, automation — और इसे personality trait नहीं बल्कि impact की तरह readable बनाना चाहिए
- जो चीज़ मूल्यवान भी हो और अदृश्य भी, वह career के लिए खतरनाक combination है
14. अगर आप हर बहस जीत रहे हैं, तो शायद आप चुपचाप resistance जमा कर रहे हैं
- अपनी certainty पर संदेह करना सीखना पड़ा, क्योंकि जब आप बहुत आसानी से "जीत" जाते हैं, तो अक्सर कुछ न कुछ ग़लत होता है
- लोग आपसे लड़ना इसलिए बंद नहीं करते कि आप उन्हें convince कर चुके हैं, बल्कि इसलिए कि वे हार मान चुके हैं, और फिर उस disagreement को meeting में नहीं बल्कि execution में दिखाते हैं
- सच्चा alignment ज़्यादा समय लेता है — दूसरे perspectives को सचमुच समझना, feedback absorb करना, और कभी-कभी publicly अपना mind बदलना
- सही होने का short-term एहसास, उन colleagues के साथ कुछ बनाने की long-term reality से बहुत कम मूल्यवान है जो वास्तव में साथ काम करना चाहते हैं
15. जब measurement ही goal बन जाए, तो वह measurement रह नहीं जाता
- management के सामने रखी गई हर metric आख़िरकार game हो जाती है, किसी बुरी नीयत से नहीं बल्कि इसलिए कि इंसान वही optimize करते हैं जिसे मापा जाता है
- lines of code track करो तो ज़्यादा lines मिलेंगी, velocity track करो तो inflated estimates मिलेंगे
- senior move यह है: हर metric request का pair में जवाब दो — एक speed के लिए, एक quality या risk के लिए — और फिर threshold worship नहीं बल्कि trend interpretation पर ज़ोर दो
- लक्ष्य insight होना चाहिए, surveillance नहीं
16. यह मान लेना कि आप नहीं जानते, जानने का नाटक करने से ज़्यादा safety बनाता है
- "मुझे नहीं पता" कहने वाला senior engineer कमज़ोरी नहीं दिखाता, बल्कि permission create करता है
- जब leader uncertainty स्वीकार करता है, तो यह signal जाता है कि बाकी लोग भी ऐसा कर सकते हैं; वरना संस्कृति ऐसी बनती है जहाँ सब समझने का नाटक करते हैं और समस्या फटने तक छिपी रहती है
- ऐसे teams देखे गए हैं जहाँ सबसे senior व्यक्ति confusion नहीं मानता, और उसका नुकसान साफ़ दिखता है — सवाल नहीं आते, assumptions challenge नहीं होतीं, और junior engineers चुप रहते हैं क्योंकि उन्हें लगता है कि बाकी सभी समझ रहे हैं
- अगर आप curiosity model करते हैं, तो आपको सचमुच सीखने वाली team मिलती है
17. आपका network आपकी हर नौकरी से ज़्यादा लंबा चलता है
- career की शुरुआत में काम पर focus किया गया और networking की उपेक्षा की गई, और पीछे मुड़कर देखें तो यह गलती थी
- जिन colleagues ने relationships में निवेश किया — company के भीतर और बाहर — उन्होंने दशकों तक उसका लाभ लिया
- उन्हें opportunities की ख़बर पहले मिलती थी, वे तेज़ी से bridges बना पाते थे, roles के लिए recommend होते थे, और सालों के trust पर ventures co-found करते थे
- नौकरियाँ स्थायी नहीं होतीं, लेकिन network हर नौकरी से लंबा चलता है — इसे transactional hustle की तरह नहीं, curiosity और generosity के साथ अपनाना चाहिए
- जब जाने का समय आता है, तो अक्सर रिश्ते ही दरवाज़े खोलते हैं
18. performance में ज़्यादातर सुधार cleverness जोड़ने से नहीं, काम हटाने से आते हैं
- जब system slow होता है, तो instinct कुछ जोड़ने की होती है — caching layer, parallelization, smarter algorithm — और कभी-कभी यह सही भी होता है, लेकिन ज़्यादा performance gains अक्सर इस सवाल से आते हैं: "ऐसा क्या है जिसे हमें compute ही नहीं करना चाहिए?"
- अनावश्यक काम हटाना लगभग हमेशा ज़रूरी काम को तेज़ करने से अधिक प्रभावशाली होता है, और सबसे तेज़ code वही है जो चलता ही नहीं
- optimize करने से पहले यह पूछना चाहिए कि यह काम होना भी चाहिए या नहीं
19. process uncertainty घटाने के लिए होता है, paperwork trail बनाने के लिए नहीं
- सबसे अच्छे process coordination आसान बनाते हैं और failures सस्ते, जबकि सबसे बुरे process bureaucratic theatre होते हैं — मदद के लिए नहीं, बल्कि गड़बड़ी होने पर blame assign करने के लिए
- अगर आप यह नहीं समझा सकते कि कोई process risk कैसे घटाता है या clarity कैसे बढ़ाता है, तो वह शायद सिर्फ overhead है
- अगर लोग काम करने से ज़्यादा समय काम को document करने में लगा रहे हैं, तो कुछ गंभीर रूप से ग़लत है
20. अंततः समय पैसे से अधिक मूल्यवान हो जाता है, और उसी हिसाब से जीना चाहिए
- career की शुरुआत में समय को पैसे से बदला जाता है, और यह ठीक है, लेकिन एक समय आता है जब हिसाब उलट जाता है — तब समझ आता है कि समय non-renewable resource है
- ऐसे senior engineers देखे गए हैं जो अगले promotion level के पीछे भागते-भागते, compensation के कुछ percentage points और optimize करते-करते burnout हो जाते हैं
- कुछ को वह मिला भी, लेकिन बाद में ज़्यादातर ने यह पूछा कि जो छोड़ा, क्या वह इसकी कीमत के लायक था?
- जवाब यह नहीं कि "कड़ी मेहनत मत करो", बल्कि "जानो कि आप क्या exchange कर रहे हो, और उसे इरादे से करो"
21. कोई shortcut नहीं है, लेकिन compounding है
- expertise deliberate practice से आती है — अपनी मौजूदा skill से थोड़ा आगे खुद को धकेलना, reflection करना, दोहराना — सालों तक — इसका कोई compressed version नहीं
- उम्मीद की बात यह है कि learning compounding की तरह काम करती है, जब वह सिर्फ नई जानकारी नहीं बल्कि नए विकल्प पैदा करती है
- लिखो — engagement के लिए नहीं बल्कि clarity के लिए — reusable primitives बनाओ, और scar tissue को playbook में बदलो
- जो engineer career को compound interest की तरह treat करते हैं, वे अक्सर उन engineers से बहुत आगे निकल जाते हैं जो इसे lottery ticket की तरह treat करते हैं
अंतिम विचार
- 21 सबक बहुत लग सकते हैं, लेकिन असल में वे कुछ मुख्य विचारों पर आकर टिकते हैं: जिज्ञासु बने रहो, विनम्र बने रहो, और काम हमेशा लोगों के बारे में होता है — उन users के बारे में जिनके लिए आप बनाते हैं और उन teammates के बारे में जिनके साथ आप बनाते हैं
- engineering career इतनी लंबी होती है कि आप बहुत-सी गलतियाँ करके भी आगे निकल सकते हैं, और सबसे सम्मानित engineers वे नहीं होते जिन्होंने सब कुछ सही किया, बल्कि वे होते हैं जिन्होंने गलतियों से सीखा, जो सीखा उसे बाँटा, और लगातार बने रहे
- अगर आप यात्रा की शुरुआत में हैं, तो यह जानना उपयोगी है कि समय के साथ यह सब और समृद्ध होता जाता है; और अगर आप गहराई में हैं, तो उम्मीद है इसमें से कुछ बातें आपसे resonate करेंगी
अभी कोई टिप्पणी नहीं है.