ഒരു സ്റ്റാർട്ടപ്പിലെ നിങ്ങളുടെ ആദ്യ മാസം വലിയൊരു സ്വാധീനം ചെലുത്തും. ലാപ്ടോപ്പ് ലഭിക്കാനായി ഐടി വിഭാഗത്തെ കാത്തിരിക്കുമ്പോഴോ ഓറിയന്റേഷൻ വീഡിയോകൾ കണ്ടുകൊണ്ടിരിക്കുമ്പോഴോ ഉള്ള സാവധാനത്തിലുള്ള ഒരു തുടക്കം അവിടെയില്ല. ഒന്നാം ദിവസം തന്നെ, യഥാർത്ഥ ആളുകൾ ഉപയോഗിക്കുന്ന കാര്യങ്ങൾ നിർമ്മിക്കാനും, അവ തകരാറിലാക്കാനും, വീണ്ടും ശരിയാക്കാനും നിങ്ങൾ തയ്യാറാവണം. ജോലി അന്വേഷിക്കുന്നവരെ അവരുടെ അപേക്ഷകൾ ക്രമീകരിക്കാൻ സഹായിക്കുന്ന ടൂളുകൾ നിർമ്മിക്കുന്ന Treevah എന്ന കമ്പനിയിൽ ചേർന്നതിന് ശേഷം ഞാൻ ഇത് വേഗത്തിൽ മനസ്സിലാക്കി. ഒരു സ്റ്റാർട്ടപ്പിലെ ആദ്യ മുപ്പത് ദിവസങ്ങൾ, ക്ലാസ് മുറികളിലോ മത്സരങ്ങളിലോ ലഭിക്കുന്നതിനേക്കാൾ കൂടുതൽ കാര്യങ്ങൾ സോഫ്റ്റ്വെയർ ഡെവലപ്മെന്റിനെക്കുറിച്ച് എന്നെ പഠിപ്പിച്ചു.
അവിരാമമായ വേഗതയാണ് ഇതിന്റെ താളം
Treevah-ൽ, നിങ്ങൾ ശീലിച്ചു വരുന്നത് വരെ ജോലി കാത്തുനിൽക്കില്ല. ഉൽപ്പന്നത്തെ ആൽഫയിൽ നിന്ന് ബീറ്റയിലേക്കും പിന്നീട് പ്രൊഡക്ഷനിലേക്കും എത്തിക്കാൻ ടീം പരിശ്രമിക്കുന്നു, അതുകൊണ്ട് തന്നെ ഓരോ ജോലിക്കും വലിയ പ്രാധാന്യമുണ്ട്. വെറുതെ സമയം കളയാനോ പ്രൊഫസറുടെ ഇൻബോക്സിൽ ഇരിക്കാനോ ഉള്ള ജോലികൾക്ക് അവിടെ സ്ഥാനമില്ല. നിങ്ങൾ ഒരു ഫീച്ചർ പുറത്തിറക്കുമ്പോൾ, അത് നേരിട്ട് ഉപയോക്താക്കളിലേക്ക് എത്തും; അവർ അടുത്ത ജോലി തേടുമ്പോൾ ഡെഡ്ലൈനുകളും ഇന്റർവ്യൂകളും ഫോളോ-അപ്പുകളും ട്രാക്ക് ചെയ്യാൻ ശ്രമിക്കുന്നവരാണ് അവർ.
ഈ വേഗത തളർത്തുന്നതാണ്. ഓരോ ദിവസവും നിങ്ങൾ വളരെ വേഗത്തിൽ നീങ്ങണം, പ്രതീക്ഷിച്ചതിലും വേഗത്തിൽ ജോലി കൂടുമെന്നതും സത്യമാണ്. ഡെഡ്ലൈനുകൾ വെറും വാക്കുകളല്ല; അവ കമ്പനിക്ക് കൂടുതൽ ആളുകളെ സേവിക്കാനോ നിലവിലുള്ള സേവനങ്ങളിലെ പോരായ്മകൾ പരിഹരിക്കാനോ സഹായിക്കുന്ന പ്രധാന ഘട്ടങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ ഭാരം നിങ്ങളെ തളർത്താം. എന്നാൽ വലിയ സ്ഥാപനങ്ങളിൽ ലഭിക്കാത്ത ഒരു വ്യക്തതയും ഇത് നൽകുന്നുണ്ട്. ഒരു ജോലി പൂർത്തിയാക്കുമ്പോൾ, ഞാൻ നിർമ്മിച്ച കാര്യവും അത് ഉപയോഗിച്ച് ജോലി തിരച്ചിൽ എളുപ്പമാക്കുന്ന ഒരു വ്യക്തിയും തമ്മിലുള്ള നേരിട്ടുള്ള ബന്ധം എനിക്ക് കാണാൻ കഴിയും. ആ ഉത്തരവാദിത്തബോധം അപൂർവ്വമാണ്, അത് ഈ തളർച്ചയെ അർത്ഥവത്താക്കുന്നു.
പ്രൊഡക്ഷനിൽ കഴിവുകൾ വേഗത്തിൽ വളരുന്നു
ഈ വേനൽക്കാലത്തിന് മുമ്പ്, എന്റെ ഭൂരിഭാഗം ഊർജ്ജവും പബ്ലിക് സ്പീക്കിംഗിനും ഹാക്കത്തോണുകൾക്കുമാണ് ചെലവഴിച്ചിരുന്നത്. സമ്മർദ്ദഘട്ടങ്ങളിൽ എങ്ങനെ വേഗത്തിൽ ചിന്തിക്കണമെന്നും ആശയങ്ങൾ അവതരിപ്പിക്കണമെന്നും ഇവ രണ്ടും എന്നെ പഠിപ്പിച്ചു. പ്രത്യേകിച്ച് ഹാക്കത്തോണുകൾ, മണിക്കൂറുകൾക്കുള്ളിൽ പ്രവർത്തിക്കുന്ന ഡെമോകൾ തയ്യാറാക്കാൻ നിങ്ങളെ പരിശീലിപ്പിക്കുന്നു. എന്നാൽ വിധികർത്താക്കളെ ആകർഷിക്കുന്ന ഒരു വീക്കെൻഡ് പ്രോജക്റ്റും, നൂറുകണക്കിന് യഥാർത്ഥ ഉപയോക്താക്കൾ ഉപയോഗിക്കുമ്പോൾ നിലനിൽക്കേണ്ട പ്രൊഡക്ഷൻ കോഡും തമ്മിൽ വലിയ വ്യത്യാസമുണ്ട്.
Treevah-ൽ വെബ് ഡെവലപ്മെന്റിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ച് ഒരു മാസം ചെലവഴിച്ചത് ആ വിടവ് നികത്താൻ സഹായിച്ചു. സ്കൂളുകളിൽ പ്രോജക്റ്റുകൾക്ക് കൃത്യമായ പരിധികളുണ്ട്. അവയുടെ വ്യാപ്തി നിശ്ചിതമാണ്, ആവശ്യങ്ങൾ മുൻകൂട്ടി നൽകിയിട്ടുള്ളതാണ്, നിങ്ങളുടെ ഡാറ്റാബേസ് സ്കീമയിൽ എന്തെങ്കിലും തകരാർ സംഭവിച്ചാൽ അത് ഒരു പ്രസന്റേഷൻ സ്ലൈഡിലൂടെ വിശദീകരിക്കാം. എന്നാൽ ഒരു സ്റ്റാർട്ടപ്പിനുള്ളിൽ, നിങ്ങളുടെ സ്കീമ കൃത്യമായിരിക്കണം, കാരണം യഥാർത്ഥ ജോലി അന്വേഷിക്കുന്നവർ അവരുടെ അപേക്ഷാ വിവരങ്ങൾ അതിൽ സൂക്ഷിക്കുന്നു. ഫീഡ്ബാക്ക് വളരെ വേഗത്തിലും കർശനവുമാണ്. ഒരു പേജ് പതുക്കെ ലോഡ് ആവുകയോ ഒരു ഫോം സേവ് ചെയ്യാൻ കഴിയാതിരിക്കുകയോ ചെയ്താൽ, ആർക്കും നിങ്ങളുടെ ഗ്രേഡിനെക്കുറിച്ച് ആശങ്കയില്ല; പകരം അവർക്ക് ഒരു അവസരം നഷ്ടപ്പെട്ടോ എന്നാണ് പ്രധാനം.
ആ സമ്മർദ്ദം വളർച്ചയ്ക്ക് കാരണമാകുന്നു. ഒരു റൂബ്രിക് ആവശ്യപ്പെടുന്നത് കൊണ്ടല്ല, മറിച്ച് പാതിരാത്രിയിൽ അത് ഡീബഗ് ചെയ്യേണ്ടത് നിങ്ങളായിരിക്കും എന്നതുകൊണ്ട് നിങ്ങൾ കൂടുതൽ വൃത്തിയുള്ള കോഡ് എഴുതാൻ പഠിക്കുന്നു. കോഡ് റിവ്യൂ സമയത്ത് കൂടുതൽ കൃത്യമായ ചോദ്യങ്ങൾ ചോദിക്കാൻ നിങ്ങൾ പഠിക്കുന്നു, കാരണം ഒരു തകരാറുള്ള ബിൽഡ് പുറത്തിറക്കുന്നത് യഥാർത്ഥ ഉപയോക്താക്കളെ ബുദ്ധിമുട്ടിക്കും. ഇവിടെയുള്ള അവസരങ്ങൾ സ്കൂൾ പ്രോജക്റ്റുകളേക്കാൾ ശക്തമാണ്. തെറ്റുകൾക്ക് വലിയ വില നൽകേണ്ടി വരുന്നു, അതിനാൽ പാഠങ്ങൾ കൂടുതൽ ആഴത്തിൽ മനസ്സിലാക്കാൻ സാധിക്കുന്നു.
ബഗുകളുടെ വിനീതമാക്കുന്ന യാഥാർത്ഥ്യം
എല്ലാ സോഫ്റ്റ്വെയർ ബഗുകളും വലിയ ലോജിക്കൽ പരാജയങ്ങളാണെന്ന ഒരു തെറ്റായ ധാരണ ഞാൻ തിരുത്താൻ ആഗ്രഹിക്കുന്നു. ചിലത് അങ്ങനെയാകാം, തീർച്ചയായും. എന്നാൽ Treevah-ൽ ഞാൻ കണ്ട പല ബഗുകളും വളരെ നിസ്സാരമായവയായിരുന്നു. അവ കണ്ണെത്താ ദൂരത്ത് ഒളിഞ്ഞിരിക്കുകയും എന്റെ ജീവിതത്തിലെ മണിക്കൂറുകൾ പാഴാക്കുകയും ചെയ്തു.
രണ്ട് രീതിയിലുള്ള പ്രശ്നങ്ങൾ ആവർത്തിച്ചു വന്നു. ആദ്യത്തേത് ഡ്യൂപ്ലിക്കേറ്റ് CSS റൂളുകളാണ്. ഒന്നിലധികം ഡെവലപ്പർമാർ ഒരേ കമ്പോണന്റിൽ ജോലി ചെയ്യുമ്പോൾ സ്റ്റൈൽ ഷീറ്റുകൾ അനാവശ്യമായി കൂടുന്നു. ഒരാൾ ഒരു margin utility class ചേർക്കുമ്പോൾ മറ്റൊരാൾ കമ്പോണന്റ് ഫയലിൽ ഒരു വാല്യൂ നേരിട്ട് നൽകുന്നു. ഇവ രണ്ടും ഒറ്റപ്പെട്ട നിലയിൽ തെറ്റല്ല. എന്നാൽ ഇവ ഒത്തുചേരുമ്പോൾ layout shifts അല്ലെങ്കിൽ specificity wars ഉണ്ടാകുന്നു; ഇത് ഒരു ബട്ടൺ Chrome-ൽ ശരിയായി കാണപ്പെടുമ്പോഴും Safari-യിൽ തകരാറിലായതുപോലെ തോന്നിപ്പിക്കാം. ഇത് കണ്ടെത്താൻ മനോഹരമായ അൽഗോരിതമിക് ലോജിക് വായിക്കുന്നതിന് പകരം browser dev tools ഉപയോഗിച്ച് ഓരോ computed styles-ഉം വരിവരിയായി പരിശോധിക്കേണ്ടി വരുന്നു.
രണ്ടാമത്തേത് എലമെന്റുകളെ അവയുടെ parent divs-ന് പുറത്ത് നിർവചിക്കുന്നതായിരുന്നു. ഒരു modal trigger അല്ലെങ്കിൽ ഒരു dropdown DOM-ൽ തെറ്റായ നോഡിൽ ചേർക്കപ്പെട്ടേക്കാം. സ്ക്രീൻ ഏകദേശം ശരിയായി കാണപ്പെടുന്നു, അതിനാൽ ഘടന ശരിയാണെന്ന് നിങ്ങൾ കരുതുന്നു. എന്നാൽ പെട്ടെന്ന് ഒരു z-index പ്രശ്നമോ അല്ലെങ്കിൽ ഒരു click event തെറ്റായ handler-ലേക്ക് പോകുകയോ ചെയ്താൽ, ഉപയോക്താവിന് അവരുടെ അപേക്ഷാ ഫോമിന് മുകളിൽ വരുന്ന ഒരു popup ഒഴിവാക്കാൻ കഴിയില്ല. ഇവ കമ്പ്യൂട്ടർ സയൻസ് പസിലുകളല്ല. വേഗത്തിൽ ജോലി ചെയ്യുമ്പോൾ സംഭവിക്കുന്ന ഘടനാപരമായ പിഴവുകളാണ് ഇവ.
ഈ ബഗുകളിൽ ചിലത് കണ്ടെത്താൻ ആഴ്ചകൾ എടുത്തു. ഞാൻ കോഡിലേക്ക് നോക്കി നിൽക്കും, ലോജിക് ശരിയാണെന്ന് എന്നെത്തന്നെ വിശ്വസിപ്പിക്കും, എന്നിട്ട് ഒരിടത്തും എത്തിച്ചേരാത്ത വഴിത്താരകളിലൂടെ അലയും. ആ നിരാശ യഥാർത്ഥമാണ്. വ്യക്തമായ എന്തോ ഒന്ന് നിങ്ങൾ കാണാതെ പോകുന്നുണ്ടെന്ന് നിങ്ങൾക്ക് തോന്നും, സത്യത്തിൽ അങ്ങനെ തന്നെയാകാം. എന്നാൽ ഒടുവിൽ ഒരു ഡ്യൂപ്ലിക്കേറ്റ് റൂളോ അല്ലെങ്കിൽ തെറ്റായ രീതിയിൽ ഇട്ട ഒരു ക്ലോസിംഗ് ടാഗോ കണ്ടെത്തുന്നത് നൽകുന്ന സംതൃപ്തി അത്ഭുതപ്പെടുത്തുന്നതാണ്...