Google में 14 साल के दौरान सीखे गए 14 और सबक
(addyo.substack.com)1. सबसे बेहतरीन इंजीनियर सही समस्याएँ चुनते हैं
आप हर काम में अपनी पूरी ऊर्जा नहीं लगा सकते।
2. अगर आपको यह नहीं पता कि क्या माँगना है, तो आप मीटिंग के लिए तैयार नहीं हैं
अनुमति, चुनाव, रुकावट दूर करना (unblock), जानकारी साझा करना (inform) — अगर आप इनमें से एक भी नहीं चुन सकते, तो वह मीटिंग समय की बर्बादी होगी।
3. "करना चाहिए" कोई योजना नहीं है। "मैं इसे मंगलवार को करूँगा" योजना है.
जब आप एक तय तारीख बताते हैं, तो आगे बढ़ने की गति बनती है।
4. धीमा कोड सिर्फ लक्षण है, असली कारण धीमा decision-making है
अगर किसी चीज़ पर फैसला लेने में घंटों नहीं बल्कि हफ्ते लग रहे हैं, तो उसके कारण को ध्यान से देखना चाहिए।
5. Reliability को प्रोडक्ट feature की तरह मानें
जिस तरह आप किसी feature को प्रोडक्ट review के बिना रिलीज़ नहीं करते, उसी तरह reliability पर चर्चा किए बिना किसी system को deploy नहीं करना चाहिए।
6. अगर टीमों के बीच interface खराब है, तो communication अच्छा नहीं हो सकता
धुंधली सीमाएँ और अस्पष्ट contract ज़्यादा मीटिंग्स और ज़्यादा Slack channels पैदा करते हैं। यह साफ़ होना चाहिए कि किसकी क्या ज़िम्मेदारी है और एक-दूसरे पर निर्भरता कैसे काम करती है।
7. सबसे अच्छी escalation वह है जो अपने साथ एक proposal भी लाए
समस्या उठाने वाला और समस्या हल करने वाला, दोनों ने issue पहचान लिया होता है, लेकिन भरोसा और autonomy सिर्फ एक पक्ष को मिलती है।
8. ऐसा system बनाइए जिसे heroes की ज़रूरत न पड़े
अगर कोई एक व्यक्ति बार-बार कंपनी या टीम को बचा रहा है, तो वह गौरव नहीं बल्कि इस बात का संकेत है कि चीज़ें गिरावट में हैं।
9. Observability को feature का हिस्सा समझें
"मैंने पुष्टि कर ली है कि कोड सही चल रहा है" को काम के पूरा होने का हिस्सा मानें।
10. छोटे PR दयालुता होते हैं। खासकर जब वे AI ने बनाए हों।
छोटे PR आपको step-by-step सोचने देते हैं, इसलिए ज्ञान भी धीरे-धीरे और व्यवस्थित रूप से जमा होता है।
11. नई टीम जोड़ने से सिर्फ node नहीं, edge भी जुड़ते हैं
अगर आप जानबूझकर connections कम नहीं करते, तो नई टीम जोड़ने पर भी output वही रहता है।
12. Migration कभी सिर्फ migration नहीं होती
जो migrations सच में पूरी होती हैं, उनमें तीन समानताएँ होती हैं: लगातार जुड़े रहने वाला sponsor, migration को सच में आगे बढ़ाने वाली टीम, और एक साफ़ end date जिस पर सबको भरोसा हो। अगर ये तीनों नहीं हैं, तो migration हमेशा 'लगभग पूरी' की स्थिति में अटकी रहती है, और दोनों systems की ज़िम्मेदारी हमेशा बनी रहती है।
13. AI drafts को आसान बनाता है, और taste अब और दुर्लभ होता जा रहा है
जो इंजीनियर सबसे बेहतरीन चीज़ को चुनना जानते हैं, वही इस दौर के सर्वश्रेष्ठ बनेंगे।
14. भरोसा latency optimization है
हर बार जब आप अपना वादा निभाते हैं, हर बार जब आप अपनी गलती ईमानदारी से मानते हैं, हर बार जब आप दूसरों की ज़िंदगी आसान बनाते हैं, तब आप जमा कर रहे होते हैं। मैंने औसत तकनीकी कौशल वाले इंजीनियरों को भी असाधारण परिणाम हासिल करते देखा है, सिर्फ इसलिए क्योंकि सब लोग उन पर भरोसा करते थे।
यह https://hi.news.hada.io/topic?id=24909 की अगली कड़ी है।
अभी कोई टिप्पणी नहीं है.