- 2016 में Uber की Business Intelligence टीम ने Uber China प्रतिस्पर्धा के लिए ज़रूरी डेटा को तेज़ी से इस्तेमाल करने हेतु R model execution tool और Excel-जैसा UI बनाया, लेकिन Uber China के Didi को बेचे जाने के बाद यह फीचर जल्द हटा दिया गया
- R-Crusher एक internal system था, जिसका उद्देश्य उस अस्थिर workflow को API-आधारित execution tool में बदलना था जिसमें data scientists Vertica data को laptop पर डाउनलोड करके रातभर R models चलाते थे
- चीन की city teams driver incentive calculation के लिए Excel files की आदी थीं, इसलिए टीम ने सैकड़ों-हज़ारों formulas को JavaScript में सीधे पोर्ट करने के बजाय browser में XLS और formulas चलाने वाला spreadsheet engine लागू किया
- Excel से result में सूक्ष्म अंतर आने का कारण यह था कि data scientists circular references का इस्तेमाल linear regression के लिए कर रहे थे, इसलिए इसे Excel की तरह convergence तक iterative calculation करने के लिए अनुकूलित किया गया
- अच्छी तरह लिखा गया code भी हटाया जा सकता है अगर वह जिस business problem को हल कर रहा था, वही समाप्त हो जाए; engineering का मूल्य code की उम्र से ज़्यादा problem solving के करीब है
Uber China को सहारा देने वाला internal data tool
- 2016 में Uber जॉइन करने के बाद लेखक Crystal Ball टीम में पहले frontend engineer के रूप में काम करने लगे
- टीम लगभग 4 लोगों की थी और ज़्यादातर backend उन्मुख थी
- भूमिका यह थी कि internal tools के लिए ऐसा UI बनाया जाए जिसे कंपनी के लोग वास्तव में इस्तेमाल कर सकें
- उस समय data scientists Vertica से data डाउनलोड करके कई laptops पर रातभर R models चलाते थे
- सुबह सिर्फ वही laptops दिन के लिए उपयोगी data देते थे जिन पर model crash नहीं हुआ होता था
- जिन laptops पर failure होता, वे ज़रूरी data नहीं बना पाते, और इससे कंपनी को पैसों का नुकसान होता
- टीम का R-Crusher उस CI system के काफ़ी क़रीब था जो API call के ज़रिए code डाउनलोड करके चलाता और result files बनाता था
- Wesley, जो R-Crusher का frontend था, जॉइन करने के कुछ ही हफ्तों में पहली version तक पहुँच गया
- उसके बाद 6–7 महीनों तक user features, debugging tools और frontend team expansion पर काम चलता रहा
चीन का बाज़ार और driver incentive calculation
- 2016 में Uber के भीतर दो बड़े फोकस थे: app rewrite/redesign और Uber China
- Crystal Ball टीम का काम अंततः Uber China को support करने के लिए ही था
- R-Crusher, Didi से प्रतिस्पर्धा के लिए ज़रूरी data हासिल करने का tool था
- चीन Uber के लिए एक अहम अवसर था, और कुछ ज़रूरी data R-Crusher से आने वाला था
- गर्मियों में एक नई requirement आई
- चीन में ride demand forecasting data रातभर तैयार करने वाला एक model था
- यह data अकेले बहुत उपयोगी नहीं था, लेकिन जब इसे एक खास Excel spreadsheet tab में डाला जाता, तो यह driver incentives की calculation करने वाला interactive tool बन जाता
- finance lead ने कहा कि इस spreadsheet को Wesley के अंदर डालना होगा
- city teams सिर्फ Excel इस्तेमाल करना जानती हैं, इसलिए मांग थी: “इसे Excel जैसा बनाइए”
- जब engineering time की कमी समझाई गई, तो जवाब मिला कि इस tool के बिना हर दिन लाखों डॉलर का नुकसान हो रहा है
Browser के अंदर Excel जैसा व्यवहार बनाना
- Backend में spreadsheet को Python या R code में बदलने का समय नहीं था, इसलिए frontend पर बहुत सा JavaScript लिखना पड़ा
- पहले Box में बनाया गया Box Sums prototype इसकी नींव बना
- इसमें React-आधारित simple spreadsheet UI और basic formula engine था
- XLS/XLSX file को page पर drop करने पर Node library उसके contents parse करती थी
- Uber के लिए implementation का लक्ष्य खुद Excel नहीं, बल्कि Excel के क़रीब behavior था
- XLS file को input के रूप में पढ़ना
- Excel formulas को data के ऊपर चलाना
- Backend ride demand data को 2D array के रूप में देता था, और frontend उसे hidden tab की तरह formula engine में डालता था
- जिन cells को users को बदलना था, उनके अलावा बाकी सबको read-only रखा गया
- असली फ़ायदा यह था कि सैकड़ों-हज़ारों घने formulas को JavaScript में सीधे translate नहीं करना पड़ा
- implementation के दौरान XLS file से formulas निकाले गए और ज़रूरी functions व syntax formula engine में जोड़े गए
-
Excel syntax extension
- absolute cell references
- दूसरे sheets के cell references
- spreadsheet syntax जो पुराने Box demo में नहीं था
-
लगभग सही, लेकिन ग़लत numbers और circular references
- पहली तुलना में Excel और custom engine के results में बहुत हल्का अंतर था
- जहाँ Excel output
3.03था, वहाँ custom output3.01था - जहाँ Excel output
1.002था, वहाँ custom output1.000था
- जहाँ Excel output
- पूरी तरह ग़लत values की तुलना में लगभग सही values ज़्यादा मुश्किल थीं
- इससे लगा कि समस्या किसी simple logic bug की नहीं, बल्कि calculation के सूक्ष्म अंतर की है
- unit tests pass हो रहे थे, और JavaScript double बनाम Excel floating-point representation भी कारण नहीं था
- data scientist से पूछने पर असली कारण सामने आया
- spreadsheet circular references का इस्तेमाल linear regression के लिए कर रही थी
- Excel circular references को हमेशा error की तरह treat नहीं करता
- अगर calculation values किसी निश्चित epsilon से कम अंतर पर converge कर जाएँ, तो वह iterative calculation रोककर उसे सफल मान लेता है
- implementation को बदलकर circular dependency graph detect करने और previous बनाम new calculated values का अंतर तुलना करने वाला बनाया गया
- अगर अंतर काफ़ी छोटा हो, तो नई value स्वीकार की जाती
- नहीं तो iteration count बढ़ाकर calculation जारी रहती
- iteration threshold 1000 रखा गया
- इस बदलाव में लगभग डेढ़ दिन लगा, और output Excel से मेल खाने लगा
- tests लिखे गए और Wesley में integration किया गया
- project जुलाई के दूसरे हफ्ते में deliver कर दिया गया
Launch के बाद security requirement और अचानक समाप्ति
- Tool सचमुच launch हुआ, और Uber China city team के सदस्य login करके उसका इस्तेमाल करने लगे
- लेखक के अनुसार, generated numbers driver incentives के लिए इस्तेमाल किए गए
- यह जुलाई के तीसरे हफ्ते की बात थी
- जुलाई के आख़िरी हफ्ते में finance lead ने इस बात पर आपत्ति जताई कि cell पर click करने से formula दिख जाता है
- चिंता यह थी कि Didi का कोई कर्मचारी Uber China intern बनकर apply करे और data निकाल ले जाए
- यह threat model engineering team के साथ पहले साझा नहीं किया गया था
- formulas को पूरी तरह सुरक्षित करने के लिए calculation को server पर ले जाना पड़ता, लेकिन यह original scope से बाहर था
- तत्काल fix के रूप में UI में cell click पर formula न दिखाने का बदलाव किया गया
- अगस्त 2016 के पहले हफ्ते में Uber China को Didi को बेच दिया गया
- कई कर्मचारियों को यह पहले news alert से पता चला
- कुछ घंटों बाद internal email से deal की घोषणा हुई
- Uber China के ख़त्म होते ही वह UI Wesley से हटा दिया गया
- यह ऐसे data workflow के लिए custom UI था जिसे फिर कभी चलाया नहीं जाना था
- browser में फिर से Excel बनाने की मांग दोबारा नहीं आई
Code की उम्र से ज़्यादा समस्या-समाधान
- उस समय कोई बहुत बड़ा खोने का एहसास या निराशा नहीं थी
- पहले ख़याल के रूप में code को GitHub पर open source करने की इच्छा हुई, फिर लेखक अगले काम पर बढ़ गए
- बस इतना अफ़सोस था कि मेहनत से लिखा गया code बहुत कम समय इस्तेमाल होकर गायब हो गया
- engineers का लिखा code कभी न कभी legacy code बनता ही है
- किसी दिन कोई और उसी code को हटाने में खुशी महसूस कर सकता है
- अच्छी तरह बना code लंबे समय तक बना रहे, यही अपने आप में लक्ष्य नहीं है
- एक engineer के रूप में आगे बढ़ना इस बात से जुड़ा है कि technology का उपयोग करके business value बेहतर कैसे बनाई जाए
- business value सिर्फ technical output से नहीं, बल्कि collaboration, mentoring, team support जैसे कई तरीकों से बनती है
- Uber China के चले जाने के बाद इस project से आगे कोई business value बची ही नहीं थी
- इसे ज़बरदस्ती आगे बढ़ाने से न व्यक्ति को फ़ायदा होता, न कंपनी को
- DevOps का वाक्यांश “Cattle, not pets” code पर भी लागू होता है
- code काम करने का एक साधन है, और जब वह काम उपयोगी न रहे तो उसके retire होने के लिए तैयार रहना चाहिए
- अगर भावनात्मक लगाव के कारण code को पालतू की तरह माना जाए, तो यह business understanding के उलट जा सकता है
बंद किए गए project से उठने वाले सवाल
- किसी project का हट जाना अपने आप में उसे failure नहीं बना देता
- बंद किए गए काम कुछ अहम सवाल छोड़ जाते हैं
- क्या ऐसा कुछ बनाया गया जो project constraints को पूरा ही नहीं करता था
- क्या माँगी गई चीज़ बनाई गई, लेकिन मूल request ही ग़लत थी
- क्या core problem को ग़लत समझा गया था
- क्या requested solution ने वास्तव में end users की ज़रूरत हल की
- क्या ऐसे सवाल थे जो stakeholders से पूछे ही नहीं गए
- क्या expectations ग़लत या अस्पष्ट थीं
- क्या जितनी robustness दी गई, उसकी वास्तव में ज़रूरत थी
- क्या कोई अधिक simple या कम चतुर solution काफ़ी होता
- क्या success criteria ग़लत तय किए गए
- क्या “जो माँगा गया वही बनाना” के अलावा भी कोई success criterion था
- अगर project closure को सिर्फ failure की तरह देखा जाए, तो यह सीखने का मौक़ा खो जाता है कि non-technical स्तर पर चीज़ें कहाँ बिगड़ीं
- बारीकी से बनाया गया component भी बड़े system के भीतर सहज रूप से fit न हो, तो हटाया जा सकता है
1 टिप्पणियां
Hacker News टिप्पणियां
सबसे अच्छा उद्धरण यह था: “Didi में काम करने वाले लोग Uber China में intern के तौर पर apply करते हैं और फिर हमारा data निकाल ले जाते हैं। हम उन्हें formulas देखने नहीं दे सकते। वरना वे ठीक वही copy कर लेंगे जो हम कर रहे हैं!”
यह बात बिल्कुल सही है। अमेरिका के लोग चीन में रोज़ाना होने वाली आर्थिक और औद्योगिक जासूसी के स्तर को ठीक से नहीं समझते। 2000 के दशक के मध्य के आसपास, एक ऐसी tech company की अलग breach incident पर response करते समय जिसका नाम मैं नहीं बता सकता, मुझे बताया गया कि “हमने Xinjiang में एक tech center खोला है और हाल में access badges खोने की घटनाएं असामान्य रूप से बढ़ गई हैं।” मैंने पूछा, “क्या आपने सोचा है कि वे खोए नहीं, बल्कि पैसे लेकर बेचे गए हो सकते हैं?” इसके बाद चुप्पी छा गई
मुझे नहीं पता executives जानते हुए भी परवाह नहीं करते, या बस अक्षम हैं, लेकिन चीन ने industrial espionage को बड़े पैमाने पर productize कर दिया है। हाल में GE Aviation भी इसका शिकार हुआ: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
फिर वे चीन में company शुरू करते हैं, चीनी investors से पैसा लेते हैं, और चीनी market के लिए लगभग वही product बनाते हैं। उदाहरण के लिए Thoratec/Abbot Heartmate III और CH Biomedical, Auris/Verb/J&J Robotic & Digital Solutions और Renovo Surgical जैसे cases हैं
विडंबना यह है कि इनमें से कुछ companies चीन में सफल होने के बाद अमेरिका और यूरोप में बेचने और compete करने की कोशिश करती हैं। अब यह कोई secret या backroom deal नहीं है; हमारी industry में यह खुलेआम होता है और आम तौर पर “ऐसा ही होता है” के रूप में स्वीकार कर लिया जाता है
एक और बात यह है कि विदेशी company के लिए चीन में business करते हुए अपनी assets की रक्षा करना बहुत मुश्किल है। इसलिए समझदार companies अक्सर खुद सीधे करने की कोशिश ही नहीं करतीं, बल्कि चीनी market के लिए किसी चीनी company को license कर देती हैं। कम से कम इससे सब कुछ चोरी हो जाने से बचने की कुछ संभावना बनती है
पहले जिस agency में मैं काम करता था, वहां हमने iBeacon hardware के लिए एक सुंदर case बनाने के लिए एक industrial designer को रखा था। output शानदार था
हमने injection molding एक चीनी company को दी और samples भी काफी अच्छे थे, इसलिए हमने उनका इस्तेमाल करने का फैसला किया। लेकिन कुछ हफ्तों बाद Alibaba/AliExpress पर हमारा case बिकता हुआ देखा
इसका मतलब यह नहीं कि पश्चिम या दूसरे देश perfect हैं, लेकिन यहां बात वह नहीं है। चीन के manufacturing/business के साथ काम कर चुके मेरे जितने भी परिचित हैं, सबने “copy कर लिया”, “हमारी मेहनत किसी और को बेच दी”, “agreed grade से कम quality का x दिया” जैसी चीजें झेली हैं
counterargument हमेशा “लेकिन पश्चिम भी X करता है” या “यह racist है” पर आकर खत्म होता है
चीनी companies, खासकर Ali-X पर business करने वाली, इस structure को बहुत पसंद करती हैं। क्योंकि वे intellectual property मुफ्त में लेकर original equipment producer को price में बाहर कर सकती हैं। Tindie वगैरह पर makers द्वारा डाले गए designs भी अक्सर copy होकर Ali पर दिखाई देते हैं
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
इस लेख को पढ़ते समय मुझे उम्मीद थी कि जटिल custom code हटाए और delete किए जाने की कहानी होगी, लेकिन लेखक उम्मीद के उलट एक engineer के रूप में विकसित हुआ
“Cattle, not pets” वाली DevOps कहावत यहाँ बिल्कुल फिट बैठती है। Code और उस code से बने product पालतू जानवर नहीं, बल्कि मवेशी हैं। वे काम करते हैं, और जब वह काम उपयोगी नहीं रह जाता, तो retire होने के लिए तैयार होते हैं। भावुक कारणों से code को पालतू जानवर जैसा मानना business के हितों के सीधे खिलाफ काम करने जैसा है
बहुत-सा code लिखना मज़ेदार होता है, और बहुत-सी समस्याएँ हल करना मज़ेदार होता है। लेकिन business, खासकर startup, को बेहद focused रहना पड़ता है। मेरा career असल में conference room में बैठकर युवा और उत्साही engineers से मत बनाओ कहने के काम जैसा है। थोड़ा उदास करने वाला है, लेकिन ज़रूरी भी है
अच्छा engineer चतुर code से कोई भी समस्या हल कर सकता है। बेहतरीन engineer समझता है कि कौन-सी समस्या असल में समस्या है ही नहीं, और शायद रोज़ update होने वाला XLS download link ही काफी होता
मैं internally hosted service के लिए monitoring system बना रहा था, और मेरे boss हमारे environment के एक छोटे-से हिस्से को monitor करने वाली छोटी utility खरीदना चाहते थे। मुझे थोड़ा बुरा लगा कि जिसे मैं खुद बना सकता हूँ, उसके लिए वे पैसे देकर खरीदना चाहते हैं
boss ने पूछा, “इसे लिखने और test करने में कितना समय लगेगा?” मैंने जवाब दिया, “शायद एक हफ्ता, अगर कुछ मुश्किल निकला तो थोड़ा और।” तब उन्होंने पूछा, “वह tool 500 dollar का है। तुम्हारे 40 घंटों की hourly cost कितनी है?”
उसी समय मुझे बात समझ आ गई, और उसके बाद मैंने company में ऐसी चीज़ खुद कभी नहीं बनाई जिसे सस्ते में खरीदा जा सकता था
Substack page के नीचे वाली checklist भी इस स्तर की requirements समझने के लिए पर्याप्त नहीं है। वे सवाल सिर्फ situation का वर्णन करते हैं, और उन्हें पूछ लेने से यह simple solution नहीं मिल जाता। checklist-आधारित सोच एक बैसाखी है और समस्या को जरूरत से ज़्यादा जटिल बना देती है
यहाँ important signals सारे organizational और social थे; यह ऐसा मामला नहीं था जिसे process सुधारकर ठीक किया जा सके। जो व्यक्ति implementation details में शामिल नहीं है, वह implementation details से जुड़े सवालों के जवाब नहीं दे सकता
“बस Excel जैसा बना दो” एक अलग ही लक्ष्य रखने वाले व्यक्ति का low-quality जवाब है। असली user के ज़्यादा करीब व्यक्ति से बात करनी चाहिए थी और वहीं से counter-arguments बनाने चाहिए थे। जो कमी थी, वह थी कमजोर assumptions को पहचानना और जानबूझकर code न लिखने का साहस, जब तक सभी parties के सहमत होने लायक details fixed न हो जाएँ। “in-charge” को बस yes नहीं कहना चाहिए
2006 में भी किसी को उस रास्ते पर जाने से रोकने के लिए लंबी बातचीत की थी, और 2026 में भी कोई फिर वही करने की कोशिश करेगा
“इस exact problem को दूसरों ने कैसे solve किया होगा?” रुककर यह सोच पाने की क्षमता developer के रूप में grow करने का बहुत बड़ा हिस्सा है, इसलिए काश schools इस पर ज़्यादा ध्यान देते
सिर्फ इस description से कि इसे short deadline में समय पर successfully complete किया गया, यह निष्कर्ष नहीं निकाला जा सकता कि implementation choice खराब थी। बल्कि कहानी यह है कि यह इतना successful हुआ कि Excel की बहुत-सी features implement हो गईं, और बाद में उन्हें हटाकर ठीक किया गया। XLS download link में आप उन्हें कैसे हटा पाते?
core point है code से बहुत ज़्यादा लगाव मत रखो, और कुछ situations में इसका मतलब “खुद मत बनाओ, XLS download link use करो” हो सकता है, लेकिन बस इतना ही सब कुछ नहीं है
“कुछ हुआ तो नहीं, लेकिन मैंने उस code को संभालकर रखा कि कभी काम आएगा। मेरा idea था कि इस code को Uber के use case के हिसाब से polish करूँ”, और “मेरी पहली प्रतिक्रिया code को GitHub पर public करने की थी” वाले हिस्से बहुत चौंकाने वाले हैं
क्या वह code Box या Uber की property नहीं है? लेखक ने यह mention नहीं किया कि उसने MIT license के तहत public करने से पहले permission ली थी
अगर Uber को ऐसा code चाहिए जो उनसे आया भी नहीं, छह महीने से ज़्यादा पुराना हजारों lines का JavaScript है, और जिसे उन्होंने एक महीने से कम use किया, तो वे letter भेज सकते हैं
“वह इस बात पर बिल्कुल यकीन नहीं कर पा रहा था कि मैंने पूरा spreadsheet engine लिखा है जो browser में चलता है” — यह हिस्सा मेरे लिए भी मानना मुश्किल है, और अच्छे अर्थ में नहीं
Apache POI इस्तेमाल करें तो headless Excel चला सकते हैं। Java में sheet लाकर उसके साथ programmatically interact किया जा सकता है, और पिछली नौकरी में मैंने ठीक इसी वजह से इसे इस्तेमाल किया था। functions, cell references वगैरह सब ठीक से काम करते थे
बस किस्मत अच्छी थी कि ‘circ’ वाली समस्या मिल गई। आगे Excel की जो छिपी हुई छोटी-छोटी अजीब बातें सामने आएंगी, उनका क्या करेंगे? क्या सच में JS में Excel की पूरी नकल बनाकर maintain करेंगे? क्या यही frontend team का लक्ष्य है?
थोड़ा-सा search कर लेते तो लगता है यहां 90% से ज्यादा काम बच सकता था। ऊपर से backend team भी इसे संभाल सकती थी
Uber अपने खुद के datacenter चलाता था। असली Excel चलाने के लिए Windows machine या VM procure करना शायद किसी चमत्कार से कम नहीं होता। मैं नया frontend service करीब 30 मिनट में खड़ा कर सकता था, और कुछ code पहले से चल भी रहा था, इसलिए यह बिल्कुल scratch से शुरू करना नहीं था। यह भी ध्यान रखना होगा कि इस system को अलग-अलग data sets वाले कई लोगों को एक साथ इस्तेमाल करना था
अगर लगातार और features तथा Excel parity की मांग आती, तो हम review करते, लेकिन ऐसा नहीं हुआ
मैं उम्मीद नहीं करता कि बहुत से लोग वही चुनाव करेंगे जो मैंने किया। लेकिन वह चला, और हैरान करने वाली अच्छी तरह चला। अगर लेख से सिर्फ “यह बड़ा और जटिल project था” ही लिया गया, तो लेख मेरा intended message ठीक से convey नहीं कर पाया
मेरी जगह होता तो मैं UI specification पर और सवाल करता, और पीछे Excel चलाने वाले विकल्प पर जोर देता। लेकिन जहां numbers input करने की जगहें बहुत ज्यादा हों, वहां यह familiar UI जरूर है
100 lines F# में spreadsheet बनाने वाला यह लेख मुझे हमेशा मजेदार लगा है: https://tomasp.net/blog/2018/write-your-own-excel/ इसे यहां जरूरी feature set तक expand करना संभालने लायक है
आखिरकार model के UI के रूप में खुद बनाया हुआ “Excel” clone बनाया गया, वजह थी “city teams को Excel के अलावा कुछ इस्तेमाल करना नहीं आता”
मैं होता तो उल्टा करता। model से निकले data को Excel से connect करता ताकि city teams असली Excel ही इस्तेमाल करती रहें। लगता है ज्यादातर finance teams ऐसा ही करती हैं
जिन्हें curiosity हो उनके लिए Excel circular references का document: https://support.microsoft.com/en-us/office/remove-or-allow-a...
अगर आप iterative calculation से familiar नहीं हैं, तो circular reference को वैसे ही छोड़ना शायद नहीं चाहेंगे। iterative calculation चालू किया जा सकता है, लेकिन तय करना होगा कि formulas को कितनी बार recalculate किया जाए। अगर maximum iterations या maximum change बदले बिना iterative calculation चालू करते हैं, तो Excel 100 iterations के बाद, या जब circular reference में सभी values का बदलाव iterations के बीच 0.001 से कम हो जाए—इनमें से जो पहले आए—calculation रोक देता है। हालांकि maximum iterations और acceptable change को control किया जा सकता है
सोच रहा हूँ कि अगर Uber या Box ने उस code को अपना बताया होता, तो क्या लेखक इस स्थिति को अलग तरह से देखता। भले ही code अपनी असली संभावनाओं तक नहीं पहुँच पाया, कम से कम यह बात कि पूरी दुनिया उसे देख और स्वीकार कर सकती है, कुछ हद तक catharsis दे सकती है
मैंने intern के तौर पर काम करते हुए पूरी programming language बनाई थी। उसमें lazy evaluation था, garbage collection था, और application-specific अजीब चीज़ें भी थीं, जैसे बिना quotes वाले MAC address का valid syntax होना
bytecode या JIT जैसी कोई चीज़ नहीं थी; interpreter syntax tree पर चलता था और stack पर values push/pop करता था, लेकिन हमारे काम के लिए वह पर्याप्त तेज़ था। interpreter pure ANSI C में लिखा था और Valgrind भी उससे काफ़ी खुश था
हो सकता है वह पूरी तरह भुला दिया गया हो, या शायद उस company के tech infra का core बन गया हो। वह code मेरे लिखे air-gapped lab से कभी बाहर नहीं गया, इसलिए जानने का कोई तरीका नहीं है। 3 साल पहले college से अभी-अभी निकलने के समय, वह मेरे लिखे “वास्तव में उपयोगी software” में अब तक की सबसे शानदार चीज़ थी, और आज भी top में है। कभी-कभी सोचता हूँ कि उसका क्या हुआ होगा
लगता है लेखक यह गलतफ़हमी रखता है कि उसने middle manager, यहाँ तक कि senior manager से “क्या आपको यह चाहिए?” पूछा और manager ने “नहीं” कहा, तो वह बात company पर कानूनी रूप से binding हो गई
“खास तौर पर clever या elegant code को masterpiece की तरह देखना आसान है। वह सच में एक खूबसूरत सजावटी चीज़ भी हो सकता है। लेकिन हम engineers खूबसूरत सजावट बनाने के business में नहीं, results बनाने के business में हैं” — यह line दिल को छू गई
हालांकि जिसने भी मेरा code देखा है, वह जानता होगा कि मैं चाहता हूँ कि code और उसका function दोनों बहुत सुंदर हों। आम तौर पर मैं वही code लिखता हूँ जिसे मुझे maintain करना होता है, इसलिए एक साल बाद देखने पर भी वह समझ में आना चाहिए
अभी मैं एक ऐसे project के अंतिम चरण में हूँ जिसे मैं यहाँ announce भी नहीं करूँगा और न ही उसका बड़ा credit लेने का इरादा है, लेकिन वह सच में कमाल की चीज़ है। ऐसा इसलिए हो पाया क्योंकि कोई इसके लिए पैसे नहीं दे रहा, और कोई इससे पैसे नहीं कमा रहा
पैसा हर चीज़ बिगाड़ भी देता है, और साथ ही हर चीज़ संभव भी बनाता है
यह पुराने Uber BI team के नज़रिए से लिखा गया सचमुच बेहतरीन लेख है। मैं उस समय Vertica team में था, और incentives पर लगाई गई मेहनत की मात्रा दिमाग घुमा देने वाली थी। downtime, product features और engineering bandwidth में रोज़ाना millions of dollars उड़ जाना एक आम topic था
खासकर Uber China के दौर में, किसी director का spreadsheet को ही UI के रूप में मांगना भी बहुत स्वाभाविक रहा होगा। मैं भी व्यक्तिगत तौर पर हर महीने team को email से आने वाली spreadsheet से FX prices Vertica में load करता था। automatic collection से control flow उलटने की bandwidth नहीं थी, इसलिए वह process एक साल से ज़्यादा समय तक बना रहा
“आज तक मैंने Uber के internal application system जितना अच्छी तरह design किया हुआ कुछ नहीं देखा। शुरू करने से लेकर *.uberinternal.com subdomain पर full CI/CD के साथ Hello World चलाने तक 30 मिनट से कम लगे” — यह सुनकर थोड़ा मन खुश हो गया
उस समय Uber में मैं इन सब चीज़ों से जुड़ा था