मुझे पीछे छूट जाने दो

 (androidessence.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Android डेवलपमेंट की शुरुआत 2014 में Java क्लास में पता चले एक मुफ्त कोर्स और पहली to-do ऐप से हुई, और हाथ में मौजूद सॉफ़्टवेयर का वास्तविक दुनिया को छूना इसकी प्रेरक शक्ति बना
  • 10 साल का करियर ऐसे ऐप्स को मेंटेन करते हुए बीता जिनसे यूज़र्स को वास्तविक लाभ मिलता था, जैसे dating app, दवाइयों की उपलब्धता, और यात्रा सहायता; इसी दौरान तकनीक के उद्देश्य की पुष्टि हुई
  • कोर्स, hackathon, पहली नौकरी, और Droidcon NYC से गुजरते हुए यह महसूस हुआ कि तैयार प्रोडक्ट से ज़्यादा लंबे समय तक लोगों से बने संबंध और खुले ज्ञान का साझा रह जाता है
  • LLM इतने बेहतर हो गए हैं कि compile होने वाला code और review तक दे सकते हैं, लेकिन Stack Overflow शैली की खोज, प्रतिवाद, voting, और trial-and-error से पैदा होने वाली समझ को कमजोर करते हैं
  • सॉफ़्टवेयर डेवलपमेंट केवल दोहराए जाने वाले कामों की automation से बदला नहीं जा सकता; यह एक कला और शिल्प है, और ऐसा काम होना चाहिए जिसे इंसान मिलकर इंसानों के लिए बनाएं और साझा करें

Android डेवलपमेंट शुरू करने की वजह

  • Android डेवलपमेंट की शुरुआत 2014 में कॉलेज की Java क्लास के दौरान एक सहपाठी द्वारा साझा किए गए मुफ्त online course से हुई, और पहला लक्ष्य local storage वाली एक to-do list app बनाना था
  • तैयार ऐप को फ़ोन पर चलाकर माता-पिता को दिखाने का क्षण “बल्ब जलने वाला क्षण” बनकर रह गया, और हाथ में लेकर सीधे interact की जा सकने वाली वास्तविक सॉफ़्टवेयर होने की बात ने इसे गहरा अर्थ दिया
  • ऐप जेब में हमेशा मौजूद रहने वाला ऐसा टूल था जो व्यवस्थित रहने और productivity में मदद करता था, और इस अनुभव से यह महसूस हुआ कि लोगों पर सकारात्मक असर डालने वाले टूल देना ही तकनीक का उद्देश्य है
  • 2018 में बाद में अपनी पत्नी से मिलाने वाली dating app पर सीधे काम करते हुए सॉफ़्टवेयर के वास्तविक दुनिया पर प्रभाव को और सीधे अनुभव किया
  • इसके बाद 10 साल तक Android डेवलपर के रूप में कौशल को निखारते हुए ऐसे ऐप्स को मेंटेन किया जो वास्तविक यूज़र्स को लाभ पहुंचाते थे, जैसे किसी खास व्यक्ति को ढूंढना, दवाइयों तक पहुंच बढ़ाना, और यात्रा में मदद करना

इस डेवलपमेंट यात्रा को बनाने वाले लोग

  • ऐप्स से भी ज़्यादा लंबे समय तक जो चीज़ बनी रही, वह थी उन ऐप्स को संभव बनाने वाले लोगों से जुड़ाव

  • कोर्स और खुला ज्ञान

    • शुरुआती लक्ष्य था जितनी हो सके उतनी जानकारी सोख लेना, और हर हफ़्ते लेक्चर सुनकर प्रोफेसर द्वारा पढ़ाई जा रही Android सामग्री सीखना
    • Googler द्वारा weather app बनाना सिखाने वाला एक और course भी लिया, और क्लास के बीच के समय तथा lunch break तक का इस्तेमाल ऐप बनाने में करने जितना डूब गया
    • कैमरे के पीछे मौजूद लोगों के गहरे ज्ञान और उसे सार्वजनिक रूप से साझा करने की उनकी इच्छा ने गहरा प्रभाव छोड़ा

  • hackathon और team building

    • इसके बाद के कुछ साल खुद बनाकर अभ्यास करने में बीते, और 10 से ज़्यादा hackathon में भाग लेते हुए सैकड़ों भावी software engineer से जुड़ाव बना
    • दोस्तों के साथ कार से 2 से 8 घंटे की यात्रा कर 3 दिनों तक लगभग बिना सोए social app, pet tracker, और NFC tag CTF game जैसी चीज़ें बनाईं
    • caffeine के सहारे टिके रहना और tech stack पर बहस करना भी था, लेकिन असली इनाम था हँसी, दोस्ती, और टीम के रूप में कुछ बनाने का गर्व
    • क्या बनाया गया या कोई पुरस्कार मिला या नहीं, यह महत्वपूर्ण नहीं था; अनुभव स्वयं ही इनाम बनकर रह गया

  • पहली नौकरी और RxJava

    • graduation के बाद digital marketing company में specialist Android डेवलपर के रूप में पहले दिन बगल में बैठे सहकर्मी ने पूछा, “RxJava के बारे में तुम क्या जानते हो?”
    • RxJava के बारे में बिल्कुल न जानने से घबराहट हुई, लेकिन सहकर्मी ने जज नहीं किया; उसने reactive programming, साथ में बनाए जाने वाले ऐप का संदर्भ, और जल्दी catch up करने का तरीका समझाया
    • दोनों दफ़्तर में हँसी लाने वाले सहकर्मी बने, और साथ ही काम और growth के लिए गहरा जुनून बनाए रखा

  • Droidcon NYC और ज्ञान लौटाना

    • उसी सहकर्मी ने पहली Android conference, Droidcon NYC, में ले गया, और समान संकीर्ण रुचि वाले सैकड़ों engineers और दर्जनों speakers के बीच का माहौल बहुत प्रभावशाली रहा
    • speakers को स्वेच्छा से ज्ञान साझा करते देख अगली पीढ़ी के Android engineers के साथ अपनी विशेषज्ञता बांटने की इच्छा पैदा हुई
    • दूसरे engineers की मदद करने के मौके ढूंढना, और पहले मिली मदद को आगे पहुंचाना, करियर का एक महत्वपूर्ण सिद्धांत बन गया

LLM द्वारा वादा किया गया डेवलपमेंट तरीका और वास्तविक अनुभव

  • LLM के आम होने के साथ यह सरल वादा कि “अब coding सीखने की ज़रूरत नहीं, बस जो चाहिए उसे prompt में लिखो और code बन जाएगा” मौजूदा software development तरीके के लिए चुनौती बन गया
  • शुरुआत में नई तकनीक की संभावनाओं को लेकर उत्साह था, लेकिन वास्तविक उपयोग में यह कभी अस्तित्वहीन methods सुझाता, कभी साफ़ bugs बनाता, और सबसे खराब स्थिति में ऐसा code देता जो compile ही नहीं होता था
  • बाद में “यह और बेहतर होगा” वाले वादे के बाद फिर इस्तेमाल करने पर सचमुच सुधार दिखा; यह compile होने वाला code लिखने लगा, stack trace का विश्लेषण कर fix सुझाने लगा, और code review तक करने लगा
  • लेकिन ये बेहतर क्षमताएँ साथ ही मानवीय अनुभव को भी खत्म करने लगीं
  • कुछ न पता होने पर AI से पूछना और लक्ष्य तक पहुंचाने वाले पहले कामचलाऊ जवाब पर निर्भर होना आसान हो गया, और पहले की तरह Stack Overflow पर वही समस्या झेल चुके किसी व्यक्ति द्वारा सार्वजनिक रूप से साझा किए गए समाधान के रास्ते को देखकर सीखना कम हो गया
  • Stack Overflow पर सिर्फ मदद ही नहीं मिलती थी, बल्कि मान्यताओं को चुनौती देने और खारिज करने वाला feedback भी मिलता था; search, review, और community voting के ज़रिए किसी समाधान के समर्थन और विरोध को देखकर समस्या और उसके समाधान को मूल रूप से समझा जा सकता था

automation से कमजोर होती सीख और सहयोग

  • engineers को automation पसंद है, लेकिन automation सबसे अच्छा काम छोटे और दोहराए जाने वाले कामों में करती है
  • जब कुछ बनाना हो, तब 10 साल में निखारी गई अपनी skills की जगह मशीन को काम सौंप देने से resilient और लंबे समय तक टिकने वाला software बनाने के लिए ज़रूरी critical thinking कमजोर पड़ सकती है
  • एक दृष्टिकोण यह भी है कि LLM तेज़ी से code बना देते हैं, इसलिए सिस्टम के बारे में और आलोचनात्मक ढंग से सोचा जा सकता है, लेकिन software development सीखने के मूल तत्व trial-and-error को खो देना आसान है
  • trial-and-error केवल यह देखने तक सीमित नहीं कि ऐप चलती है या crash करती है; यह उस architecture, library, pattern, और style को खोजने के लिए कई तरीके आज़माने की प्रक्रिया है जो लक्ष्य हासिल करने के लिए सबसे उपयुक्त हो
  • समाधानों पर feedback भी अगर सहकर्मी के सामने बैठकर implementation choices और trade-offs पर चर्चा करने के बजाय किसी black box से पूछा जाए, तो वास्तविक प्रोजेक्ट में क्या काम आया और क्या नहीं, इस पर आधारित बातचीत गायब हो जाती है
  • trade-offs पर चर्चाएँ अक्सर सिद्धांत नहीं बल्कि किसी और के सीधे अनुभव पर आधारित होती थीं, और ऐसी बातचीत implementation संबंधी निर्णय को और गहरा बनाती थी

इंसानों के लिए सॉफ़्टवेयर

  • LLM एक prediction machine है; इसे खुले तौर पर सीखने और बनाने का चुनाव करने वाले engineers की लंबे समय की प्रतिबद्धता पर प्रशिक्षित text generator और statistical system के रूप में परिभाषित किया गया है
  • सार्वजनिक रूप से बनाना तकनीक को बंद कर देना नहीं था, बल्कि युवा engineers के लिए खोजने, समझने और सीखने योग्य वास्तविक उदाहरण बनाना था
  • जब code compile नहीं होता, तब LLM साथ बैठकर हँसता नहीं; और जब कोई पूछे “यह कैसे काम करता है?”, तब वह सॉफ़्टवेयर की ऐसी समझ भी नहीं बनाता कि कोई उत्साह से समझा सके
  • सबसे बढ़कर, वह मुड़कर मुस्कुराते हुए साथ में “हमने इसे बनाया” कहने की खुशी में शामिल नहीं हो सकता
  • लोगों से जुड़ना, अपनी vulnerability दिखाना, मुश्किलें साझा करना, और मदद पाने के बाद blog post या talk के ज़रिए उसे फिर से साझा करना—ये आदतें AI के उपयोग से कमजोर हुई हैं, लेकिन इन्हें फिर से वापस लाने की ज़रूरत है
  • सॉफ़्टवेयर डेवलपमेंट एक कला और शिल्प है जिसमें समर्पण, धैर्य, और मजबूत community की ज़रूरत होती है, और इसे इंसानों द्वारा इंसानों के लिए बनाया जाना चाहिए
  • अगर AI के साथ बनाना सचमुच भविष्य है, तो उस भविष्य में पीछे छूट जाना भी स्वीकार है

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.