लाइब्रेरी बनाने के लिए पढ़ना बंद करें। समस्या सुलझाने के लिए पढ़ना शुरू करें।
अधिकांश इंजीनियरिंग रीडिंग लिस्ट ज्ञान इकट्ठा करने पर ध्यान केंद्रित करती हैं। आधुनिक इंजीनियरिंग बाधाओं (bottlenecks) को सुलझाने के लिए पुरस्कृत करती है।
हाल ही में एक जूनियर इंजीनियर ने मुझे "Top 10 Books for Engineers" की एक लिस्ट दिखाई। यह दस साल पहले की लिस्ट जैसी ही लग रही थी। यह उसी पुरानी धारणा पर आधारित थी।
धारणा यह है कि पर्याप्त किताबें पढ़ना आपको एक बेहतर इंजीनियर बनाता है। हाई-परफॉर्मिंग टीमें इस तरह से नहीं सीखती हैं।
बेहतरीन इंजीनियर बाधाओं (constraints) के इर्द-गिर्द सीखने की योजना बनाते हैं।
मानक रीडिंग लिस्ट यह मानती हैं कि सभी ज्ञान का मूल्य है। वास्तव में, इंजीनियरिंग का मूल्य संदर्भ (context) पर निर्भर करता है।
• डेटाबेस की समस्याओं का सामना कर रहे एक backend इंजीनियर को Agile पर किताब की ज़रूरत नहीं है। • AI inference पर बहुत अधिक खर्च करने वाली टीम को किसी सामान्य craftsmanship किताब की ज़रूरत नहीं है। • लेटेंसी (latency) की समस्याओं का सामना कर रहे स्टार्टअप को leadership framework की ज़रूरत नहीं है।
इन लोगों को अपने सामने मौजूद विशिष्ट bottleneck के समाधान की आवश्यकता है। रीडिंग लिस्ट पूर्णता (completeness) के लिए अनुकूलित होती हैं। इंजीनियरिंग प्रासंगिकता (relevance) को पुरस्कृत करती है।
डेटाबेस और नेटवर्किंग जैसे fundamentals अभी भी मायने रखते हैं। लेकिन वे अब पर्याप्त नहीं हैं।
आधुनिक प्रणालियाँ नई constraints लाती हैं। AI inference लागत इसका एक बड़ा उदाहरण है। पारंपरिक लिस्ट शायद ही कभी इन समस्याओं को कवर करती हैं।
चुनौती अब केवल सही सॉफ्टवेयर लिखना नहीं है। चुनौती probabilistic components के ऊपर विश्वसनीय सिस्टम बनाना है।
अतीत में, इंजीनियर deterministic systems के साथ काम करते थे। एक ही input से एक ही output मिलता था।
आज, systems अलग तरह से व्यवहार करते हैं। एक prompt अलग-अलग responses देता है। एक agent अलग-अलग paths अपनाता है। एक model upgrade आपके code को बदले बिना behavior बदल देता है।
नए प्रश्न ये हैं: • आप quality का मूल्यांकन कैसे करते हैं? • आप इन बदलावों को कैसे प्रबंधित करते हैं?
ये edge cases नहीं हैं। ये रोज़मर्रा के engineering tasks हैं।
कुशल इंजीनियर cover to cover नहीं पढ़ते हैं। वे mechanisms के लिए पढ़ते हैं। वे एक bottleneck ढूँढते हैं, mechanism की पहचान करते हैं, और केवल वही सीखते हैं जिसकी उन्हें आवश्यकता होती है।
• यदि latency अधिक है, तो batching का अध्ययन करें। • यदि context एक समस्या है, तो retrieval का अध्ययन करें। • यदि agents विफल होते हैं, तो evaluation का अध्ययन करें।
यह सीखने को सीधे production से जोड़ता है। ज्ञान leverage बन जाता है।
इस learning loop का उपयोग करें:
- bottleneck की पहचान करें।
- उस समस्या के लिए विशिष्ट resource खोजें।
- समाधान लागू करें।
रीडिंग लिस्ट को पूरा करने की कोशिश करना बंद करें। सिस्टम को बेहतर बनाने की कोशिश करना शुरू करें।
अपनी अगली किताब से पहले, पूछें: मेरे सिस्टम की सबसे बड़ी बाधा क्या है?
क्या यह लेटेंसी, लागत, विश्वसनीयता, या ऑब्जर्वेबिलिटी है?
उस संसाधन को खोजें जो उस बाधा को दूर करे। इंजीनियरिंग कोई पढ़ने की प्रतियोगिता नहीं है। यह बाधाओं को सुलझाने वाला पेशा है।
सिस्टम तय करता है कि आप आगे क्या सीखेंगे।