हमने abstraction के बहुत ज़्यादा स्तर इस्तेमाल कर लिए
(unixsheikh.com)- tech industry में tools और automation इस्तेमाल करना सीखने वाले लोग बढ़ने के साथ, निचली layers कैसे काम करती हैं यह समझने वाली technical depth कमजोर हो रही है
- abstraction steering wheel या power steering की तरह काम आसान बनाता है, लेकिन breakdown या outage होने पर अगर अंदरूनी चीज़ें जानने वाला कोई न हो तो recovery capability घट जाती है
- तेज़ release और cost reduction का दबाव DevOps·DevSecOps की तरह कई roles एक ही व्यक्ति पर डाल देता है, जिससे और ज्यादा automation और कम deep understanding की स्थिति बनती है
- security में GUI-based penetration testing tools की green light पर ही भरोसा करने से, वास्तविक breach लंबे समय तक detect नहीं हो सकता
- technology सीखने वालों को सिर्फ trends के पीछे भागने के बजाय, tools जो काम उनके लिए करते हैं उसे खुद करके देखना चाहिए, और code व lower layers में गहराई तक जाने वाला engineer का attitude बनाए रखना चाहिए
abstraction से छिप जाने वाला technical understanding का gap
- आज कई “experts” tools configure करना तो जानते हैं, लेकिन technology गहरी layers में कैसे काम करती है यह नहीं समझते
- abstraction अपने-आप में जरूरी है
- steering wheel car चलाना आसान बनाने वाला abstraction है
- power steering driving experience को और बेहतर बनाने वाला एक और abstraction है
- समस्या तब सामने आती है जब abstraction टूटता है
- अगर underlying technology समझने वाला कोई न हो, तो खराब हुई layer को ठीक करना मुश्किल हो जाता है
- tool normal दिखे, फिर भी वास्तविक system state का आकलन नहीं हो सकता
- tech industry profit और release speed के दबाव से जोरदार तरीके से चलती है
- इसके परिणामस्वरूप और ज्यादा abstraction और automation अपनाए जाते हैं
- कम लोग ज्यादा काम संभालते हैं
- deep understanding के बजाय किसी खास tool का इस्तेमाल कैसे करना है, इस पर जोर दिया जाता है
- पहले के programmer और system administrator roles अब DevOps, DevSecOps की तरह development, security और operations को एक व्यक्ति की job में शामिल करने की दिशा में बदल रहे हैं
- एक व्यक्ति के लिए development, security और system administration तीनों में पूरी mastery पाना मुश्किल है, इसलिए जितना हो सके उतना काम automate कर दिया जाता है
- परिणामस्वरूप modern tech workforce किसी खास tool का इस्तेमाल तो सीखती है, लेकिन internal technology के बारे में लगभग कुछ नहीं जान सकती
technology सीखने वालों के लिए जरूरी attitude
- modern life technology पर बहुत निर्भर है, लेकिन technology खुद धीरे-धीरे समझना मुश्किल होती जा रही है
- security में भी यह आलोचना है कि बहुत लोग पहले से बने penetration testing tools का उपयोग करना तो जानते हैं, लेकिन security खुद को ठीक से नहीं समझते
- tool के web GUI में green light दिखे तो माना जा सकता है कि सब ठीक है
- भले ही असली attacker पहले ही system में सेंध लगाकर data को darknet पर बेच रहा हो, leak या breach detect नहीं हो सकता
- कुछ students को files और folders की concept भी नहीं पता, ऐसे उदाहरण के तौर पर Slashdot article लिंक किया गया है
- technology पढ़ने वालों के लिए जरूरी practices ये हैं
- सिर्फ hype या trends का पीछा न करना
- केवल tools न सीखकर underlying technology कैसे काम करती है, यह समझना
- संभव हो तो configuration tool जो काम आपके लिए करता है, उसे एक बार manually करके देखना
- संभव हो तो tool का code देखना
- लगातार सीखना और experiment करना, और जिस technology में रुचि हो उसमें और गहराई तक जाना
- संभव हो तो homelab बनाकर उसे सीखने और चीज़ें तोड़ने के playground की तरह इस्तेमाल करना
- जो समझ न आए उस पर सवाल पूछना, और यह default assumption न रखना कि कोई और इसे बेहतर जानता ही होगा
- इसका मतलब यह नहीं कि हर व्यक्ति को हर चीज़ first principles से समझनी चाहिए या tools इस्तेमाल नहीं करने चाहिए
- abstraction जरूरी है
- जैसे truck driver truck चलाता है और mechanic truck ठीक करता है, वैसे ही specialties मौजूद हैं
- मुख्य समस्या यह है कि technology के साथ काम करने वाले लोगों में होना चाहिए ऐसा engineering attitude कमजोर हो रहा है
- software development में बहुत सारी specialist roles tools और automation से replace हो रही हैं
- धीरे-धीरे और भी कम लोग अपने काम वाली layer के ठीक नीचे की layer तक को नहीं समझते
- अगर web developer TCP/IP, DNS, HTTP, TLS और security knowledge के बिना केवल पहले से बने tools या frameworks से site बनाता है, तो समस्या आने पर उसकी usefulness बहुत घट जाती है
1 टिप्पणियां
Hacker News की राय
विमानन इतिहास में भी एक समय ऐसा था जब जो व्यक्ति विमान उड़ा सकता था, वही उसे डिज़ाइन और बना भी सकता था। सोचता हूँ, क्या तब भी लोग उस भविष्य को लेकर चिंतित रहे होंगे जिसमें मशीन के first principles को सच में न समझने वाला कोई व्यक्ति cockpit में बैठेगा
आज हम इस विचार के आदी हो चुके हैं कि उड़ाना और बनाना अलग-अलग skills और professions हैं, और यह भी स्वाभाविक मानते हैं कि aerospace engineer को bauxite mining या aluminium smelting आना ज़रूरी नहीं
logic gates से web request तक पूरा रास्ता देख पाना आश्वस्त करता है, लेकिन यह अनिवार्य नहीं है। ऐसे overview वाले engineers का कम होना चेतावनी संकेत से ज़्यादा tech industry की परिपक्वता और क्षेत्रों के विभाजन को दिखाता है
उदाहरण के लिए, “चलो सब assembly पर लौट चलें” जैसी बातों में, high-level languages मुख्यधारा बनने के बाद भी काफी समय तक programmers को assembly जाननी पड़ती थी। भले ही ज़्यादातर काम C या Pascal में होता हो, compiler और debugging tools की abstractions leak करती थीं
आज की समस्या यह है कि mature होने का समय दिए बिना leaky abstractions को परत-दर-परत चढ़ाया जा रहा है। इन्हें इस गलत धारणा के तहत काम का समय घटाने के लिए design किया जाता है कि developers हमेशा happy path पर ही होंगे, लेकिन असल में ज़्यादातर समय उन स्थितियों को debug करने में जाता है जहाँ चीज़ें design के मुताबिक नहीं चलतीं। happy path को तेज़ बनाने की जगह अगर unhappy path को धीमा कर दिया जाए, तो आम तौर पर net loss होता है
Airbus automation stall को लगभग असंभव बना देता है, जब तक कि कुछ बहुत गलत न हो जाए और वह manual law पर वापस न लौट आए, इसलिए उसे ठीक से समझ नहीं था कि stall कैसे काम करता है। उस flight में ठीक यही हुआ, और जब captain cockpit में वापस आया तो उसने तुरंत deep stall पहचान लिया, लेकिन तब तक बहुत देर हो चुकी थी
संबंधित Mentour Pilot वीडियो: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
उड़ान की प्रक्रिया में शुरुआत से ही physical limits होती हैं, लेकिन computing और उसके बारे में सोचने के frameworks बेहद बदलने योग्य हैं और उनका scope भी व्यापक है। आजकल बिकने वाली बकवास को अगर aviation analogy में बदलें, तो यह उड़ान के नाम पर गधे की सवारी बेचने जैसा है। कई customers के पास फर्क समझने का ज्ञान नहीं होता
progress के लिए एक अहम ingredient यह है कि किसी चीज़ को सरल बनाना सीखने के बाद ही हम उस आधार पर बड़ी छलांग लगा सकते हैं। अगर चीज़ बहुत जटिल हो जाए, तो जाने की दूरी और ऊँचाई पर सीमा लग जाती है। यह technical debt को मानवता के पैमाने तक बढ़ाने जैसा है
दुर्भाग्य से, इतिहास में जब कोई चीज़ एक स्तर और सरल हो जाती है, हम उसे ठीक से पहचान नहीं पाते। पीछे मुड़कर देखने पर वह स्वाभाविक रूप से obvious लगती है
मुझे लगता है आजकल के बच्चों को पर्याप्त credit नहीं मिलता। कुछ हफ्ते पहले एक दोस्त के बेटे ने बहुत उत्साह से वह Roblox game दिखाया जो वह अपने दोस्तों के साथ बना रहा था
Canadian Thanksgiving था, इसलिए परिवार और परिचितों के कई लोग मौजूद थे। उसने पहले ही चुन लिया था कि किसे कौन-सा हिस्सा दिलचस्प लगेगा, और मैं “Lua दिखाने वाला व्यक्ति” था
लोग सोचते हैं कि phones या laptops lock रहते हैं और curiosity नहीं जगाते, इसलिए बच्चे भी ऐसे ही होंगे, लेकिन उल्टा मुझे लगता है कि adults ही कम curious हो गए हैं
बेशक यह abstractions पर बना है, लेकिन high abstractions के पहाड़ों के बीच भी curious minority के लिए घाटियाँ हमेशा रही हैं। C64 BASIC किसी भी memory address को POKE करने देता था, लेकिन 10 साल के बच्चे से FPS elements वाले एक complex 3D collection game की व्याख्या सुनना भी काफी शानदार बात है
माहौल ऐसा है जैसे कोई बूढ़ा आदमी बादलों पर चिल्ला रहा हो
कुछ लोग experts होते हैं और कुछ बस ठीक-ठाक स्तर के होते हैं—इसमें नया कुछ नहीं। हर कोई मसीहा नहीं हो सकता, जैसे इस छोटे लेख का आधा हिस्सा अपनी शेखी में खर्च करने वाले author
इस लेख का abstraction से बहुत कम संबंध है। author पहले दो paragraphs के बाद अपने thesis में रुचि खो देता है
examples भी बहुत खराब हैं। “किसी ने modern framework इस्तेमाल किया और hack हो गया, लेकिन performance problem hack की वजह से नहीं बल्कि framework के भयंकर slow होने की वजह से थी” — कौन-सा framework था, सिर्फ diff देखकर कैसे पता चला कि वह slow है, और tools को performance के हिसाब से tune न कर पाना abstraction से कैसे जुड़ता है, कुछ समझ नहीं आता
एक और समस्या यह है कि हमने कई बार गलत abstraction अपनाए हैं। आज software industry में एक घमंडी monoculture है जिसे लगता है कि हम इतिहास के अंतिम पड़ाव पर आ गए हैं और सब कुछ समझ चुके हैं।
असल में, मुझे लगता है कि हाल की कई technologies में हम गलत रास्ते पर चले गए। लगभग 2014 तक सब कुछ सही दिशा में जाता हुआ लगता था, लेकिन उसके बाद progress उलटी पड़ने लगी और हर कोई वही overhyped framework इस्तेमाल करने लगा। कंपनियों ने ये framework सब पर थोपे, और software development inefficent और हौसला तोड़ने वाला काम बन गया।
मैंने अपने personal projects के लिए एक SDK बनाया है, जो company के काम में इस्तेमाल होने वाले mainstream frameworks से कम से कम 10 गुना ज़्यादा productive है, और code भी कहीं ज़्यादा पढ़ने और maintain करने लायक है। अगर मैं इसे किसी ऐसे junior को दिखाऊँ जिसे framework नहीं पता, तब भी वह productive तरीके से काम कर सकता है। इस SDK से मैंने part-time 2 महीनों में एक no-code BaaS platform बना लिया, जबकि mainstream tools और frameworks से मुझे लगता है कि मैं या कोई और full-time 12 महीनों में भी यह मुश्किल से कर पाता।
बेशक उसमें दूसरे frameworks से बेहतर बातें हो सकती हैं, लेकिन परिचय expertise पैदा करता है और expertise productivity पैदा करती है।
drywall screws popular होने से पहले कई skilled workers को पूरा यकीन था कि screws धीमे और खराब हैं, लेकिन nails में expert और screws में expert—दोनों अपना काम तेज़ और अच्छा पूरा करते हैं।
frontend हो या backend, हमारे “इन frameworks” को इस्तेमाल करने के कारण हैं। हो सकता है वे कारण आपको पसंद न आएँ, लेकिन enterprise programming में सिर्फ language purity नहीं, बल्कि hireability, maintainability, continuity जैसे पैसा कमाने वाले factors मायने रखते हैं।
अगर company आपका custom SDK इस्तेमाल करे और आप छोड़कर चले जाएँ, तो क्या होगा? आपको लग सकता है कि आप इसे दूसरों को आसानी से सिखा सकते हैं, लेकिन company के technology decisions में इससे कहीं ज़्यादा factors शामिल होते हैं।
“आजकल के तथाकथित experts में से बहुतों को बस कोई trending tool configure करना आता है; deeper level पर चीजें कैसे चलती हैं, इसकी उन्हें बिल्कुल समझ नहीं होती” — यह बात बहुत असर करती है।
हर कोई “X करना है तो config file में यह line जोड़ो” जैसे रटकर सीखे हुए procedures जानता है, लेकिन जब X से थोड़ा अलग कुछ करना हो, या X का कोई variant करना हो, तो script से बाहर कैसे जाना है यह नहीं जानते। इससे भी बुरा, लोग conversation को not-quite-X से वापस X पर लाने में समय बर्बाद करवाते हैं। यह उसी analogy की याद दिलाता है जिसमें खोया हुआ wallet सिर्फ streetlight के नीचे खोजा जाता है।
मुझे लगता है कि ऐसा technology ecosystem—एक तरह का “techosystem”—बनाना शानदार है, जिसमें बहुत narrow knowledge के साथ भी योगदान दिया जा सके। कम positive ढंग से कहें तो इससे companies कम technical skill मांगने वाली सस्ती labor hire कर सकती हैं।
कई मामलों में मेरा मानना है कि औसत दर्जे का solution किसी solution के न होने से बेहतर है। 1995–2005 का internet औसत दर्जे के solutions पर बना था, और वह सचमुच मजेदार था।
गहराई में जाने वाले experts कोई लुप्त होती species नहीं हैं, न ही abstraction से पहले के युग का secret knowledge रखने वाला limited resource। बल्कि आज वे पहले से कहीं ज्यादा हैं। उन्हें इस बात से define नहीं किया जाता कि उन्होंने stack के ऊपर-नीचे सब कुछ किया है या नहीं, बल्कि इस curiosity से किया जाता है कि वे अपने layer से बाहर भी झांकते हैं।
क्योंकि ऊपर abstraction layers जुड़ने के साथ-साथ नीचे की layers भी NVMe, WebGPU, WebAssembly, QUIC, AVX512 जैसी चीजों के कारण बदल रही हैं।
हालांकि मेरा मानना है कि गहराई में जाने वाला expert ज्यादातर teams के लिए एक गैर-जरूरी luxury है, और technology manager की सबसे महत्वपूर्ण क्षमताओं में से एक यह जानना है कि ऐसे व्यक्ति को कब जरूर hire करना चाहिए।
abstraction levels का बढ़ना जरूरी है। इंसान का दिमाग साल-दर-साल बहुत ज्यादा capable नहीं हो रहा, लेकिन available tools की संख्या बढ़ रही है, इसलिए focus करने के लिए abstraction चाहिए।
इसका मतलब यह नहीं कि भविष्य अंधकारमय है। business problems पर काम करने वाला programmer EUV, compiler, assembly, instruction set, kernel, USB protocol, HTTP, die, substrate आदि जाने बिना भी high-level language में बहुत productive हो सकता है। pilots को भी aerodynamics, tensile strength, aluminum, rubber, GPS आदि सब जानने की जरूरत नहीं होती।
लेकिन modern society में incentive misalignment पर चर्चा जरूर की जा सकती है। मैं pilots पर generally business software developers, researchers, bankers से ज्यादा भरोसा करता हूँ। क्योंकि crash होने पर pilot सबसे पहले पहुंचता है।
catapult के लिए software को उस overly generic CRUD app से अलग approach चाहिए जो यह expose करती है कि आपके पास कितनी mansions हैं।
दुनिया में बहुत बेवकूफ software है, और यह ठीक है। कई “real problems” भी काफी बेवकूफाना होती हैं और heroic engineering नहीं मांगतीं।
डराने वाली हद तक कई मामलों में बस जोड़-तोड़ कर बनाया गया घटिया software भी पर्याप्त होता है।
मुझे भी यह पसंद नहीं, लेकिन मुझे लगने लगा है कि या तो अपनी बेहतर engineering से business बनाकर compete करूं और साबित करूं कि वे गलत हैं, या फिर मान लूं कि मैं cloud पर चिल्ला रहा हूँ।
hospitals खरीदारी के decisions लेते समय software quality को “यह button दब नहीं रहा” के स्तर से बस थोड़ा आगे तक ही जांचते हैं।
abstractions की आलोचना करने वाले लेख में “आजकल कुछ students को यह भी नहीं पता कि files और folders क्या होते हैं” वाक्य को hyperlink के रूप में लगाना अजीब तरह से fitting है।
वह link Slashdot thread पर जाता है, वहां से PC Gamer article पर, वह article Verge article को फिर से लिखकर link करता है, और Verge article Stack Exchange question तक जाता है।
दूसरे शब्दों में, यह cargo cult programming है। मैंने इस पर 2 साल पहले लिखा था [1], और प्रतिक्रियाएँ पूरी तरह सहमत होने या इसे gatekeeping कहकर तीखा हमला करने के बीच बँट गईं
काश इस बीमारी को ठीक करने का कोई बेहतर तरीका होता, बिना उन engineers के पेशेवर immune system को छेड़े जो अपनी पसंदीदा technologies में गहराई से invested हैं
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
दोनों लोग सवाल समझ नहीं पाए, लेकिन उसने सवाल को स्पष्ट करने या यह सोचने की कोशिश भी नहीं की कि समस्या सवाल में हो सकती है
“React.js expert से direct DOM manipulation, MVC-based client-side templates, component-based DOM manipulation, vanilla JS में compile करने जैसे अलग-अलग SPA approaches की तुलना करने को कहा” — यह वाक्य मुझे भी ईमानदारी से समझ नहीं आता
“vanilla JS में compile” से मतलब TypeScript को JavaScript में compile करना है या नहीं, और उसका DOM से क्या संबंध है, मुझे नहीं पता। “MVC-based component-based DOM manipulation” भी अजीब है। यह ऐसा लगता है जैसे किसी ने design patterns की किताब पढ़ी हो और जो लोग उसके जैसे शब्द इस्तेमाल नहीं करते उन्हें marks काटता हो; ऐसा नहीं लगता कि वह development को ज्यादा गहराई से समझता है
मेरे हिसाब से जो लोग अच्छा काम कर लेने की संतुष्टि को सच में enjoy करते हैं, वे आम तौर पर उन लोगों से ज्यादा समय चीज़ों को सच में समझने में लगाते हैं जो बस काम खत्म करना चाहते हैं
लेकिन वह जिज्ञासा हमें क्या देती है? मुझे fortune(6) का यह किस्सा याद आता है, और सोचता हूँ कि जिन लोगों में जिज्ञासा नहीं है उनमें से कितने इसे समझ पाएँगे
एक नौसिखिया खराब Lisp machine को power off और on करके ठीक करने की कोशिश कर रहा था। Knight ने उसे देखा और सख्ती से कहा, “क्या गलत है यह समझे बिना सिर्फ power off और on करके तुम machine ठीक नहीं कर सकते।” Knight ने machine को off और on किया। machine चल पड़ी
इसे “तुम gatekeeping कर रहे हो, इसलिए मैं जीत गया” जैसे trump card की तरह इस्तेमाल किया जाता है, जो बेहूदा सोच है। उच्च professional standards का समर्थन करने में कुछ गलत नहीं है, और वही मूल रूप से gatekeeping है। डॉक्टर के पास जाते समय मुझे यह जानकर बहुत राहत होती है कि medicine एक gatekept profession है