मेरी नज़र में सबसे खराब प्रोग्रामर (2023)

 (dannorth.net)
16 पॉइंट द्वारा GN⁺ 2025-03-24 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख बताता है कि टीम की उत्पादकता को मापने की कोशिश कैसे विफल हुई
  • व्यक्तिगत मूल्यांकन और डेवलपमेंट के उद्देश्य से व्यक्तिगत प्रदर्शन मेट्रिक्स लागू करने का निर्णय लिया गया
    • कोड लाइनों की संख्या या बग्स की संख्या में हेरफेर की संभावना अधिक होने के कारण उन्हें बाहर रखा गया, और इसके बजाय story points या deliver की गई stories की संख्या से प्रदर्शन मापने का फैसला किया गया

Tim Mackinnon का प्रदर्शन ‘0’

  • टीम की उत्पादकता मापने वाले टूल्स (Jira आदि) के माध्यम से सभी टीम सदस्यों का प्रदर्शन मापा गया
  • Tim का प्रदर्शन स्कोर 0 था → क्योंकि उन्होंने एक भी story point दर्ज नहीं किया था
  • मैनेजर ने मांग की कि Tim का प्रदर्शन 0 है, इसलिए Tim को बदल दिया जाए

Tim Mackinnon प्रदर्शन क्यों नहीं दिखा पाए

  • Tim ने सीधे किसी story की जिम्मेदारी नहीं ली थी
  • इसके बजाय उन्होंने टीम के सदस्यों के साथ pair programming पर ध्यान केंद्रित किया
    • कम अनुभव वाले डेवलपर्स के साथ काम करते हुए उन्हें समस्याएँ सुलझाने की दिशा में आगे बढ़ाया
    • खुद समाधान देने के बजाय सवालों के ज़रिए समाधान निकलवाने में मदद की
    • senior developers के साथ समस्याओं पर मिलकर विचार किया और समाधानों को बेहतर बनाया
  • Tim ने सीधे कोड नहीं लिखा, लेकिन टीम के समग्र प्रदर्शन को बेहतर बनाया

Tim Mackinnon का वास्तविक योगदान

  • Tim के योगदान को व्यक्तिगत प्रदर्शन स्कोर से नहीं मापा जा सकता
  • Tim की वजह से पूरी टीम की उत्पादकता और कोड क्वालिटी बेहतर हुई
  • Tim के साथ काम करने पर ज़्यादा तेज़ और बेहतर नतीजे मिलते थे

मूल्यांकन का तरीका टीम उत्पादकता में बदला गया

  • मैनेजर को Tim के योगदान की व्याख्या की गई और उन्हें इसे देखने का अवसर दिया गया
  • पूरी टीम के प्रदर्शन में सुधार की पुष्टि होने के बाद व्यक्तिगत प्रदर्शन मापने की पद्धति छोड़ दी गई
  • व्यक्तिगत प्रदर्शन के बजाय टीम प्रदर्शन और बिज़नेस इम्पैक्ट के आधार पर मूल्यांकन का तरीका अपनाया गया

सारांश (tl;dr)

  • उत्पादकता को बिज़नेस परिणामों (जैसे: लागत में कमी, राजस्व सृजन आदि) से मापना चाहिए
  • जटिल सिस्टम्स में व्यक्तिगत प्रदर्शन मापना अर्थहीन है
  • DORA Metrics आदि सिस्टम प्रदर्शन मापने के टूल्स हैं, व्यक्तिगत योगदान मापने के टूल्स नहीं
  • अगर Tim Mackinnon के साथ काम करने का मौका मिले, तो उसे न गंवाएँ

संबंधित पढ़ाई

5 टिप्पणियां

 
bus710 2025-03-26

असल में, senior से आगे बढ़कर staff engineer स्तर तक पहुँचने पर, लगता है कि आपका काम धीरे-धीरे field में deploy होने वाले code से दूर होता जाता है.... उसकी जगह senior/junior लोगों की coaching ज़्यादा करनी पड़ती है। managers की शिकायतें भी सुननी पड़ती हैं.... और जब कोई समस्या फूट पड़ती है, तो इधर-उधर बुलाया जाता है और solution देना पड़ता है....

काम अगर इस तरह का हो, तो Jira tickets और points को भी quantitatively मापना संभव नहीं होता।
 
castedice 2025-03-24

Tech lead के रूप में मैं ऐसे काम काफ़ी ज़्यादा करता हूँ। Story point-आधारित quantification की कोशिश करना भी कुछ ऐसा ही है, लेकिन अच्छी बात यह है कि कंपनी इतनी बड़ी नहीं है, इसलिए executives सहित बाकी लोग यह समझते हैं कि मैं क्या भूमिका निभाता हूँ, इसलिए अभी के लिए कोई समस्या होती नहीं दिख रही है.
अगर संगठन बड़ा होता है, तो quantification के तरीकों पर भी सोचना पड़ेगा।
 
kallare 2025-03-24

लग रहा था कि यह कहानी कहीं देखी हुई है.. यह 2023 की पोस्ट है
यही पोस्ट 2 साल पहले भी आई थी https://hi.news.hada.io/topic?id=10680
 
crawler 2025-03-24

लगता है आप GitHub Copilot जैसे ही शख्स हैं....
 
GN⁺ 2025-03-24
Hacker News की राय

  • किसी individual developer की productivity मापना बेतुका है। code lines या story points को मापना productivity के उलट है। ज़्यादा अहम यह है कि developer कम code से ज़्यादा value पैदा करे

    • business outcomes को मापना महत्वपूर्ण है, लेकिन उसे किसी एक developer से जोड़ना मुश्किल है
    • आखिरकार यह मान लेना बेहतर है कि हमें subjective judgment पर निर्भर रहना ही पड़ेगा

  • Tim का नाम टिकट पर लगाकर समस्या हल करने का तरीका मिल गया। टीम के सदस्य खुशी-खुशी मदद करेंगे

    • productivity metrics पूरी तरह बेकार नहीं हैं। टीम के भीतर PR और Jira tickets के अनुपात को देखकर team leader का अनुमान लगाया जा सकता है

  • यह खुशी की बात है कि Tim टीम में बना हुआ है और process को सही दिशा में ले जा रहा है। सुनने वाला manager ज़रूरी है

    • OKR की वजह से developers अलग-थलग पड़ जाते हैं। team-based की बजाय individual-based OKR समस्याएँ पैदा करते हैं
    • समस्या सुलझाने में समय लगता है। OKR की वजह से मदद नहीं मिल पाई

  • ऐसा model अजीब है जिसमें एक programmer अपना कोई individual काम किए बिना सिर्फ़ सबकी मदद करता रहे

    • ज़्यादा healthy स्थिति यह होगी कि Tim दूसरों के साथ मिलकर stories पर काम करे और मदद की ज़रूरत होने पर group से पूछे
    • अगर टीम बहुत असंतुलित है, तो Tim को mentor की भूमिका निभानी चाहिए

  • Tim का कोई individual काम न करना अजीब है। team productivity को अधिकतम करने के लिए individual contribution और team collaboration के बीच संतुलन ज़रूरी है

    • हो सकता है Tim ने बहुत ज़्यादा patience दिखाकर समय बर्बाद किया हो

  • अगर Tim टीम में योगदान नहीं दे रहा है, तो मैं कहूँगा कि वह काम शुरू करे और stories deliver करे। Tim का दूसरों की मदद करना अच्छा है, लेकिन उसे अपना काम भी करना चाहिए

  • हर चीज़ को group activity होने की ज़रूरत नहीं है। अगर एक average developer, Tim की लगातार मदद के बिना features deliver नहीं कर सकता, तो टीम में समस्या है

    • software development में individual work और group work, दोनों के लिए समय चाहिए

  • सबसे बेहतरीन टीमों में हमेशा Tim जैसा कोई न कोई होता है। Tim की मदद दूसरों तक फैलती है और पूरी टीम को बढ़ने में मदद करती है

    • जब developer अटकते हैं, तो पहले खुद हल निकालने की कोशिश करते हैं और ज़रूरत पड़ने पर मदद माँगते हैं

  • story points से developer productivity मापना अच्छा नहीं है। Zero नाम का एक developer stories assign हुए बिना टीम की मदद करता था

    • manager Zero की अहमियत समझता था। Zero के न होने पर वह कभी-कभी महत्वपूर्ण releases टाल देता था

  • support की value को quantify करना मुश्किल है। लेकिन support ज़रूरी है। हमें भरोसा करना चाहिए कि leaders सही निर्णय ले सकें