ഒരു ലൈബ്രറി ഉണ്ടാക്കാൻ വേണ്ടി വായിക്കുന്നത് നിർത്തുക. ഒരു പ്രശ്നം പരിഹരിക്കാൻ വേണ്ടി വായിക്കാൻ തുടങ്ങുക.
മിക്ക എഞ്ചിനീയറിംഗ് റീഡിംഗ് ലിസ്റ്റുകളും അറിവ് ശേഖരിക്കുന്നതിലാണ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്. എന്നാൽ ആധുനിക എഞ്ചിനീയറിംഗിൽ തടസ്സങ്ങൾ (bottlenecks) പരിഹരിക്കുന്നതിനാണ് പ്രാധാന്യം നൽകുന്നത്.
അടുത്തിടെ ഒരു ജൂനിയർ എഞ്ചിനീയർ എനിക്ക് "Top 10 Books for Engineers" എന്നൊരു ലിസ്റ്റ് കാണിച്ചുതന്നു. പത്ത് വർഷം മുമ്പുള്ള ലിസ്റ്റുകൾ പോലെ തന്നെയായിരുന്നു അതും. പഴയ അതേ ധാരണയിലായിരുന്നു അത് നിലകൊള്ളുന്നത്.
ധാരാളം പുസ്തകങ്ങൾ വായിക്കുന്നത് നിങ്ങളെ ഒരു മികച്ച എഞ്ചിനീയർ ആക്കും എന്നതാണ് ആ ധാരണ. എന്നാൽ മികച്ച പ്രകടനം കാഴ്ചവെക്കുന്ന ടീമുകൾ ഇങ്ങനെയല്ല പഠിക്കുന്നത്.
മികച്ച എഞ്ചിനീയർമാർ തടസ്സങ്ങളെ (constraints) അടിസ്ഥാനമാക്കിയാണ് തങ്ങളുടെ പഠന പദ്ധതികൾ തയ്യാറാക്കുന്നത്.
എല്ലാ അറിവിനും മൂല്യമുണ്ടെന്നാണ് സാധാരണ റീഡിംഗ് ലിസ്റ്റുകൾ കരുതുന്നത്. എന്നാൽ യഥാർത്ഥത്തിൽ, എഞ്ചിനീയറിംഗിലെ മൂല്യം സാഹചര്യങ്ങളെ (context) ആശ്രയിച്ചിരിക്കും.
• ഡാറ്റാബേസ് പ്രശ്നങ്ങൾ നേരിടുന്ന ഒരു backend engineer-ന് Agile-നെ കുറിച്ചുള്ള പുസ്തകം ആവശ്യമില്ല. • AI inference-നായി വലിയ തുക ചിലവാക്കുന്ന ഒരു ടീമിന് ഒരു generic craftsmanship book ആവശ്യമില്ല. • latency പ്രശ്നങ്ങൾ നേരിടുന്ന ഒരു startup-ന് ഒരു leadership framework ആവശ്യമില്ല.
ഇവർക്ക് തങ്ങളുടെ മുന്നിലുള്ള പ്രത്യേക തടസ്സങ്ങൾക്കുള്ള പരിഹാരങ്ങളാണ് വേണ്ടത്. റീഡിംഗ് ലിസ്റ്റുകൾ പൂർണ്ണതയ്ക്കായി (completeness) ശ്രമിക്കുമ്പോൾ, എഞ്ചിനീയറിംഗ് പ്രസക്തിയ്ക്കാണ് (relevance) മുൻഗണന നൽകുന്നത്.
Databases, networking തുടങ്ങിയ അടിസ്ഥാന കാര്യങ്ങൾ ഇപ്പോഴും പ്രധാനമാണ്. എന്നാൽ അവ മാത്രം മതിയാകില്ല.
ആധുനിക സിസ്റ്റങ്ങൾ പുതിയ തടസ്സങ്ങൾ കൊണ്ടുവരുന്നു. AI inference ചിലവുകൾ ഇതിനൊരു പ്രധാന ഉദാഹരണമാണ്. പരമ്പരാഗത ലിസ്റ്റുകൾ ഇത്തരം പ്രശ്നങ്ങളെ അപൂർവ്വമായി മാത്രമേ ഉൾക്കൊള്ളാറുള്ളൂ.
വെറുമൊരു ശരിയായ സോഫ്റ്റ്വെയർ എഴുതുക എന്നതല്ല ഇന്നത്തെ വെല്ലുവിളി. Probabilistic ഘടകങ്ങൾക്ക് മുകളിൽ വിശ്വസനീയമായ സിസ്റ്റങ്ങൾ നിർമ്മിക്കുക എന്നതാണ് വെല്ലുവിളി.
പണ്ട്, എഞ്ചിനീയർമാർ deterministic സിസ്റ്റങ്ങളിലാണ് പ്രവർത്തിച്ചിരുന്നത്. ഒരേ input നൽകിയാൽ ഒരേ output തന്നെ ലഭിക്കുമായിരുന്നു.
ഇന്ന് സിസ്റ്റങ്ങൾ വ്യത്യസ്തമായി പെരുമാറുന്നു. ഒരു prompt വ്യത്യസ്തമായ മറുപടികൾ നൽകുന്നു. ഒരു agent വ്യത്യസ്ത പാതകൾ സ്വീകരിക്കുന്നു. നിങ്ങളുടെ code മാറ്റാതെ തന്നെ ഒരു model upgrade ചെയ്യുന്നത് സിസ്റ്റത്തിന്റെ പെരുമാറ്റത്തിൽ മാറ്റം വരുത്തുന്നു.
പുതിയ ചോദ്യങ്ങൾ ഇവയാണ്: • നിങ്ങൾ എങ്ങനെയാണ് ഗുണനിലവാരം (quality) വിലയിരുത്തുന്നത്? • ഇത്തരം മാറ്റങ്ങളെ നിങ്ങൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു?
ഇവ അസാധാരണമായ സാഹചര്യങ്ങളല്ല (edge cases). ഇവ ദൈനംദിന എഞ്ചിനീയറിംഗ് ജോലികളാണ്.
മികച്ച എഞ്ചിനീയർമാർ പുസ്തകങ്ങൾ തുടക്കം മുതൽ അവസാനം വരെ വായിക്കാറില്ല. അവർ മെക്കാനിസങ്ങൾ മനസ്സിലാക്കാനാണ് വായിക്കുന്നത്. അവർ ഒരു bottleneck കണ്ടെത്തുന്നു, അതിന്റെ മെക്കാനിസം തിരിച്ചറിയുന്നു, ആവശ്യമുള്ള കാര്യങ്ങൾ മാത്രം പഠിക്കുന്നു.
• Latency കൂടുതലാണെങ്കിൽ, batching പഠിക്കുക. • Context ഒരു പ്രശ്നമാണെങ്കിൽ, retrieval പഠിക്കുക. • Agents പരാജയപ്പെടുന്നുണ്ടെങ്കിൽ, evaluation പഠിക്കുക.
ഇത് പഠനത്തെ നേരിട്ട് production-മായി ബന്ധിപ്പിക്കുന്നു. അറിവ് ഒരു കരുത്തായി മാറുന്നു.
ഈ learning loop ഉപയോഗിക്കുക:
- തടസ്സം (bottleneck) തിരിച്ചറിയുക.
- ആ പ്രശ്നത്തിനുള്ള കൃത്യമായ സ്രോതസ്സ് കണ്ടെത്തുക.
- പരിഹാരം പ്രയോഗിക്കുക.
ഒരു റീഡിംഗ് ലിസ്റ്റ് പൂർത്തിയാക്കാൻ ശ്രമിക്കുന്നത് നിർത്തുക. സിസ്റ്റം മെച്ചപ്പെടുത്താൻ ശ്രമിച്ചു തുടങ്ങുക.
നിങ്ങളുടെ അടുത്ത പുസ്തകത്തിന് മുമ്പ് ചോദിക്കുക: എന്റെ സിസ്റ്റത്തിലെ ഏറ്റവും വലിയ പരിമിതി എന്താണ്?
അത് ലേറ്റൻസി (latency), ചിലവ് (cost), വിശ്വാസ്യത (reliability), അതോ ഒബ്സർവബിലിറ്റി (observability) എന്നിവയാണോ?
ആ തടസ്സം (bottleneck) പരിഹരിക്കുന്ന വിഭവങ്ങൾ കണ്ടെത്തുക. എൻജിനീയറിങ് എന്നത് ഒരു വായനാ മത്സരമല്ല. അത് പരിമിതികൾ പരിഹരിക്കുന്ന (constraint-solving) ഒരു തൊഴിലാണ്.
അടുത്തതായി നിങ്ങൾ എന്താണ് പഠിക്കേണ്ടതെന്ന് സിസ്റ്റം നിശ്ചയിക്കുന്നു.