നിങ്ങൾ ഡോക്യുമെന്റേഷൻ വായിക്കുന്നത് നിർത്തി, ഇപ്പോൾ നിങ്ങൾക്ക് സിസ്റ്റങ്ങളെക്കുറിച്ച് ധാരണയില്ല

ഞാൻ സർവ്വകലാശാലയിൽ കമ്പ്യൂട്ടർ സയൻസ് പഠിച്ചവനല്ല. ഞാൻ പഠിച്ചത് ജിയോഫിസിക്സ് (geophysics) ആണ്.

വായനയിലൂടെയാണ് ഞാൻ സോഫ്റ്റ്‌വെയർ പഠിച്ചത്. ഞാൻ ഡോക്യുമെന്റേഷനുകളും, സോഴ്സ് കോഡുകളും, GitHub ഇഷ്യൂകളും വായിച്ചു. പഴയ ബ്ലോഗ് പോസ്റ്റുകളും RFC ത്രെഡുകളും ഞാൻ വായിച്ചു. ഞാൻ ഒരു ബൂട്ട്ക്യാമ്പ് (bootcamp) ഉപയോഗിച്ചില്ല. ഒരു ബ്രൗസറും ലഭ്യമായ വിവരങ്ങളും മാത്രമാണ് ഞാൻ ഉപയോഗിച്ചത്.

ഞാൻ Cloudflare Workers പഠിച്ചപ്പോൾ എന്റെ കയ്യിൽ ഒരു കോഴ്സ് ഉണ്ടായിരുന്നില്ല. എന്റെ കയ്യിൽ ഡോക്സുകളും (docs) ചേഞ്ച്‌ലോഗും (changelog) മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ. പുലർച്ചെ 1 മണിക്ക് തകരാറിലായ ഒരു ഡിപ്ലോയ്മെന്റ് ശരിയാക്കാൻ ഞാൻ ബൈൻഡിംഗ് കോൺഫിഗറേഷൻ മൂന്ന് തവണ വായിച്ചു. വർഷങ്ങൾക്ക് മുമ്പുള്ള GitHub ത്രെഡുകളിൽ നിന്നാണ് ഞാൻ ഉത്തരങ്ങൾ കണ്ടെത്തിയത്.

കാര്യങ്ങൾ വ്യക്തമാകുന്നതുവരെ ആ വിവരങ്ങൾക്കൊപ്പം ഇരുന്നാണ് ഞാൻ പഠിച്ചത്.

ഇപ്പോൾ ഞാൻ ഒരു പുതിയ രീതി കാണുന്നുണ്ട്. ഒരു ഭാഗം എന്തുകൊണ്ടാണ് ആശയക്കുഴപ്പമുണ്ടാക്കുന്നത് എന്ന് ആളുകൾ ചോദിക്കുന്നില്ല. പകരം 'X'-ന് വേണ്ട കോഡ് ചോദിക്കുന്നു. സിസ്റ്റത്തിന്റെ പ്രവർത്തനം മനസ്സിലാക്കാൻ അവർ സോഴ്സ് കോഡ് പരിശോധിക്കുന്നില്ല. ഒരു ഫങ്ക്ഷൻ എന്താണ് ചെയ്യുന്നത് എന്ന് മാത്രമാണ് അവർ ചോദിക്കുന്നത്.

പണ്ട് ലക്ഷ്യം കാര്യങ്ങൾ മനസ്സിലാക്കുക എന്നതായിരുന്നു. ഇപ്പോൾ ലക്ഷ്യം ഔട്ട്പുട്ട് (output) ആണ്. ആളുകൾ ഇതിനെ കാര്യക്ഷമത (efficiency) എന്ന് വിളിക്കുന്നു. എന്നാൽ യഥാർത്ഥത്തിൽ ഇത് ഒരു കടബാധ്യതയാണ് (debt).

ഒരു 'half-open state' എന്നാൽ എന്താണെന്ന് അറിയാതെ തന്നെ നിങ്ങൾക്ക് ഒരു 'circuit breaker' നിർമ്മിക്കാൻ കഴിഞ്ഞേക്കാം. അത് നിങ്ങളുടെ ടെസ്റ്റുകളിൽ പ്രവർത്തിക്കും. എന്നാൽ ആറ് ആഴ്ചകൾക്ക് ശേഷം വലിയ ലോഡ് വരുമ്പോൾ പ്രൊഡക്ഷനിൽ അത് പരാജയപ്പെടും. നിങ്ങൾക്ക് ഒരു mental model ഇല്ലാത്തതുകൊണ്ടാണ് നിങ്ങൾ പരാജയപ്പെടുന്നത്. 'എന്ത്' എന്നത് നിങ്ങൾക്കറിയാം, പക്ഷേ 'എന്തുകൊണ്ട്' എന്നത് അറിയില്ല.

'എന്തുകൊണ്ട്' എന്നത് മാത്രമാണ് പ്രസക്തമായ ഭാഗം.

ഡോക്യുമെന്റേഷൻ വായിക്കുന്നത് ഒരു mental model നിർമ്മിക്കാൻ സഹായിക്കുന്നു. ഫൂട്ട്നോട്ടുകളിൽ (footnotes) നിങ്ങൾ ട്രേഡ്ഓഫുകളും (tradeoffs) എഡ്ജ് കേസുകളും (edge cases) കാണുന്നു. വായിക്കുമ്പോൾ നിങ്ങൾ അനുഭവിക്കുന്ന ബുദ്ധിമുട്ടുകളാണ് യഥാർത്ഥത്തിൽ പഠനം നടക്കുന്നത്.

ഞാൻ Bookmark Brain നിർമ്മിച്ചപ്പോൾ എനിക്ക് Cloudflare Vectorize മനസ്സിലാക്കേണ്ടി വന്നു. ഞാൻ വെറുതെ API മാത്രം ഉപയോഗിച്ചില്ല. എംബെഡിംഗ് ഡൈമൻഷനുകൾ (embedding dimensions), ഇൻഡക്സ് ബിഹേവിയർ (index behavior), ക്വറി ഡിസ്റ്റൻസ് മെട്രിക്സ് (query distance metrics) എന്നിവ ഞാൻ പഠിച്ചു. ഞാൻ HNSW പേപ്പർ വായിച്ചു. ആശയക്കുഴപ്പങ്ങൾ അറിവായി മാറുന്നത് വരെ ഞാൻ അതിൽ മുഴുകി ഇരുന്നു.

ആ അറിവാണ് എന്റെ സിസ്റ്റങ്ങൾ പ്രൊഡക്ഷനിൽ സുഗമമായി പ്രവർത്തിപ്പിക്കുന്നത്. പുലർച്ചെ 2 മണിക്ക് എന്തെങ്കിലും തകരാർ സംഭവിച്ചാൽ, എന്നെ നയിക്കാൻ എന്റെ കയ്യിൽ ഒരു mental model ഉണ്ട്. ഞാൻ പ്രോംപ്റ്റുകൾ (prompts) മാത്രം ഉപയോഗിച്ചിരുന്നെങ്കിൽ, എനിക്ക് ഒരു ഡെമോ (demo) ലഭിക്കുമായിരുന്നു, എന്നാൽ യുക്തിസഹമായി വിശകലനം ചെയ്യാൻ കഴിയുന്ന ഒരു സിസ്റ്റം ലഭിക്കില്ലായിരുന്നു.

ഇത് എഞ്ചിനീയറിംഗിൽ ഒരു വിടവ് സൃഷ്ടിക്കുന്നു.

  • കോഡ് റിവ്യൂകളിൽ (code reviews): ഒരു ഡെവലപ്പർ ORM ഡോക്സുകൾ വായിച്ചതുകൊണ്ട് ഒരു N+1 പ്രശ്നം പെട്ടെന്ന് തിരിച്ചറിയുന്നു. എന്നാൽ കോഡ് ജനറേറ്റ് ചെയ്തതുകൊണ്ട് മാത്രം മറ്റേ ഡെവലപ്പർ അത് ശ്രദ്ധിക്കാതെ പോകുന്നു.
  • ആർക്കിടെക്ചറിൽ (architecture): ഒരു ഡെവലപ്പർ Kafka പാർട്ടീഷനുകളും (partitions) ഓഫ്‌സെറ്റുകളും (offsets) മനസ്സിലാക്കുന്നു. മറ്റേയാൾക്ക് പദങ്ങൾ മാത്രം അറിയാം, പക്ഷേ അതിന്റെ ഘടന അറിയില്ല.
  • ഡീബഗ്ഗിംഗിൽ (debugging): ഡീബഗ്ഗിംഗ് എന്നത് നിങ്ങളുടെ mental model-നെ ആശ്രയിച്ചിരിക്കുന്നു. അതില്ലെങ്കിൽ, നിങ്ങൾ വെറുതെ കാര്യങ്ങൾ മാറ്റിക്കൊണ്ടിരിക്കുകയും അത് ശരിയാകുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുകയേയുള്ളൂ.

AI-ക്ക് ഒരു മുഴുവൻ ആർക്കിടെക്ചറും ഉൾക്കൊള്ളാൻ കഴിയില്ല. നിങ്ങളുടെ കോഡ്ബേസിലെ (codebase) വലിയ ചിത്രം അതിന് കാണാൻ കഴിയില്ല. AI നിർമ്മിച്ച കാഷിംഗ് ലെയറുകൾ (caching layers) എല്ലാ ടെസ്റ്റുകളും പാസ്സ് ചെയ്യുകയും എന്നാൽ റേസ് കണ്ടീഷനുകൾ (race conditions) ആരും മനസ്സിലാക്കാത്തതുകൊണ്ട് പ്രൊഡക്ഷനിൽ തകരാറിലാവുകയും ചെയ്യുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്.

ഈ വിടവ് AI ഉപയോഗിക്കുന്നതിനെക്കുറിച്ചല്ല. നിങ്ങൾ അത് എങ്ങനെ ഉപയോഗിക്കുന്നു എന്നതിനെക്കുറിച്ചാണ്.

നിങ്ങൾ അത് ട്രേഡ്ഓഫുകൾ മനസ്സിലാക്കാൻ ഉപയോഗിക്കുന്നുണ്ടോ? അതോ കാര്യങ്ങൾ മനസ്സിലാക്കാതിരിക്കാൻ ഉപയോഗിക്കുന്നുണ്ടോ?

മികച്ച ഡെവലപ്പർമാർ വേഗത്തിൽ മാത്രം നീങ്ങുന്നവരല്ല. അവർ ഇപ്പോഴും ചേഞ്ച്‌ലോഗുകളും സോഴ്സ് കോഡും വായിച്ചുകൊണ്ടിരിക്കുന്നു. പ്രോംപ്റ്റിംഗിലൂടെ (prompting) പകരം വെക്കാൻ കഴിയാത്ത ഒരു mental model അവർ നിർമ്മിക്കുന്നു.

ഡോക്യുമെന്റേഷൻ വായിക്കുന്നത് ഒരു ശീലമാണ്. അത് നിങ്ങളുടെ ഉൽപ്പാദനക്ഷമതയെ (productivity) ബാധിക്കുന്ന ഒരു നികുതിയല്ല. സിസ്റ്റം തകരാറിലാകുമ്പോൾ നിങ്ങളെ മറ്റാരും പകരം വെക്കാൻ കഴിയാത്തവരാക്കുന്നത് ഇതാണ്.

നിങ്ങൾ വായന ഒഴിവാക്കിയാൽ, നിങ്ങൾ ചിന്തയെയും ഒഴിവാക്കുന്നു. താങ്ങാൻ ആരുമില്ലാതെ പ്രൊഡക്ഷനിൽ എത്തുന്നതുവരെ നിങ്ങൾ ഇത് തിരിച്ചറിയുകയുമില്ല.

Source: https://dev.to/dannwaneri/you-stopped-reading-the-docs-now-you-dont-understand-the-systems-go1

Optional learning community: https://t.me/GyaanSetuAi