4 தயாரிப்புகளைத் தனியாக வெளியிடுதல்

நான் ஓராண்டில் நான்கு தயாரிப்புகளை வெளியிட்டேன்.

அவற்றில் spectr-ai, Scry, Argus மற்றும் Lomi ஆகியவை அடங்கும். இவை பாதுகாப்பு (security), Web3, பிரவுசர் எக்ஸ்டென்ஷன்கள் (browser extensions) மற்றும் B2B SaaS ஆகியவற்றை உள்ளடக்கியவை.

இவற்றைத் தனியாகக் கட்டமைத்தது, எந்தவொரு தனித் திட்டமும் கற்பிக்க முடியாத பாடங்களைக் கற்றுக்கொடுத்தது.

நான் கற்றுக்கொண்டவை இதோ.

  1. சலிப்பூட்டும் பணிகளுக்காகத் திட்டமிடுங்கள்.

நான் எனது ஆற்றலை கடினமான தொழில்நுட்பப் பிரச்சனைகளில் செலவிட்டேன். நான் AI பகுப்பாய்வு மற்றும் bytecode reconstruction ஆகியவற்றில் கவனம் செலுத்தினேன். இந்தப் பகுதிகள் கடினமானவை, ஆனால் கணிக்கக்கூடியவை.

உண்மையான சவால்கள் கவர்ச்சியற்ற பணிகளாக இருந்தன. Chrome Web Store மதிப்பாய்வுகள், proxy resolution மற்றும் deployment setup ஆகியவை எனது திட்டங்களை கிட்டத்தட்ட முடக்கிவிட்டன.

உண்மையான வேலை பெரும்பாலும் ஓரங்களில் இருக்கும் ஒருங்கிணைப்பு (integration) ஆகும். ஒவ்வொரு முறையும் இதற்காக நான் போதிய நேரத்தை ஒதுக்கவில்லை.

  1. AI தொடக்கத்தை எளிதாக்குகிறது, முடிவை அல்ல.

AI ஒரு தனிமனிதரால் ஒரு நிறுவனத்தை உருவாக்க முடியும் என்று மக்கள் சொல்கிறார்கள். உண்மை இன்னும் நுணுக்கமானது.

AI ஒரு அம்சத்தின் (feature) முதல் 80% வேலையைச் செய்கிறது. இது boilerplate-களை உருவாக்குகிறது மற்றும் சோதனைகளை (tests) வரைவு செய்கிறது. இது தனித்து வேலை செய்வதைச் சாத்தியமாக்குகிறது.

AI கடைசி 20% வேலையைச் செய்வதில்லை. இதில் edge cases, பாதுகாப்பு மதிப்பாய்வுகள் மற்றும் நிலையற்ற இணைப்புகளைச் சரிசெய்தல் (debugging flaky connections) ஆகியவை அடங்கும். அந்தப் பகுதி இன்னும் மெதுவானது. அதற்கு இன்னும் உங்கள் முழு கவனமும் தேவைப்படுகிறது.

  1. பெயர் மாற்றம் என்பது முன்னேற்றம்.

திட்டங்கள் வளர வளர நான் பலவற்றிற்குப் பெயர் மாற்றினேன். பெயர் மாற்றம் செய்வது எனது முயற்சியைத் வீணடித்தது என்று நான் முன்பு நினைத்தேன்.

நான் தவறு செய்துவிட்டேன். பெயர் மாற்றம் செய்வது என்பது நீங்கள் இறுதியாக அந்தத் தயாரிப்பைப் புரிந்து கொண்டீர்கள் என்பதைக் குறிக்கிறது. குறியீடு (code) அப்படியே இருக்கும், ஆனால் உங்கள் தெளிவு மேம்படும்.

  1. மெருகூட்டுவதற்கு முன் தர்க்கம் (Logic) முக்கியம்.

அழகான UI ஒரு பொறி. செயல்பாடுகள் (functionality) மாறினால், நீங்கள் வடிவமைப்பை மீண்டும் செய்ய வேண்டியிருக்கும். இது நேரத்தை வீணடிக்கும்.

எனது விதி எளிமையானது: எந்தவொரு ஸ்டைலிங்கிற்கும் (styling) முன் தர்க்கத்தையும் சோதனைகளையும் (logic and tests) முடித்துவிடுங்கள். ஒரு சோதனை அதை நிரூபிக்கும் போது மட்டுமே ஒரு அம்சம் செயல்படுகிறது. அது சரியாகச் செயல்படும் வரை அதை அழகாக மாற்ற வேண்டாம்.

  1. தோல்விகளைப் பற்றி எழுதுங்கள்.

பகிரங்கமாக உருவாக்குவது (Building in public) என்பது மோசமான பகுதிகளைப் பகிர்வதையும் குறிக்கும்.

நான் ஹேக்ஸ் (hacks), தோல்வியடைந்த அணுகுமுறைகள் மற்றும் பிழைகள் (bugs) பற்றி எழுதினேன். இது அமைதியாக வேலை செய்வதை விட எனக்கு அதிகம் கற்றுக்கொடுத்தது. இது உங்கள் செயல்முறையில் அக்கறை கொள்ளும் ஒரு ரசிகர் கூட்டத்தையும் உருவாக்கியது.

நீங்கள் தனியாகக் கட்டமைப்பவர் என்றால், இந்த விதிகளைப் பின்பற்றுங்கள்:

• முக்கிய அம்சத்தை விட ஒருங்கிணைப்பிற்காக (integration) அதிக நேரத்தைச் செலவிடுங்கள். • சாதாரணமான வேலைகளுக்கு AI-ஐப் பயன்படுத்துங்கள், ஆனால் அந்த கடினமான 20% வேலையை நீங்களே செய்யுங்கள். • UI-ஐ விட சோதனைகளுக்கு (tests) முன்னுரிமை கொடுங்கள். • நீங்கள் செய்யும் தவறுகளைப் பகிருங்கள்.

வெளியிடுதல் (Shipping) என்பது ஒரு வினைச்சொல். அது ஒரு முடிவடைந்த நிலை அல்ல. அதை நான்கு முறை செய்தது, ஒரு தயாரிப்பைத் துல்லியமாகச் செய்வதை விட எனக்கு அதிகம் கற்றுக்கொடுத்தது.

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

விருப்பமான கற்றல் சமூகம்: https://t.me/GyaanSetuAi