GitLab में काम करने का अनुभव
(yorickpeterse.com)- अक्टूबर 2015 में GitLab के 28वें कर्मचारी के रूप में शामिल होकर दिसंबर 2021 तक काम किए गए 6 साल पूरी तरह remote work, तेज़ी से बढ़ते startup की अव्यवस्था, performance·deployment·organizational culture की समस्याओं और burnout का मिला-जुला अनुभव थे
- शुरुआती GitLab में performance गिरना और बार-बार outage होना यूज़र्स की सबसे बड़ी शिकायत थी, लेकिन performance monitoring infrastructure की कमी थी और ऐसे tools भी साथ बनाने पड़ते थे जिन्हें self-hosting ग्राहक भी इस्तेमाल कर सकें
- 2017~2018 में Database टीम में database load balancer बनाया गया, और इसी दौरान production DB deletion और backup failure एक साथ होने से लगभग 6 घंटे का data loss और लगभग 24 घंटे की recovery हुई
- 2019~2021 में Delivery टीम ने Community Edition और Enterprise Edition के अलग repository ढांचे को एकीकृत किया, जिससे commit के बाद GitLab.com deployment तक लगने वाला समय, जो सबसे खराब स्थिति में 3 हफ्ते था, कुछ घंटों~एक दिन तक घट गया
- GitLab से सीखे गए सबक ये थे कि scalability को culture का हिस्सा होना चाहिए, data के बिना “minimal viable” का फैसला जोखिम भरा है, SaaS और self-hosting को साथ चलाने से requirements में टकराव पैदा होता है, और तेज़ deployment व role-based compensation महत्वपूर्ण हैं
GitLab में शामिल होने से पहले और शुरुआती भूमिका
- GitLab में शामिल होने से पहले मैं Amsterdam के एक छोटे startup में काम करता था, और कंपनी की हालत इतनी खराब थी कि फंड की कमी के कारण उसे अपने ऑफिस का एक हिस्सा किराये पर देना पड़ रहा था
- निजी समय में मैं Rubinius पर काम करता था, और उसे इतना स्थिर बनाना चाहता था कि production environment में इस्तेमाल हो सके; इसी वजह से मैंने ऐसी नौकरी ढूंढनी शुरू की जहां इस तरह का काम कर सकूं
- Ruby meetup और Rails Girls workshop में Sytse से मुलाकात के बाद GitLab में रुचि पैदा हुई, और 2015 की गर्मियों में ईमेल भेजने के बाद अक्टूबर 2015 में employee #28 के रूप में शामिल हुआ
- मेरी जिम्मेदारी GitLab की performance सुधारना थी, और काम के समय का 20% Rubinius पर खर्च कर सकता था
- 6 साल में कई टीमों से गुज़रते हुए काफी autonomy मिली, 10 अलग-अलग managers को report किया, और GitLab को 30 लोगों से बढ़कर लगभग 2000 लोगों तक जाते देखा
2015~2017: remote work और performance tools बनाना
- पिछली कंपनी में आखिरी कामकाजी दिन के ठीक अगले दिन GitLab में काम शुरू किया, और हफ्ते में 5 दिन ऑफिस जाने से हफ्ते में 5 दिन remote work पर आ गया
- शुरुआती GitLab पूरी तरह remote company थी, लेकिन उसका माहौल काफी social था, और Amsterdam व Austin जैसी जगहों पर company gatherings और events अक्सर होते थे
- इस दौरान GitLab ने अपनी पहली growth phase देखी, लगभग 100 नए कर्मचारी जुड़े, और कंपनी का आकार 30 से बढ़कर 130 के आसपास पहुंचा, फिर 80 तक घटा और उसके बाद फिर बढ़ा
- साथ ही तेज़ी से बढ़ते startup की समस्याएँ भी झेलीं: गंभीर performance issues, लगभग हर हफ्ते outage, और अपरिपक्व management
- “GitLab is slow” यूज़र्स की सबसे बड़ी शिकायत थी
- Hacker News पर भी GitLab की धीमी performance की शिकायतें अक्सर दिखती थीं
- performance सुधारना tools की कमी के कारण और मुश्किल था
- उस समय performance monitoring के नाम पर सिर्फ New Relic trial account था, और कुल 15~20 servers में से सिर्फ 1~2 को ही monitor किया जा सकता था
- आने वाला data पूरी स्थिति का सही प्रतिनिधित्व नहीं करता था
- GitLab चाहता था कि उसके tools self-hosting ग्राहकों को भी उपलब्ध हों, और संभव हो तो open source भी हों
- performance सुधारने के लिए पहले tools बनाने पड़े, और यही आगे चलकर आधिकारिक feature GitLab Performance Monitoring बना
- development environment के लिए भारी profiler Sherlock भी इसी समय बनाया गया
- GitLab ने समझ लिया कि performance problems एक व्यक्ति अकेले हल नहीं कर सकता, इसलिए Performance टीम बनाई गई, dedicated manager दिया गया और छोटी hiring budget भी तय की गई
- Rubinius को GitLab पर चलाने की कोशिश की गई, लेकिन सफलता नहीं मिली; maintenance direction और Ruby community के भीतर विवादों की वजह से आखिरकार यह काम छोड़ दिया गया
2017~2018: Database टीम, load balancer, production DB incident
- पहले डेढ़ साल की अव्यवस्था के बाद performance में काफी सुधार हुआ, और GitLab ने भी performance को अधिक गंभीरता से लेना शुरू किया
- Performance टीम का दायरा सामान्य performance improvements से बदलकर database performance पर केंद्रित हो गया और यह Database टीम बन गई
- hiring budget भी बढ़ा, और नए database setup जैसी चीज़ों में मदद के लिए infrastructure engineer भी जोड़ा गया
- इस समय बनाया गया मुख्य feature था GitLab database load balancer
- इससे जुड़ी प्रस्तुति Scaling the GitLab database में सार्वजनिक की गई
- developers सामान्य तरीके से DB queries लिखते थे, और load balancer उन्हें primary या replica की ओर route करता था
- write के बाद sticking लागू किया जाता था, ताकि बदलाव सभी replicas में reflect होने तक primary का इस्तेमाल हो
- इसका performance पर बड़ा सकारात्मक असर पड़ा, और इसे transparent तरीके से लागू किया गया—यही इसका सबसे गर्व वाला हिस्सा रहा
- 31 जनवरी 2017 को GitLab.com के production database को गलती से delete कर दिया गया
- घटना का विवरण GitLab.com database incident में प्रकाशित हुआ
- backup system लंबे समय से सही तरह काम नहीं कर रहा था, और backup failure की सूचना देने वाला system भी काम नहीं कर रहा था
- recovery इसलिए संभव हो सकी क्योंकि लगभग 6 घंटे पहले का production data staging environment में कॉपी किया गया था
- recovery में लगभग 24 घंटे लगे और लगभग 6 घंटे का data loss हुआ
- इसी समय GitLab database sharding करना चाहता रहा, लेकिन उस समय उपलब्ध data और engineers के आकलन के अनुसार यह समस्या का सही समाधान नहीं था
- GitLab में read requests, write requests की तुलना में लगभग 10:1 थीं
- stored data का आकार भी sharding की complexity को सही ठहराने जितना बड़ा नहीं था
- एक consultant ने भी कहा था कि इससे कहीं बड़े load और storage scale वाले ग्राहकों के लिए भी sharding ज़रूरत से ज़्यादा है
2019~2021: Delivery टीम और deployment time में सुधार
- 2018~2019 के आसपास performance और reliability से जुड़े काम से थककर नई बनी Delivery टीम में चला गया
- Delivery टीम का लक्ष्य GitLab की release process और tools को सुधारना था, और उस समय की स्थिति काफी अव्यवस्थित थी
- main branch में commit आने के बाद GitLab.com पर deploy होने तक औसतन कई दिन लगते थे, और सबसे खराब स्थिति में 3 हफ्ते तक
- सबसे बड़ा bottleneck यह था कि GitLab Community Edition और GitLab Enterprise Edition अलग-अलग Git repositories में मौजूद थे
- manual merge और conflict resolution नियमित रूप से करने पड़ते थे
- इसे हल करने के लिए दोनों projects को एक करने का कई महीनों का काम चला
- इससे जुड़ा काम Merging CE and EE codebases में प्रकाशित हुआ
- Delivery टीम ने release process में बड़ा सुधार किया और बदलावों को कुछ घंटों के भीतर deploy करने की स्थिति तक पहुंचाया
- सबसे खराब स्थिति 3 हफ्ते से घटकर लगभग 1 दिन रह जाना बड़ा सुधार था
- फिर भी यह गति आदर्श रूप से पर्याप्त तेज़ नहीं थी
संगठनात्मक संस्कृति में बदलाव और कंपनी छोड़ने तक की प्रक्रिया
- 2018 employee-focused GitLab summit का आखिरी साल था, और 2019 के बाद यह format ग्राहकों के लिए पारंपरिक conference जैसा हो गया
- 2000+ लोगों के gatherings बहुत महंगे होते हैं, इसलिए वित्तीय दृष्टि से यह समझ में आने वाला बदलाव था, लेकिन social experience के लिहाज़ से यह पहले जितना मज़ेदार नहीं रहा
- laptop management का मुद्दा भी बार-बार टकराव का कारण बना
- GitLab ने company Mac या personal hardware के जरिए GitLab resources तक पहुंचने वाले कर्मचारियों के लिए remote management software की installation अनिवार्य करने या उस पर विचार करने की कोशिश की
- प्रस्तावित tools इतने intrusive थे कि उनका इस्तेमाल user activity logging जैसी चीज़ों के लिए हो सकता था, और abuse रोकने की गारंटी भी पर्याप्त नहीं लगी
- कर्मचारियों के बहुत से feedback को तब तक नज़रअंदाज़ किया जाता था जब तक core employees दबाव न बनाएं
- अंततः GitLab ने SentinelOne आधारित laptop management solution चुना
- cultural change और personal change एक साथ आए, जिससे motivation और productivity घटी और stress बढ़ा
- अच्छी reviews पाने वाले manager के दूसरी भूमिका में जाने और नए manager के टीम संभालने के बाद टकराव हुआ, और performance enablement plan लागू किया गया
- PEP, PIP से पहले का चरण था, जिसका उद्देश्य संबंध और काम को फिर से सामान्य स्थिति में लाना था
- शुरुआत में इसे दोनों पक्षों के सुधार की प्रक्रिया बताया गया था, लेकिन व्यवहार में यह सिर्फ मुझसे अपेक्षित बदलावों पर केंद्रित लगा
- मूल रूप से यह एक महीने के लिए था, लेकिन एक महीना और बढ़ा, और दो महीने बाद नतीजा संतोषजनक माना गया
- इसके बाद मुझे लगा कि GitLab और मैं अलग दिशाओं में जा रहे हैं, और मैंने इस्तीफे के बारे में सोचना शुरू किया
- GitLab के IPO और stock option exercise timing की वजह से दिसंबर 2021 में इस्तीफा देना संभव हुआ
- उस समय Netherlands में stock option exercise price और valuation के अंतर पर, liquidity हुई या नहीं, इसकी परवाह किए बिना 52% income tax देना पड़ता था
- tax burden इतना बड़ा था कि GitLab के IPO से पहले options exercise करना मुश्किल था
- बाद में कानून बदला और exercise के समय या shares के liquid होने के समय—इनमें से किसी एक पर tax payment timing चुनना संभव हुआ
- दिसंबर 2021 में GitLab छोड़कर Inko पर full-time ध्यान देना शुरू किया
GitLab के अनुभव से सीखे गए सबक
-
scalability को culture बनना चाहिए
- GitLab ने scalability को पर्याप्त प्राथमिकता नहीं दी, और लेखक के अनुसार नौकरी छोड़ते समय भी यह समस्या बनी हुई थी
- GitLab की मुख्य revenue, GitLab.com से नहीं बल्कि GitLab Enterprise Edition को self-host करने वाले ग्राहकों से आती थी
- GitLab.com जितना कमाता था, उससे कहीं अधिक cost पैदा करता था, इसलिए फोकस self-hosting market पर चला गया
- GitLab.com की कई performance problems सीधे तौर पर बहुत से self-hosting ग्राहकों पर लागू नहीं होती थीं
- बहुत से developers performance सुधारना चाहते थे, लेकिन उन्हें उसके लिए समय और resources नहीं मिलते थे
-
टीमों को data और developers के आधार पर चलना चाहिए
- GitLab में product manager-driven संस्कृति बहुत मजबूत थी, और कौन-से features बनेंगे यह अक्सर product managers और directors तय करते थे
- कुछ निर्णय उचित थे, लेकिन कुछ ऐसे लगते थे मानो Hacker News पर अच्छा idea पढ़कर उसे बना देना है
- लेखक का मानना है कि अगर सरल hierarchy पहले लाई जाती, team leads को अधिक अधिकार मिलता और उन्हें users से अधिक बातचीत करने दी जाती, तो परिणाम बेहतर हो सकते थे
- लेखक के अनुसार product manager की भूमिका तकनीकी रूप से product बनाने में योगदान देने और टीम व users के बीच पुल बनने की होनी चाहिए
-
data के बिना “minimal viable” तय करना मुश्किल है
- GitLab के मुख्य principles में से एक था हमेशा minimal viable change से शुरुआत करना
- समस्या यह थी कि हर व्यक्ति “minimal” को अलग तरह से समझता था
- कुछ teams performance या अच्छी usability को viable की requirement मानती थीं, जबकि कुछ teams इन्हें महत्वपूर्ण नहीं मानती थीं
- इसके परिणामस्वरूप ऐसे features बने जो users के लिए उपयोगी नहीं थे
- माँगा ही नहीं गया और अंततः बंद कर दिया गया serverless platform
- Kubernetes cluster management support, जो 3 हफ्ते तक काम नहीं कर रही थी और किसी को पता भी नहीं चला
- existing solution की बजाय CI के ऊपर बनाया गया chatops solution
- requirements management feature, जिसमें create और read तो संभव थे लेकिन edit या delete नहीं
- GitLab हर quarter में user survey करता था और कुछ teams के पास user engagement data की पहुँच भी थी, लेकिन याददाश्त और पूर्व सहकर्मियों से हुई बातचीत के अनुसार यह data टीम workflows का केंद्र नहीं था बल्कि बीच-बीच में इस्तेमाल होता था
-
SaaS और self-hosting को साथ चलाना कठिन है
- GitLab self-hosted installation और SaaS दोनों देता था
- दोनों models की revenue structure, requirements और updates लागू करने के तरीके अलग थे
- SaaS में तेज़ deployment और centralized infrastructure पर बड़े पैमाने के data व workload handling की ज़रूरत होती है
- अधिकांश self-hosted instances SaaS की तुलना में बहुत छोटे होते हैं, इसलिए SaaS की समस्याएँ और उनके समाधान सीधे लागू नहीं होते
- नतीजतन platform के कई हिस्सों में SaaS और self-hosting के लिए दो code paths पर विचार करना पड़ता था
- अगर SaaS या self-hosting में से किसी एक पर फोकस किया जाए, तो उसी operating model के अनुसार अनुभव को बेहतर बनाने पर पूरा ध्यान दिया जा सकता है
-
ज़्यादा लोग होना बेहतर परिणाम की गारंटी नहीं है
- GitLab ने वर्षों में बहुत से लोगों को hire किया और अब 2000 से अधिक लोगों को रोजगार देता है
- developers की सटीक संख्या ज्ञात नहीं, लेकिन team pages देखने पर कम से कम कई सौ का अनुमान लगता है
- किसी project में लोगों की संख्या बढ़ाने से productivity और output अपने आप बेहतर नहीं हो जाते; यह बात “The Mythical Man-Month” से भी जुड़ती है
- लेखक के पास data नहीं है, लेकिन उसका मानना है कि अधिकांश कंपनियों के लिए 20 से कम developers पर्याप्त होते हैं, कुछ के लिए 20~50, और बहुत कम के लिए 50~100 की आवश्यकता होती है
- अगर developers की संख्या 100 से ऊपर जाती है, तो सोचना चाहिए कि product scope कहीं बहुत बड़ा तो नहीं हो रहा
- यह आकलन software developers के लिए है; custom hardware production, sales, support जैसे क्षेत्रों में synchronization cost अलग होती है, इसलिए वे अपवाद हो सकते हैं
-
Ruby on Rails के बारे में राय मिश्रित है
- GitLab Ruby और Ruby on Rails में बना था, और इस संयोजन ने GitLab की सफलता में बड़ा योगदान दिया
- लेकिन जैसे-जैसे project बड़ा होता है और contributors के experience level में विविधता बढ़ती है, Rails में खराब performance वाला code आसानी से बन जाता है
- इसका प्रतिनिधि उदाहरण N+1 query problem है
- Rails के ActiveRecord में इसे हल करने की सुविधाएँ हैं, लेकिन वे opt-in हैं
- अगर developer यह भूल जाए, तो row-level queries चलती रहती हैं और performance problem पैदा होती है
- GitLab के शुरुआती वर्षों में हल की गई बहुत-सी performance problems N+1 queries ही थीं
- Ruby खुद भी शानदार language थी, लेकिन meta programming का भारी इस्तेमाल बड़े projects में मुश्किल पैदा करता है
- लेखक के अनुसार Go, Rust, Node.js Ruby से अधिक efficient हो सकते हैं, लेकिन Ruby on Rails जितना शक्तिशाली framework उनके पास नहीं है
- Python और Django भी विकल्प हो सकते हैं, लेकिन उनमें भी Ruby और Rails जैसी कुछ समस्याएँ आ सकती हैं
-
deployment time संगठन की सफलता के लिए महत्वपूर्ण है
- लेखक का मानना है कि code को target branch या tag पर push होने के बाद अधिकतम एक घंटे के भीतर deploy हो जाना चाहिए
- GitLab को इस स्तर तक पहुंचने में लगभग 4 साल लगे, और तब भी सफर बाकी था
- तेज़ deployment incident response में मदद करता है
- अगर deployment में कई घंटे लगते हों, तो hot-patch की ज़रूरत पड़ सकती है
- तेज़ deployment motivation पर भी असर डालता है
- अपने बनाए बदलाव को वास्तव में चलते हुए देखना और इस्तेमाल होते देखना संतोष देता है
- कई हफ्ते काम किया गया बदलाव अगर फिर 2 हफ्ते बाद deploy हो, तो उससे उत्साह घटता है
- संगठनों को deployment time और deployment process में लगने वाले test suite time को कम करने के लिए बहुत आक्रामक होना चाहिए
- मुख्य बात यह नहीं कि हर test और deployment किसी तय सीमा से नीचे ही हो, बल्कि यह कि business requirements की अनुमति के भीतर जितना संभव हो उतनी तेज़ deployment को प्राथमिकता बनाया जाए
-
location-based salary भेदभावपूर्ण है
- GitLab की salary कई variables से प्रभावित होती थी, और उनमें से एक location था
- अगर किसी कंपनी के physical offices हों और उसे किसी खास क्षेत्र में hiring करनी हो, तो location-based adjustment समझ में आ सकती है; लेकिन पूरी तरह remote company में एक ही experience और responsibility वाले दो लोगों को सिर्फ रहने की जगह के आधार पर अलग salary देने का कोई उचित कारण नहीं है
- नौकरी छोड़ते समय Netherlands में लेखक की pre-tax annual salary लगभग €120,000 थी, यानी monthly लगभग €8,500
- अगर वह Bay Area में रहता, तो संभवतः कम से कम दोगुना, शायद उससे भी अधिक पाता
- समाधान यह है कि compensation, उम्मीदवार की location नहीं बल्कि job requirements के आधार पर तय हो
- 0xide Computer Company का उदाहरण दिया गया है, जो location-based pay की बजाय समान भुगतान करती है
- संबंधित चर्चा Compensation as a Reflection of Values में है
निष्कर्ष
- GitLab में बिताया समय बहुत सकारात्मक और बहुत नकारात्मक अनुभवों का मिश्रण था
- अलग-अलग टीमों में हासिल की गई उपलब्धियों और साथ काम करने वाले लोगों पर गहरा गर्व है
- यह अफसोस बना रहा कि आखिरी लगभग एक साल ने पूरे अनुभव को कुछ कड़वा बना दिया
- GitLab में काम करने पर पछतावा नहीं है, और अगर फिर मौका मिले तो hindsight के आधार पर कुछ चीज़ें अलग तरह से की जातीं
- कमियों के बावजूद लेखक का मानना है कि GitLab कई दूसरी कंपनियों से काफी बेहतर है, और वह आज भी इसे काम करने लायक कंपनी के रूप में recommend करता है
1 टिप्पणियां
Hacker News की राय
अगर कोई कंपनी त्वचा के रंग या लिंग के आधार पर वेतन घटाए तो यह बड़ी समस्या होगी, लेकिन निवास स्थान के आधार पर घटाना क्यों ठीक माना जाए—इस तुलना पर और सोचना ज़रूरी है
त्वचा का रंग·लिंग और निवास स्थान इस बात में अलग हैं कि क्या उन्हें बदला जा सकता है, और क्या उनका काम से वास्तव में संबंध है
निवास स्थान काम से जुड़ा है, क्योंकि कंपनी को स्थानीय कानूनी इकाई बनाना, न्यायिक और टैक्स सिस्टम समझना, time zone, travel cost आदि संभालने पड़ते हैं
क्षेत्र के हिसाब से compensation सही है या नहीं, इस पर चर्चा हो सकती है, लेकिन इसे नस्लीय या लैंगिक भेदभाव से तुलना करने पर GitLab को जैसे नस्लवादी·लिंगभेदी संगठन बना दिया जाता है, और बहस जल्दी खत्म हो जाती है
अगर वह Bay Area में रहता तो शायद दोगुने से ज़्यादा पाता; वह कहता है कि सिर्फ निवास स्थान अलग होने के कारण यह अन्यायपूर्ण है, लेकिन यहां victim point मिलने जैसा कुछ नहीं दिखता
यह तर्क economy को ठीक से न समझने जैसा अधिक लगता है
अभी अमेरिका में मिलने वाली salary UK के समय की लगभग दोगुनी है, लेकिन जीवन स्तर समान है; कुछ पहलू बदतर हैं और कुछ बेहतर
मूल लेखक भी अगर Bay Area चला गया होता, तो compensation अधिक होने पर भी उसका जीवन स्तर उल्टा गिरा हो सकता था
केवल income नहीं, बल्कि social security, tax और culture तक को ध्यान में रखना चाहिए; और अधिक आराम से जीने के लिए Europe लौटते हुए बड़ी salary cut स्वीकार करने पर भी विचार है
GitLab के क्षेत्रीय compensation का rationale https://handbook.gitlab.com/handbook/total-rewards/compensat... में दिया है, और काफी उचित लगता है
Philippines या Ukraine तक Bay Area salary देने पर लोग golden handcuffs में बंध सकते हैं, और जब छोड़ना चाहिए तब भी नहीं छोड़ पाएंगे, जिससे burnout हो सकता है
उल्टा अगर worldwide median salary दी जाए तो California या London में लोगों को hire करना मुश्किल हो जाएगा
यह दावा भी विवादास्पद है कि product manager की ज़रूरत नहीं होती और एक product पर 100 से ज़्यादा developers नहीं होने चाहिए
मूल लेखक बहुत autonomy वाला एक बेहतरीन engineer लगता है, जो शायद किसी अपेक्षाकृत छोटे startup में कहीं ज़्यादा खुश और सफल होता
अगर उसे tax rule बदलने का इंतज़ार न करना पड़ता, तो वह शायद पहले ही छोड़कर एक अच्छा experience write-up लिखता
Stocks के अलावा Amsterdam में $300k compensation भी मिला होता, तो कंपनी छोड़ना कितना मुश्किल होता, यह भी सोचने लायक है
अगर पूरी दुनिया में समान compensation अनिवार्य कर दिया जाए, तो company offsite, same time zone और communication advantages के कारण शायद बस local hiring ही करना चाहेगी
खासकर उस economic situation में जहां high cost-of-living क्षेत्रों में भी job candidates बहुत हैं
आगे यह बदल सकता है, लेकिन वास्तविक incentive structure को देखना उपयोगी है
दूसरे देशों में hiring करने वाली companies जो risk लेती हैं, वह भी होता है, और इससे local जगहों पर knowledge और future companies के बीज छोड़ने का असर भी होता है
office में आकर काम करना उस क्षेत्र की living cost की वजह से employee को wage negotiation power देता है, लेकिन fully remote company और culture में company कहीं से भी hire करके lowest common denominator के करीब salary दे सकती है
remote work सभी को global talent से compete करने वाले independent contractor जैसा बना देता है, जबकि office work में competition मुख्यतः उसी क्षेत्र के लोगों से होता है
ऐसा लगता है कि 28वें कर्मचारी के रूप में वे सीधे CEO को रिपोर्ट करते थे, फिर ऊपर धीरे-धीरे मैनेजर आने लगे, और उनमें से एक ने उन्हें PEP पर डाल दिया; संकेत समझकर वे छोड़ गए
यह काफ़ी standard flow है, और शायद यही एक वजह है कि बड़ी कंपनियों में लोग बड़े काम अच्छी तरह नहीं कर पाते
कंपनी के अंदर कोई project शुरू करके सफल कर भी दें, तो कंपनी ऊपर से लोगों को बीच में डाल देती है, और अंत में आप अपने ही शुरू किए project में nवें कर्मचारी बन जाते हैं और फिर “performance कम है” सुनना पड़ सकता है
वे सिर्फ़ मज़ेदार और दिलचस्प काम करना चाहते हैं, अंत में गैर-महत्वपूर्ण चीज़ों पर strong opinions रखते हैं, और अगर CEO के करीबी individual contributor मैनेजर की पसंद को स्वीकार न करें तो उन्हें manage करना nightmare बन जाता है
वे फैसलों की ज़िम्मेदारी लिए बिना इधर-उधर घूमकर समस्याएँ पैदा कर सकते हैं
endpoint security और personal devices का इस्तेमाल इसके संकेतों में से एक है
ऐसी permissive culture compliance और developer productivity की लागत के कारण scale नहीं होती
अपनी पसंदीदा Linux distribution पर अड़े पुराने developer को हटाना मुश्किल है, लेकिन काम के लिए work computer इस्तेमाल करना और updates को कंपनी द्वारा manage कराना ही सही है
database backup वाली बात भी वैसी ही है; अगर आप database team में हैं तो backup नंबर 1 काम है
“backup नहीं था” को passive voice में टाला नहीं जा सकता, और ऐसा लगता है कि वे routine तरीके से site maintain करने के बजाय sharding architecture की बहस में ज़्यादा रुचि रखते थे
यह निष्कर्ष भी कि GitLab ने hosting product की performance में पर्याप्त investment नहीं किया, अगर वह product बड़े घाटे में था तो उसमें और resources न डालना स्वाभाविक हो सकता है
यह सिर्फ़ मज़ेदार engineering नहीं है; वास्तविक business justification देकर समझाना होगा कि वह काम ज़्यादा महत्वपूर्ण क्यों है और पैसा कैसे कमाता है
एक मैनेजर ने मेरे साथ मिलकर सफल project शुरू किया था, लेकिन leadership ने लालच में politics और social dilemmas घसीट लिए, management layers डाल दीं, और मुझे व उस मैनेजर को replace करने की कोशिश कर रही है
मैंने सीखा कि काम की सच में परवाह क्यों नहीं करनी चाहिए, और इसी वजह से लगता है कि project टूटकर खत्म हो जाएगा
यहाँ माहौल ऐसा है मानो यह मान लिया गया हो कि वह कर्मचारी सचमुच high performer था, मैनेजर की ज़रूरत नहीं थी, और उसे PEP मिलना नहीं चाहिए था; लेकिन यह safe assumption नहीं है
मैंने शुरुआती startups में ऐसे शुरुआती employees देखे हैं जो कंपनी और role के बढ़ने की गति के साथ grow नहीं कर पाए या grow करना नहीं चाहते थे
पुराने योगदान के सम्मान, replace करना कठिन historical knowledge, और founders व leaders बन चुके शुरुआती कर्मचारियों से संबंधों के कारण उन्हें बनाए रखना आम है
लेकिन सिर्फ़ शुरुआती कर्मचारी होना और किसी महत्वपूर्ण शुरुआती project में शामिल होना यह नहीं बताता कि वे आगे भी वही काम संभालने के लिए सबसे अच्छे या suitable हैं
ad-hoc fixes, cron jobs और manual intervention से चीज़ें चलाने में वे माहिर हो सकते हैं, लेकिन बड़ी कंपनी में ऐसा operations model बिल्कुल fit नहीं बैठता
अगर वे adapt नहीं कर पाते या बड़ी कंपनी के तरीके से काम करने पर नाराज़ रहते हैं, तो मदद से ज़्यादा नुकसान होता है
हर शुरुआती company में ऐसे शुरुआती employees होते हैं जो साथ-साथ grow नहीं कर पाते, लेकिन यह इकलौता या आम अंत नहीं है
GitLab में लंबे समय से काम कर रहे कई कर्मचारी भी हैं, लेकिन शिकायत भरे blog posts में उनकी आवाज़ नहीं सुनाई देती, इसलिए selection bias को ध्यान में रखना चाहिए
मैं लंबे समय से GitLab इस्तेमाल कर रहा हूँ, और product लगातार बेहतर हो रहा है, इसलिए मैं इस दावे से सहमत नहीं कि product ठहर गया है
3 साल बाद जब देखा गया कि releases लगातार fail हो रहे हैं, तब जाकर यह समस्या बनी, लेकिन यह मेरे influence की वजह से कम और किसी ने Google पर “release failures रोकने का तरीका” search किया, ऐसा ज़्यादा लगा
समाधान क्या है, पता नहीं; और अभी भी किसी दूसरे topic पर वही चीज़ फिर झेल रहा हूँ
शुरू में बस जो ज़रूरी था वह कर दिया जाता था, लेकिन बाद में “गलत काम न हो” यह सुनिश्चित करने के नाम पर हर step को नए जोड़े गए manager पद से होकर गुजरना पड़ता है
यह सब उस शुरुआती idea और contributions से बेपरवाह होकर होता है जिसकी वजह से कंपनी grow कर पाई
सोचता हूँ कि GitLab CI से जुड़े कई साल पुराने issues के बचे रहने की background भी क्या इसी से जुड़ी है
बाहर से देखने पर लगता है कि GitLab ने बेहतरीन चीज़ें बनाने की क्षमता पूरी तरह खो दी है, और impression ऐसा है कि कई साल पुराने bugs बार-बार आते रहें तो भी उन्हें ठीक करने की कोशिश नहीं की जाती
कर्मचारियों को अपना निजी कंप्यूटर इस्तेमाल करने की अनुमति देने वाली बात लगभग चौंकाने वाली है
संगठन कितना भी छोटा हो, उसे कंपनी-स्वामित्व वाला उपकरण देना चाहिए और सभी कंपनी का काम उसी उपकरण पर करवाना चाहिए
कंपनी को बौद्धिक संपदा पर नियंत्रण के लिहाज़ से बड़ा फ़ायदा होता है, और कर्मचारियों के लिए भी काम के समय और निजी समय को अलग रखने में बहुत मदद मिलती है; लागत भी इतनी ज़्यादा नहीं होती
आप जहां भी जाएं, अपने पसंदीदा tools का वही सेट इस्तेमाल कर सकते हैं, और जल्दी से मिटाकर दोबारा बनाने की क्षमता “मेरे कंप्यूटर पर चलता/नहीं चलता” तरह की समस्याओं को debug करने में भी अच्छी रहती है
एक छोर पर याददाश्त पर निर्भर तरीका है, और दूसरे छोर पर https://nixos.org/ से कहीं भी पूरी तरह reproducible build बनाने का तरीका है
इनके बीच भी कई विकल्प हैं, और मैंने ऐसे लोगों को भी देखा है जो
host: localhostके साथ ज़रूरी चीज़ें install करने वाली Ansible files का bundle maintain करते हैंमैं latest Ubuntu version इस्तेमाल करता हूं और कुछ shell scripts [1] maintain करता हूं, जो fresh install पर मेरी चाही हुई चीज़ों का 80% install कर देती हैं
अगर आप वैज्ञानिक तरीके से जाना चाहते हैं, तो https://atuin.sh/ जैसा कुछ install करके long-term shell history के आधार पर आंकड़े निकाल सकते हैं कि आप वास्तव में कौन से programs बार-बार चलाते हैं
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
यह perfect solution नहीं है, लेकिन कम से कम कंपनी के device पर leakage या तो malicious action होगा, या sensitive data को unauthorized route से ले जाने वाली अक्षमता का नतीजा
अगर कंपनी पर मुकदमा होता है, तो निजी device की contents तक तरह-तरह के subpoena के दायरे में आ सकती हैं
अलग device की मांग करने से user को work-life balance में कोई फायदा होता है, ऐसा नहीं; बस असुविधा होती है
काम और निजी समय को अलग रखने वाला व्यवहार मुख्य रूप से आपकी अपनी आदतों, क्षमता, और आखिरकार फैसले पर निर्भर करता है
पहले मुझे लगता था कि region-based salary भेदभाव है, लेकिन अब मैं काफी हद तक उस सोच से बाहर आ चुका हूं
आखिर बात SF salary मांगने की ही होती है, और भारत के लोग Netherlands या SF salary मांगने लगते हैं
ऐसा करने पर race to the bottom होने की संभावना काफी है
सीधी-सी बात यह है कि हर कोई अपने region में अच्छी तरह जीने लायक कमाता था
अगर और चाहिए तो move कर सकते हैं, और अगर move नहीं करते तो उसके पीछे कोई वजह होगी
हर कोई SF salary और Indiana या India का cost of living चाहता है, लेकिन साफ वजहों से यह टिकना मुश्किल है
अगर hire हो गए, तो San Francisco में हों या Poland या Indonesia में, आपको US-level salary मिलती है
ऐसी positions बेहद competitive होती हैं
जैसे दुनिया भर के लिए दरवाज़ा खोलकर “दिखाओ तुम्हारे पास क्या है” कह दिया गया हो; इससे कहीं बड़ा applicant और talent pool देखा जा सकता है, और उसमें गरीब देशों से आए बहुत intelligent, driven, exceptional talent भी बहुत होते हैं
supply और demand ऐसे ही काम करते हैं
अगर आप ज़्यादा pay करने को तैयार हों, तो आम तौर पर higher-caliber candidates hire करते हैं
मैं अमेरिका के कई states में remote काम करते हुए SF-level salary पाने वाले काफी लोगों को जानता हूं
जाहिर है, यह संभव है
SF को भी बहुत ज़्यादा आत्ममुग्ध नहीं होना चाहिए
Detroit भी कभी Motor City और Music City था, और global cultural व technology center था, लेकिन उसकी core capabilities को सस्ते और अधिक efficient दूसरे regions की labor ने हिला दिया
मांग है same work, same pay की
अगर team members वही काम कर रहे हैं, लेकिन बाकी लोगों को पूरा payment मिल रहा है और आपको सिर्फ हिस्सा, तो यह गंभीर रूप से गलत है
team में contribution इस पर निर्भर नहीं करता कि आप फिलहाल कहां हैं
commute में कितना समय लगाते हैं, इससे output expectations नहीं बदलतीं
अगर office location बहुत महंगी है, तो company को कोई सस्ती location ढूंढकर problem solve करनी चाहिए; employees को company की खराब office location को subsidize करने की कोई वजह नहीं
employee को मिलने वाले 100k और company की cost अलग चीज़ें हैं
हर देश में company पर अतिरिक्त taxes, social security, benefits अलग होते हैं, और कई मामलों में local entity या virtual form of business, और local law compliance support resources चाहिए होते हैं
मैं खुद एक multinational company में global role में हूं और local-standard salary पाने वाले employees की तरफ हूं, लेकिन ऊपर से जितना दिखता है उससे कहीं ज़्यादा चीज़ें consider करनी पड़ती हैं
मूल रूप से hiring cost नहीं, बल्कि cost of living को reflect करते हुए adjust करती है, लेकिन equal salary को लक्ष्य रखती है
खराब managers industry की मुसीबत हैं
उल्टे, कई startups इसलिए बनते हैं क्योंकि founders ने अपनी पिछली नौकरी में खराब managers झेले होते हैं
traitorous eight और Fairchild Semiconductors की कहानी याद आती है
व्यक्तिगत रूप से, अगर मेरी पिछली नौकरी में non-technical, political और retaliatory manager न मिला होता, तो शायद मेरे पास अपना startup शुरू करने की प्रेरणा नहीं होती
पीछे मुड़कर देखता हूं तो लगता है, काश career की शुरुआत में ही ऐसा खराब manager और पहले मिल गया होता
और यह भी अच्छा होता कि जिन companies को सच में मेरी skills की जरूरत है, उन्हें ढूंढकर HR process के बोझ के बिना ज्यादा आसानी से move किया जा सके
यह दावा है कि Ruby का पूरा programming model इस आधार पर बना था कि ज़्यादातर समय input/output या network के इंतज़ार में जाता है, इसलिए भाषा की speed मायने नहीं रखती
लेकिन अब Node.js और JVM की तरफ ऐसे models हैं जो input/output·network का इंतज़ार करते हुए दूसरा काम कर सकते हैं या ज़्यादा requests handle कर सकते हैं
2024 में Ruby/Rails इस्तेमाल करना शायद waste हो सकता है, लेकिन सीमित users वाले enterprise apps, जहां development speed सबसे ज़्यादा अहम हो, या market validation के लिए quick prototype में यह अच्छा विकल्प हो सकता है
Rails एक बेहतरीन framework है और productivity शानदार है, लेकिन 2–3 साल पुराने Rails projects को maintain करना हमेशा मुश्किल होता है
Rails projects, Django या Express projects से ज़्यादा मुश्किल नहीं होते
किसी भी codebase में खरपतवार न उगने दें, इसके लिए discipline और लगातार gardening चाहिए
Ruby और Rails की अगर कमज़ोरी है, तो वह अब भी raw language performance और ज़्यादा memory requirements/usage है; इसलिए low latency या छोटे memory footprint की ज़रूरत वाले कामों के लिए यह कम आकर्षक है
अनुभव के आधार पर, परेशानी मुख्यतः तब होती है जब traffic अचानक बहुत ज़्यादा fluctuate करे, या WebSocket इस्तेमाल करने वाले active users बहुत ज़्यादा हों; WebSocket वाली समस्या anycable से काफी हद तक हल हो जाती है
लेकिन बहुत कम products ऐसी limit तक पहुंचेंगे, और पहुंच भी जाएं तो उसे solve किया जा सकता है
Stripe, GitHub, Shopify ऐसे प्रमुख उदाहरण हैं जहां Rails कई तरीकों से बिना समस्या scale हुआ है
Rails को आगे बढ़ाने वाली बड़ी ताकत DHH का developer happiness को लेकर विचार था, और यह development speed से गहराई से जुड़ा है
Rails community में input/output पर चर्चा इसलिए होती है क्योंकि यह web server operations के लिए महत्वपूर्ण है, न कि इसलिए कि यह भाषा या framework चुनने का अकेला या मुख्य focus है
अगर लक्ष्य web server CPU usage को maximize करना है, तो Rails में भी कई processes चलाकर ऐसा किया जा सकता था, और यह JVM में कई threads चलाने जैसी ही पद्धति के रूप में लंबे समय से इस्तेमाल होता आया है
यह कम सुविधाजनक हो सकता है, लेकिन यह 90s से इस्तेमाल हो रहा model है, और web requests आम तौर पर स्वतंत्र रूप से चलती हैं, इसलिए inter-process communication भी अक्सर बड़ी समस्या नहीं होती
इसे आम तौर पर “waste” कहना बहुत sweeping है
Rust में app लिखना भी स्थिति के हिसाब से waste हो सकता है; यह इस पर निर्भर करता है कि pressure कहां है
शुरुआती stage में ship न कर पाना कहीं बड़ी चिंता है, और mid-to-late stage में भी developer speed scale करने के लिए सबसे कठिन factors में से एक है
Rails backend और React frontend इस्तेमाल करने वाली company के CTO के रूप में, development speed बहुत अहम है, और Rails development speed अब भी बड़ा advantage है
scaling issues भी हैं, लेकिन 99% cases में वे Rails की नहीं बल्कि database की समस्या होते हैं
मुझे लगता है कि company का engineers को location के आधार पर salary देना एक और तरह का discrimination है
payment employee की ability के आधार पर होना चाहिए, location के आधार पर नहीं
government rules कहते हैं कि gender, religion, sexual orientation आदि के आधार पर discrimination न करें, तो location के आधार पर salary discrimination क्या fair है?
मैंने ऐसे friends देखे हैं जो उसी role में Europe से Asia चले गए; वही व्यक्ति, वही role, फिर भी सिर्फ location बदलने की वजह से उन्हें कम pay मिला
अगर कोई कम competitive market में move कर जाए जहां दूसरी jobs पाना मुश्किल हो, तो कम salary पर भी काम पर आने की संभावना बढ़ जाती है
remote होने से ऐसा लग सकता है कि आप local market से बंधे नहीं हैं, लेकिन governments अक्सर international hiring में बड़े barriers लगाती हैं, इसलिए कुछ countries कम competitive markets बन सकती हैं
अगर वही company में वही काम करते हुए दूसरे देश में जाने पर salary कम हुई, तो लगभग पक्का है कि इसी वजह से उस cut को accept किया गया
मेरे हिसाब से company को किसी universal value scale के बजाय इस आधार पर pay करना चाहिए कि employee आरामदायक और स्वस्थ जीवन जी सके
मुझे लगता है ऐसा universal value असंभव है
सिर्फ ability के आधार पर pay करने की दलील अनजाने में community को तोड़ती है, और inequality के जरिए gentrification और social cohesion के टूटने को और खराब करती है
location मायने रखती है
payment इसलिए होता है कि समान quality of life, समान type का housing, family को support करने के अवसर, और बच्चों को मिलते-जुलते schools में भेजने के मौके मिल सकें
इन चीज़ों की cost हर country में अलग होती है, इसलिए required income भी अलग होती है
company को एक खास ability चाहिए, और market उस ability की जो value तय करता है, company उतना ही देती है, उससे ज़्यादा नहीं
location के हिसाब से market उसी ability की अलग कीमत लगाता है, इसलिए salary भी बदलती है
religion एक ambiguous exception है, लेकिन fair हो या न हो, यह discrimination नहीं है
अगर GitLab.com की cost हमेशा उसकी कमाई से कहीं ज़्यादा थी, और company मुख्य रूप से self-hosted GitLab Enterprise Edition customers से पैसा कमाती थी, तो मुझे संदेह है कि scalability में पर्याप्त investment न करना सच में गलती थी या नहीं
primary तौर पर company को पैसा खोने वाली चीज़ों के बजाय पैसा कमाने वाली चीज़ों में invest करना चाहिए
यह high-level judgement हो सकता है कि बेहतर performance वाला gitlab.com ज़्यादा customers और reputation ला सकता है, लेकिन अगर actual business self-hosted software बेचने का है, तो development resources वहीं focus करना उचित है
वास्तव में जब हमने GitLab license खरीदा और फिर पता चला कि hosting GitLab को सौंपें या खुद करें, seat cost एक ही है, तो लगा कि infrastructure cost हम क्यों उठाएं
अगर GitLab.com को आधे-अधूरे ढंग से करना है, तो या तो इसे ठीक से करो, या product हटाकर सिर्फ GitLab Enterprise Edition जैसे self-hosting customers पर focus करना लंबे समय में बेहतर हो सकता है
लेकिन management में कोई भी ऐसा decision लेना नहीं चाहेगा
इसलिए product को आधा-अधूरा चलाया जाता है
जिन लोगों को product की सच में परवाह है, उनके लिए यह स्थिति frustrating हो सकती है
हर नया developer आते ही कहता है, “हमें scalability पर और ध्यान देना चाहिए,” और seniors कहते हैं, “हां हां, पता है…”
आर्थिक रूप से, अगर Amsterdam का डेवलपर Bay Area के डेवलपर जैसी ही वैल्यू दे रहा है, तो उसे वही वेतन देना संभवतः सही है
Amsterdam डेवलपर का स्थानीय market rate कम है, लेकिन आप एक global company बना रहे हैं और दूसरी global companies से प्रतिस्पर्धा कर रहे हैं
अभी आप Amsterdam डेवलपर को discounted price पर पा सकते हैं, लेकिन अंततः कोई competitor उसकी वैल्यू के ज़्यादा करीब रकम ऑफर करेगा या वे अपना काम करने के लिए चले जाएंगे
लगता है सबसे मजबूत कंपनियां talent को location-independent compensation देंगी
आखिर में मायने दी गई वैल्यू का है
अगर GitLab की तरह आपके पास बड़ा Ruby codebase है, और आप performance और reliability को महत्व देने वाली बड़ी enterprises को बेचना चाहते हैं, तो ऐसे व्यक्ति को सालाना €120k से ज़्यादा देंगे, ऐसा लगता है
performance, type safety और reliability को महत्व देने वाले अधिकतर engineers Ruby में दिलचस्पी नहीं रखते, इसलिए उस skill combination का market rate निश्चित रूप से ज़्यादा है
यह Bay Area के सालाना $500k स्तर का है या नहीं, पता नहीं, लेकिन शीर्ष talent चाहने वाली मजबूत कंपनियां अगर compensation को location से नहीं बल्कि दी गई वैल्यू से नहीं जोड़ेंगी, तो talent खो देंगी
code deploy करने में लगने वाला समय, startup के scale होने पर developer speed बनाए रखने के लिए सबसे महत्वपूर्ण metrics में से एक—शायद सबसे महत्वपूर्ण metric—मानता हूं
context switching developer की रोज़मर्रा की जिंदगी में सबसे महंगे tasks में से एक है, फिर भी इसे सबसे आसानी से नज़रअंदाज़ किया जाता है
managers अपनी schedule के हिसाब से team schedule बनाना पसंद करते हैं, लेकिन इससे individual contributors के “maker schedule” में अक्सर बाधा आती है
कई organizations इसे नोटिस करती हैं और scheduling के संदर्भ में context switching cost पर ध्यान देती हैं, लेकिन developers के लिए build से deploy तक लगने वाला समय भी उतना ही, या उससे भी ज्यादा महत्वपूर्ण है