તમારું કામ માત્ર કોડ લખવાનું નથી. તે નિર્ણયો લેવાનું છે. તમે તેમાંથી શીખો છો. સમય જતાં તમે ભૂલો ઓછી કરો છો. અંતે, તમે અન્ય લોકોને તે જ ધુમ્મસમાંથી માર્ગદર્શન આપો છો. તે વળાંક—લોજિક લખવાથી લઈને પરિણામોની જવાબદારી લેવા સુધીનો—તે વ્યક્તિને અલગ પાડે છે જે માત્ર સિન્ટેક્સ ટાઈપ કરે છે અને જે સિસ્ટમ બનાવે છે.
તમે દરરોજ પસંદગીઓ કરો છો. કેટલીક ક્ષુલ્લક લાગે છે, જેમ કે બટનનો રંગ પસંદ કરવો. અન્ય પસંદગીઓ આખા પ્રોડક્ટને બદલી નાખે છે. યુક્તિ એ છે કે વહેલી તકે ઓળખી લેવું કે આ બંને એકબીજા સાથે જોડાયેલા છે. બેદરકારીથી લેવાયેલો નાનો નિર્ણય પાછળથી મોટો અવરોધ બની શકે છે, જ્યારે વહેલી તકે લેવાયેલો મુશ્કેલ નિર્ણય પાછળથી ઘણીવાર પ્રતિભાશાળી લાગે છે.
વહેલી પસંદગીઓનો પ્રભાવ વિસ્તાર (Blast Radius)
જ્યારે તમે શરૂઆત કરી રહ્યા હોવ, ત્યારે તમારી ભૂલો એક નાના રૂમમાં ગુંજે છે. એક ખરાબ commit સ્થાનિક build ને તોડી નાખે છે. એક અસાવધ function એક સ્ક્રીનને ધીમી પાડે છે. પ્રભાવ વિસ્તાર મર્યાદિત રહે છે. તમે બહુ ઓછા લોકોને અસર કરો છો, અને સુધારો કરવામાં ઓછો ખર્ચ થાય છે.
પરંતુ જેમ તમે આગળ વધો છો, પછી તે વ્યક્તિગત એન્જિનિયર તરીકે હોય કે કંપની તરીકે, તમારા નિર્ણયો વધુ સિસ્ટમોને અસર કરે છે. મોટા પાયે લેવાયેલી એ જ પસંદગી અઠવાડિયાઓનો સમય ખર્ચાવી શકે છે. આથી જ તમારે અત્યારે જ ગણતરીપૂર્વક નિર્ણયો લેતા શીખવું જોઈએ, તે પહેલાં કે તેની કિંમત વધી જાય.
ત્રણ સામાન્ય જાળ (traps) વિશે વિચારો:
એવું પ્લેટફોર્મ વાપરવું જેને તમારા dependencies સપોર્ટ ન કરતા હોય, તેનાથી ડઝનબંધ કે સેંકડો એન્જિનિયરિંગ કલાકો બરબાદ થઈ શકે છે. તે કલાકો માત્ર ટાઈપિંગ માટે નથી. તે વિચિત્ર compatibility સમસ્યાઓનું debugging કરવા, transitive libraries ને patch કરવા અને સ્ટેકહોલ્ડર્સને સમજાવવા માટે છે કે શા માટે એક સાદું ફીચર આખા ક્વાર્ટરનો સમય લઈ ગયું.
પ્રોડક્ટના જીવનના શરૂઆતના તબક્કે session-based authentication થી JWTs પર સ્થાનાંતરિત થવું પાછળથી મોંઘા rewrite ને અટકાવે છે. જ્યારે તમારી પાસે હજારો યુઝર્સ હોય ત્યારે login logic ને refactor કરવું ઘણું સરળ છે, તેના કરતા જ્યારે તમારી પાસે લાખો યુઝર્સ હોય અને downtime ને કારણે વાસ્તવિક નાણાંનું નુકસાન થતું હોય ત્યારે તે મુશ્કેલ છે.
સમયનો અંદાજ તમારી શ્રેષ્ઠ ધારણા કરતા બમણો રાખવો ત્યારે જ કામ લાગે છે જો તમે તે buffer નો ઉપયોગ ગુણવત્તા જાળવવા માટે કરો છો. સોશિયલ મીડિયા સ્ક્રોલ કરવા માટે શેડ્યૂલમાં વધારાનો સમય ઉમેરવો એ બગાડ છે. ટેસ્ટ લખવા, edge cases ની સમીક્ષા કરવા અને observability ચકાસવા માટે સમય ઉમેરવો એ રોકાણ છે.
અહીં પેટર્ન સરળ છે: technical debt વ્યાજ સાથે વધતું જાય છે. જ્યારે મૂળ રકમ નાની હોય ત્યારે જ તેને ચૂકવી દો.
ડેડલાઇન અને નિયંત્રણનો ભ્રમ
ડેડલાઇન બધે જ છે. રિલીઝ તારીખો, ડેમો તારીખો, code freezes. મોટી કંપનીઓમાં તે ઘણીવાર ટેકનિકલ હેતુ કરતાં મનોવૈજ્ઞાનિક હેતુ માટે વધુ કામ કરે છે. તેઓ જટિલતા પર નિયંત્રણનો એવો અહેસાસ કરાવે છે જેને કોઈ સંપૂર્ણ રીતે સમજી શકતું નથી.
તેની આડઅસર અનુમાનિત છે. જેમ જેમ ડેડલાઇન નજીક આવે છે, તેમ ગુણવત્તા ઘટે છે. ટીમો ટેસ્ટ કાઢી નાખે છે, error handling ને comment out કરી દે છે, અને એવો કોડ શિપ કરે છે જેને કોઈ જાળવી રાખવા માંગતું નથી. ડેડલાઇન પૂરી થાય છે. કેલેન્ડર ચોખ્ખું દેખાય છે. પણ પ્રોડક્ટ ખરાબ બને છે.
આવું એટલા માટે થાય છે કારણ કે એન્જિનિયરોને પરફેક્ટ કોડ અને સુંદર આર્કિટેક્ચર ગમે છે. તે આપણી પ્રકૃતિમાં છે. પરંતુ હંમેશા સંપૂર્ણ જવાબ હોતો નથી. સાચી પસંદગી એ છે જે તમારી ટીમની વર્તમાન સ્થિતિને અનુરૂપ હોય. ત્રણ વ્યક્તિવાળા સ્ટાર્ટઅપને નિયમનકારી હેલ્થકેર પ્લેટફોર્મ જેવી જ વિધિઓની જરૂર નથી. તમે અત્યારે જ્યાં છો તે મુજબ નિર્માણ કરો છો, નહીં કે પાંચ વર્ષ પહેલાં હજારો એન્જિનિયરો ધરાવતી સંસ્થા ક્યાં હતી તે મુજબ.
જ્યારે વૃદ્ધિ જૂના નિયમો તોડી નાખે છે
અહીં એક એવી બાબત છે જે નેતૃત્વ (leadership) ઘણીવાર ચૂકી જાય છે. જેમ કંપની વધે છે, તેમ ડેડલાઇન પણ વધવી જોઈએ. પ્રક્રિયાઓ વિસ્તરે છે. નવા લોકો જોડાય છે અને તેમને onboarding ની જરૂર પડે છે. વધુ પ્રોડક્ટ્સ હોવાથી કાર્યો વધતા જાય છે. પાલન (compliance) ની જરૂરિયાતો વધતી જાય છે—આંતરિક સુરક્ષા સમીક્ષા, બાહ્ય ઓડિટ, ડેટા ગવર્નન્સ ચેક. કાર્યક્ષેત્ર વધે છે, પરંતુ અંતિમ લક્ષ્ય (finish line) સ્થિર રહે છે.
વધુ કામ સાથે સમાન ડેડલાઇન રાખવાથી ટીમ ઝડપી બનતી નથી. તેનાથી તેઓ અસાવધ બને છે. કામમાં છૂટછાટ આપવામાં આવે છે. ડોક્યુમેન્ટેશન ગાયબ થઈ જાય છે. ઇન્સિડન્ટ રિસ્પોન્સ માત્ર પ્રતિક્રિયાત્મક (reactive) બની જાય છે. જે એન્જિનિયરો એક સમયે ચોખ્ખો કોડ શિપ કરતા હતા, તેઓ હવે માત્ર કામચલાઉ ઉપાયો (bandages) શિપ કરે છે કારણ કે કેલેન્ડર બદલાવા તૈયાર નથી.
જો કંપની મોટા પાયે ઝડપ ઈચ્છતી હોય, તો તેણે કાં તો કામના સમાંતર ટ્રેક ઉમેરવા જોઈએ અથવા સમયમર્યાદા વધારવી જોઈએ. તમે સતત વધતા જતા બેકલોગને એવા સ્પ્રિન્ટમાં સમાવી શકતા નથી જે ત્રણ નવા કર્મચારીઓની ભરતી પહેલાં પણ ટાઈટ લાગતી હતી.
બફર સાથે નિર્માણ કરવું
એક આદત જે તમને માનસિક રીતે સ્થિર રાખશે: માની લો કે કંઈક ખોટું થશે. આ નિરાશાવાદ નથી. આ વાસ્તવવાદ છે.
સિસ્ટમ્સ નિષ્ફળ જાય છે. થર્ડ-પાર્ટી APIs ધીમા પડે છે. પ્રોડક્ટ મેનેજરે ગઈકાલે ગ્રાહક સાથે વાત કરી હોવાથી જરૂરિયાતો બદલાઈ જાય છે. જ્યારે તમે અવરોધો (friction) માટે આયોજન કરો છો, ત્યારે તમારી ડેડલાઇન પ્રમાણિક રહે છે. તમે ઝડપ અને ગુણવત્તા વચ્ચે પસંદગી કરવાની ક્ષમતા મેળવો છો. તે બફર વગર, દર વખતે તમારા માટે નિર્ણય લેવામાં આવે છે. તમે ઝડપ પસંદ કરવા માટે મજબૂર થાઓ છો, જેનો અર્થ છે કે તમે ગુણવત્તા સાથે સમાધાન કરવા માટે મજબૂર થાઓ છો.
તે બફર એ શીખવા માટેનું સ્થાન પણ છે. જો દરેક કલાક ફીચર વર્ક માટે ફાળવવામાં આવે, તો કોઈ પાસે બિલ્ડ પાઇપલાઇન સુધારવા, ક્વેરી લેયર રિફેક્ટર કરવા અથવા API કોન્ટ્રાક્ટ ડોક્યુમેન્ટ કરવા માટે જગ્યા હોતી નથી. ટીમ તેની વર્તમાન વેલોસિટી પર કાયમ માટે અટકી જશે.
એક ભૂલને બીજી ભૂલથી બદલવી
અમે હાલમાં એક વિચિત્ર વ્યવહાર તરફ દોડી રહ્યા છીએ. અમે માનવીય ભૂલોને નોન-ડિટરમિનિસ્ટિક સોફ્ટવેર ભૂલોથી બદલી રહ્યા છીએ. લાર્જ લેંગ્વેજ મોડલ્સ કોઈપણ જુનિયર એન્જિનિયર કરતા ઝડપથી બોઈલરપ્લેટ જનરેટ કરી શકે છે, ટેસ્ટ સૂચવી શકે છે અને ડોક્યુમેન્ટેશન ડ્રાફ્ટ કરી શકે છે. પરંતુ તેઓ આ કામ આત્મવિશ્વાસ સાથે કરે છે, અને તેઓ એવી રીતે ભૂલ કરે છે જે...