𝗦𝗵𝗶𝗽𝗽𝗶𝗻𝗴 𝟰 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝘀 𝗦𝗼𝗹𝗼

ഒരു വർഷത്തിനുള്ളിൽ ഞാൻ നാല് ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കി.

അവയിൽ spectr-ai, Scry, Argus, Lomi എന്നിവ ഉൾപ്പെടുന്നു. ഇവ സുരക്ഷ (security), Web3, ബ്രൗസർ എക്സ്റ്റൻഷനുകൾ (browser extensions), B2B SaaS എന്നീ മേഖലകളെ ഉൾക്കൊള്ളുന്നു.

ഇവ ഒറ്റയ്ക്ക് നിർമ്മിച്ചത് ഒരു ഒറ്റപ്പെട്ട പ്രോജക്റ്റിലൂടെയും ലഭിക്കാത്ത പാഠങ്ങൾ എനിക്ക് നൽകി.

ഞാൻ പഠിച്ച കാര്യങ്ങൾ ഇതാ.

  1. വിരസമായ കാര്യങ്ങൾക്കായി സമയം മാറ്റിവെക്കുക.

കഠിനമായ സാങ്കേതിക പ്രശ്നങ്ങളിൽ ഞാൻ എന്റെ ഊർജ്ജം ചെലവഴിച്ചു. AI വിശകലനത്തിലും (AI analysis) bytecode reconstruction-ലും ഞാൻ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു. ഇവ പ്രയാസകരമായിരുന്നുവെങ്കിലും മുൻകൂട്ടി പ്രവചിക്കാവുന്നതായിരുന്നു.

എന്നാൽ യഥാർത്ഥ വെല്ലുവിളികൾ ആകർഷണമില്ലാത്ത ജോലികളായിരുന്നു. Chrome Web Store റിവ്യൂകൾ, proxy resolution, deployment setup എന്നിവ എന്റെ പ്രോജക്റ്റുകളെ പാതിവഴിയിൽ തകർത്തേക്കാം എന്ന അവസ്ഥയിലെത്തിച്ചു.

യഥാർത്ഥ ജോലി പലപ്പോഴും അതിന്റെ അവസാന ഘട്ടങ്ങളിലെ സംയോജനമാണ് (integration). ഓരോ തവണയും ഇതിനായി ഞാൻ മതിയായ സമയം മാറ്റിവെക്കാത്ത പോരായ്മ സംഭവിച്ചു.

  1. AI തുടക്കം എളുപ്പമാക്കുന്നു, പക്ഷേ അവസാനം അല്ല.

ഒരാൾക്ക് ഒരു കമ്പനി കെട്ടിപ്പടുക്കാൻ AI സഹായിക്കുമെന്ന് ആളുകൾ പറയാറുണ്ട്. എന്നാൽ സത്യം കുറച്ചുകൂടി വ്യക്തമാണ്.

ഒരു ഫീച്ചറിന്റെ ആദ്യത്തെ 80% AI കൈകാര്യം ചെയ്യുന്നു. അത് boilerplate കോഡുകൾ നിർമ്മിക്കുകയും ടെസ്റ്റുകൾ തയ്യാറാക്കുകയും ചെയ്യുന്നു. ഇത് ഒറ്റയ്ക്ക് ജോലി ചെയ്യുന്നത് സാധ്യമാക്കുന്നു.

എന്നാൽ ബാക്കിയുള്ള അവസാന 20% AI കൈകാര്യം ചെയ്യുന്നില്ല. ഇതിൽ edge cases, security reviews, തകരാറുള്ള കണക്ഷനുകൾ പരിശോധിക്കൽ (debugging flaky connections) എന്നിവ ഉൾപ്പെടുന്നു. ആ ഭാഗം ഇപ്പോഴും സാവധാനത്തിലാണ് നടക്കുന്നത്. അതിന് നിങ്ങളുടെ പൂർണ്ണ ശ്രദ്ധ ആവശ്യമാണ്.

  1. പേര് മാറ്റുന്നത് പുരോഗതിയാണ്.

പ്രോജക്റ്റുകൾ വളരുന്നതിനനുസരിച്ച് ഞാൻ അവയുടെ പേരുകൾ പലതവണ മാറ്റിയിരുന്നു. പേര് മാറ്റുന്നത് എന്റെ അധ്വാനം പാഴാക്കി എന്നായിരുന്നു ഞാൻ കരുതിയിരുന്നത്.

ഞാൻ തെറ്റായിരുന്നു. പേര് മാറ്റുക എന്നതിനർത്ഥം നിങ്ങൾ ഒടുവിൽ ഉൽപ്പന്നത്തെ ശരിയായി മനസ്സിലാക്കി എന്നാണ്. കോഡ് മാറുന്നില്ല, പക്ഷേ നിങ്ങളുടെ കാഴ്ചപ്പാട് കൂടുതൽ വ്യക്തമാകുന്നു.

  1. മിനുക്കുപണികൾക്ക് മുൻപ് ലോജിക് വേണം.

ആകർഷകമായ ഒരു UI ഒരു കെണിയാണ്. പ്രവർത്തനരീതി (functionality) മാറിയാൽ, നിങ്ങൾക്ക് ഡിസൈൻ വീണ്ടും ചെയ്യേണ്ടി വരും. ഇത് സമയം പാഴാക്കും.

എന്റെ നിയമം ലളിതമാണ്: സ്റ്റൈലിംഗിന് മുൻപ് ലോജിക്കും ടെസ്റ്റുകളും പൂർത്തിയാക്കുക. ഒരു ടെസ്റ്റ് അത് ശരിയാണെന്ന് തെളിയിച്ചാൽ മാത്രമേ ഒരു ഫീച്ചർ പ്രവർത്തിക്കുന്നു എന്ന് പറയാനാകൂ. അത് ശരിയായി പ്രവർത്തിക്കുന്നത് വരെ അതിനെ ഭംഗിയാക്കാൻ ശ്രമിക്കരുത്.

  1. പരാജയങ്ങളെക്കുറിച്ച് എഴുതുക.

പബ്ലിക്കായി നിർമ്മിക്കുക (Building in public) എന്നാൽ മോശം ഭാഗങ്ങളും പങ്കുവെക്കുക എന്നാണ് അർത്ഥം.

ഹാക്കുകൾ (hacks), പരാജയപ്പെട്ട രീതികൾ, ബഗുകൾ എന്നിവയെക്കുറിച്ച് ഞാൻ എഴുതി. നിശബ്ദമായി ജോലി ചെയ്യുന്നതിനേക്കാൾ കൂടുതൽ ഇത് എനിക്ക് പഠിപ്പിച്ചു തന്നു. കൂടാതെ നിങ്ങളുടെ പ്രവർത്തനരീതിയിൽ താൽപ്പര്യമുള്ള ഒരു പ്രേക്ഷകവൃന്ദത്തെയും ഇത് സൃഷ്ടിച്ചു.

നിങ്ങൾ ഒറ്റയ്ക്കാണ് നിർമ്മിക്കുന്നതെങ്കിൽ, ഈ നിയമങ്ങൾ പാലിക്കുക:

• കോർ ഫീച്ചറിനേക്കാൾ കൂടുതൽ സമയം ഇന്റഗ്രേഷനായി (integration) ചെലവഴിക്കുക. • കഠിനമല്ലാത്ത ജോലികൾക്കായി AI ഉപയോഗിക്കുക, എന്നാൽ പ്രയാസകരമായ ആ 20% നിങ്ങൾ തന്നെ ചെയ്യുക. • UI-യേക്കാൾ കൂടുതൽ ടെസ്റ്റുകൾക്ക് മുൻഗണന നൽകുക. • നിങ്ങളുടെ തെറ്റുകൾ പങ്കുവെക്കുക.

'ഷിപ്പിംഗ്' (Shipping) എന്നത് ഒരു ക്രിയയാണ്. അതൊരു പൂർത്തിയായ അവസ്ഥയല്ല. ഒരു ഉൽപ്പന്നം പൂർണ്ണതയിലെത്തിക്കുന്നതിനേക്കാൾ കൂടുതൽ നാല് തവണ ഇത് ചെയ്തത് എനിക്ക് പഠിപ്പിച്ചു തന്നു.

Source: https://dev.to/pavelespitia/shipping-four-products-solo-what-a-year-of-building-in-public-taught-me-2nhh

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