प्रोग्रामिंग के 40 साल
प्रोग्रामिंग में दीर्घायु और आनंद
- कई टिप्पणीकार 30–50+ वर्षों से कोडिंग कर रहे होने की बात बताते हैं, शुरुआती होम कंप्यूटरों (C64, ZX Spectrum, Tandy, Amiga) से लेकर आधुनिक वेब और बैकएंड काम तक।
- एक बड़ा समूह अब भी रोज़ कोड करता है और वास्तव में इसका आनंद लेता है, कुछ तो रिटायरमेंट के करीब या उसके बाद भी।
- अन्य लोग आधुनिक “सॉफ़्टवेयर डेवलपमेंट” संस्कृति से थका हुआ महसूस करते हैं, भले ही उन्हें लो-लेवल या एम्बेडेड काम अभी भी पसंद हो।
कौशल और भर्ती पर अनुभव का प्रभाव
- लंबे अनुभव को मुख्यतः निर्णय क्षमता के लिए मूल्यवान माना जाता है: क्या नहीं करना है यह जानना, tradeoffs समझा पाना, और अपरिचित कोड को जल्दी पढ़ लेना (अपने पुराने कोड सहित)।
- कुछ लोग बताते हैं कि 50 की उम्र तक गहरी विशेषज्ञता अक्सर उन्हें निकालना मुश्किल बना देती है और परामर्श के अवसर खोलती है।
- अन्य लोग broad background होने के बावजूद ageism और tech-stack fetishism के कारण नौकरी पाने में कठिनाई बताते हैं।
करियर पथ, प्रबंधन, और पैसा
- कई mid/late-career devs जानबूझकर management या शीर्ष “staff” स्तरों से बचते हैं ताकि hands-on coding बना रहे और meetings व stress कम हों।
- कुछ लोग नेतृत्व भूमिकाओं को भावनात्मक रूप से महंगा बताते हैं, जिसमें burnout और लगातार context-switching शामिल है।
- वेतन की bimodality पर चर्चा: sub‑$100k बनाम $200k+; बताए गए कारणों में FAANG बनाम अन्य employer, geography/cost of living, और यह कि कोई पैसे के लिए optimize करता है या coding की खुशी के लिए।
बदलती तकनीक और प्रैक्टिस
- एक बड़ा बदलाव नोट किया गया: shrink-wrapped software से 24/7 services की ओर बदलाव, जिसमें on-call और continuous updates शामिल हैं।
- इस पर अलग-अलग राय है कि “programming itself” कितना बदला है; fundamentals और abstraction skills को स्थिर माना जाता है, जबकि frameworks और paradigms लगातार बदलते रहते हैं।
कोड की सरलता, जटिलता, और रखरखाव
- इस पर मजबूत सहमति है कि production code का “simple, obvious” होना मुश्किल है; जटिल code लिखना आसान है और उसे गलत करना भी आसान है।
- अनुभवी लोगों को अक्सर डरावने legacy code को बचाने का काम मिलता है, जिसे कोई और छूने की हिम्मत नहीं करता।
- कई लोग “future me” के लिए लिखने पर ज़ोर देते हैं, साफ़ संरचना और documentation के साथ।
अकेले बनाम टीम का काम
- इस पर बहस कि क्या “interesting and significant” software टीमों द्वारा ही बनना चाहिए।
- कुछ का तर्क है कि अधिकांश आधुनिक महत्वपूर्ण systems के लिए teams चाहिए; अन्य historical और modern one- या two-person successes (games सहित) का हवाला देते हैं और उम्मीद करते हैं कि tools/LLMs solo क्षमता बढ़ाएँगे।
मीटिंग्स, संचार, और प्रक्रिया
- dysfunctional meetings की कई कहानियाँ: notes नहीं, decisions नहीं, बड़े groups, और समय की बर्बादी।
- कुछ उत्तरदाता जानबूझकर concise notes लेते और साझा करते हैं या समझ को align करने के लिए shared documents को live-edit करते हैं।
- एक side thread “useless jobs/meetings” को universal basic income के तर्कों से जोड़ता है।
विविधता और संस्कृति
- लेख का human rights और diversity पर रुख बहस छेड़ता है।
- कुछ लोग विविधता अपनाने और कुछ नैतिक विचारों को गैर-परक्राम्य घोषित करने के बीच तनाव देखते हैं; अन्य मानते हैं कि basic human rights को प्राथमिकता देना विविध दृष्टिकोणों के साथ संगत है।
विस्तृत विचार
- कई लोग software के बढ़ते सामाजिक प्रभाव पर विचार करते हैं, और महसूस करते हैं कि यह लोगों का समर्थन करने के बजाय increasingly उन्हें नियंत्रित कर रहा है।
- निराशाओं के बावजूद, कई लोग programming में एक lifelong, creative career के लिए कृतज्ञता व्यक्त करते हैं.