- Missouri के एक दादाजी का जीवन दिखाता है कि craft सिर्फ़ साधारण हाथ की कुशलता नहीं, बल्कि खराबी और जोखिम को पहले से पहचानकर लोगों और systems को अधिक सुरक्षित बनाने का एक रवैया है
- डगमगाते dining table के पाये, घटिया सामग्री, बिगड़े हुए angles, और बीमार पेड़ को पढ़ लेने की संवेदना, तैयार वस्तु के पीछे छिपे चयन·सीमाएँ·घर्षण को देखने की क्षमता के अधिक क़रीब है
- युद्ध के बाद एक खतरनाक bag factory में काम करने के उनके अनुभव से पता चलता है कि speed से ज़्यादा cadence बनाए रखना जीवन-मरण का सवाल हो सकता है
- software industry में craft पर कुछ चर्चाएँ, कौशल का सम्मान करने के बजाय यह तय करने वाली बहिष्करण की भाषा बन सकती हैं कि असली skilled person कौन है
- craft किसी ख़ास पेशे की हैसियत नहीं, बल्कि बाद में बैठने वाले व्यक्ति के लिए table ठीक करना, और जिन लोगों को ख़तरनाक कहा जाता है उनके साथ गरिमा से पेश आना, और मिलकर अधिक सुरक्षित माहौल बनाना है
दादाजी ने craft की जो संवेदना दिखाई
- Missouri के दादाजी बिजलीविहीन farm पर पले-बढ़े थे, और वे इस बात को महत्वपूर्ण मानते थे कि वे 8वीं कक्षा के बाद भी स्कूल गए थे
- वे अपनी पोती के harp बजाने को “elegant” कहते थे, और Missouri के accent में बोलते थे
- परिवार उन्हें craftsman कहता था, लेकिन craft का अर्थ उस दृश्य में अधिक साफ़ दिखता है जब उन्होंने डगमगाती मेज़ को ठीक किया
- restaurant की मेज़ हिल रही थी, लेकिन दूसरे लोगों ने उसे बस नज़रअंदाज़ कर दिया
- दादाजी ने सिक्के से screw घुमाकर सस्ते और घटिया तरीके से जोड़ा गया पाँव चुपचाप ठीक कर दिया
- वे सिर्फ़ पहले से टूटी चीज़ें ही नहीं, बल्कि जो जल्द टूटने वाली हों उन्हें भी पहचान लेते थे
- वे घटिया सामग्री, जोखिमभरे काम, बिगड़ते angles, और short-term planning के निशानों को संवेदनशीलता से देखते थे
- जब ज़्यादातर लोग chair जैसी तैयार वस्तु देखते थे, तब वे उसके भीतर के choices, constraints, tension, friction, और लगे हुए effort को भी साथ देखते थे
प्रकृति और वस्तुओं में पढ़े गए संकेत
- दादाजी की craft वाली संवेदना सिर्फ़ बनाई गई चीज़ों तक सीमित नहीं थी
- वे दूर से भी beech, birch, maple, और oak के पेड़ों में फ़र्क कर सकते थे
- वे यह भी पहचान लेते थे कि कोई पेड़ स्वस्थ बढ़ रहा है या बीमार पड़ रहा है
- बीमार पेड़ के बारे में वे कहते थे, “जब वह बस खुश नहीं दिखता”
- ऐसी अवलोकन-क्षमता वस्तुओं और प्रकृति की सतह से आगे बढ़कर उनकी स्थिति और संकेतों को पढ़ने की क्षमता में बदल जाती है
युद्ध और factory से सीखा cadence
- दादाजी ने द्वितीय विश्वयुद्ध में 196 दिन लगातार युद्ध झेला, और उसके बाद एक bag factory में काम किया
- वह factory assembly line और equipment वाला एक ख़तरनाक workplace था, और वहाँ ऐसे लोगों को भी नौकरी दी जाती थी जिन्हें सामाजिक रूप से ख़तरनाक माना जाता था
- वहाँ कामकाज संभालते हुए वे अक्सर लोगों को रोक देते थे जब वे ज़्यादा तेज़ या अलग तरीके से काम करना चाहते थे
- क्योंकि काम के तरीके में बदलाव से हंगामा, ripple effect, और “mess” पैदा हो सकता था
- इस वास्तविकता की पृष्ठभूमि थी कि अगर assembly line की लय टूट जाए, तो कोई मर सकता है
- वे सिर्फ़ speed बढ़ाने के बजाय यह सुनिश्चित करते थे कि सब लोग cadence के साथ चलें
- हिंसा के क़रीब माहौल में भी वे हथियार लेकर नहीं चलते थे
- एक रात उन्होंने अपने पीछे आते एक आदमी को देखकर ख़तरे की आशंका की, लेकिन उस आदमी ने कहा कि “यह ख़तरनाक हो सकता है, इसलिए मैं आपके साथ घर तक चलना चाहता था”
- जिस माहौल को ख़तरनाक कहा जाता था, वहाँ भी उन्होंने लोगों पर अविश्वास करने के बजाय भरोसा और सुधार को चुना
जब software industry में craft हथियार बन जाता है
- software engineering में craft की बात करने का तरीका कभी-कभी weaponize हो जाता है
- कुछ developers, teams, और leaders craft के सम्मान की माँग करते हैं, लेकिन यह नहीं मानते कि हर कोई craftsperson बन सकता है
- ऐसी चर्चा अक्सर इस निष्कर्ष की ओर बहती है कि “software का काम दूसरे कामों से अलग है, उसका मूल्यांकन उसी मानदंड से नहीं होना चाहिए, और हम विशेष हैं”
- यह रवैया इस विचार से टकराता है कि हर श्रम skilled labor है
- अगर software work के मूल्यांकन का तरीका बदलना है, तो software को दुनिया के दूसरे श्रम से अलग करके नहीं देखा जा सकता
- जब speed की माँग cadence को पीछे धकेल देती है, तो factory और खेत दोनों में लोग घायल हो सकते थे, और software labor भी उस दुनिया से अलग नहीं है
बहिष्कारी craft और मिलकर बनाया जाने वाला craft
- career की शुरुआत में, एक tech company में contractor के रूप में काम करते समय, software engineers makerspace में अपने-आप प्रवेश कर सकते थे, लेकिन उनका badge दरवाज़ा नहीं खोल पाता था
- किसी ने कहा, “क्या engineers builder नहीं होते?”
- लेकिन पूरी ज़िंदगी कुछ-न-कुछ बनाते रहने का अनुभव सिर्फ़ software engineers के पास नहीं था
- electric fence ठीक करने का अनुभव
- ride-on lawn mower पर driving सीखने का अनुभव
- रात का खाना खरीदने के लिए costume workshop में सिलाई करते हुए उँगलियों पर ख़ून लग जाने का अनुभव
- बहुत से पेड़ों की पहचान कर लेने का अनुभव
- यहाँ जो विरोध है, वह संवाद·सहयोग·सृजन के रूप में craft और निर्णय व बहिष्कार के रूप में craft के बीच है
- craft उस table को ठीक करने के अधिक क़रीब है जिस पर बाद में दूसरे लोग बैठेंगे; यह फैसला सुनाने का काम नहीं कि किसके काम को असली कौशल माना जाने के योग्य समझा जाए
- दादाजी शायद computers या software को अच्छी तरह नहीं जानते थे, लेकिन वे जिन लोगों को ख़तरनाक कहा जाता था उनके साथ गरिमा से पेश आते थे, और उसी वजह से सबको अधिक सुरक्षित बनाते थे
- वे प्रकृति से प्रेम करते थे, लेकिन उन्होंने factory की मशीनों की आवाज़ सुनना भी सीखा, और जिस ecosystem में वे थे उसके भीतर लोगों के लिए बेहतर संभावनाएँ विस्तृत कीं
1 टिप्पणियां
Hacker News की रायें
अच्छा लेख है। शायद लेखक को यह जानकर सांत्वना मिले कि software engineering के भीतर भी अंदरूनी और बाहरी लोग होते हैं, और engineering की कुछ अहम उपलब्धियाँ बाहरी लोगों ने बनाई हैं
गरीबी में पले-बढ़े, self-taught रहे और अपने आसपास अकेले programmer होने के नाते मैं पूरी ज़िंदगी outsider जैसा महसूस करता रहा; दूसरे programmers के साथ घुलना-मिलना शुरू करने के बाद भी वह एहसास खत्म नहीं हुआ
स्थिर परिवार, जीवन-कौशल, college education, व्यापक support network, structural trauma की अनुपस्थिति, और दुनिया को समझने के बिल्कुल अलग तरीकों वाले लोगों के बीच मैं धीरे-धीरे अपनी जगह खोज रहा हूँ, लेकिन outsider होने का एहसास शायद पूरी तरह नहीं जाएगा
यह भी संयोग नहीं है कि मुझे पसंद आने वाला संगीत और कला अक्सर outsider art की श्रेणी में रखे जाते हैं। किसी तरह makerspace में घुस पाना और REPL खोलकर देखना अच्छा होगा। Software engineering कठोर और गहरे engineering principles मांग सकती है, लेकिन software craftsmanship सबका है। Personal computer सामान्य लोगों को खुद को और अपने आसपास की दुनिया को expand करने के लिए बनाए गए थे, और हमें यह बात नहीं भूलनी चाहिए
https://en.wikipedia.org/wiki/Outsider_art
उसके पास liberal arts college की degree थी और वह अपने दम पर coding करता आया था। उसने कहा कि पहली बार real life में दूसरे developers के साथ उठते-बैठते हुए वह daemons, libraries और projects के नामों का उच्चारण नए सिरे से सीख रहा है। उस समय मैंने मन ही मन मान लिया, “junior developer है, बहुत आगे नहीं जाएगा,” और सोचा कि career और status बढ़ाने हैं तो और skilled लोगों के साथ रहना होगा
लेकिन वही व्यक्ति करीब एक साल बाद company छोड़कर दूसरी company में developer के रूप में शुरू हुआ, CTO बना और आखिरकार CEO बना; CEO रहते हुए उसकी company 1 अरब डॉलर से ज्यादा में बिक गई। साथ काम करते समय भी उससे सीखने लायक बहुत कुछ था। लोगों को आसानी से किसी खांचे में बंद कर देना, या यह मान लेना कि किसी स्तर की skill तक दूसरे आसानी से नहीं पहुँच सकते, आसान है; लेकिन ऐसे फैसले बहुत गलत हो सकते हैं। उसने नई company में software development और operations practices पर जो blog posts लिखीं, वे भी बेहतरीन थीं और मैंने उनसे बहुत सीखा
उस खालीपन ने मेरे चुने हुए tech stack को भी प्रभावित किया और आखिरकार मुझे आज का बनाया, लेकिन उम्मीद है कि “Zoom native” पीढ़ी ज्यादा खुले online spaces में व्यापक रूप से जुड़ते हुए इस outsider वाले एहसास को कम महसूस करेगी
मुझे यह लेख खास पसंद नहीं आया। Craftsmanship शीर्षक के नीचे कुछ अस्पष्ट-सी romantic sentimentality बिछी हुई है
पेड़ों को पहचान लेना मुझे craftsmanship नहीं लगता, riding lawn mower चलाना blue-collar नहीं लगता, और रात की सड़क पर किसी से डरना “कुछ जल्द टूटने वाला है” यह पहचानना भी नहीं लगता। “rhythm” को safety device कहना भी अक्सर उल्टा ही होता है। Rhythm आसानी से न रुकने के दबाव की तरह काम करता है, और safety व quality अक्सर इस बात से आती है कि कोई भी line रोक सके
मैंने कुछ “family repairman” भी देखे हैं, लेकिन उनकी प्रेरणा craftsmanship नहीं बल्कि emotional escape थी। परिवार के साथ बैठकर बात करने के बजाय दीवार पर लगे सारे frames फिर से टांगने हैं—ऐसा कुछ। आसपास बेचैनी से नज़र दौड़ाते हुए कुछ ठीक करने लायक चीज़ को बेतहाशा खोजने वाला रवैया पहचाना जा सकता है। Software teams में भी अक्सर किसी ज्यादा असहज चीज़ से बचने के लिए किए जा रहे अनावश्यक काम को “craftsmanship” का justification दे दिया जाता है
फिर भी “ठीक करने वाले” का perspective जिस जगह दिलचस्प है, वह यह समझ है कि दुनिया बदल सकती है और अपने पास उसे बदलने की क्षमता है। समस्या पैदा करने वाली चीज़ों को बस स्वीकार कर लेना अक्सर ज्यादा स्वाभाविक मानवीय प्रवृत्ति होती है। लोगों को रोकने वाली चीज़ आलस तक नहीं, बल्कि possibility न देख पाना है
अगर कुछ ठीक करने के लिए expert बुलाना पड़े, तो उसे फेंककर नया खरीद लेना कहीं ज्यादा आकर्षक लगता है। यह अपेक्षाकृत नया attitude quality में ज्यादा invest न करने और जल्दी टूटने वाला सस्ता सामान बनाने की incentive बढ़ाता है। क्योंकि वैसे भी हम उसे ठीक करने में लगने वाला समय और पैसा खर्च नहीं करेंगे
यह नहीं पता कि दादा वास्तव में insider थे या खुद को ऐसा मानते थे। लेख में एक तरह की nostalgia है और वह ठीक है, लेकिन पढ़ने से पहले मैंने जिस लेख की उम्मीद की थी, यह वह नहीं था
मैं लेखक के दादा से सहमत महसूस करता हूँ। लेकिन आजकल इस attitude को ज्यादा समर्थन नहीं मिलता
हमारे जैसे लोग असल में tech industry के केंद्र में नहीं हैं। पहले कभी थे या नहीं, इसका भी मुझे भरोसा नहीं है, इसलिए मैंने “अब नहीं” नहीं जोड़ा
बहुत पहले पढ़ी हुई Software Craftsmanship नाम की एक काफी अच्छी किताब थी और उसने सांत्वना दी थी। अपने approach की वजह से मुझे अक्सर तिरस्कार झेलना पड़ता था, लेकिन कम से कम मैं पूरी तरह अजीबोगरीब नहीं था
[0] https://en.wikipedia.org/wiki/Software_craftsmanship
फिर भी refactoring पर समय खर्च किया जाए या new features जोड़े जाएँ, इस पर अक्सर अब भी convince करना पड़ता है
मेरी नज़र में सबसे अच्छे software craftsmen वे हैं जो technical debt जमा किए बिना तेजी से features add कर सकते हैं। इसके लिए feature जोड़ने के आसपास के दूसरे हिस्सों को तुरंत ठीक करना और refactor करना सबसे अच्छा है। मूल लेख के दादा भी शायद ऐसे ही व्यक्ति थे
निजी तौर पर भी, सही तरीके से बनाना चाहता हूँ इसलिए कभी-कभी internal deadline miss होने पर भी ज्यादा समय लग जाता है। Code में सही “smell” होना चाहिए। मैंने सीखा है कि ऐसा न किया जाए तो कबाड़ जमा होता जाता है और आखिरकार रात 3 बजे का production incident अपरिहार्य हो जाता है
दूसरे लोगों ने समझा हो या नहीं, फर्क नहीं पड़ता। उन्हें उस approach का फायदा पहले ही मिल चुका होगा
कहानी भावुक है, लेकिन दादा जी ने रेस्तरां की मेज़ ठीक की, उससे मिलने वाली सीख पर थोड़ा और आत्मचिंतन ज़रूरी है
engineering संदर्भों में भी डगमगाती मेज़ की टांग ठीक करने का लोभ होता है। समस्या यह है कि जब तक मैं हर महीने जाकर उसे बार-बार ठीक न करूँ, इससे हालात और बिगड़ सकते हैं। ज़रूरत उस process की है जो समस्या को स्थायी रूप से हल करे
ऊपर से, स्थिति दिखने से कहीं ज़्यादा खराब हो सकती है। डगमगाती टांग किसी गहरी बीमारी का लक्षण हो सकती है। kitchen भी गंदा हो सकता है, और वह टांग कोयला-खदान की कैनरी हो सकती है। सच तो यह है कि पूरा संगठन जड़ से सड़ा हुआ भी हो सकता है
असली समाधान है रेस्तरां को takeover करना, management को निकालना, बेहतर processes बनाना, और लंबी अवधि के नज़रिए को महत्व देने वाली culture तैयार करना
दूसरा तरीका है कुछ भी न करना। मेज़ को डगमगाने देना, ताकि दूसरे ग्राहक इसे कहीं और जाने का संकेत समझें। वह रेस्तरां एक टिकाऊ enterprise के तौर पर अपनी आख़िरी टांग पकड़े हुए है। बेहतर है कि आर्थिक ताकतें उसे जल्दी और बिना भावनात्मक लगाव के बंद होने दें, और उसकी जगह अधिक मज़बूत नींव और अधिक मजबूत टांगों वाली कोई चीज़ ले सके
इस लेख ने मुझे अपने दादा जी की भी याद दिला दी, जिनका 2 हफ्ते पहले दुखद निधन हो गया। वे mechanical engineer थे और सचमुच के कारीगर थे
परिवार में एक किस्सा अक्सर याद किया जाता है। लंबी छुट्टियों की यात्रा के दौरान कार का engine अचानक सड़क के बीचोंबीच बंद हो गया। दादा जी ने समस्या समझी और अपनी हमेशा साथ रहने वाली pocket knife और सड़क किनारे फेंके गए metal can box से कार ठीक कर दी। workshop वालों को उस अस्थायी मरम्मत को हटाकर original part लगाने में काफी मशक्कत करनी पड़ी
मुझे अपने दादा जी की याद आती है, जो उसी दौर में रहे थे। उन्होंने World War II के दौरान bomber control panel की wiring की थी, और सुना है कि वे इसमें काफी माहिर थे
वे लगभग हर काम कर लेने वाले व्यक्ति थे, लेकिन उनका मुख्य पेशा electrician और locksmith का था। garage में वे तरह-तरह की चीज़ों से छेड़छाड़ करते रहते और पुरानी कारों को भी चलाए रखते। middle school में एक गर्मी में मैं अपने grandparents के घर रहा था, तब दादा जी मुझे electrical job sites पर ले जाते और tools और wires लाने को कहते। एक site पर inspector आया और दादा जी ने मेरा परिचय कराया। inspector ने कहा, “Mel ने panel wire किया है, यह मैं हमेशा पहचान सकता हूँ। वह art work होता है”
उस दौर के लोगों को Great Depression और World War II जैसी बहुत-सी कठिनाइयाँ झेलनी पड़ीं, और उनमें से कई farm पर पले-बढ़े थे। इसलिए चीज़ें ठीक करने और उगाने-बढ़ाने का उनके पास भरपूर अनुभव था। ये broadly useful skills थीं, जो हममें से ज्यादातर के पास अब नहीं हैं
मैंने भी guerrilla-style repairs किए हैं। एक बार revolving door में गायब screw बदल दिया था, क्योंकि मुझे पता था कि ऐसा न किया तो वह कभी ठीक नहीं होगा
laundry की कुर्सियों में भी बहुत-से गायब screws लगाए हैं। यह सहना मुश्किल है कि दुनिया में ऐसी चीज़ें जमा होती रहती हैं जिन्हें बस 1 मिनट का ध्यान और 1 dollar के parts चाहिए होते हैं। बिना अनुमति refactoring भी करता हूँ, लेकिन सिर्फ छोटी और आसानी से rollback हो सकने वाली चीज़ें
अभी घर में फँसा हूँ और समय ही समय है, इसलिए एक बड़े refactoring project पर काम शुरू किया है। सफल हुआ तो कमाल होगा, और असफल हुआ तो भी उस problem domain के बारे में कुछ नई बातें सीखूँगा। इस काम को शुरू कराने वाली खुजली सीधी है
“computer के अंदर लगभग हर transistor किसी भी क्षण बस इंतज़ार कर रहा होता है”
दादा जी एक मौन mentor और role model हो सकते हैं। मेरे दादा जी भी ऐसे ही थे, और उनकी बहुत याद आती है
लेखक के दादा जी 『East of Eden』 के Sam Hamilton की याद दिलाते हैं। बेशक वे काल्पनिक पात्र हैं, लेकिन जब मैं सोचता हूँ कि कभी कैसा इंसान बनना चाहता हूँ, तो वे अक्सर याद आते हैं
खासकर दो वाक्य ध्यान खींच गए
pizza को गोल बनाने की कोशिश करते हुए पता चला कि उसमें भी skill और feel है। इतने लोग करते हैं तो यह इतना मुश्किल नहीं हो सकता, लेकिन मैं अभी तक इसे ठीक से सीख नहीं पाया हूँ
cooking भी craft skill है। इसलिए chef interviews में अक्सर “omelette बनाकर दिखाओ” कहा जाता है। कुछ dishes ज़रूर ऐसी हैं जिन्हें recipe को सख्ती से follow करके बनाया जा सकता है, लेकिन कुछ dishes में उँगलियों की practice चाहिए होती है
यहाँ craftsmanship omelette जैसी simple recipe को भी खास स्वाद वाला बनाने में है। इसलिए chefs से ऐसा सवाल पूछा जाता है