दयालु Engineering

दयालुता क्या है?

Kind is about being invested in other people, figuring out how to help them, meeting them where they are.

दयालुता का मतलब है दूसरे लोगों में निवेश करना, उनकी मदद कैसे की जाए यह समझना, और उन्हें वहीं पर मिलना जहाँ वे हैं।

— Tanya Reilly, Continuous

दयालुता, जैसा ऊपर Tanya Reilly ने कहा है, लोगों में निवेश करने के बारे में है। यह सिर्फ विनम्र होने की बात नहीं है, बल्कि सामने वाले की स्थिति में खुद को रखकर उसकी भावनाओं और पृष्ठभूमि को समझने का अर्थ है। यह हर स्थिति का万能 समाधान नहीं है, लेकिन कई समस्याओं को हल करने में मदद कर सकती है।

आत्मीयता

• सिर्फ "professional" होने से आगे बढ़कर अपने काम में दिल लगाइए।
• खुले और मानवीय तरीके से व्यवहार कीजिए ताकि भरोसा बन सके।
• लोगों से सीधे मिलिए, लेकिन सोच-समझकर उनकी परवाह भी कीजिए।
• छोटी-मोटी सफेद झूठ बुरी नहीं लग सकती, लेकिन वे लोगों को बढ़ने में मदद नहीं करतीं।
• अपनी आत्मीयता बनाए रखिए, अच्छे व्यवहार की सराहना कीजिए और सुधार के बिंदु दीजिए।

asynchronous (async) संवाद

• बदलाव के मामले में सिर्फ "क्या?" और "कैसे?" ही नहीं, बल्कि "क्यों?" को भी ज़्यादा समझने की कोशिश कीजिए।
• दुर्भावना या अयोग्यता मानकर मत चलिए।
• तीखे या विवाद को बढ़ाने वाले कथनों की जगह खुले मन वाले सवाल पूछिए।
• किसी बात की ओर इशारा करने से पहले स्पष्ट labeling होना ज़रूरी है।
• बहुत ज़्यादा pointing out काम में और बड़ी रुकावट बन सकता है।
• अगर राय बहुत अधिक हों, तो संवाद को क्रमिक तरीके में बदलिए।

मनोवैज्ञानिक सुरक्षा

• टीम या सहकर्मियों से सबसे पहले feedback माँगिए।
• feedback की संरचना इस तरह सरल है:
  • क्या अच्छा हुआ
  • क्या गलत हुआ
  • आगे क्या करना है
• लोगों की पृष्ठभूमि, इतिहास और व्यक्तिगत पसंदों को खुलेपन से स्वीकार कीजिए।
• उन लोगों पर ध्यान दीजिए जो मीटिंग या दस्तावेज़ों में बड़ा योगदान नहीं दे पाते, और उनके लिए आवाज़ उठाने का तरीका खोजिए।
• लोगों को जिस भी तरीके से सही लगे, उस तरीके से खुद को व्यक्त करने देने के लिए आवाज़ उठाइए।
• कई बार किसी व्यक्ति की विफलता असल में process, environment, या workflow की विफलता हो सकती है।
• हम साथ में सफल होते हैं, और साथ में असफल भी होते हैं।
• हर "विफलता" या घटना को बढ़ने और सीखने के अवसर के रूप में मनाया जाना चाहिए।
• innovation को बढ़ावा देने के लिए लोगों को जोखिम लेने, चुनौती देने, और यह महसूस करने के लिए प्रोत्साहित करना चाहिए कि ऐसा करना सुरक्षित है।

feedback/आलोचना

• शुरुआत से ही मूल्यांकन करने वाले नहीं, बल्कि सबसे पहले मूल्यांकन पाने वाले बनिए।
• इसे व्यक्तिगत मत बनाइए।
• feedback या प्रशंसा देते समय जितना संभव हो उतना विशिष्ट और thorough होने की कोशिश कीजिए।
• अगर आप किसी को आलोचनात्मक feedback दे रहे हैं, तो समाधान भी सुझाइए।
• अपनी feedback preferences को समझिए।
• सुनिए, समझिए, फिर feedback देने वाले को धन्यवाद दीजिए।
• तुरंत प्रतिक्रिया मत दीजिए; थोड़ा समय लेकर अपने विचार व्यवस्थित कीजिए और feedback को process कीजिए।
• स्पष्टीकरण या उदाहरण माँगिए।
• feedback देने के तीन तत्व याद रखिए:
  • भावना
  • विश्वसनीयता
  • तर्क
• अपनी नहीं, श्रोता की भावनाओं को ध्यान में रखिए।
• विशेषज्ञता और विनम्रता दिखाइए।
• अपना काम करने का तरीका और निष्कर्ष तक पहुँचने की प्रक्रिया दिखाइए।

---

• टेक उद्योग की toxic tone की समस्या, इसे ठीक करें!

[arfwene]

यह तो स्वाभाविक बात है, लेकिन इसे अमल में लाना मुश्किल है..

[aster]

ऊपर की सामग्री के आधार पर, विकास में दयालु इंजीनियरिंग को कैसे लागू किया जा सकता है
इसी को KDD (Kindness Driven Development) कहा गया है, और मैंने इसे AI की मदद से तैयार किया है।

कोड लिखना

• comments और documentation लिखते समय क्यों? पर ज़ोर दें। यह समझाना महत्वपूर्ण है कि code क्यों मौजूद है और उसकी पृष्ठभूमि क्या है।
• जटिल logic में domain terms का उपयोग करते हुए variable names और function names रखें, ताकि दूसरे developers के लिए समझना आसान हो।
• नई technology या pattern अपनाते समय team members की learning curve का ध्यान रखें।
• legacy code को बुरा-भला न कहें। उस समय अपनी सीमाएँ और context रहे होंगे।
• भविष्य के maintainers के लिए edge cases और failure cases के handling को document करें।
  आर्किटेक्चर डिज़ाइन
• system design करते समय operations team और QA team के नज़रिए को भी ध्यान में रखें।
• monitoring और debugging को आसान बनाना भी दयालु डिज़ाइन का हिस्सा है।
• scalable design भविष्य के team members के लिए एक तरह का ध्यान है।
• technical debt को manage करते समय उसका पूरी तरह हटाना नहीं, बल्कि manage किए जा सकने वाले स्तर को लक्ष्य बनाइए।
• ऐसा structure बनाना महत्वपूर्ण है जिसमें नई features जोड़ना आसान हो।
  कोड रिव्यू
• review request करते समय बदलावों का context पर्याप्त रूप से समझाइए।
• ऐसे करें तो कैसा रहेगा? जैसे सुझावात्मक feedback का उपयोग करें।
• सकारात्मक पहलुओं का भी ज़रूर उल्लेख करें। यह हिस्सा सच में बहुत साफ़-सुथरा है
• विकल्प सुझाते समय उसका कारण भी साथ में समझाइए।
• जो improvements तत्काल ज़रूरी नहीं हैं, उन्हें अलग issue के रूप में दर्ज करें और मौजूदा PR के scope का सम्मान करें।
  टेस्ट कोड
• test fail होने पर स्पष्ट error messages दें।
• test cases documentation का काम भी करते हैं। ऐसे tests लिखें जो business rules को अच्छी तरह समझाएँ।
• ऐसा structure बनाइए जिसमें दूसरे developers आसानी से tests जोड़ सकें।
• test data में समझने में आसान, वास्तविक उदाहरणों का उपयोग करें।
• test environment setup को automate करके entry barrier कम करें।
  डिप्लॉयमेंट और संचालन
• deployment scripts में पर्याप्त explanation और guides शामिल करें।
• incident होने पर debugging में मदद करने वाले logs पहले से तैयार रखें।
• अगर configuration changes की ज़रूरत हो, तो उसके impact को document करें।
• नई feature release करते समय rollback plan भी साथ में तैयार रखें।
• operations guide नए developers के नज़रिए से लिखें।
  ज्ञान साझा करना
• troubleshooting के अनुभवों को document करके साझा करें।
• नई technology अपनाते समय learning materials बनाकर साझा करें।
• code writing guide में हमने ऐसा करने का फैसला क्यों किया यह भी शामिल करें।
• नियमित technical sharing sessions के ज़रिए team की growth को बढ़ावा दें।
• सवाल पूछने के लिए अच्छा माहौल बनाना junior developers की growth में मदद करता है।

[bbulbum]

यह इतना अच्छा कंटेंट है कि इसे अलग से लेख के रूप में भी लिखा जा सकता है, हा हा

[laeyoung]

यह बहुत बढ़िया है!

[aer0700]

यह वाकई बहुत अच्छा कमेंट है।