शीर्ष 1% इंजीनियरों की 7 सरल आदतें

• "एलीट कोडर दूसरे कोडरों से बेहतर प्रदर्शन कैसे करते हैं"

कोडर नहीं, इंजीनियर बनें (Be an engineer, not a coder)

• इंजीनियरिंग का मतलब समस्याओं को हल करना है
• बेहतरीन इंजीनियर कोड को लक्ष्य हासिल करने का एक साधन मानते हैं
• कोड लिखने में आनंद है, लेकिन बिना उद्देश्य के कोड लिखना अर्थहीन है। इसके बजाय, कोड का उपयोग उपयोगकर्ताओं के लिए समाधान डिज़ाइन करने में किया जाता है
• कोडिंग रचनात्मकता को आगे बढ़ाती है! रचनात्मकता अक्सर सीमाओं के भीतर पैदा होती है। जब "हल की जाने वाली स्पष्ट समस्या" जैसी एक सीमा जुड़ती है, तो इंजीनियरों को उस तरीके से समाधान खोजने और बनाने की आज़ादी मिलती है जिसे वे उपयुक्त समझते हैं
• बेहतरीन इंजीनियर product-centric होते हैं और सबसे बढ़कर लोगों की समस्याएँ हल करने को प्राथमिकता देते हैं, और यही अगली बात की ओर ले जाता है

कंप्यूटर के लिए नहीं, इंसानों के लिए कोड लिखें (Code for the human, not the computer)

"कोई भी मूर्ख ऐसा कोड लिख सकता है जिसे कंप्यूटर समझ सके। महान प्रोग्रामर ऐसा कोड लिखते हैं जिसे इंसान समझ सकें।" - Martin Fowler

• कोड सिर्फ कंप्यूटर के लिए नहीं, इंसानों के लिए भी होता है
• कोड उन इंजीनियरों के लिए होता है जो उसी टीम में उसे पढ़ेंगे, maintain करेंगे, और आपके कोड के ऊपर build करेंगे
• कोड उन उपयोगकर्ताओं के लिए होता है, चाहे वह मोबाइल फोन इस्तेमाल करने वाला बच्चा हो, API कॉल करने वाला developer हो, या आप खुद हों
• बेहतरीन इंजीनियर हमेशा सभी उपयोगकर्ताओं के लिए कोड की value का आकलन करते थे
• अगर उनका कोई एक भी ग्राहक संतुष्ट नहीं होता, तो वह कोड production में नहीं जाता था

कोड से खुद को अलग रखना (Detach from the code itself)

• उत्कृष्ट इंजीनियर कोड से भावनात्मक लगाव नहीं रखते
• अगर अंतिम परिणाम कुल मिलाकर बेहतर हो सकता हो, तो वे 90% तक तैयार कोड को भी हटाकर फिर से शुरू करने से नहीं डरते
• वे feedback को खुलकर स्वीकार करते हैं क्योंकि कोड कोई व्यक्तिगत चीज़ नहीं है
• कोड परिपूर्ण नहीं होता। किसी को perfect code में दिलचस्पी नहीं होती। दिलचस्पी सिर्फ ऐसे कोड में होती है जो बदलाव लाए
• खुद को कोड से अलग रखना सीखने का सबसे अच्छा तरीका है यह समझना कि "20 साल बाद आपके अधिकांश कोड के technical debt बन जाने, इस्तेमाल से बाहर हो जाने, या दोबारा लिखे जाने की संभावना है"

एकसमान मानकों का उपयोग करें (Use consistent standards)

• कोड लिखते समय consistent standards और coding style का पालन करें
• consistency बनाए रखने से भविष्य के आप और आपकी टीम दोनों के लिए कोड पढ़ना और समझना आसान हो जाता है
• एक समान style guide का उपयोग करने से टीम और codebase, दोनों को scale करना आसान हो जाता है
  • यही तरीका है जिससे Meta/Google जैसी कंपनियाँ समय के साथ codebase को अपठनीय या unmaintainable बनाए बिना बहुत सारा कोड तेज़ी से deploy करती हैं
• हर high-performing कंपनी ने style guide को अपने काम में शामिल किया, उसके फायदे समझे, और जहाँ तक संभव हो उसका पालन किया
  • Google ने अपनी कुछ style guides को open source किया है
  • Meta के कुछ open source प्रोजेक्ट्स में C++ style guide मौजूद है
• टिप: अपनी टीम के लिए linter formatting सेट करना निश्चित ही समय देने लायक है

सरल कोड लिखें (Write simple code)

• जितने भी elite engineers को मैं जानता हूँ, उन्होंने ऐसा कोड बनाया जो बनाते समय शायद जटिल रहा हो, लेकिन अंत में पढ़ने और समझने में आसान था
• इसके बारे में मैं सबसे अच्छी बात यह कह सकता हूँ कि उनका कोड "सौंदर्य की दृष्टि से संतोषजनक" होता था
• उनका कोड clean, organized, and logical होता था
• कोड में लिया गया हर निर्णय सार्थक था, और जहाँ ऐसा नहीं था, वहाँ उसे कोड में अच्छी तरह document किया गया था
• साफ-सुथरा कोड लिखने का अच्छा तरीका है SOLID principles जैसे सिद्धांतों का पालन करना। इन्हें शुरू में OOP (Object-Oriented Programming) को ध्यान में रखकर बनाया गया था, लेकिन इन्हें सामान्य programming पर भी लागू किया जा सकता है
  • Single Responsibility: एक class की सिर्फ एक ही responsibility होनी चाहिए
  • Open-Closed: software objects (class, module आदि) विस्तार के लिए खुले लेकिन बदलाव के लिए बंद होने चाहिए, ताकि अनुमानित और maintainable code बनाया जा सके
  • Liskov Substitution: subtypes को base types के स्थान पर इस तरह इस्तेमाल किया जा सके कि program की correctness पर असर न पड़े
  • Interface Segregation: कोड को ऐसे विशाल interface पर निर्भर नहीं होना चाहिए जिसका वह सब कुछ उपयोग ही न करे। इसके बजाय, packages को छोटे और विशिष्ट interfaces शामिल व import करने की अनुमति होनी चाहिए
  • Dependency Inversion: high-level modules को low-level modules पर निर्भर नहीं होना चाहिए; दोनों को abstractions पर निर्भर होना चाहिए ताकि अधिक flexible और decoupled system design को बढ़ावा मिले
• इसका एक उदाहरण naming है: अच्छे नामों में कोई जादुई values नहीं होतीं, उनमें स्पष्ट भेद होता है, और वे descriptive function names तथा आसानी से समझ आने वाले variables व्यक्त करते हैं

अनपेक्षित चीज़ों की गुंजाइश न छोड़ें (Don’t allow surprises)

• कोड से अप्रत्याशित परिणाम नहीं आने चाहिए। यह code principles का पालन करने और उचित tests लिखने से संभव है
• अच्छा कोड predictability देता है
• tests कोड की स्पष्टता और predictability को मजबूत करते हैं, और आत्मविश्वास देते हैं। बेहतरीन automated tests के साथ टीम बिना छिपे हिस्सों को तोड़ने की चिंता के कोड बदल सकती है
• कुछ तरह के tests
  • अलग-अलग components और isolated functions के लिए unit tests
  • कई components के बीच interaction के लिए integration tests
  • user के नज़रिए से पूरे system की functionality जाँचने के लिए end-to-end tests
• tests सरल होने चाहिए। failed test पढ़ते ही आसानी से समझ आ जाना चाहिए कि क्या गड़बड़ हुआ
• यह जानना भी महत्वपूर्ण है कि किन चीज़ों का test नहीं करना चाहिए
  • उदाहरण के लिए, अगर end-to-end tests की मेहनत program के वास्तविक लाभ से अधिक हो, तो testing की जगह सावधानीपूर्वक documentation, monitoring, और उपयुक्त लोगों (जैसे code owner) को alerts भेजना बेहतर हो सकता है
  • साथ ही, tests को implementation details की जाँच नहीं करनी चाहिए, जैसे frontend code में किसी खास CSS selector का test करना, या सिर्फ data attributes अथवा screenshot tests पर निर्भर रहना

अक्सर संवाद करें (Communicate often)

• बेहतरीन systems अकेले नहीं बनते। बेहतरीन इंजीनियर design reviews से गुज़रते थे, feedback माँगते थे, और कोड के शुरुआती design को लगातार दोहराकर बेहतर बनाते थे
• हर व्यक्ति के ज्ञान में कुछ न कुछ खाली जगह होती है जिसे कोई और भर सकता है। नया दृष्टिकोण अक्सर कोड को अधिक स्पष्ट बनाने या ऐसा नया तरीका देने में मदद करता है जिसके बारे में पहले सोचा न गया हो
• बेहतरीन इंजीनियर बेहतर अंतिम परिणाम पाने के लिए साथ काम करने में समय लगाने से नहीं डरते थे, और communication व collaboration को महत्व देते थे
• यह उतना सरल भी हो सकता है जितना किसी दस्तावेज़ की त्वरित समीक्षा के लिए टीममेट को ping करना, या किसी महत्वपूर्ण pull request में code reviewer जोड़ना

तेज़ी से... और धीरे कोड करें (Code fast… and slow)

• जिन बेहतरीन इंजीनियरों को मैं जानता हूँ, वे projects जल्दी पूरा करते हैं लेकिन coding धीरे करते हैं
• अजीब लगता है, है न?
  • ऊपर दिए गए सभी principles और habits coding के शुरुआती चरण में अधिक समय जोड़ते हैं। लेकिन इन्हीं principles और habits के ज़रिए इंजीनियर project की प्रगति को एक-एक कदम आगे बढ़ा पाते हैं
  • standards का उपयोग करने, सही testing करने, principles अपनाने, और बार-बार संवाद करने में समय लगाकर, वे लंबी अवधि में अधिक समय बचा लेते हैं
• intern और junior engineer के समय मैंने इसे खुद अनुभव किया है, और कई अन्य इंजीनियरों ने भी शायद यही देखा होगा: 3 कदम आगे बढ़ने की जल्दबाज़ी कभी-कभी किसी बाधा से टकराकर 5 कदम पीछे ले जाती है

नियमों का आँख बंद करके पालन न करें (Don’t follow rules blindly)

• ऊपर बताए गए "नियम" और "सिद्धांत" सिर्फ guidelines हैं। हर चीज़ इन guidelines में साफ-सुथरे तरीके से फिट नहीं बैठती
• कभी-कभी आप जो कोड लिख रहे होते हैं, वह गोल छेद में फिट न होने वाला चौकोर टुकड़ा हो सकता है, और यह ठीक है
  • ऐसे मामलों में यह document करें कि कोड किसी खास तरीके से क्यों लिखा गया
  • नहीं तो भविष्य में आप जैसा कोई व्यक्ति कोड देखकर सोच सकता है, "वाह, उस समय मैं कितना बेवकूफ था। यह हमारे standards का पालन क्यों नहीं कर रहा?"
  • फिर वह उसी निष्कर्ष तक दोबारा पहुँचने के लिए 20 घंटे standards के हिसाब से code फिर से लिखने में बिता देगा
• software development की वास्तविकता यह है कि हर कोड साफ-सुथरा नहीं हो सकता या नियमों का पूरी तरह पालन नहीं कर सकता
• लेकिन consistent, clean, easy-to-understand, testable, और valuable code ज़रूर मौजूद हो सकता है
• बेहतरीन इंजीनियरों में देखे गए कुछ और पैटर्न
  • कम-से-कम एक क्षेत्र में गहरी domain knowledge रखते हैं। जिन भी इंजीनियरों को मैंने नोट किया, वे frontend infrastructure, distributed systems, clean UI जैसे किसी खास क्षेत्र पर फोकस करके विशेषज्ञ बने, और इसी वजह से आज अपने क्षेत्र में शीर्ष स्तर पर हैं
  • वे अपने आप को नियमित और सही तरीके से market भी करते हैं। ये इंजीनियर नज़र से दूर छिपे नहीं रहते थे। उनके साथ काम करने वाले सभी लोग उनकी value और expertise जानते थे, और यह उचित self-marketing तथा impactful projects पर काम करने का परिणाम था

[greety]

मुझे अच्छी insights मिलीं। धन्यवाद :)

[geekbini]

अच्छा लेख है!

[nina514]

तकनीक भी महत्वपूर्ण है, लेकिन आखिरकार लोगों के लिए फायदेमंद product बनाना ज़्यादा महत्वपूर्ण है—यह बात फिर से सोचने पर मजबूर करती है!!!

[functor]

अच्छे लेख के लिए धन्यवाद!

[functor]

अब देखा तो 7 आदतें हैं, लेकिन अंदर की सामग्री तो 9 बातें बता रही है lol

[xguru]

मैंने भी गिनकर देखा.. लगता है सबसे पीछे वाला और सबसे आगे वाला बस title ही हैं! haha

[saalome]

वाह, यह एक शानदार लेख है जिससे ज़्यादातर बातों पर सहमति बनती है, हाहा

[saalome]

अब तक इस तरह के जो भी लेख मैंने देखे हैं, उनमें यह अब तक का सबसे बेहतरीन कंटेंट है।

[rsm0503]

थोड़ा सा सामान्यीकृत करें तो यह एक अच्छा लेख है जो सभी के लिए मददगार हो सकता है।

[kuroneko]

यह तो सारांश से ज़्यादा अनुवाद जैसा लगता है... फिर भी शानदार सारांश के लिए बहुत धन्यवाद।
यह ऐसा लेख है जिसे बार-बार पढ़ने का मन करेगा।

[piriri11]

सच में ऐसा ही है lol, मैं भी इसे बार-बार पढ़ने के लिए संभालकर रखूंगा।