अंत पर सीधे पहुँच गया डेवलपर
(danangell.com)- बचपन से Google को प्रोग्रामर करियर की परम मंज़िल मानने वाला एक डेवलपर लगभग 20 साल बाद L4 SWE के रूप में वहाँ शामिल हुआ, लेकिन यह उसकी उम्मीद के मुताबिक सीखने की जगह नहीं निकला
- शुरुआती startup में छोटी टीम, अच्छा work-life balance, और founding engineer के साथ करीबी सहयोग की वजह से उसकी growth की रफ़्तार बहुत तेज़ थी
- तेज़ी से बढ़ रहे AI/LLM startup में उसने rewrite project कुछ ही महीनों में ship किया, और नए user flow के आधार पर घंटे-घंटे का feedback अनुभव किया
- Google में शामिल होने के बाद धीमे approval process, remote meeting culture, team structure की उलझन, managers के बीच authority struggle, और headcount पर obsession ने सीखने और बनाने के मौके कम कर दिए
- 15 महीने बाद Google छोड़ते हुए उसने तय किया कि बड़े compensation या impact से ज़्यादा startup में step-by-step scale बनाना उसके लिए अधिक महत्वपूर्ण है
बचपन में बना Google का भ्रम
- 2003 में, 8 साल की उम्र में उसने एक दोस्त के साथ वेबसाइट बनाना शुरू किया
- दोस्त की दादी ने domain name और web hosting खरीदी
- उस समय Web 2.0 की चर्चा थी, और लाइब्रेरी की किताबों में DHTML मिलता था
- mobile app market तब नहीं था, और native application development में entry barrier काफ़ी ऊँचा था
- उसने दोस्त के साथ choose-your-own-adventure जैसी simple webpages बनाते हुए web बनाना सीखा
- सिर्फ़ अगले page पर जाने वाला link हो तो भी game बनाया जा सकता था
- design ऐसा होता था कि landscape और tropical coast की 24-bit JPEG background image पर लाल 12pt Times New Roman text रखा जाता था
- Philadelphia Inquirer में office building की slide और free candy dispenser की तस्वीरें देखने के बाद Google ने उस पर गहरा असर डाला
- Google तब पहली “web scale” company बनती जा रही थी
- Google Earth इतना प्रभावशाली था कि वह रेगिस्तान की घाटियाँ और पहाड़ ढूँढता फिरता था
- हाई स्कूल के समय उसने अपनी personal site को blog की तरह चलाया और HTML व CSS खुद लिखे
- graphics भी उसने Paint में खुद बनाए
- Google Earth satellite image में मिली खोजों पर लिखी गई posts भी थीं
- परिवार वाले कहते थे कि वह एक दिन Google में काम करेगा, और Google उसके लिए प्रोग्रामर करियर की परम मंज़िल बन गया
- उसे लगता था कि वहीं सबसे ज़्यादा compensation मिलता है, सबसे ज़्यादा काम होता है, और employees को सबसे ज़्यादा सम्मान मिलता है
startup में सीखा तेज़ feedback
- CS में bachelor degree पूरी करने के बाद उसे Google recruiter का cold email मिला और वह Seattle onsite interview तक पहुँचा, लेकिन select नहीं हुआ
- इसके बाद उसने Silicon Valley startup का रुख किया
- उसके पास पहले से कुछ projects, co-op, और part-time अनुभव था
- उसे कई competing offers मिले और उनमें से बेहतर offer चुनकर वह अमेरिका के दूसरे छोर पर जा बसा
- उसकी पहली startup job उम्मीद से ज़्यादा healthy work environment निकली
- बेवजह लंबी working hours नहीं थीं और work-life balance अच्छा था
- वह 20 दयालु और जानकार सहकर्मियों के साथ काम करता था
- सभी वहाँ कुछ साथ मिलकर बनाने की इच्छा से थे
- उसने एक founding engineer के साथ बैठकर 1 साल काम किया और उतना सीखा जितना न पहले कभी सीखा था, न बाद में
- वह engineer बहुत blunt इंसान माना जाता था
- उसकी यही bluntness डेवलपर के रूप में उसे पैना करने में काम आई
AI/LLM startup की रफ़्तार और अनिश्चितता
- pandemic के दौरान उसने तेज़ी से बढ़ते AI/LLM क्षेत्र के startup में job बदली
- उसके शामिल होने तक company पहले ही hypergrowth में थी
- founders ने 8 महीनों में रोज़ाना हज़ारों signups और millions of dollars ARR हासिल कर लिया था
- उसे जो काम मिला, वह सब कुछ शुरू से rewrite करना था
- rewrite project कुछ महीनों बाद launch हो गया
- नए users की बाढ़ का उपयोग करते हुए onboarding और product features पर बार-बार iteration हुआ
- ticket से PR, LGTM, release, और metrics check तक एक घंटे के अंदर पहुँचने वाला flow सीखने का बहुत शक्तिशाली तरीका था
- लगातार और तेज़ feedback expert बनने के अहम तत्वों में से एक था
- लेकिन इस तेज़ execution के पीछे direction की समस्या बनी रही
- तेज़ी से बदलते माहौल में मज़बूत direction की कमी थी
- VC-funded GPT-3 app बस ठहरकर नहीं बैठ सकता था
- वहाँ बिताए जा रहे समय की value को लेकर उसकी अनिश्चितता बढ़ती गई
- इसी दौरान Google से फिर cold email आया, और interview के बाद उसे L4 SWE offer मिला
- लगभग 20 साल बाद वह उस “जादुई जगह” में पहुँच गया जहाँ slide और free candy हुआ करती थी
Google में सामने आई धीमी organization
- कुछ अलग तरह का काम करने की सोचकर वह phone firmware team में शामिल हुआ
- कुछ ही हफ़्तों बाद tech lead ने company छोड़ दी
- manager अक्सर emails का जवाब नहीं देता था
- शुरुआती कुछ महीनों में उससे कहा गया कि कुछ न करना भी ठीक है
- जब असली काम मिला, तो वह जल्दी ही bureaucracy से टकराया
- production error tracking project में कई महीने लगने वाले थे
- सिर्फ़ strings को log करने की वजह से ज़्यादातर समय Privacy Council approval में जाना था
- team members पास ही रहते थे, लेकिन office लगभग नहीं आते थे, और virtual meetings में cameras बंद रहते थे
- सहकर्मी लगातार company छोड़ते जा रहे थे
- जिस team में वह आया था, वह भी उसकी उम्मीद वाली team नहीं निकली
- first-party phones वाले product को संभालने वाली team अलग थी और broader platform संभालने वाली team अलग
- क्योंकि Google 3rd party OEMs को paid support भी नहीं देता था, इसलिए OEMs शामिल नहीं होते थे
- hiring freeze की वजह से वह “असली” team में जा भी नहीं सकता था
- नए skip manager ने team बंद करने की बात कही और उसे पास की certificate authority management team में भेज दिया
- यह काम web-based होने वाला था
- Rust firmware development में entry की कोशिश असफल होने के बाद web पर लौटना उसे अच्छा लगा
headcount politics और resign करने का फ़ैसला
- नए project का web हिस्सा किसी दूसरे विभाग के पास maintain हो रहा था, और वह उसी विभाग में attached resource की तरह काम करने लगा
- उसे एक “dotted-line manager” assign किया गया
- उसने कहा कि वह 20% projects के बारे में सुनना नहीं चाहता, क्योंकि उसके हिसाब से ऐसे काम हमेशा 20% से ज़्यादा हो जाते हैं
- वह यह भी नहीं चाहता था कि उसे direct manager की तरफ़ के काम में खींचा जाए, और उसका रवैया ऐसा था मानो लोग उसकी मिल्कियत हों
- पहला project खत्म होने के बाद खाली बैठने के बजाय उसने नया काम उठा लिया, और यही समस्या बन गया
- dotted-line manager और उसकी team पहले ही कई quarters का काम backlog में लिख चुके थे
- उसने unassigned item चुनकर लगभग 200~300 lines के code वाला design doc भेजा, लेकिन इसे मनमानी समझा गया
- dotted-line manager ने skip manager से कहा कि उसे control में रखा जाए
- skip manager और direct manager ने उसका बचाव किया, लेकिन उसे लगा कि सीखना और बनाना मानो allowed ही नहीं है
- दूसरे managers के साथ अनुभव भी अच्छे नहीं रहे
- direct manager कभी-कभी future sex robots के ज़रिए male loneliness को monetize करने की कल्पना करता था
- skip manager ने dotted-line manager का project खींच लाने की कोशिश में team chat में उसका मज़ाक उड़ाने वाला message लिखा
- वह अक्सर कहता था, “उधर के लोग बहुत toxic हैं”
- उसे लगा कि project पहले जैसा ही है, इसलिए उसने direct manager से अपनी नाराज़गी साफ़ कह दी
- उसने कहा कि समस्या company में ही है, और किसी दूसरे project में जाने से समाधान होगा, इस पर उसे कोई आशा नहीं है
- direct manager ने जवाब दिया कि किसी को fire करने में paperwork बहुत होता है, इसलिए 12 महीने तक कुछ न करके भी निकल जाना संभव है
- Google leadership की सफलता का एक बड़ा metric यह माना जाता था कि उनके नीचे कितने लोग हैं
- एक-दो लोग काम न भी करें, तो भी अगर self-set OKRs पूरे हो जाएँ, तो सब अच्छा दिख सकता है
- उसने dotted-line manager के लोगों को खींचने की कोशिश को भी ऐसे समझा कि hiring freeze में headcount पाने का वही एक रास्ता था
- 15 महीने बाद उसने Google छोड़ दिया
- उसने निष्कर्ष निकाला कि उसे Google का compensation या बड़े स्तर का impact नहीं चाहिए
- उसका मानना था कि Series A startup से सीधे mature public company में कूदकर उसने बीच के चरणों का अनुभव खो दिया
- उसके भीतर यह भावना बची रही कि scale को वह कठिन काम के ज़रिए खुद हासिल करना चाहता है
- FAANG सीखने की जगह नहीं, बल्कि पैसे कमाने का तरीका था, और वह Silicon Valley सिर्फ़ कमाई के लिए नहीं आया था
- उसने यह भी साफ़ कहा कि जिन ICs के साथ उसने काम किया, वे सभी अच्छे थे, और उनके साथ बिताया समय उसके लिए मूल्यवान रहा
1 टिप्पणियां
Hacker News की राय
Google में leadership success के प्रमुख संकेतकों में से एक रिपोर्ट करने वाले कर्मचारियों की संख्या होना, कागज़ पर भले ठीक लगे, लेकिन यह अनचाहे नतीजे पैदा करने वाली चीज़ है
लगभग 10 साल पहले जिस कंपनी में मैं था, वहाँ corporate website के “About us” पेज को नया रूप दिया गया था; वह कोई असली product भी नहीं था और महीने में views भी बस कुछ सौ थे. फिर भी एक टीम ने custom CMS बनाया और दूसरी टीम ने CMS data को visitors के लिए “render” किया—इस तरह 10–20 लोग एक साल से ज़्यादा समय तक लगे रहे, और यह सब गैर-ज़रूरी था
विदाई drinks के दौरान जब मेरे manager ने कहा, “बाकी candidates के पास manage करने के लिए लोग बहुत कम हैं, इसलिए शायद मेरा promotion हो जाएगा,” तब बात समझ आई. इस project का मकसद लोगों को busy दिखाना, और लोगों को hire करके headcount बढ़ाना था ताकि promotion और salary hike मिल सके
लेकिन ऐसे माहौल में managers की स्वाभाविक empire-building पर यह दबाव लगाम नहीं लगाता कि organization को अपनी लागत निकालने लायक revenue लाना होगा. इसलिए organizations तब तक बढ़ती रहती हैं जब तक आसमान से बरस रहे अरबों dollars पूरे खर्च न हो जाएँ
यह एक cynical ex-Googler का loosely held विचार है
रिपोर्ट करने वाले कर्मचारियों की संख्या आम तौर पर आप जो provide कर रहे हैं उसकी cost के करीब होती है. उसे पैदा की जा रही “value” के बराबर मानना बेतुका है, और पहली impression यही जाती है कि आप या आपका department महंगे हैं
ऐसा इसलिए था क्योंकि higher management roles (MD, VP) तक जाने के लिए same-level लोगों को manage करना लगभग prerequisite था, और वाकई इससे काम बना. जिन director और managing director को promote किया गया था, उनमें से कोई भी अब उस role में नहीं है, और Google में भी सिर्फ एक व्यक्ति बचा है, लेकिन उन दोनों को जो चाहिए था वह मिल गया
अगर offer यह हो कि “12 महीने तक कुछ न करके टिके रह सकते हो,” तो इस शर्त पर मैं तुरंत मान लूँगा कि उस दौरान मुझे open-source project करने देंगे
भले वह मेरे नाम पर न होकर © Google का ownership हो, मुझे ज़्यादा फर्क नहीं पड़ेगा. पसंद का काम करते हुए ऐसी चीज़ बनाना जो सबके काम आए, और उसके लिए पैसे भी मिलें—इसे मना करने की वजह नहीं दिखती
और यह भी सोचता हूँ कि लोगों को आखिर high-salary no-work roles के offers मिलते कैसे हैं
एक बार मुझे Google recruiter से mail मिला था; शायद Google Docs / Workspace team थी और Germany relocate करना पड़ता. Docs भी मुझे खास interesting नहीं लगा, इसलिए उस समय मैंने response नहीं दिया
मैंने open source भी ठीक से नहीं किया है, इसलिए कल्पना करता हूँ कि अगर community हो तो यह काफी बेहतर हो सकता है
यह आपको ऐसी स्थिति में लाने का trap भी हो सकता है जहाँ तुरंत निकालना आसान हो. सीमाएँ भी बदल सकती हैं
अगर आपको लगता है कि अभी जो कर रहे हैं वह गलत है, तो अपने लिए जगह बदलना बेहतर है
Google के बारे में मैंने जो लगभग सब कुछ पढ़ा और सुना है, वह काफी डिस्टोपियन लगता है
मैं भी एक काफी बड़ी tech company में काम करता/करती हूँ, लेकिन खुशी है कि मेरा अनुभव लेखक द्वारा बताए गए अनुभव से बिल्कुल अलग है। काम अपेक्षाकृत तेजी से आगे बढ़ता है, लोग सचमुच गंभीरता से परवाह करते हैं, और managers में empathy है और वे वाकई सक्षम हैं
बेशक सब कुछ perfect नहीं है, लेकिन दूसरी कंपनियों के बारे में जो सुनने को मिलता है, उसकी तुलना में यह काफी ठीक है
बड़ी tech companies में मेरे दोस्त हैं, और मुझे नहीं लगता कि कोई एक जगह बुनियादी रूप से बाकी से बेहतर है। सभी की अपनी अजीब बातें हैं, अच्छी teams और भयानक teams हैं, और bureaucracy भी खूब है
मुख्य समस्या यह है कि इन कंपनियों ने यह दावा करते हुए अपनी प्रतिष्ठा बनाई कि उन्होंने business करने और कर्मचारियों के साथ व्यवहार करने के नए तरीके ईजाद किए हैं। वे Microsoft, IBM, Sun जैसी corporate cultures का antidote लगती थीं, लेकिन आखिर में लगभग उसी दिशा में converge हो गईं
इससे पहले मैंने Microsoft, IBM जैसी कई बड़ी tech companies में भी काम किया है, और Red Hat जब काफी छोटी थी, तब जैसी छोटी कंपनियों में भी काम किया है
जिन बड़ी tech companies में मैंने काम किया, उनमें Google अब तक सबसे बेहतर रही। साथ ही, Google जैसी बड़ी company के अंदर—खासकर जहाँ हर division बड़ा है और एक-दूसरे से बहुत अलग काम करता है—culture और अनुभव हैरान करने वाली हद तक अलग हो सकते हैं
100 लोगों वाली company और 100,000 लोगों वाली company को एक ही तरीके से manage नहीं किया जा सकता। बड़े distributed computer systems की तरह, छोटे scale पर अच्छी तरह काम करने वाले HR और management systems बड़े scale पर नहीं फैलते
इसलिए Google धीरे-धीरे checks and balances, processes और protocols वाली एक पारंपरिक company बनता जा रहा है। लेकिन self-motivation, independence को बढ़ावा देने और “दुनिया बचाने वाली company” वाली बची-खुची बाहरी छवि अब भी मौजूद है, इसलिए ये systems जोरदार टकराते हैं और कभी-कभी दुखद नतीजे पैदा करते हैं
मैंने ऐसे कई मामलों के बारे में सुना है जहाँ लोगों ने company को अपना मानकर सब कुछ झोंक दिया, और अंत में यह महसूस किया कि company बस एक company है, और promotion मेहनत से ज्यादा salary budget constraints, headcount, arbitrary quotas, market और social forces पर निर्भर करता है
पक्षपात कम करने के लिए पुराने system के कुछ हिस्सों में काम का मूल्यांकन ऐसी team से कराया जाता था जो project को लगभग नहीं जानती थी, और इससे समस्या बढ़ी। इसके side effect के तौर पर self-promotion और communication skills को बढ़ावा मिला, जो रोजमर्रा की software engineering में बहुत जरूरी नहीं होते, और अच्छी engineering अच्छी self-promotion के आगे दब सकती है
लगता है कि सबसे खराब अनुभव वाले लोग ही लिखते हैं, और वही posts popular हो जाती हैं। जब मैं बताता/बताती हूँ कि मुझे Google में अपना अनुभव सचमुच क्यों पसंद है, तो आम तौर पर लोग कहते हैं कि मैं corporate propaganda में फँस गया/गई हूँ या PR कर रहा/रही हूँ
average experience मेरे अनुभव के करीब है या इस blog post के करीब, मुझे नहीं पता, लेकिन उम्मीद है कि वह मेरे वाले के ज्यादा करीब हो
सफल business बनाने वाले लोग अपनी सफलता से दूसरे लोगों को आकर्षित करते हैं। लेकिन वे “दूसरे लोग” founders जैसी वजहों से company में नहीं आते, बल्कि इसलिए आते हैं क्योंकि वहाँ पहले से प्रतिष्ठा और पैसा होता है
ये लोग company culture को बदल देते हैं, ताकि success बनाने वाली चीजों की बजाय अपनी reputation और compensation को प्राथमिकता मिले। यह distortion company को अजीब बना देता है और उसकी छवि धुंधली पड़ जाती है। founder-type लोग अजीब हो चुके माहौल की वजह से अब join नहीं करते, और अंत में वही “दूसरे लोग” बचते हैं
शेयरहोल्डर के नज़रिये से, यह सुनकर हैरानी होती है कि Google इस तरह से चल रहा है, फिर वे और ज़्यादा नाराज़ क्यों नहीं होते। कंपनी कितनी bureaucratic और political हो गई है, यह लगभग common knowledge है, और ऐसी कहानियाँ हर जगह मिलती हैं
अगर कोई बड़ा pension fund या asset management firm हो, तो वह board से ऐसे सवाल पूछेगा: “अगर कई teams में कुछ भी आगे नहीं बढ़ रहा है, तो Google headcount 50% घटा दे तो क्या होगा?” और “बिना किसी स्पष्ट penalty function के, संगठन के अंदर managers के लिए headcount बढ़ाना incentive क्यों बन जाता है?”
horror story लिखने के लिए motivation चाहिए। अगर कोई यह उम्मीद करके join करता है कि यह अच्छी workplace होगी और सच में अच्छी workplace निकलती है, तो उसके पास खास तौर पर लिखने की motivation कम होती है। भले ही वह लिखे, किसी के पास उस गैर-horror story को Hacker News पर डालने या readers के पास उसे upvote करने की motivation भी कम होती है
इसलिए web और HN पर दिखने वाली कहानियों का distribution horror stories और extreme cases की तरफ skewed होता है
hacker culture और non-standard corporate leadership shareholder class को हमेशा undesirable लगती है और उसे punish किया जाता है। Oracle/IBM-style business leadership परिचित है और rewarded होती है
यह स्थिति अमेरिकी companies की default है, और Google लंबे समय तक ऐसा नहीं था, इसलिए वह खास था। आखिरकार shareholders उस operating style से control हासिल करने में सफल रहे जिसे वे समझते हैं
modern अमेरिकी companies अपने economic future को खुद कमजोर कर रही हैं और China के हमले के लिए vulnerable हो रही हैं, इसकी वजहें हैं
और employees 500~1000 startups बनाएंगे, जिनमें से कुछ इस knowledge के आधार पर असली competitors बन सकते हैं कि करोड़ों लोगों वाले markets को ठीक से serve क्यों नहीं किया जा रहा
गलत समय पर health insurance और income खोने वाले लोगों और खुद Google को छोड़ दें, तो यह सबके लिए अच्छा हो सकता है
वे लगभग कुछ भी करें, पैसा कमा सकती हैं। ज्यादातर shareholders को अंदर क्या हो रहा है, इससे खास फर्क नहीं पड़ता। पैसा आना-जाना चाहिए, बस
बहुत से लोग गलत तरह से इस belief को पकड़े रहते हैं कि पैसा process को validate करता है। FB में भी terrible processes थे, लेकिन लोग लगातार cheer करते रहे। जब stock price crash हुआ, तो Meta rebrand क्यों हुआ यह पूछने के बजाय उन्होंने सबसे हालिया घटना को blame किया
यहाँ भी वैसा ही है। revenue एक lagging indicator है। जब तक stock price बढ़ रहा है, बहुत से shareholders leadership पर आँख मूँदकर भरोसा करते हैं और उन्हें पैसे का विशाल ढेर देने से भी खुश रहते हैं
इस article के कुछ महीनों बाद Google ने 12,000 employees को lay off किया, और काफी contracts भी renew नहीं किए। कुछ और similar moves भी हुए
उससे पहले भी काफी strong hiring freeze था, जिससे बहुत से लोग अधर में अटक गए थे
https://www.theguardian.com/technology/2022/nov/15/major-inv...
Google से कोई खास बैर नहीं है, लेकिन हैकर संस्कृति की सामूहिक आकांक्षा का धीरे-धीरे नीचे आना अच्छा नहीं लगता
पहले हर कोई startup बनाकर किसी बड़ी tech company में acqui-hire होने का सपना देखता था। अब लगता है लोग मानते हैं कि tech role का अंतिम लक्ष्य FAANG में घुसकर जीवन भर वहीं रहना है
बहुत ज़्यादा पालतू बना दिया गया है, बहुत ज़्यादा conformist हो गया है। अब लगता है hackerdom ज़्यादातर अश्लील स्तर के पैसे और status के बारे में ही रह गया है
बचपन में भविष्य के सपने देखते हुए, मैंने कभी किसी tech giant में acqui-hire होने को “success” नहीं माना। अगर वही करना है, तो सीधे सामान्य तरीके से apply क्यों न करें? सपना तो eBay या YouTube जैसी चीज़ बनाकर इतनी बड़ी सफलता पाना था कि giant companies से मुकाबला हो सके। ज़रूरत बस keyboard और किस्मत की थी
पता नहीं सिर्फ मैं ऐसा हूँ या यह पीढ़ी का फर्क है। मैं अभी 30 से कम हूँ, इसलिए अगर यह पीढ़ी वाली बात है तो संभवतः यह काफी हालिया phenomenon है। 2000 के दशक के मध्य में जन्मे programmers शायद ऐसी दुनिया में बड़े हुए जहाँ कुछ tech giants पहले से dominant थे, और वे वह दौर चूक गए जब वे बढ़ रहे थे और प्रभुत्व के लिए लड़ रहे थे
बेशक आज की स्थिति देखते हुए, ऐसे सपने शायद सबसे rational भी हो सकते हैं। अगर आप innovative और sustainable business बना भी लें, तो tech giants जब जानते हैं कि उन्हें सज़ा नहीं मिलेगी, तब anti-competitive tactics से हमला करें तो टिकना मुश्किल है
फिर भी इससे यह कम छोटा नहीं हो जाता
लेकिन No True Scotsman निकालकर realistic ढंग से कहें तो, “hacker” को Sun के Bill Joy से ज़्यादा UCB के Bill Joy जैसा होना चाहिए
Bill Joy जब UCB में BSD hack कर रहे थे, तो नहीं लगता कि वे business या financial success के बारे में सोच रहे होंगे। hacking कोई साधन नहीं, अपने आप में उद्देश्य था
“hackerdom” का जो भी मतलब हो, यह रोज़ी-रोटी के लिए काम करने से अलग चीज़ है
90s के आखिर और 2000s की शुरुआत के असली hackers ऐसी चीज़ें सामान्य समझकर करते थे जिन्हें आज के कई “hackers” computer crime के ख्याल मात्र से पीला पड़कर डर जाएँगे, या कम से कम downvote button टटोलने लगेंगे
nerds के लिए वह रोमांचक दौर था। क्या आपने कभी चोरी किए गए credit card numbers और पूरी billing info वाले CSV को scroll किया है? यह cocaine की एक line सूँघने जैसा एहसास होता है। मैंने teenager रहते 22 हज़ार dollar चुराए थे, और कई साल तक पीछे मुड़-मुड़कर डरता रहा कि कहीं गोली न लग जाए या हथकड़ी न लग जाए
किसी समय “hacker” शब्द को code लिखने वाले हर व्यक्ति के अर्थ में अपना लिया गया। Silicon Valley के tech founders असल में “hackers” नहीं, बल्कि software engineering skills थोड़ी-बहुत रखने वाले businesspeople हैं। बस उन्हें ऐसा कहना खुद को hacker कहने जितना edgy या cool नहीं लगता
acqui-hire होने का मतलब, परिभाषा के अनुसार, यह है कि अब आप पूरी तरह तय नहीं कर सकते कि business आगे क्या करेगा। अगर उद्देश्य सच में कुछ बनाना, और सबसे बेहतरीन कुछ बनाना होता, तो वे acqui-hire से इनकार करते
acqui-hire की ओर बढ़ना आखिर में पैसे लेने के लिए ही है
Google एक बड़ी company है, इसलिए संभवतः लगभग हर तरह की tech job कहीं न कहीं वहाँ मौजूद होगी। toxic managers भी हैं, dead-end projects भी, और rocketship जैसी teams और शानदार culture वाली जगहें भी हैं
मैं खुशनसीब हूँ कि अच्छे हिस्से में हूँ, लेकिन इस व्यक्ति का अनुभव भी समझता हूँ
हालांकि यहाँ की कुछ प्रतिक्रियाएँ देखकर लगता है कि लेखक ने उस experience से सीख सकने वाला एक दिलचस्प growth opportunity शायद खो दिया। मेरा मतलब यह नहीं कि अंतिम नतीजा अलग होता, और हो सकता है manager ने सीखने के लिए ठीक से setup भी न किया हो
मैं भी मिलते-जुलते background से आया और ऐसी ही कुछ challenges झेली, लेकिन मैंने अलग lessons लिए और startup engineer से आगे grow हुआ महसूस करता हूँ
“पैसा मायने नहीं रखता” या “पैसा खुशी नहीं खरीदता” जैसी बातें अमीर लोग कहते हैं, और “Google मायने नहीं रखता” पूर्व Googler कहते हैं
बात समझ में आती है, लेकिन लगता है वह कुछ समय Google में अच्छा पैसा कमाने और जीवन भर पूर्व Googler कहलाने के privilege को भूल रहे हैं
पैसा मायने रखता है। छुट्टी plan करते समय, गंभीर रूप से बीमार पड़ने पर, नया घर, car या laptop खरीदना चाहें तब। पैसा मायने नहीं रखता कहना naive है। कई चीज़ें important हैं, और पैसा भी उनमें से एक है
हाँ, यह privileged position है, लेकिन जो व्यक्ति रोज़ी-रोटी के लिए जूझ रहा हो उससे अलग priorities रखना संभव है। अगर basic needs और emergencies संभालने के लिए पर्याप्त पैसा है, तो happiness ज़्यादा important है
“पैसा खुशी नहीं खरीदता, लेकिन पैसे की कमी दुख खरीदती है”
जो “अमीर” यह भूल जाता है, वह अपनी success में बहुत डूबा हुआ है और अपनी किस्मत को acknowledge नहीं करता
बड़ी companies के incentives अजीब हो सकते हैं। एक बार एक supplier ने ऐसा काम करने के लिए, जो मूल रूप से हमारे लिए 40-page PDF generate करना था, लगभग 100k dollars का estimate दिया था। मैंने pressure डालना जारी रखा और उसे ऐसी proposal तक घटवाया जो अभी भी महंगी थी, लेकिन कम absurd थी
बाद में पीछे मुड़कर देखा तो अगर मैंने original request approve कर दी होती, तब भी कुछ बुरा नहीं होता। मेरे अलावा invoice देखने वाला कोई नहीं था, और वह amount उस हफ्ते के revenue के rounding error के भी rounding error जितना था
असल में नुकसान सिर्फ हमारी team को हुआ था। proposal पर आगे-पीछे होने से काम delay हो गया
इस मामले में incentives ऐसे set थे कि manager के लिए company के पैसे को लेकर कम बचत-भरा और कम responsible व्यवहार करना ही rational choice बन गया था
व्यक्तिगत योगदान देने वाले software engineer के लिए कंपनी के आकार का sweet spot मेरे हिसाब से 50–500 लोगों के बीच है
यह इतना छोटा आकार है कि आप आसपास के लोगों से अच्छे रिश्ते बना सकें, autonomy रख सकें और सीख सकें, लेकिन इतना भी नहीं कि bureaucratic प्रक्रियाओं से दब जाएँ
50–500 लोगों की कंपनी आदर्श रूप से इतनी बड़ी होती है कि कंपनी के runway की चिंता न करनी पड़े, और work-life balance, ठीक-ठाक compensation और benefits भी मिल सकें। कंपनी बढ़े तो चाहें तो ऊपर जाने के मौके भी आम तौर पर होते हैं
अब लगता है कि tech industry में रहते हुए FAANG में काम न करना भी ठीक है—इस विचार से आखिरकार मेरा समझौता हो गया है
इतने लंबे समय तक किसी ने DHTML का ज़िक्र नहीं किया कि मुझे लगा कहीं मैंने hallucinate तो नहीं किया था। 9 साल की उम्र में वेबसाइट बनाना खेल-खेल में सीखते हुए इसे सीखा था, तो यादें फिर ताज़ा हो गईं