छात्रों के लिए

• शुरुआती computing jobs ढूँढना कठिन होता जा रहा है और software industry भी बुरी तरह डगमगा रही है, ऐसे माहौल में code की मात्रा और अल्पकालिक मुनाफा गुणवत्ता और sustainability पर भारी पड़ रहे हैं
• तकनीक लोगों की मदद करने का औज़ार भी है, लेकिन इसका उपयोग ध्यान भटकाने, निगरानी, extraction और हत्या के लिए भी किया जाता है; साथ ही biased data और अत्यधिक computing resources की खपत की समस्या भी सामने आ रही है
• computing की शुरुआत में विचारों की सुंदरता, कुछ बनाने का आनंद, और ऐसे tools बनाने की संभावना थी जो लोगों की मदद करें और मानवीय रिश्तों को मजबूत करें
• हावी तकनीकी narrative का आँख मूंदकर पीछा करने के बजाय इरादतन चयन के साथ नैतिक सीमाएँ पहले से तय करनी चाहिए, गहराई से सोचने के लिए समय और जगह बचाए रखनी चाहिए, और साफ़ व सुरुचिपूर्ण code तथा documentation बनाना चाहिए
• मुनाफे और productivity से अधिक लोगों, रिश्तों और न्याय को प्राथमिकता देनी चाहिए, और डर नहीं बल्कि प्रेम से संचालित होने वाला रवैया आगे के computing में अधिक महत्वपूर्ण होगा

---

computing के आसपास का मौजूदा परिदृश्य

• computer science की पढ़ाई पूरी करने के बाद जिस दुनिया का सामना होगा, उसमें entry-level computing jobs ढूँढना कठिन है, और software industry भी समग्र रूप से बड़े झटकों से गुजर रही है
• intellectual property का सम्मान नहीं किया जाता, code की quality से अधिक उसकी मात्रा को महत्व दिया जाता है, और दीर्घकालिक sustainability से पहले अल्पकालिक मुनाफा रखा जाता है
• तकनीक लोगों की मदद करने के बजाय ध्यान भटकाने, extraction, निगरानी और हत्या के लिए भी इस्तेमाल होती है, और इसे कभी-कभी इंसानी गहरे cognitive biases और blind spots का फायदा उठाने के लिए डिज़ाइन किया जाता है
• biased data पर train किए गए systems में सदियों के पक्षपात और भेदभाव अंकित हो जाते हैं, और अनिश्चित लाभ के लिए scarce resources को अत्यधिक computing पर खर्च किया जाता है
• intelligent machines बनाने की दौड़ जारी है, लेकिन इसके साथ उन्हें गुलामों की तरह चलाने की दिशा भी दिखाई देती है

computing शुरू करने की वजह और अब भी बचे हुए मानदंड

• computing की शुरुआत में विचारों की सुंदरता, कुछ बनाने का आनंद, और ऐसे tools बनाने की संभावना थी जो लोगों की मदद करें और मानवीय रिश्तों को प्रोत्साहित करें
• उन मूल्यों पर विश्वास आज भी बाकी है, लेकिन industry का बड़ा हिस्सा उस दिशा से दूर जा चुका है
• कक्षा में पढ़ाई जाने वाली चीज़ों से भी अधिक महत्वपूर्ण मानदंड के रूप में, दुनिया में आगे बढ़ते समय या पढ़ाई जारी रखते समय बार-बार सोचने लायक एक दृष्टि सामने है

किन narratives का पीछा नहीं करना चाहिए और कौन-सी सीमाएँ पहले तय करनी चाहिए

• किसी तकनीक को अपरिहार्य बताने या यह कहने वाली self-justifying narrative पर भरोसा करने की ज़रूरत नहीं कि यह आगे भी ऐसे ही चलती रहेगी
• हावी narrative का बिना सोचे-समझे पालन करने की ज़रूरत नहीं; आप स्वयं इरादतन चयन कर सकते हैं और दूसरों को भी ऐसा करने में मदद कर सकते हैं
• अपनी नैतिक और आचारिक सीमाएँ पहले से तय रखनी चाहिए, और बाद में कुछ बेहतर मिलने तक सिद्धांतों को थोड़ी देर के लिए किनारे रख देने वाले समझौते में संतुष्ट नहीं होना चाहिए

गहराई से सोचने की क्षमता और काम करने का तरीका

• गहराई से सोचने की क्षमता विकसित करनी चाहिए, और इसके लिए जगह और समय दोनों में बिना बाधा वाले हिस्से खुद बनाने चाहिए
• इस प्रक्रिया में, उन तकनीकों या काम करने के patterns के लिए भी ना कहना ज़रूरी हो सकता है जिन्हें दूसरे लोग महत्वपूर्ण या अपरिहार्य मानते हैं
• code को तब तक refactor करना चाहिए जब तक वह स्पष्ट और सुरुचिपूर्ण न हो जाए, और ऐसा अच्छा documentation लिखना चाहिए जिसे दूसरे लोग पढ़ सकें
• जब सब लोग तेज़ी से चलने और shortcuts लेने का दबाव डालें, तब भी धीरे चलने का साहस होना चाहिए

किसे अधिक प्राथमिकता देनी चाहिए

• मुनाफे, code और productivity से अधिक लोगों, रिश्तों और न्याय की गहरी परवाह करनी चाहिए
• सबसे बढ़कर, डर नहीं बल्कि प्रेम से संचालित होना चाहिए

[GN⁺]

Hacker News की रायें

• जो लोग सिर्फ अकादमिक दुनिया में रहे हैं और जिन्होंने कभी कंपनी में engineer के तौर पर काम नहीं किया, उनका industry सलाह देना काफ़ी खटकता है
  craft का ख़याल रखने, कोड को लगातार निखारने और बहुत मेहनत से documentation लिखने की सलाह, shortcuts से बचने वाली बात को छोड़ दें तो, कुछ ही सालों में बेरोज़गारी की ओर जाने वाला रास्ता लगती है
  अगर यहाँ craft से मतलब code लिखना और उसे polish करना है, तो वह धीरे-धीरे high-level system design के सामने पीछे छूटती, पुरानी पड़ती skill जैसा दिखता है
  इतना मेहनत से लिखा documentation आख़िर पढ़ेगा कौन, और अंत में क्या वे agents नहीं होंगे जो मेरी जगह ले लेंगे?

  • पिछले 1 साल में मैंने पिछले 5 सालों को मिलाकर जितना उपयोगी software ship किया था, उससे ज़्यादा किया है, और इसका बड़ा कारण यह है कि मैंने code ही output है वाली सोच छोड़कर product ही output है वाली सोच अपनाई
    craft ग़ायब नहीं हुआ, बस एक स्तर ऊपर चला गया
    अगर कोई junior कई हफ़्तों तक refactoring में लगा रहे, तो वह उस junior से जल्दी पीछे रह जाएगा जो पहले ship करता है और फिर iterate करता है
    अभी feedback loop बहुत ज़्यादा तेज़ है
  • हो सकता है industry की नज़र ही उल्टा short-sighted हो
    आख़िर सबके अपने biases होते हैं
  • निराशा शायद इस बात से आती है कि professors अपने values के आधार पर चुन सकते हैं, लेकिन औसत व्यक्ति के लिए ऐसा करना आसान नहीं होता
    यह दुखद है कि आधुनिक समाज में, चाहे जैसा भी महसूस हो, जीवित रहने के लिए वही करना पड़ता है जो ज़रूरी है; मुझे लगता है बहुत-सा दुख वहीं से आता है
  • यह खटकता है, इस बात से सहमत हूँ, और LinkedIn देखने पर भी साफ़ दिखता है कि इनके पास सचमुच सिर्फ अकादमिक अनुभव ही है
    लेकिन फिर भी मुझे नहीं लगता कि ऐसी सलाह सीधे बेरोज़गारी तक ले जाती है
    कंपनियों में भी बहुत तेज़ी से काम होता है, लेकिन ये principles हर स्थिति में न सही, काफ़ी हद तक साथ-साथ चल सकते हैं
    industry advice के मामले में लगभग 30 साल के अनुभव वाले AWS Distinguished Engineer Marc Brooker ज़्यादा practical लगते हैं
    https://brooker.co.za/blog/2026/03/25/ic-junior.html
  • मुद्दा यह नहीं है कि documentation कौन पढ़ता है
    high-level system design अच्छी तरह करने के लिए आख़िरकार ख़ुद code लिखने और refactor करने का पर्याप्त अनुभव होना ज़रूरी है
    यह वैसा है जैसे कोई chef बनना चाहता हो लेकिन ingredients काटना-छाँटना सीखे बिना सिर्फ़ आदेश दे
    elegant code लिखने की कोशिश इसलिए नहीं की जाती कि कोई और उसे पढ़ेगा, बल्कि इसलिए कि उसी प्रक्रिया में शरीर-मन से सीखा जाता है कि engineering trade-offs और abstraction कैसे काम करते हैं

• engineering ethics के लिए अपने मानदंड पहले से तय कर लेना चाहिए — इस बात से सहमति है
  UK में mechanical engineering की undergraduate पढ़ाई के दौरान ethics course अनिवार्य था, और Bhopal disaster जैसे case studies पर चर्चा हुई थी; वह आज भी याद है
  इसके उलट, कम-से-कम UK के computer science विभागों में मैंने ऐसे ethics courses बहुत कम देखे हैं, और मुझे लगता है इस क्षेत्र में ऐसी शिक्षा की बेहद ज़रूरत है

  • CS degree में अनिवार्य ethics course था, लेकिन यह उम्मीद करना कि students बस एक course को हल्के में लेकर अपनी सोच बदल लेंगे, काफ़ी भोली बात है
    Therac-25 पर चाहे जितनी चर्चा कर लो, उससे कोई व्यक्ति सच में यह नहीं पूछने लगेगा कि उसे Palantir या Raytheon में काम करना चाहिए या नहीं
  • अमेरिका में लगभग सभी ABET-accredited CS programs में Ethics in Computer Science credits की ज़रूरत होती है
    मैंने भी Therac-25 सहित कई cases पढ़े थे, और general ethics व philosophy की बुनियाद भी पढ़ाई गई थी, जो काफ़ी अच्छी लगी
  • लगभग 8 साल पहले जब मैं अमेरिका में computer engineering की undergraduate पढ़ाई कर रहा था, तब ethics class अनिवार्य थी, लेकिन याद पड़ता है कि मिलते-जुलते career path वाले CS curriculum में वह नहीं थी
    अब शायद जोड़ दी गई है, तो या तो मुझे ग़लत याद है या बाद में शामिल की गई
    class ख़ुद मुझे अच्छी लगी थी, और contract negotiation जैसी चीज़ें भी सिखाई गई थीं, लेकिन उस समय मुझे सच में यह एहसास नहीं था कि ये सवाल कभी मेरे अपने काम का हिस्सा बनेंगे
    काम शुरू करने के बाद ही वह बदल गया
  • पढ़ाते समय मैं ऐसे लेख इस्तेमाल करता हूँ
    We should teach our Students what Industry doesn’t want, Kevin Ryan, https://dl.acm.org/doi/pdf/10.1145/3377814.3381719
    Are you sure your software will not kill anyone?, Nancy Leveson, https://dspace.mit.edu/handle/1721.1/136281.2
  • सिर्फ़ ethics पढ़ाने से बुरा इंसान अच्छा इंसान बन जाएगा — इसे किसी magic bullet की तरह देखना बहुत भोला है

• LLM को किसी भी रूप में इस्तेमाल नहीं करूँगा — यह रुख़ समझ में आता है
  उम्मीद है कभी ऐसा vegetarian-type LLM आएगा जिसे ऐसे लोग भी स्वीकार कर सकें
  मैं केवल public domain data पर trained models पर नज़र रख रहा हूँ, लेकिन अभी तक ऐसा कोई उपयोगी model नहीं देखा जिसमें web scrape data न मिला हो या जिसे non-vegetarian models के outputs पर fine-tune न किया गया हो
  Andrej Karpathy का कहना है कि अब GPT-2 स्तर का model 80 डॉलर से भी कम में train किया जा सकता है, इसलिए कम-से-कम environmental cost शायद कभी स्वीकार्य स्तर तक नीचे आ जाए
  https://twitter.com/karpathy/status/2017703360393318587
  अच्छा होगा अगर computer science के professors ऐसे दिलचस्प models को अपने principles तोड़े बिना ख़ुद छू-परख सकें
  संयोग से मैंने HN के front page पर https://talkie-lm.com/introducing-talkie देखा, और संबंधित post यह थी: https://news.ycombinator.com/item?id=47927903
  पहले मैंने public domain data पर बने Mr Chatterbox को भी देखा था, लेकिन उसमें Haiku और GPT-4o-mini द्वारा बनाए गए synthetic conversation pairs थोड़े मिले हुए थे, इसलिए उसकी शुद्धता संदिग्ध थी
  https://simonwillison.net/2026/Mar/30/mr-chatterbox/
  Talkie भी पूरी तरह शुद्ध नहीं है, और उसने ख़ुद बताया है कि Claude Opus 4.6 और Talkie के बीच rejection-sampled synthetic chats पर supervised fine-tuning का एक और चरण किया गया है

  • मैं मानव श्रम के शोषण और दुर्लभ संसाधनों की बर्बादी जैसे वाक्यों को online haters द्वारा बार-बार दोहराई जाने वाली अतिशयोक्ति की तरह देखता हूँ
    मेरा मानना है कि इंटरनेट तक पहुँचने के लिए इस्तेमाल होने वाले computing devices के निर्माण में, ML models की training की तुलना में, ज़्यादा resources लगे होंगे और ज़्यादा human labor का exploitation हुआ होगा
  • यह real programmers write assembly से शुरू होकर real programmers don't need copilot, real programmers don't use llms तक आने वाली परंपरा जैसा लगता है
    अभी बस उसकी जगह LLM ban ने ले ली है

• गहराई से सोचने की क्षमता विकसित करने के लिए, exercise और reading जैसी routines जो attention को restore करती हैं, सचमुच असरदार होती हैं
  अक्सर लगता है कि समय ही नहीं है, लेकिन जब इन्हें लगातार फिर से शुरू करते हैं, तब पता चलता है कि ये activities समय छीनती नहीं, बल्कि दूसरी चीज़ों के लिए ज़्यादा समय बना देती हैं

  • सच में, अजीब हद तक ऐसा होता है
    मैंने कभी नहीं सोचा था कि marathon training शुरू करने से रोज़मर्रा की energy इतनी बढ़ जाएगी, लेकिन सच में ऐसा हुआ

• यह लेख किसी ऐसे व्यक्ति का लिखा हुआ लगता है जिसने पूरी ज़िंदगी academic bubble में बिताई है और जिसने conflicting interests वाले लोगों के बीच, समय की पाबंदी में, फ़ैसले नहीं किए
  कोई artist अपनी कसौटी पर अपने काम को और बेहतर बनाना चाहे — यह ठीक है — लेकिन अगर वह ग्राहक क्या चाहता है, यह समझे बिना उसी को प्राथमिकता दे, तो अंत में दिवालिया हो जाएगा
  अपनी रुचियों को hobby की तरह पालिए, और अगर वही आपकी कमाई की क्षमता से मेल खा जाए तो यह अच्छी किस्मत है
  ज़्यादातर लोगों के लिए ये दोनों चीज़ें मेल नहीं खातीं

  • मैं पलटकर पूछना चाहूँगा कि artists के लिए औसत दर्जे का output जितनी जल्दी हो सके उतनी जल्दी निकालने की रणनीति कितनी सफल रही है
    अब तो यह ऐसा काम है जो बिना किसी training के भी कोई कर सकता है
    LLM ने औसत स्तर का काम तेज़ी से कर पाने की क्षमता को बराबरी पर ला दिया है, और अगर आपकी क्षमता बस इतनी ही है, तो भविष्य नहीं है
    उल्टा अब अजीबपन, विशिष्टता और मौलिकता ज़्यादा महत्वपूर्ण हो गई है, और इस मायने में academic bubble शायद फ़ायदे का सौदा हो सकता है

• Professor Yorgey लंबे समय से अच्छा research करते आए हैं, और उन्होंने एक paper भी लिखा है जो मुझे बहुत पसंद है
  इस तरह खुलकर बोलना अच्छा लगा
  मैंने पहले अपनी alma mater में Anthropic के एक engineer की talk सुनी थी, और वहाँ से जो impression मिला वह यह था: अगर Anthropic ही बेहतर पक्ष है, तो आगे का रास्ता सच में बहुत कठिन होगा
  paper है Monoids: Theme and variations (functional pearl), और यहाँ है
  http://ozark.hendrix.edu/~yorgey/pub/monoid-pearl.pdf

• मैं अकादमिक क्षेत्र में हूँ और मेरे परिवार के कुछ लोग FAANG जैसी कंपनियों में हैं, और इस लेख की टिप्पणियाँ हमारे परिवार में अक्सर होने वाली बहसों से हैरान कर देने वाली हद तक मिलती-जुलती हैं, इसलिए यह मज़ेदार लगा
  मैं deep thinking, research और analysis को महत्व देता हूँ, और code को उस मानसिक काम का byproduct मानता हूँ, जबकि industry में 10 साल से ज़्यादा समय बिता चुके मेरे रिश्तेदार एक line code न लिखने पर गर्व करते हैं और Opus को बस productivity tool की तरह देखते हैं
  लेकिन उस तरह काम करते हुए बड़ी कंपनियों को आख़िर उनकी ज़रूरत क्यों होगी, इसका जवाब वे ठीक से नहीं दे पाते
  क्योंकि बात परिवार की आजीविका से जुड़ी है, इसलिए यह और ज़्यादा दर्दनाक लगता है, और आगे का outlook भी बहुत अच्छा नहीं दिखता

• यह पढ़कर कि technology का इस्तेमाल लोगों को विचलित करने, शोषण करने, निगरानी करने और मारने के लिए होता है, मुझे कोई विशेष आश्चर्य नहीं हुआ
  पहला general-purpose programmable computer 1945 में अमेरिकी सेना के लिए artillery firing tables की गणना के उद्देश्य से बनाया गया था, और जल्द ही उसका उपयोग nuclear weapons design में हुआ
  computers सहित हर technology शुरुआत से ही हथियार की तरह इस्तेमाल हुई है, और आगे भी होगी

  • मेरे हिसाब से ठीक उसके नीचे वाला वाक्य ज़्यादा महत्वपूर्ण है
    कि technology अनिवार्य है, या क्योंकि वह पहले से स्थापित हो चुकी है इसलिए उसका पालन करना ही होगा, इस तरह के self-justification पर भरोसा मत करो
    हावी narrative में बह जाना ज़रूरी नहीं है; आप ख़ुद चुन सकते हैं और दूसरों को भी ऐसा करने में मदद कर सकते हैं

• बिना बाधा का समय और स्थान बनाकर गहराई से सोचने की सलाह पर मैं इन दिनों सचमुच अमल करने की कोशिश कर रहा हूँ
  आजकल सबको पता है कि हर चीज़ हमारा attention छीनने पर तुली है, लेकिन जब तक आप सच में उसका विरोध करने की कोशिश नहीं करते, तब तक उसकी तीव्रता का एहसास भी नहीं होता

• मैं LLM को किसी भी रूप में, किसी भी उद्देश्य से इस्तेमाल नहीं करूँगा — यह वाक्य पढ़कर academic self-satisfaction बहुत ज़्यादा महसूस हुआ

  • जिन्हें जिज्ञासा हो, उनके लिए बता दूँ कि लेखक ने दूसरी पोस्ट में इस रुख़ को और विस्तार से समझाया है
    http://ozark.hendrix.edu/~yorgey/forest/009L/index.xml
  • आजकल हर चीज़ बहुत ज़्यादा polarized होती जा रही है
    LLM इस्तेमाल करने से कोई मूर्ख या भ्रमग्रस्त नहीं बन जाता, और समस्याएँ होने का मतलब यह भी नहीं कि उसे हर हाल में ठुकरा देना चाहिए
    यह सही है कि कुछ लोग और संगठन इस पर ज़रूरत से ज़्यादा निर्भर हैं, लेकिन इसका यह मतलब बिल्कुल नहीं कि जो लोग इसकी उपयोगिता मानते हैं और इसे एक tool की तरह इस्तेमाल करते हैं, वे इसे सोचने-समझने की क्षमता का विकल्प मानते हैं
    अब तो इसके फ़ायदे-नुक़सान पर शांत ढंग से बात करना भी मुश्किल हो गया है; माहौल ऐसा है कि या तो सब कुछ पूरी तरह अच्छा होना चाहिए या पूरी तरह बुरा, और यह थकाने वाला है
    लेखक का रुख़ इतना अत्यधिक है कि उल्टा अनभिज्ञ और मूर्खतापूर्ण लगता है
    अगर कोई शिक्षक है, तो उससे कम-से-कम इससे ज़्यादा खुलापन और nuanced perspective की उम्मीद होती है