೪ ಉತ್ಪನ್ನಗಳನ್ನು ಏಕಾಂಗಿಯಾಗಿ ಬಿಡುಗಡೆ ಮಾಡುವುದು
ನಾನು ಒಂದು ವರ್ಷದಲ್ಲಿ ನಾಲ್ಕು ಉತ್ಪನ್ನಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ.
ಅವುಗಳಲ್ಲಿ spectr-ai, Scry, Argus, ಮತ್ತು Lomi ಸೇರಿವೆ. ಇವು security, Web3, browser extensions, ಮತ್ತು B2B SaaS ಕ್ಷೇತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿವೆ.
ಇವುಗಳನ್ನು ಏಕಾಂಗಿಯಾಗಿ ನಿರ್ಮಿಸುವುದು ಯಾವುದೇ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಕಲಿಸದ ಪಾಠಗಳನ್ನು ನನಗೆ ಕಲಿಸಿತು.
ನಾನು ಕಲಿತ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.
- ಬೇಸರ ತರಿಸುವ ಕೆಲಸಗಳಿಗಾಗಿ ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲವನ್ನು ಮೀಸಲಿಡಿ.
ನಾನು ನನ್ನ ಶಕ್ತಿಯನ್ನು ಕಠಿಣ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳ ಮೇಲೆ ವ್ಯಯಿಸಿದೆ. ನಾನು AI analysis ಮತ್ತು bytecode reconstruction ಮೇಲೆ ಗಮನ ಹರಿಸಿದೆ. ಈ ಭಾಗಗಳು ಕಠಿಣವಾಗಿದ್ದವು ಆದರೆ ಊಹಿಸಬಹುದಾಗಿದ್ದವು.
ನಿಜವಾದ ಸವಾಲುಗಳು ಆಕರ್ಷಕವಲ್ಲದ ಕೆಲಸಗಳಾಗಿದ್ದವು. Chrome Web Store reviews, proxy resolution, ಮತ್ತು deployment setup ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್ಗಳನ್ನು ವಿಫಲಗೊಳಿಸುವ ಹಂತಕ್ಕೆ ತಲುಪಿಸಿದ್ದವು.
ನಿಜವಾದ ಕೆಲಸವು ಹೆಚ್ಚಾಗಿ ಅಂಚಿನಲ್ಲಿರುವ ಇಂಟಿಗ್ರೇಷನ್ (integration) ಕೆಲಸಗಳಾಗಿರುತ್ತವೆ. ನಾನು ಪ್ರತಿ ಬಾರಿಯೂ ಇದಕ್ಕೆ ಕಡಿಮೆ ಸಮಯವನ್ನು ಮೀಸಲಿಟ್ಟಿದ್ದೆ.
- AI ಆರಂಭವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಅಂತ್ಯವನ್ನಲ್ಲ.
ಒಬ್ಬ ವ್ಯಕ್ತಿಯೇ ಕಂಪನಿಯನ್ನು ಕಟ್ಟಲು AI ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ಜನರು ಹೇಳುತ್ತಾರೆ. ಆದರೆ ಸತ್ಯವು ಅದಕ್ಕಿಂತ ವಿಭಿನ್ನವಾಗಿದೆ.
AI ಒಂದು ಫೀಚರ್ನ ಮೊದಲ 80% ಅನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. ಇದು boilerplate ತಯಾರಿಸುತ್ತದೆ ಮತ್ತು tests ಗಳ ಕರಡು ಪ್ರತಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಇದು ಏಕಾಂಗಿ ಕೆಲಸವನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.
AI ಕೊನೆಯ 20% ಅನ್ನು ನಿಭಾಯಿಸುವುದಿಲ್ಲ. ಇದರಲ್ಲಿ edge cases, security reviews, ಮತ್ತು flaky connections ಗಳ debugging ಸೇರಿವೆ. ಆ ಭಾಗವು ಇನ್ನೂ ನಿಧಾನವಾಗಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಗಮನದ ಅಗತ್ಯವಿದೆ.
- ಮರುನಾಮಕರಣ ಮಾಡುವುದು ಪ್ರಗತಿಯ ಸಂಕೇತ.
ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಬೆಳೆದಂತೆ ನಾನು ಹಲವಾರು ಪ್ರಾಜೆಕ್ಟ್ಗಳ ಹೆಸರನ್ನು ಬದಲಾಯಿಸಿದೆ. ಹೆಸರನ್ನು ಬದಲಾಯಿಸುವುದು ಎಂದರೆ ನಾನು ಶ್ರಮವನ್ನು ವ್ಯರ್ಥ ಮಾಡಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ.
ನಾನು ತಪ್ಪಾಗಿದ್ದೆ. ಮರುನಾಮಕರಣ ಎಂದರೆ ನೀವು ಅಂತಿಮವಾಗಿ ಉತ್ಪನ್ನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ. ಕೋಡ್ ಹಾಗೆಯೇ ಇರುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ಸ್ಪಷ್ಟತೆ ಸುಧಾರಿಸುತ್ತದೆ.
- ಮೆರುಗು ನೀಡುವ ಮೊದಲು ಲಾಜಿಕ್ ಮುಖ್ಯ.
ಸುಂದರವಾದ UI ಒಂದು ಬಲೆ. ಕಾರ್ಯಕ್ಷಮತೆ (functionality) ಬದಲಾದರೆ, ನೀವು ವಿನ್ಯಾಸವನ್ನು ಮತ್ತೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ನನ್ನ ನಿಯಮ ಸರಳವಾಗಿದೆ: ಯಾವುದೇ ಸ್ಟೈಲಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಲಾಜಿಕ್ ಮತ್ತು tests ಪೂರ್ಣಗೊಳಿಸಿ. ಒಂದು ಟೆಸ್ಟ್ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿದಾಗ ಮಾತ್ರ ಫೀಚರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳಬಹುದು. ಅದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಅದನ್ನು ಸುಂದರಗೊಳಿಸಲು ಹೋಗಬೇಡಿ.
- ವೈಫಲ್ಯಗಳ ಬಗ್ಗೆ ಬರೆಯಿರಿ.
'Building in public' ಎಂದರೆ ಕೆಟ್ಟ ಭಾಗಗಳನ್ನು ಸಹ ಹಂಚಿಕೊಳ್ಳುವುದು ಎಂದರ್ಥ.
ನಾನು ಹ್ಯಾಕ್ಗಳು, ವಿಫಲವಾದ ವಿಧಾನಗಳು ಮತ್ತು ಬಗ್ಗಳ ಬಗ್ಗೆ ಬರೆದೆನು. ಇದು ಮೌನವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಲಿಸಿತು. ಇದು ನಿಮ್ಮ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವ ಪ್ರೇಕ್ಷಕರನ್ನು ಕೂಡ ರೂಪಿಸಿತು.
ನೀವು ಏಕಾಂಗಿಯಾಗಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ:
• ಕೋರ್ ಫೀಚರ್ ಗಿಂತ ಇಂಟಿಗ್ರೇಷನ್ ಮೇಲೆ ಹೆಚ್ಚು ಸಮಯ ವ್ಯಯಿಸಿ. • ಕಷ್ಟಕರವಲ್ಲದ ಕೆಲಸಗಳಿಗೆ AI ಬಳಸಿ, ಆದರೆ ಕಠಿಣವಾದ 20% ಕೆಲಸವನ್ನು ನೀವೇ ಮಾಡಿ. • UI ಗಿಂತ tests ಗೆ ಆದ್ಯತೆ ನೀಡಿ. • ನಿಮ್ಮ ತಪ್ಪುಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾ ಸಾಗಿ.
ಶಿಪ್ಪಿಂಗ್ (Shipping) ಎಂಬುದು ಒಂದು ಕ್ರಿಯೆ. ಇದು ಕೇವಲ ಒಂದು ಮುಗಿದ ಸ್ಥಿತಿಯಲ್ಲ. ಇದನ್ನು ನಾಲ್ಕು ಬಾರಿ ಮಾಡಿದ್ದು, ಒಂದು ಉತ್ಪನ್ನವನ್ನು ಪರಿಪೂರ್ಣಗೊಳಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಲಿಸಿತು.
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi