क्या चीज़ किसी डेवलपर को उत्कृष्ट बनाती है

यह लेख Infcon 2023 में दिए गए जूनियर फ्रंटएंड इंजीनियरों के प्रदर्शन और क्षमता-वृद्धि के लिए व्यावहारिक गाइड के भाग 1 के समान है। इसे पहले GeekNews पर साझा किए गए
फ्रंटएंड इंजीनियर करियर रोडमैप: जूनियर के लिए विशेषज्ञता के 3 ट्रैक का वैचारिक उत्तराधिकार भी माना जा सकता है।

---

उत्कृष्ट इंजीनियर कैसा होता है?

Li Paul Luo ने 2015 के शोधपत्र <What Makes a Great Software Engineer?> में उन 5 आवश्यक शर्तों का प्रस्ताव रखा जो किसी इंजीनियर को उत्कृष्ट बनाती हैं। शोध-पद्धति इस प्रकार थी।

• डेवलपरों के लिए आवश्यक शिक्षा, क्षमताओं, व्यवहार आदि पर किए गए अनेक पूर्व शोधों का विश्लेषण
• Microsoft में level 2 या उससे ऊपर के, यानी कुछ हद तक क्षमता-मान्यता प्राप्त 59 डेवलपरों के गहन इंटरव्यू। इससे डेवलपर में होने योग्य 54 संभावित व्यक्तिगत गुण निकाले गए, जैसे व्यक्तित्व, ज्ञान, व्यवहार आदि
• Microsoft के लगभग 2,000 डेवलपरों पर सर्वे। (प्रत्येक गुण का विस्तार से वर्णन करने के बाद) “अगर कोई skilled डेवलपर इस गुण के बिना हो, तो क्या आप उसे उत्कृष्ट डेवलपर मानेंगे?”
• सर्वे परिणामों का विश्लेषण और उत्तरदाताओं के follow-up इंटरव्यू
• सर्वे विश्लेषण और follow-up इंटरव्यू के आधार पर डेवलपरों के मुख्य सहयोगियों (artists, content planners, data scientists, designers, electrical engineers आदि) में से 40 अतिरिक्त लोगों के इंटरव्यू

मैंने लेखक द्वारा प्रस्तावित इन 5 आवश्यक शर्तों के क्रम और व्याख्या को थोड़ा बदलकर, अपने विचार जोड़ते हुए उन्हें इस तरह व्यवस्थित किया है।

1. बेहतरीन कोड लिखें (Be a competent coder)

‘कुशल coder’ की तुलना में ‘बेहतरीन कोड’ को लक्ष्य बनाना अधिक उपयोगी है।

कोडिंग स्किल जूनियर के लिए सबसे महत्वपूर्ण क्षमता है। लेकिन एक निश्चित स्तर के बाद, दूसरी क्षमताओं को विकसित करना अधिक प्रभावी हो जाता है। यह ‘एक निश्चित स्तर’ व्यक्ति और संगठन के अनुसार बदलता है.

मेरे अनुसार जूनियर की कोडिंग क्षमता का आकलन इस आधार पर किया जा सकता है कि वह ‘1) code quality पर अपना सुसंगत दृष्टिकोण रखता हो, 2) customer requirements को पूरा करने वाला कोड लिखता हो, 3) तेज गति से, 4) कम bugs के साथ, 5) और पठनीय तरीके से लिखता हो।’

2. साक्ष्य-आधारित निर्णय लेने का अभ्यास करें (Practice informed decision-making)

निर्णय लेने की क्षमता विकसित करनी हो तो परिणाम की बजाय निर्णय-प्रक्रिया को बेहतर बनाने पर ध्यान देना अधिक लाभकारी है। क्योंकि परिणाम कई बार हमारी इच्छा से अलग भी तय हो सकता है।

और साक्ष्य-आधारित होने का मतलब है डेटा पर आधारित होना, लेकिन डेटा की व्याख्या पूर्वाग्रह के साथ न करना और जल्दबाज़ी में निष्कर्ष न निकालना। खासकर यदि नई जानकारी मिले, तो मन न भी चाहे तब भी rationalize करने के बजाय अपने पुराने निर्णय पर फिर से विचार करना बेहतर है।

खासतौर पर debugging करते समय, अगर मुझे लगे कि समस्या मेरी नहीं बल्कि library या browser की है, तो ज़्यादातर बार मैं ग़लत होता हूँ। और यदि सचमुच browser की समस्या हो भी, तब भी हर मिलती-जुलती समस्या को browser की गलती मान लेना ख़तरनाक है, क्योंकि इससे मेरी अपनी गंभीर गलती भी अनदेखी हो सकती है।

पूर्वाग्रह और जल्दबाज़ी से बचने का एक तरीका है कि बाहरी विविध दृष्टिकोणों को खुले मन से स्वीकार किया जाए। थोड़ा रुककर यह देखना कि दोस्त, सहकर्मी, ग्राहक, प्रतियोगी, प्रबंधक आदि इस मुद्दे को कैसे देखते हैं, मेरे पूर्वाग्रह को टिके रहने नहीं देता।

बेशक, जब इंसान stress में होता है तो तर्कसंगत ढंग से व्यवहार करना कठिन हो जाता है। संगठन भी ऐसे ही होते हैं। इसलिए समझदार संगठन जानबूझकर schedule और resources में margin रखते हैं, और समझदार व्यक्ति meditation जैसी चीज़ों से stress manage करना सीखते हैं।

अगर रोज़मर्रा में साक्ष्य-आधारित निर्णय लेने का अभ्यास करना है, तो अपने पास अच्छे साक्ष्य भी अधिक होने चाहिए। इसके लिए ऐसा सिस्टम बनाना उपयोगी है जिसमें विविध और गुणवत्तापूर्ण जानकारी लगातार आपके आसपास आती रहे। जैसे newsletter subscribe करना, communities का हिस्सा बनना, study groups में भाग लेना।

3. सहकर्मियों को प्रभावी निर्णय लेने में सक्षम बनाएं (Enable others to make decisions efficiently)

उत्कृष्ट डेवलपर जानकारी और अनुभव साझा करके सहकर्मियों की growth में मदद करते हैं, टीम की productivity बढ़ाते हैं, और अंततः संगठन को बेहतर निर्णय लेने में सक्षम बनाते हैं।

तो फिर जूनियर क्या करे? जूनियर के लिए तुरंत बड़े results देने से अधिक महत्वपूर्ण है सवाल पूछकर बढ़ना; यही सहकर्मियों और संगठन की मदद करना है। कम आंके जाने, मना कर दिए जाने, या दूसरों के लिए बोझ बनने के डर को पार करके high-context सवाल पूछें। आमतौर पर लोग सोचते हैं कि ऐसी vulnerability दिखाने के लिए पहले trust बनाना पड़ता है, लेकिन वास्तविक शोध उल्टा दिखाता है। जब लोग अपनी कमज़ोरियाँ दिखाते हैं और साहस के साथ जोखिम लेते हैं, तो trust की नींव तेज़ी से बनती है।

vulnerability दिखाने का भी एक अच्छा तरीका होता है: संदर्भ को अच्छी तरह शामिल करना। जूनियर अक्सर A समस्या के कारण B आज़माते हैं, फिर B के भीतर C काम न करे तो केवल C के बारे में पूछते हैं। ऐसे में प्रायः बहुत सतही जवाब मिलता है, और जवाब मिल जाने पर भी समस्या हल नहीं होती। उल्टा, मैंने अक्सर देखा है कि अगर A को सही तरह से परिभाषित कर दिया जाए, तो B अपने आप सामने आ जाता है और C की ज़रूरत ही नहीं रहती।

अगर सवाल पूछने को प्रोत्साहित करना है, तो vulnerability और transparency को बहुत महत्व देने वाली संगठन-संस्कृति बनानी होगी। इस समय संगठन के भीतर default क्या रखा जाता है, यह काफ़ी महत्वपूर्ण है, क्योंकि default मानवीय cognition और behavior पर बहुत बड़ा असर डालता है।

इस दृष्टि से Public by Default टूल, जिनमें छिपाने के लिए action लेना पड़ता है, जैसे Slack, Notion, उन Private by Default टूल्स से बेहतर हैं, जिनमें साझा करने के लिए action लेना पड़ता है, जैसे Email, Google Docs। “कभी भी बात कर सकते हैं, बस इस समय छोड़ दें (Do Not Disturb)” यह मॉडल “इस समय आकर स्वतंत्र रूप से बात कर सकते हैं (Open Hours)” से बेहतर है।

4. अपने काम के वर्तमान मूल्य को अधिकतम करें (Maximize current value of your work)

उत्कृष्ट डेवलपर के लिए systemic thinking भी ज़रूरी है—यानी बाद में समस्या बन सकने वाले हिस्सों या requirements के बदलने की संभावना को देखकर long-term perspective से implementation करना—और तुरंत कार्रवाई करना भी ज़रूरी है—यानी analysis करते-करते रुक न जाना, uncertainty से डर लगे तब भी पहले कूदकर execute करना और feedback लेना।

खासतौर पर startup में दूसरा तरीका अधिक लाभकारी होता है, लेकिन किसी भी चरम पर जाना नुकसानदेह है। तेज़ execution पर ध्यान देते हुए, ऐसे कामों को आदत बना लेना अच्छा है जिनमें थोड़ा सा प्रयास भी बड़ा लाभ दे। सूक्ष्म उदाहरण के तौर पर, कोई value सिर्फ एक ही क्यों न हो, उसे hardcoding के बजाय variable में निकालना; या values अभी केवल दो ही क्यों न हों, यदि वह किसी एक component से आगे की option category है, तो Boolean के बजाय Mode का उपयोग करना। व्यापक उदाहरण यह है कि मैं किस hypothesis को validate करने के लिए यह काम कर रहा हूँ, और validation किस data से करूँगा—यह सोचकर execute करना।

आख़िरकार, जब मैं अपनी इच्छा से systemic thinking और तुरंत कार्रवाई के बीच लचीले ढंग से आ-जा सकता हूँ, तभी काम का मूल्य अधिकतम होता है।

5. प्रभावी और लगातार सीखें (Continuously learn)

प्रभावी ढंग से सीखना कैसे सीखें—यही हर growth की शुरुआत है। यह जितना जल्दी किया जाए उतना अच्छा है, क्योंकि इससे compound लाभ मिलता है।

सीखना अंततः अपने ज्ञान को बढ़ाकर जीवन बदलने के लिए है। लेकिन यह कोई गारंटी नहीं कि पुराना ज्ञान आज भी वैध हो, इसलिए नई जानकारी से लगातार स्वयं को अपडेट करते रहना ज़रूरी है।

हालाँकि केवल जानकारी ज़्यादा होना हमेशा अच्छा नहीं होता। unrefined big data की तरह, कुछ जानकारी सिर्फ बाधा बनती है। इसलिए गलत या मेरी समस्या से असंबंधित ‘noise’ की जगह ‘signal’ का अनुपात बढ़ाना चाहिए। मेरे हिसाब से अच्छे signal के उदाहरण हैं: ऐसे insights जो मेरे विशेषज्ञता-क्षेत्र के बाहर से आकर मेरे मौजूदा ज्ञान से जुड़ते हों, या ऐसे प्रमाण जो दिखाएँ कि मैं किसी खास शर्त में ग़लत हो सकता हूँ।

प्रभावी learning को इस सवाल में समेटा जा सकता है: ‘मैं हर दिन थोड़ा और प्रभावी ढंग से कैसे बढ़ सकता हूँ?’ इसका उत्तर है 1) अभी वास्तविक जीवन में मुझे क्या चाहिए यह पहचानना, 2) उससे संबंधित सैद्धांतिक आधार को जितना आवश्यक हो उतना ही सीखना, 3) और सीखते ही तुरंत उसे लागू करके self-feedback लेना—और इस चक्र को दोहराना।

तो अभी वास्तविक जीवन में मुझे क्या चाहिए, यह कैसे पता चले? डायरी लिखकर रोज़मर्रा की समस्याएँ खोजी जा सकती हैं, या पिछले एक सप्ताह में जिन कामों पर मैंने बहुत समय लगाया, उन्हें बेहतर करने की कोशिश की जा सकती है। उदाहरण के लिए, यदि आप job seeker हैं तो आप अक्सर study करते होंगे; ऐसे में study को प्रभावी ढंग से करने के तरीकों पर शोध करना मददगार होगा। जो काम आप बार-बार करते हैं, उनमें सीखने के मौके भी अधिक होते हैं और सुधार होने पर जीवन की गुणवत्ता में बढ़ोतरी भी ज़्यादा होती है।

इसे कैसे इस्तेमाल करें - जूनियर और सीनियर के दृष्टिकोण से

जूनियर इन लक्ष्यों को एक-एक करके देख सकते हैं, खासकर “बेहतरीन कोड लिखना” और “प्रभावी व लगातार सीखना” में बताए गए ज्ञान और व्यवहार से वे खुद कितने मेल खाते हैं, यह जाँच सकते हैं। फिर जिन क्षमताओं की कमी हो, उन्हें केंद्रित रूप से विकसित कर सकते हैं।

और यदि आप सीनियर हैं, तो इन्हें hiring evaluation और performance evaluation में इस्तेमाल कर सकते हैं। इस पर विचार किया जा सकता है कि उम्मीदवार के पास ये क्षमताएँ पर्याप्त रूप से हैं या नहीं, और किन signals से इसका आकलन किया जा सकता है। जूनियर की क्षमता बढ़ाने के लिए lead करते समय भी इन्हें इसी तरह उपयोग किया जा सकता है।

और ये क्षमताएँ केवल ‘बेहतरीन कोड लिखने’ को किसी खास domain expertise से बदल दें, तो किसी भी job function का मूल्यांकन करने के लिए अच्छे मानदंड बन जाती हैं। इसलिए वास्तव में XL8 में PM हो, designer हो, या developer—लोगों को hire करने, onboarding कराने और feedback देने के दौरान इन्हीं को यथासंभव क्षमता-मूल्यांकन के मानदंड के रूप में उपयोग किया जा रहा है, और इससे काफ़ी बड़ा प्रभाव मिला है।

उपयोग करते समय ध्यान देने योग्य बातें

ये पाँचों क्षमताएँ एक-दूसरे की पूरक हैं। सब आपस में जुड़ी हुई हैं, इसलिए केवल एक को विकसित करने को लक्ष्य बनाना बहुत प्रभावी न भी हो। दूसरी ओर, इसका यह मतलब भी हो सकता है कि एक चीज़ अच्छी हो जाए तो बाकी चीज़ों को बेहतर करना आसान हो जाए।

और यह शोध भी, दूसरे शोधों की तरह, कोई पूर्ण सत्य नहीं है। स्वाभाविक है कि इसकी सीमाएँ हैं, और यह भी ध्यान में रखना चाहिए कि इसमें शोधपत्र-लेखक की व्याख्या और मेरी व्याख्या दोनों शामिल हैं।

साथ ही, क्योंकि शोधपत्र का शीर्षक 'What Makes a Great Software Engineer?' था, इसलिए यह सोचा जा सकता है कि ये पाँच क्षमताएँ हों तो कोई उत्कृष्ट डेवलपर बन जाएगा—यानी ये पर्याप्त शर्तें हैं। लेकिन वास्तव में शोध ने यह देखा कि ‘यदि यह न हो, तो किसी को उत्कृष्ट डेवलपर नहीं कहा जा सकता’—यानी ये आवश्यक शर्तें हैं। इसलिए इन्हें अच्छे लक्ष्य, दिशा, या रास्ते के पड़ाव की तरह मानना ठीक है, लेकिन अंतिम मंज़िल मानने की ज़रूरत नहीं।

इसे कैसे इस्तेमाल करें - फ्रंटएंड डेवलपर के दृष्टिकोण से

इन 5 क्षमताओं को फ्रंटएंड डेवलपमेंट के संदर्भ में लागू करने के लिए ऐसे सवाल पूछे जा सकते हैं।

• फ्रंटएंड domain में बेहतरीन कोड किसे कहेंगे? और बेहतर कोड कैसे लिखा जा सकता है?
• फ्रंटएंड domain में बेहतर निर्णय लेने के लिए कौन से साक्ष्य कैसे इकट्ठा किए जाने चाहिए?
• फ्रंटएंड domain में सहकर्मियों को प्रभावी निर्णय लेने में सक्षम बनाने का क्या अर्थ है?
• फ्रंटएंड domain में मेरे काम के वर्तमान मूल्य को कैसे मापा जाए? और उसे अधिकतम कैसे किया जाए?
• फ्रंटएंड domain का ज्ञान लगातार और प्रभावी ढंग से कैसे सीखा जाए?

इन्हीं सवालों के जवाब खोजने की प्रक्रिया से फ्रंटएंड इंजीनियर करियर रोडमैप निकला। इसमें फ्रंटएंड डेवलपर से संगठन की अपेक्षित भूमिकाओं को web/product/operations specialization tracks में बाँटकर, हर track की प्रमुख विशेषताएँ, फायदे और सीमाएँ समझाई गई हैं। (Infcon प्रस्तुति में यह हिस्सा पूरी तरह छूट गया था, लेकिन इसे अलग लेख में और विस्तार से समझाने की योजना है.)

इस रोडमैप को भी जूनियर और सीनियर दोनों संदर्भों में उपयोग किया जा सकता है।

उदाहरण के लिए, फ्रंटएंड जूनियर पहले से शोध या इंटरव्यू सवालों के माध्यम से कंपनी की स्थिति समझकर, “जिस संगठन में मैं जाना चाहता हूँ वहाँ इस तरह की विशेषज्ञता चाहिए। अगर मैं इस विशेषज्ञता को अच्छी तरह विकसित करूँ और अच्छी तरह दिखाऊँ, तो hire होने की संभावना बढ़ेगी।” इस तरह job search में इसका उपयोग कर सकता है।

और सीनियर इस तरह सोच सकते हैं: “हमारे संगठन में इस तरह की विशेषज्ञता वाले लोग कम हैं। इसलिए हमें इस व्यक्ति को यह विशेषज्ञता विकसित करने में मदद करनी चाहिए। और इस विशेषज्ञता वाले लोगों की सही पहचान करके उन्हें hire करना चाहिए।” इस तरह टीम को विकसित करने और hiring में इसका उपयोग किया जा सकता है।

बेशक, ऊपर दिए गए शोधपत्र की तरह, यह भी ध्यान में रखना चाहिए कि ये 3 tracks भी एक-दूसरे के पूरक हैं, कोई पूर्ण सत्य नहीं हैं, और अंतिम मंज़िल भी नहीं हैं।

उत्कृष्ट सीनियर डेवलपर बनना

फ्रंटएंड इंजीनियर करियर रोडमैप में मैंने उत्कृष्ट सीनियर डेवलपर बनने के बारे में अपने विचार भी संक्षेप में बताए थे।

• जो व्यक्ति बुनियाद पर मज़बूती से टिके रहकर इन 5 आवश्यक क्षमताओं को लगातार विकसित करता है, वही अच्छा सीनियर बनता है।
• कई बार सहकर्मी का एक आदर्श व्यवहार, किसी औपचारिक leader के अनेक शब्दों से अधिक प्रभाव डालता है। जो व्यक्ति leader की भूमिका में न होते हुए भी leadership दिखाता है, अंततः उसी को leadership की भूमिका दी जाती है।
• किसी भी स्थिति में, कोई भी छोटा काम मिले, जो लोग उससे बड़ा impact बनाते हैं, उन्हें आगे चलकर और बड़े काम सौंपे जाते हैं।

[spilist2]

Notion से सीधे कॉपी किया था, इसलिए पीछे वाला 'Frontend Engineer Career Roadmap' लिंक Notion लिंक के रूप में चला गया है। T_T https://steady-study.super.site/frontend-engineer-career-roadmap यही वाला है।