एक डेवलपर ने अपना पूरा करियर एक भयानक codebase को समझने में लगा दिया

 (taylor.town)
2 पॉइंट द्वारा GN⁺ 2023-08-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Arthur Westbrook ने 58 वर्ष की उम्र में early retirement की घोषणा की, और 35 साल तक उस legacy codebase पर काम किया जो कथित तौर पर किसी medical software को चलाती थी
  • नौकरी के दौरान उनका योगदान सिर्फ कुछ सौ लाइनों का code था, लेकिन एक बार उन्होंने legacy code को छुआ और फिर भी कंपनी बर्बाद नहीं हुई — इसी तरह व्यंग्य किया गया
  • Westbrook का मानना था कि वह पूरे codebase का 4% से अधिक समझते थे, और एक पूर्व सहकर्मी ने इसे “wingdings में लिखी War & Peace” कहा
  • कंपनी के भीतर उन्हें “टीम के programmers में से एक” के रूप में जाना जाता था, और एक manager ने आकलन किया कि उनमें transferable skills के बिना भी लंबे समय तक टिके रहने की कला थी
  • उनके retirement पर प्रतिक्रिया फीकी रही, और Westbrook ने सड़क पर प्रदर्शन, कूड़ेदान खंगालने, और Soylent तथा Whole Foods Premium Adult Cat Salmon Mix को मिलाकर बनने वाले व्यंजन को और निखारने की योजना बनाई

35 साल पुराना legacy codebase

  • Arthur Westbrook ने इस सप्ताह 58 वर्ष की उम्र में early retirement की घोषणा की
  • उन्होंने 35 साल तक उस codebase पर काम किया जो कथित तौर पर किसी medical software को चलाती थी
  • अपने कार्यकाल के दौरान उन्होंने कुछ सौ लाइनों का code योगदान किया
  • एक बार उन्होंने legacy code को छुआ, लेकिन कंपनी तबाह नहीं हुई
  • Westbrook का मानना था कि उन्हें पूरे codebase का 4% से अधिक हिस्सा समझ में आता था
  • एक पूर्व सहकर्मी ने उस codebase को “wingdings में लिखी War & Peace” कहा

कंपनी की प्रतिक्रिया और retirement के बाद की योजना

  • कंपनी में Westbrook को “टीम के programmers में से एक” के रूप में जाना जाता था
  • एक manager ने कहा कि Westbrook में transferable skills सीखे बिना भी मेहनत से काम करते रहने की कला थी
    • उन्होंने यह भी जोड़ा कि उनकी जगह लेने के लिए “दो junior developers और एक Keurig” चाहिए होगा
  • दशकों की सेवा के सम्मान में एक सहकर्मी ने कहा कि वह “शायद अगले महीने” उन्हें drink पिलाएगा
  • टीम के किसी भी सदस्य ने टिप्पणी के अनुरोध का जवाब नहीं दिया
  • retirement के बाद Westbrook सड़क पर प्रदर्शन और कूड़ेदान खंगालने की कोशिश करने की योजना बना रहे हैं
  • वह Soylent और Whole Foods Premium Adult Cat Salmon Mix को मिलाकर बनने वाले व्यंजन को भी और बेहतर बनाते रहेंगे

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

1 टिप्पणियां

 
GN⁺ 2023-08-04
Hacker News की राय

  • मुझे लगता है कि जिन भी कंपनियों में मैंने काम किया, हर जगह ऐसा कोई न कोई व्यक्ति ज़रूर था।
    जब आपको ऐसा legacy code मिलता है जिसका चलना समझ से बाहर हो, और आप उसके पास जाते हैं, तो आपको 10 साल की अंदरूनी राजनीति और नाकाम replatforming projects पर 2 घंटे की इतिहास-क्लास सुननी पड़ती है। फिर भी उससे नफरत करना मुश्किल होता है

    • “...और वे AIX machines तो सचमुच दानव थीं। 20 मशीनें थीं, और हर एक अलग 20-ampere circuit खाती थी। steel case की grounding अक्सर उड़ जाती थी, और upgrade करना हो तो पहले मोटे leather gloves लेने पड़ते थे...”
    • समझ गया कि तुमने मेरी parody की है ;)
      पता है मैं 2 घंटे का इतिहास क्यों सुनाता हूँ? पहला, इंसानी interaction ज़रूरी है लेकिन मुझे लोग खास पसंद नहीं। दूसरा, मैं चाहता हूँ कि तुम बस रटकर दोहराने के बजाय सीखो और समझो, ताकि अगली बार मुझे परेशान किए बिना खुद हल कर सको। अब जाओ, इस हफ्ते का social quota पूरा हो गया। /मज़ाक — क्या सच में मज़ाक है?
    • ऐसे कुछ लोग देखे हैं; कुछ तो सोने के भाव के बराबर कीमती होते हैं। लेकिन ज़्यादातर लोग लंबे समय तक सब कुछ टूटने से बचाए रखने के trauma की वजह से अपने तरीकों में जड़ हो गए होते हैं, और लगभग सभी ठहर जाते हैं, नए ideas अंदर नहीं ला पाते। कई बार वे कंपनी की dysfunction को बहुत लंबे समय तक झेलते-झेलते और उसे अपनी ही समस्या की तरह ढोते-ढोते इंसानी तौर पर सिर्फ खोल भर रह जाते हैं
    • ऐसे लोग आम तौर पर बेहतरीन engineers भी होते हैं। किसी चीज़ का 1.0 बार-बार नए सिरे से लिखना कहीं ज्यादा आसान है। दशकों से improve होते आए system को फिर से improve करना बेहद कठिन engineering challenge है। 30 साल से ज्यादा पुरानी कंपनी में ऐसे लोग सबसे central होते हैं, लेकिन सम्मान मिलने के बजाय उन्हें linked article जैसी हिकारत भरी चीज़ें मिलती हैं
    • यह बुरा चुनाव नहीं लगता। अगर कंपनी काफी stable हो, 25 साल तक engineer की salary मिले और job security भी जबरदस्त हो, तो यह ठीक रास्ता है।
      50 साल की उम्र में किसी 28 साल के interviewer को अभी-अभी निकले latest framework की skills से impress करने की कोशिश करने से तो बेहतर ही लगता है

  • एक व्यक्ति अपने पूरे career में लगातार job बदलने की वजह खुद को यह समझाकर जीता है कि “बाकी लोग घटिया code लिखते हैं।”
    Karl Hackerman हर meeting में शिकायतें करता रहता है। system को Rust में फिर से लिखने की अनुमति न मिलने की वजह से वह उखड़ा हुआ दिखता है। उसे latest frameworks और best practices बहुत पता हैं, और office में उनका इस्तेमाल न कर पाने पर वह हमेशा चिढ़ा रहता है। उसे लगता है कि बाकी लोग बेहतरीन programmer बनने के बजाय wage slave बनकर settle हो गए हैं। सब उसे इसलिए झेलते हैं क्योंकि उन्हें पता है कि वह वैसे भी 6 महीने बाद छोड़ देगा। Karl अब 47 साल का है, और कभी भी कुछ साल से ज्यादा किसी एक job में नहीं रहा। हाल में वह ज्यादातर freelance काम करता है और ऐसी technologies और frameworks पर किताबें बेचने की कोशिश करता है जिनकी अब किसी को परवाह नहीं

    • मैं लेखक हूँ! यह बहुत बढ़िया है। मैं भी कभी बिल्कुल ऐसा व्यक्ति था :) असहनीय know-it-all न बनना सीखना हैरानी की बात है कि काफी मुश्किल काम था।
      जरूरत से ज्यादा उत्साही, हर चीज़ जानने वाले engineers पर Confederacy of Dunces style में एक लंबा उपन्यास भी लिख रहा हूँ। उसमें मेरी आत्मा इतनी ज्यादा डली है कि शायद कुछ समय तक पूरा न कर पाऊँ
    • सोकर उठा तो उम्मीद नहीं थी कि इस तरह attack हो जाऊँगा। बिना किसी warning के। क्रूरता है।
      फिर भी मैं अभी 40s में नहीं हूँ, इसलिए भटके हुए रास्ते से उबरने का समय बाकी है
    • यह अच्छा लगा।
      शुरुआत में मुझे भी ऐसा ही लगता था, लेकिन जल्द ही मैंने सीख लिया कि day job में संतोष सिर्फ ship करने से लेना है, और computer science के रहस्य आम तौर पर अपने personal time में explore करने हैं। कभी-कभी दोनों overlap करते हैं, लेकिन मेरे अनुभव में अच्छी job भी 80% boring होती है
    • “best practices” पर मैं हँस पड़ा। पहले ऐसे इंसान के साथ काम किया है। जब भी उसके पास कोई proper argument नहीं होता था, वह यही phrase इस्तेमाल करता था, और असल में लगभग हमेशा ऐसा ही होता था। काम जितना कम important होता, उसकी opinion उतनी ही strong होती
    • वैसे Karl का पुनर्जन्म MyCurrentIntern के रूप में हुआ है

  • 10 साल तक ऐसे C++ codebase पर काम किया जिसमें कोई भी third-party library इस्तेमाल नहीं होती थी। STL तक नहीं इस्तेमाल किया, क्योंकि उस समय हमें ज़्यादा तेज़ और thread-safe strings और maps चाहिए थे। Boost? वह क्या होता है?
    sockets के ऊपर खुद बनाया हुआ messaging middleware था, Unix system calls से बना अपना distributed process management system भी था, और HTML या Java जैसी चीज़ों की एक लाइन भी नहीं थी। आरामदायक और मोटी salary वाली ज़िंदगी थी, और high-frequency trading और distributed/concurrent computing जैसी cutting-edge समस्याएँ हल कीं। 2013 में इस किस्मत से बचने के लिए ज़बरदस्ती नौकरी छोड़ी, आधी salary देने वाली छोटी company में गया और web tech stack को बिल्कुल नीचे से सीखा। मैं मानना चाहता हूँ कि यह सफल रहा

    • मुझे नहीं लगता कि high-frequency trading में low-level C++ करने वाले किसी व्यक्ति की किस्मत वैसी ही होगी। ऐसे काम से मिलने वाली ज़्यादातर skills काफ़ी transferable लगती हैं। लेख उस job के ज़्यादा करीब लगता है जहाँ 95% काम company-specific business logic के हिसाब से CRUD implementation करना होता है।
      ऐसी नौकरी बदलने की वजह सोचूँ तो बस non-compete compensation period काटने जैसी कोई बात लगती है, लेकिन मैं इस industry में नहीं हूँ, इसलिए शायद कुछ miss कर रहा हूँ
    • “मैं web tech stack को नीचे से सीखना चाहता था। यह किस्मत टालने के लिए था। मैं मानना चाहता हूँ कि यह सफल रहा।”
      यह intended humor है या नहीं, मुझे ठीक से समझ नहीं आ रहा
    • मेरा भी काफ़ी मिलता-जुलता अनुभव है। एक बड़े telecom operator के subcontractor के तौर पर 7 साल तक CORBA, pthreads, ACE reactor library के साथ काम किया। पहले हफ्ते में codebase में एक sleep call डाल दी और UAT environment की पूरी call center service रोक दी। कुछ साल बाद मैं हजारों threads वाले core dumps आसानी से debug कर पाता था, semaphores और reentrancy समझता था, और POA व BOA Orbix adapters के फर्क भी बता सकता था।
      मैं सब कुछ जानने वाला legendary व्यक्ति बनता जा रहा था, लेकिन इसलिए नहीं कि मैं technically बहुत brilliant था; बल्कि इसलिए कि मैं business समझता था और जानता था कि वह अलग-अलग architecture elements पर कैसे map होता है। फिर लगने लगा कि शायद पूरी ज़िंदगी वहीं रह जाऊँगा, इसलिए सोचा कि web नाम की एक बड़ी दुनिया है और 2004 में PHP सीखना शुरू किया। legendary “5 minutes में blog” Rails demo आने के बाद 2007 में job बदली, और फिर पीछे मुड़कर नहीं देखा
    • C++ सच में कठिन काम है। हर किसी को लगता है कि वह बेहतर कर सकता है, और किसी को दूसरे का code भरोसे लायक नहीं लगता, इसलिए अंत में NIMBY-style code और उलझी हुई build settings का एक विशाल monolith बन जाता है। Code review भी उन्हीं C++ वाली वजहों से बेहद पीड़ादायक होता है। सब कुछ हर चीज़ को प्रभावित कर सकता है, और जब memory, time, order पर निर्भर behavioural effects पर भरोसा करना पड़ता है, तो encapsulation की अवधारणा टूटने लगती है। हर बदलाव सही conditions में production में अपने ही पैर पर चलने वाली गोली है।
      जब आप language, tools या दूसरे developers में सही होने का भरोसा नहीं कर सकते, तो productive होना मुश्किल है
    • मैंने भी कुछ ऐसा ही किया। लगा था C++ गिरावट में चला जाएगा। अब मैं Java और JavaScript में proficient हूँ और अच्छे full-stack apps भी बना सकता हूँ। लेकिन high-frequency trading C++ jobs दोगुना pay कर रही हैं, इसलिए सोच रहा हूँ कि systems boring हों तो भी वापस चला जाऊँ

  • काम करने के लिए मत जियो, जीने के लिए काम करो। Arthur शायद पहले खूब मस्ती करता था, बिना सोए office आता था, और retrospectives व refinement meetings में झपकी लेता था। developer के तौर पर शायद वह सबसे कम उपयोगी रहा हो, लेकिन Burning Man में राजा रहा होगा। अब वह मोटे 401k के साथ retire होकर farmers’ market में बेचने के लिए छोटी लकड़ी की गुड़ियाँ बना सकता है। सच तो यह है कि वह वहाँ लोगों को अपनी पकड़ी सबसे बड़ी मछली की कहानी सुनाना चाहता होगा, या यह सपना कि अगर ससुराल वाले साथ में invest कर दें तो ramen food truck खोलना चाहता है। Arthur ने ज़िंदगी जी — बस office में नहीं

    • अगर ज़िंदगी का ज़्यादातर हिस्सा काम है, तो ऐसा करना मुश्किल है। Full-time job, exercise, personal hygiene, meals जैसी चीज़ें जागते समय से निकाल दें तो असली ज़िंदगी के लिए जगह ढूँढना बहुत कठिन लगता है। असल में दिन में लगभग 2 घंटे और weekend ही बचते हैं, और weekends भी अक्सर weekday में निपटा न सके काम पूरा करने में लग जाते हैं।
      मुझे यह विचार पसंद नहीं कि मेरी ज़िंदगी retirement के बाद ही शुरू होगी। खासकर अगर जहाँ मैं रहता हूँ वहाँ statutory retirement age 67 हो सकती है
    • भले ही यह बनाया हुआ example रहा हो, छोटी-छोटी details सच में बहुत अच्छी थीं। संयोग से ही सही, यह काफी मेरी कहानी जैसा लगा और मान्यता मिलने जैसा महसूस हुआ :)
    • अगर ऐसा है तो सच में अच्छा होगा, और मैं उम्मीद करता हूँ कि A की वास्तविकता भी इसी का कोई रूप हो।
      लेकिन आम तौर पर बात इतनी गुलाबी नहीं होती। Arthur overweight हो सकता है, बहुत सारी health problems हो सकती हैं, अकेला रहता हो और XYZ, जैसे anime या games, से unhealthy तरीके से चिपका हुआ हो। फिर भी अगर उसके बच्चे हैं और उसने उन्हें अच्छे से पाला है, तो एक parent के तौर पर मैं सिर्फ उसी बात के लिए उसका बहुत सम्मान करता हूँ। पीछे मुड़कर देखें तो बाकी सब details हैं

  • प्रतिभाशाली लोग हर जगह होते हैं, और कुछ groundbreaking बनकर दुनिया पर असर डालने की संभावना बेहद कम होती है। अगर आप अपनी self-worth को उसी लक्ष्य से जोड़ देंगे, तो mental health काफ़ी डगमगा सकती है।
    बच्चा होने के बाद मेरी महत्वाकांक्षा और obsession का स्तर साफ़ बदल गया। पहले मैं best बनने के लिए पागल था, लेकिन अब बात ज़्यादा “पैसे दो और निकलो” जैसी है, और परिवार व दोस्तों के लिए जितना हो सके उतना free time बचाना प्राथमिकता है। मुझे Mr. Westbrook जैसा career भी ठीक लगता है। ख़ुशकिस्मती से अपने पूरे career में मुझे उनके जैसे ख़राब colleagues नहीं झेलने पड़े। हर किसी की चाहत अलग होती है, इसलिए judge करने की ज़रूरत नहीं। महान विचारक Alicia Keys ने जैसा कहा है, “तुम अपने जैसे रहो”

    • best बनने की कोशिश करने के बजाय सिर्फ़ कल वाले अपने आप से बेहतर बनना भी आपको बहुत दूर ले जा सकता है, यह मैंने समझा।
      मैंने कभी compete नहीं किया, बस अपना काम किया। ऐसा करते-करते एहसास हुआ कि जिन बहुत-से लोगों से मुझे inspiration मिलती थी, उनसे मैं पहले ही ज़्यादा जानता हूँ और आगे हूँ। फिर भी वह कभी मेरा लक्ष्य नहीं था, और आज भी नहीं है। मैं बस उन तथाकथित dark developers में से एक हूँ। बस अपना काम करता हूँ, हर बार बेहतर करने की कोशिश करता हूँ, और hall of fame जैसी चीज़ों की परवाह नहीं करता—चाहे हल्की-फुल्की हो या गंभीर
    • इस मुद्दे पर मैं लगातार pendulum की तरह झूलता रहता हूँ। मेरा मतलब “दुनिया-स्तर पर groundbreaking” या “दुनिया पर असर” वाले लक्ष्य से नहीं, बल्कि अपनी क्षमता के दायरे में “बेहतरीन” काम करना चाहता हूँ।
      जब मेरा पहला बच्चा हुआ, तो मैं इस तरफ़ काफ़ी झुक गया था कि काम से मुझे परिवार की रोज़ी-रोटी और उनके साथ समय के अलावा कुछ नहीं चाहिए। बेशक colleagues को support करने और भरोसा न तोड़ने की सीमा में। लेकिन जैसे-जैसे बच्चे बड़े होकर अधिक independent हो रहे हैं, मेरी mental bandwidth और energy बढ़ने के चरण में आ गई है, और अब उस energy को प्रभावशाली काम में लगाने को लेकर फिर उत्साह महसूस होता है। बस अहम बात यह है कि अब मुझे अपने और परिवार के लिए स्वस्थ और खुशहाल balance बनाने के तरीके को लेकर कहीं ज़्यादा समझ आ गई है। मैं भोलेपन में यह नहीं सोचता कि यह आसान होगा, और मानता हूँ कि लगातार कोशिश करनी पड़ेगी। लेकिन baby care की धुंध से बाहर निकलकर अब फिर साफ़ दिखता है कि सिर्फ़ परिवार पर पूरी तरह focus करना या सिर्फ़ काम पर पूरी तरह focus करना—दोनों ही मेरा रास्ता नहीं हैं
    • मैं इसे उल्टा देखता हूँ। आधुनिक समाज और जीवन के इतने सारे पहलू हैं, और हर साल नए रास्ते व क्षेत्र बनते हैं, कि किसी खास community या niche में ऐसा दुनिया हिला देने वाला काम ढूँढ़ना, जो अभी तक किसी ने नहीं किया, असल में काफ़ी आसान है।
      हर किसी के लिए दुनिया हिला देने वाला काम काफ़ी overrated है
    • सहमत हूँ। इस लेख का point क्या है, समझ नहीं आया। थोड़ा sarcastic elitism छोड़कर कुछ दिखता नहीं। उम्मीद है original लेखक को इससे थोड़ा बेहतर महसूस हुआ होगा
    • मैं इस बात से सहमत नहीं कि प्रतिभाशाली लोग हर जगह होते हैं। Jonathan Blow, Salvatore Sanfilippo(redis), Mike Pall(LuaJIT) जैसे हर एक व्यक्ति के पीछे feature factory में काम करने वाले हज़ारों average developers होंगे। शानदार software सिर्फ़ किस्मत से नहीं बनता। GenericCo का boss ख़ास तौर पर आकर आपसे वह चीज़ बनाने को भी नहीं कहेगा जिसका आपने हमेशा सपना देखा था।
      आप या तो दिलचस्प software बनाने का चुनाव करते हैं, या पूरी तरह valid हज़ारों वजहों में से किसी एक के चलते छोटा जीने का चुनाव करते हैं। अगर आप सच में खुद को इतना महान मानते हैं, तो company को “मौका नहीं दिया” कहकर दोष मत दीजिए। coding के लिए ज़रूरी tools आपके पास पहले से हैं। कुछ शानदार बना दीजिए

  • मज़ेदार तो है, लेकिन अगर Arthur खुश था या अब खुश है, तो कोई समस्या नहीं। यह बात लेख में नहीं आती

    • बिल्कुल यही। संभव है कि उसने एक stable और आरामदायक नौकरी में कई साल बिताए, और codebase व technology को इतना समझ लिया कि परिवार, दोस्तों और hobbies के लिए उसके पास बहुत समय था। इस कहानी से ज़्यादा HN की प्रतिक्रिया डरावनी लगती है
    • समस्या है।
      2023 है, और आज कंपनियाँ जिस पल तय करती हैं कि आप profitable नहीं हैं, वे खुशी-खुशी आपको निकाल देती हैं। यह काल्पनिक व्यक्ति retirement तक पहुँच गया, इसलिए अच्छा हुआ। लेकिन जो व्यक्ति 15 साल तक यह strategy अपनाए और फिर company को headcount 18% घटाना पड़े, इसलिए वह अभी नौकरी ढूँढ़ रहा हो? उपयोगी skills में बड़ा gap है और retirement में अभी दशकों बाकी हैं। वह व्यक्ति सचमुच मुश्किल में है
    • employer खुश था या नहीं, यह भी मायने रखता है। 35 साल तक उसे रखा, तो एक तरह से खुश ही था
    • एक आसान role में 35 साल, अच्छी job security, और early retirement तक। Arthur खुश था
    • लेकिन… वह cat food खा रहा है। क्या आप ऐसे बहुत से खुश लोगों को जानते हैं जो cat food खाते हों?

  • हमारी company medical devices बनाती है। software development lifecycle वाला क्षेत्र बहुत strict है। एक colleague बहुत बड़ी दूसरी medical device company में चला गया, और कुछ साल बाद मिलने पर उसने कहा कि पीछे मुड़कर देखने पर हमारी company high-performing, super-agile organization थी। उसकी नई company में असल में कुछ बदलना भी नहीं, बस कुछ जोड़ने वाला दो line का code change करने में 1 साल लग जाता है। उसने खुद लगातार push किया, फिर भी ऐसा ही हुआ।
    निष्पक्ष होकर कहें तो, blood dialysis system में बदलाव करना कोई खेल नहीं है

    • पुराने AT&T 5ESS switch में भी कुछ ऐसा ही माहौल था। अब पता नहीं। नियम था कि features delete नहीं किए जा सकते, इसलिए function मिटाने के बजाय function के अंदर का code मिटा दिया जाता था। मुझे याद है कि Bell Labs से आए एक बेहद प्रतिभाशाली व्यक्ति 5ESS team में थे, और मैंने पढ़ा था कि major telephone system outages रोकने के लिए बने तमाम rules की वजह से वे 1 साल में हास्यास्पद रूप से बहुत कम lines of code ही लिखते थे
    • इसके साथ बहुत analysis जुड़ा होता है। मैंने medical devices और transportation, खासकर railway rolling stock signaling systems, दोनों में काम किया है। लोगों से भरे विशाल metal के ढेरों को चलाना कभी भी मज़ाक नहीं होता

  • यह प्रोग्रामरों के लिए WH Auden की कविता The Unknown Citizen जैसा लगता है [0].
    जब मैंने इसे पहली बार पढ़ा था, तो मुझे यह उस व्यक्ति के बारे में एक उदास कविता लगी थी जिसने अपनी ज़िंदगी साधारण और रोज़मर्रा की चीज़ों में बर्बाद कर दी। अब मैं इसे एक सकारात्मक कविता की तरह देखता हूँ: ऊपर से उसने औसत जीवन जिया, लेकिन बहुत मुमकिन है कि उसके भीतर एक समृद्ध आंतरिक जीवन रहा हो जिसे उसने दुनिया से साझा नहीं किया, और हमें यह उम्मीद नहीं करनी चाहिए कि कौन महान था, इसे बाहर से मापे जा सकने वाले संकेतकों से तय किया जा सकता है। यह भी शानदार है कि इस आदमी का पैशन इंसानों के लिए Soylent कैट-फूड मिश्रण है। उसने इतने सारे साल काम किया और आखिरकार अपने पैशन के लिए मुक्त हुआ।
    [0] https://poets.org/poem/unknown-citizen

    • साथ ही Sisyphus भी याद आता है।
      यह विचार कि जीवन अर्थहीन है, और हमें कठिन श्रम या दोहराव के बीच खुश रहना चाहिए, और इसके बजाय “यात्रा” और हर पल में संतुष्ट रहना चाहिए। साहित्य और इतिहास भर में यह बहुत आम है। तकनीक रखने वाला आधुनिक इंसान यह सोचना चाहता है कि वह किसी तरह अलग है, एक नए स्तर पर पहुँचकर उद्देश्य खोज रहा है, लेकिन अब मुझे यकीन नहीं। शायद हम अब भी बस दिन-प्रतिदिन जीते हैं और मर जाते हैं।
      https://en.wikipedia.org/wiki/Sisyphus
      https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus
    • यह तो औसत से कहीं बेहतर जीवन जैसा लगता है। कोई खास समस्या नहीं और हर तरह से समाज का कार्यशील सदस्य? अच्छे रिश्ते? पाँच बच्चे?
      कविता की आखिरी पंक्ति के बावजूद, साफ लगता है कि वह असल में खुश था। अगर नहीं होता, तो काम पर फट पड़ता, या शराबी बन जाता, या तलाक ले लेता। या फिर वह बेहद कट्टर Stoic रहा होगा
    • ये पुराने अंश मौजूदा zeitgeist से तुक मिलाते हैं

      Our researchers into Public Opinion are content
      That he held the proper opinions for the time of year;
      When there was peace, he was for peace: when there was war, he went.

  • अगर यह तथाकथित साधारण प्रोग्रामर पर तंज है, तो यह मज़ेदार नहीं है।
    मेरा एक दोस्त है जिसे AP कह लेते हैं; वह एक स्थानीय Java डेवलपमेंट कंपनी में प्रोग्रामर है। ग्रेजुएशन के बाद 12 साल से उसी जगह काम कर रहा है, और इस लेख के वर्णन से कुछ हद तक मेल खाता है, लेकिन जिन लोगों को मैं जानता हूँ उनमें वह सबसे खुश लोगों में से है। औसत से ज़्यादा कमाता है, काम आसान है और बहुत तनावपूर्ण नहीं। कोडबेस को अंदर-बाहर जानता है और सहकर्मियों से भी अच्छी बनती है। काम के बाहर दोस्तों के साथ साइकिल चलाता है या बीयर पीता है, और अपनी पत्नी के साथ दुनिया घूमता है। हर व्यक्ति की प्राथमिकताएँ अलग होती हैं, और हर कोई काम में उत्कृष्ट बनने को लेकर जुनूनी नहीं होता

    • यह लेख उन कर्मचारियों पर तंज है जो सालों, दशकों तक न्यूनतम प्रयास से टिके रहते हैं। “सैकड़ों लाइनों का कोड” वाला हिस्सा इसका संकेत है।
      बहुत से बेहतरीन इंजीनियर उबाऊ और सड़े हुए कोडबेस पर काम करते हैं। इसमें शर्म की कोई बात नहीं
    • लेखक हूँ! सहमत हूँ :) अतिरिक्त संदर्भ यहाँ है
      [0] https://news.ycombinator.com/item?id=36985316

  • कोई भी ग्रीनफील्ड में नई और चमकदार चीज़ बना सकता है। अगर बात न बने, तो भी जिसे बनाना था वह मूल रूप से बहुत शानदार और बेहद अभिनव[1] प्रयास था, इसलिए दोष देने के लिए कोई व्यक्ति या चीज़ हमेशा मिल जाती है। समय के साथ किसी दूसरी नई और चमकदार चीज़ पर चले जाना भी न सिर्फ ठीक है, बल्कि अपेक्षित भी है।
    दूसरी ओर, अच्छे और बुरे दौरों से गुजरते हुए किसी एक चीज़ से अंत तक चिपके रहना ऐसा काम नहीं है जो बहुत लोग कर सकें। ज़्यादातर मामलों में यह अकेले पर्याप्त नहीं होता, लेकिन टिकाऊ सफलता के लिए ज़रूरी लगता है। उदाहरण: Guido van Rossum[2], Linus Torvalds, Daniel Stenberg.
    [1] “high-risk” प्रकृति को छोटे अक्षरों में लिखने की भी ज़रूरत नहीं। सब पहले से ही इसे ऐसे ही समझते हैं।
    [2] स्रोत नहीं मिल पा रहा, लेकिन मुझे एक इंटरव्यू याद है जिसमें Python की breakthrough के बारे में पूछे जाने पर Guido ने कहा था कि ऐसा कुछ नहीं था, बस यह लगातार धीरे-धीरे बढ़ता रहा

    • वे उदाहरण किसी औसत संगठन के IT project से लगभग कोई संबंध नहीं रखते। scope भी अलग है, success की definition भी, और “completion” की definition भी।
      अगर कंपनी कोई programming language या operating system बना रही है, तो यह पक्का कर लेना चाहिए कि वह काम वाकई आपका प्रिय काम है