“कोड कभी मुश्किल हिस्सा नहीं था” सभी प्रोग्रामरों का अपमान है
“Code was never the hard part” AI tools द्वारा increasingly working code generate करने के साथ एक विवाद का मुद्दा बन गया है, जिससे यह डर बढ़ रहा है कि programming skill का मूल्य घट रहा है। टिप्पणीकार इस बात पर बहस करते हैं कि क्या code टाइप करना कभी मुख्य bottleneck था भी, या requirements समझना, system design, maintenance, और organizational politics जैसी बातें ज़्यादा कठिन थीं। कई लोग LLMs को मौजूदा तनावों को बढ़ाने वाला मानते हैं: वे routine coding को तेज़ कर सकते हैं, लेकिन वे low-quality “vibe code” की बाढ़ का जोखिम भी लाते हैं, जिससे human judgment, architecture, और software की long-term जिम्मेदारी पहले से भी अधिक महत्वपूर्ण हो जाती है।
“कोड कभी मुश्किल हिस्सा नहीं था” का अर्थ
- कई लोग इसे इस तरह पढ़ते हैं: जब आप अनुभवी हो जाते हैं, तब “कोड टाइप करना बाधा नहीं है”; असली मुश्किलें यह तय करना होती हैं कि क्या बनाना है, इसे कैसे डिजाइन करना है, और इसे उलझी हुई संस्थाओं में फिट करना है।
- दूसरे लोग कहते हैं कि यह वाक्य भ्रामक या अपमानजनक है, क्योंकि यह “कोडिंग आसान है” जैसा सुनाई देता है और वास्तविक तकनीकी कठिनाई को मिटा देता है, खासकर गैर-तुच्छ डोमेनों में।
क्या कोडिंग कठिन है?
- कई लोग तर्क देते हैं कि बुनियादी कोडिंग बहुत से लोगों के लिए स्वभावतः कठिन है (CS छोड़ने की दर, fizzbuzz में असफलता, वर्षों के अभ्यास की आवश्यकता)।
- दूसरे कहते हैं कि, requirements, architecture, communication, और politics की तुलना में, code implement करने का काम अक्सर पूरी नौकरी का सबसे आसान हिस्सा होता है।
- अक्सर “कुछ चलाना” और ऐसा code लिखना जो performant, correct, maintainable, और evolvable हो—इनमें फर्क किया जाता है; दूसरा वाला अब भी कठिन माना जाता है।
Coding बनाम programming / engineering
- बार-बार आने वाला विषय: “coding” = निर्देश डालना; “programming/engineering” = समस्या हल करना, design करना, domains को model करना, systems को integrate करना, और उन्हें operate तथा evolve करना।
- कई लोग कहते हैं कि अच्छे engineers अनिवार्य रूप से “अदृश्य टोपी” पहनते हैं: requirements refinement, architecture, performance, security, compliance, operations।
AI/LLMs और उनका प्रभाव
- कुछ लोगों का दावा है कि LLMs ने रोज़मर्रा की coding के बड़े हिस्से को कम-कौशल वाले “line cook/burger flipping” काम में बदल दिया है; असली value अब design, orchestration, और specification की ओर खिसकती है।
- दूसरे लोग बताते हैं कि LLMs ज़्यादा sloppy, buggy, या unsafe code बनाते हैं, खासकर complex systems (distributed, regulated, performance-critical) में, जिससे review और maintenance का बोझ बढ़ता है।
- साझा दृष्टिकोण: LLMs boilerplate और “typing” में मदद करते हैं, लेकिन गहरी समझ, दीर्घकालिक maintenance, या सही उच्च-स्तरीय निर्णयों की जगह नहीं ले सकते।
Product, requirements, और organizations
- बहुत से लोग कहते हैं कि असली bottlenecks अस्पष्ट requirements, बदलती priorities, और cross-functional alignment हैं; “बिना meetings वाले coding days” दुर्लभ होते हैं और बहुत प्रिय।
- इस बात पर असहमति है कि user understanding का मालिक कौन होना चाहिए: कुछ कहते हैं engineers को शुरू से शामिल होना चाहिए; दूसरे मानते हैं कि product/PM को engineers की ढाल बनना चाहिए और research संभालनी चाहिए।
Quality, maintenance, और regulation
- Maintenance और debugging को बार-बार सबसे कठिन, सबसे समय लेने वाले हिस्सों के रूप में उद्धृत किया जाता है; मौजूदा code का बहुत सा हिस्सा “basic audit” में भी पास नहीं होगा।
- regulated या safety-critical domains में, process और documentation code से भी बड़े हो सकते हैं, लेकिन code फिर भी सही होना चाहिए और उसे सुरक्षित रूप से बदलना कठिन होता है।
Labor, status, और identity
- कई लोग “code was never the hard part” को automation anxiety के सामने एक coping narrative के रूप में देखते हैं।
- दूसरे नोट करते हैं कि high salaries scarcity और leverage को दर्शाती थीं, केवल difficulty को नहीं, और कई non-coding skills (product, management) भी कठिन हैं लेकिन उनकी visible value कम मानी जाती है।