உங்கள் வேலை வெறும் குறியீடுகளை (code) எழுதுவது மட்டுமல்ல. முடிவுகளை எடுப்பதுதான். அவற்றிலிருந்து நீங்கள் கற்றுக்கொள்கிறீர்கள். காலப்போக்கில் நீங்கள் குறைவான தவறுகளையே செய்கிறீர்கள். இறுதியில், அதே குழப்பமான சூழலில் மற்றவர்களுக்கு வழிகாட்டுகிறீர்கள். தர்க்கத்தை (logic) எழுதுவதிலிருந்து அதன் விளைவுகளுக்குப் பொறுப்பேற்பது வரையிலான அந்தப் பயணம் தான், வெறும் குறியீடுகளைத் தட்டச்சு செய்பவருக்கும், அமைப்புகளை (systems) உருவாக்குபவருக்கும் இடையிலான வேறுபாடாகும்.
நீங்கள் ஒவ்வொரு நாளும் முடிவுகளை எடுக்கிறீர்கள். ஒரு பொத்தானின் நிறத்தைத் தேர்ந்தெடுப்பது போன்ற சில முடிவுகள் மிகச் சாதாரணமானதாகத் தோன்றலாம். மற்றவை முழு தயாரிப்பையும் மாற்றியமைக்கும். இந்த இரண்டிற்கும் தொடர்பு இருப்பதை முன்கூட்டியே உணர்வதே இதில் உள்ள ரகசியம். கவனக்குறைவாக எடுக்கப்படும் ஒரு சிறிய முடிவு பின்னாளில் ஒரு பெரிய தடையாக மாறக்கூடும்; அதேசமயம் ஆரம்பத்திலேயே எடுக்கப்படும் ஒரு கடினமான முடிவு, பின்னோக்கிப் பார்க்கும்போது ஒரு புத்திசாலித்தனமான முடிவாகத் தோன்றும்.
ஆரம்பகால முடிவுகளின் பாதிப்பு எல்லை (Blast Radius)
நீங்கள் தொடக்க நிலையில் இருக்கும்போது, உங்கள் தவறுகள் ஒரு சிறிய அறையிலேயே எதிரொலிக்கும். ஒரு தவறான commit ஒரு உள்ளூர் build-ஐப் பாதிக்கும். ஒரு மோசமான function ஒரு திரையை (screen) மெதுவாக்கும். அதன் பாதிப்பு எல்லை மிகச் சிறியதாகவே இருக்கும். நீங்கள் மிகக் குறைந்த நபர்களை மட்டுமே பாதிப்பீர்கள், மேலும் அதைச் சரிசெய்வதற்கான செலவும் குறைவாகவே இருக்கும்.
ஆனால் நீங்கள் ஒரு தனிப்பட்ட பொறியாளராகவோ அல்லது ஒரு நிறுவனமாகவோ வளரும்போது, உங்கள் முடிவுகள் அதிக அமைப்புகளைப் (systems) பாதிக்கும். அதே முடிவு பெரிய அளவில் எடுக்கப்படும்போது வாரக்கணக்கில் நேரத்தை வீணடிக்கும். எனவே, அதன் விலை அதிகமாகும் முன், கணக்கிடப்பட்ட முடிவுகளை எடுக்க நீங்கள் இப்போதே கற்றுக்கொள்ள வேண்டும்.
மூன்று பொதுவான பொறிகளைப் பற்றிச் சிந்தியுங்கள்:
உங்கள் dependencies ஆதரிக்காத ஒரு தளத்தைப் பயன்படுத்துவது டஜன் கணக்கான அல்லது நூற்றுக்கணக்கான பொறியியல் நேரத்தை வீணடிக்கும். அந்த நேரங்கள் வெறும் தட்டச்சு செய்வதற்காக மட்டுமல்ல. விசித்திரமான compatibility சிக்கல்களைத் தீர்ப்பதற்கும் (debugging), transitive libraries-களைச் சரிசெய்வதற்கும் (patching), மற்றும் ஒரு எளிய அம்சம் ஏன் ஒரு முழு காலாண்டைத்took என்று பங்குதாரர்களிடம் (stakeholders) விளக்குவதற்கும் அந்த நேரங்கள் செலவாகும்.
ஒரு தயாரிப்பின் ஆரம்பக் கட்டத்திலேயே session-based authentication-லிருந்து JWT-களுக்கு மாறுவது, பின்னாளில் அதிக செலவு மிகுந்த மறுவேலைகளைத் தவிர்க்க உதவும். ஆயிரக்கணக்கான பயனர்கள் இருக்கும்போது login logic-ஐ மறுசீரமைப்பது (refactor) எளிது; ஆனால் மில்லியன் கணக்கான பயனர்கள் இருக்கும்போது, downtime-ஆல் ஏற்படும் பண இழப்பு மிகப்பெரியது.
உங்கள் சிறந்த கணிப்பை விட இரண்டு மடங்கு நேரத்தைக் கணக்கிடுவது, அந்த கூடுதல் நேரத்தை (buffer) தரத்தைப் பாதுகாக்கப் பயன்படுத்தினால் மட்டுமே பயனுள்ளதாக இருக்கும். சமூக ஊடகங்களைப் பார்ப்பதற்காக கால அட்டவணையை நீட்டிப்பது வீண். ஆனால் சோதனைகளை (tests) எழுதவும், விளிம்புநிலைச் சூழல்களை (edge cases) ஆய்வு செய்யவும், மற்றும் observability-ஐ உறுதிப்படுத்தவும் அந்த நேரத்தைப் பயன்படுத்துவது ஒரு முதலீடு.
இங்கே உள்ள முறை எளிமையானது: தொழில்நுட்பக் கடன் (technical debt) கூட்டு வட்டியாக வளரும். அதன் அசல் சிறியதாக இருக்கும்போதே அதைச் செலுத்திவிடுங்கள்.
காலக்கெடுவும் கட்டுப்பாட்டின் மாயையும்
காலக்கெடு (Deadlines) எல்லா இடங்களிலும் உள்ளன. வெளியீட்டுத் தேதிகள், டெமோ தேதிகள், code freezes. பெரிய நிறுவனங்களில், இவை தொழில்நுட்ப நோக்கத்தை விட உளவியல் ரீதியான நோக்கத்திற்காகவே பெரும்பாலும் பயன்படுத்தப்படுகின்றன. யாருக்கும் முழுமையாகப் புரியாத ஒரு சிக்கலான சூழலின் மீது, ஒரு கட்டுப்பாட்டு உணர்வை இவை உருவாக்குகின்றன.
இதன் பக்கவிளைவு கணிக்கக்கூடியதுதான். காலக்கெடு நெருங்க நெருங்க, தரம் குறைகிறது. குழுக்கள் சோதனைகளை (tests) நீக்குகின்றன, error handling-ஐத் தவிர்க்கின்றன, மற்றும் யாரும் பராமரிக்க விரும்பாத குறியீடுகளை (code) வெளியிடுகின்றன. காலக்கெடு பூர்த்தி செய்யப்படுகிறது. காலண்டர் சுத்தமாகத் தெரிகிறது. ஆனால் தயாரிப்பின் தரம் மோசமடைகிறது.
பொறியாளர்கள் சரியான குறியீட்டையும் (perfect code) நேர்த்தியான கட்டமைப்பையும் (elegant architecture) விரும்புவதால் இது நிகழ்கிறது. இது நமது இயல்பு. ஆனால் ஒரு சரியான விடை எப்போதும் இருப்பதில்லை. உங்கள் குழுவின் தற்போதைய நிலைக்குப் பொருத்தமானதே சரியான முடிவு. மூன்று பேர் கொண்ட ஒரு startup-க்கு, ஒழுங்குமுறைப்படுத்தப்பட்ட ஒரு சுகாதாரத் தளத்திற்கு (healthcare platform) தேவைப்படும் அதே நடைமுறைகள் தேவையில்லை. நீங்கள் இப்போது இருக்கும் நிலைக்கு ஏற்ப உருவாக்க வேண்டும், ஐந்து ஆண்டுகளுக்கு முன்பு ஆயிரம் பேர் கொண்ட ஒரு பொறியியல் நிறுவனம் இருந்த நிலைக்கு ஏற்ப அல்ல.
வளர்ச்சி பழைய விதிகளை உடைக்கும்போது
தலைமைப் பொறுப்பில் இருப்பவர்கள் பெரும்பாலும் கவனிக்கத் தவறும் ஒரு விஷயம் இதுதான். ஒரு நிறுவனம் வளரும்போது, காலக்கெடுவும் வளர வேண்டும். செயல்முறைகள் விரிவடைகின்றன. புதியவர்கள் இணைகிறார்கள், அவர்களுக்குப் பயிற்சி (onboarding) தேவைப்படுகிறது. அதிக தயாரிப்புகள் இருப்பதால் பணிகள் பெருகுகின்றன. உள்நாட்டுப் பாதுகாப்பு ஆய்வுகள், வெளிநாட்டுத் தணிக்கைகள், தரவு நிர்வாகச் சோதனைகள் என இணக்கத் தேவைகள் (compliance requirements) குவிகின்றன. பணிச்சுமை அதிகரிக்கிறது, ஆனால் இலக்கு (finish line) அப்படியே உறைந்து கிடக்கிறது.
அதிக வேலைப்பளுவுடன் அதே காலக்கெடுவைப் பயன்படுத்துவது குழுவை வேகமாகச் செயல்பட வைக்காது. அது அவர்களைத் தரம் தாழ்ந்து செயல்பட வைக்கும். வேலைகளில் குறுக்குவழிகள் எடுக்கப்படும். ஆவணங்கள் (documentation) காணாமல் போகும். விபத்துகளுக்குப் பதிலளிக்கும் முறை (incident response) வெறும் எதிர்வினையாக மட்டுமே இருக்கும். ஒரு காலத்தில் சுத்தமான குறியீடுகளை வெளியிட்ட அதே பொறியாளர்கள், இப்போது காலக்கெடுவை மாற்ற முடியாது என்பதால் தற்காலிகத் தீர்வுகளை (bandages) மட்டுமே வழங்குகிறார்கள்.
ஒரு நிறுவனம் பெரிய அளவில் வேகத்தை விரும்பினால், அது அல்லது பணிகளை இணையான பாதைகளில் (parallel tracks) செய்ய வேண்டும் அல்லது காலக்கெடுவை நீட்டிக்க வேண்டும். தொடர்ந்து வளர்ந்து வரும் பணிகளின் பட்டியலை (backlog), மூன்று புதிய பணியாளர்களைச் சேர்த்தபோது இறுக்கமாக இருந்த ஒரு sprint-க்குள் அடக்க முடியாது.
கூடுதல் நேரத்தை (Buffer) திட்டமிடுதல்
உங்களை நிதானமாக வைத்திருக்க உதவும் ஒரு பழக்கம்: ஏதோ ஒன்று தவறாக நடக்கும் என்று கருதுங்கள். இது எதிர்மறை எண்ணம் அல்ல; இது யதார்த்தம்.
அமைப்புகள் (Systems) தோல்வியடையும். மூன்றாம் தரப்பு APIs தாமதமாகும். ஒரு தயாரிப்பு மேலாளர் நேற்று ஒரு வாடிக்கையாளரிடம் பேசியதால் தேவைகள் மாறக்கூடும். தடைகளை முன்னரே கணக்கிட்டுத் திட்டமிடும்போது, உங்கள் காலக்கெடு உண்மையானதாக இருக்கும். வேகம் மற்றும் தரம் ஆகிய இரண்டிற்கும் இடையே சரியானதைத் தேர்ந்தெடுக்கும் திறனை நீங்கள் பெறுவீர்கள். அந்த கூடுதல் நேரம் (buffer) இல்லையென்றால், ஒவ்வொரு முறையும் உங்களுக்காக ஒரு முடிவு எடுக்கப்படும். நீங்கள் வேகத்தைத் தேர்ந்தெடுக்க வேண்டிய கட்டாயத்திற்குத் தள்ளப்படுவீர்கள், அதாவது தரத்தைத் தியாகம் செய்ய வேண்டிய கட்டாயம் ஏற்படும்.
That buffer is also where learning lives. If every hour is allocated to feature work, no one has space to improve the build pipeline, refactor the query layer, or document the API contract. The team stays stuck at its current velocity forever.
Replacing One Error for Another
We are currently rushing into a strange trade. We are replacing human errors with non-deterministic software errors. Large language models can generate boilerplate, suggest tests, and draft documentation faster than any junior engineer. But they do it with confidence, and they do it wrong in ways that are