ನಿಮ್ಮ ಕೆಲಸ ಕೇವಲ ಕೋಡ್ ಬರೆಯುವುದಲ್ಲ. ಅದು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು. ನೀವು ಅವುಗಳಿಂದ ಕಲಿಯುತ್ತೀರಿ. ಕಾಲಾನಂತರದಲ್ಲಿ ನೀವು ಕಡಿಮೆ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತೀರಿ. ಅಂತಿಮವಾಗಿ, ನೀವು ಇತರರಿಗೆ ಅದೇ ಅಸ್ಪಷ್ಟತೆಯ ನಡುವೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುತ್ತೀರಿ. ತರ್ಕವನ್ನು (logic) ಬರೆಯುವುದರಿಂದ ಫಲಿತಾಂಶಗಳ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊರುವವರೆಗೆ ಇರುವ ಆ ಬೆಳವಣಿಗೆಯ ಹಾದಿಯೇ—ಸರಳವಾಗಿ ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಟೈಪ್ ಮಾಡುವವರಿಂದ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು (systems) ನಿರ್ಮಿಸುವವರನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.

ನೀವು ಪ್ರತಿದಿನ ಆಯ್ಕೆಗಳನ್ನು ಮಾಡುತ್ತೀರಿ. ಬಟನ್ ಬಣ್ಣವನ್ನು ಆರಿಸುವಂತೆ ಕೆಲವು ಆಯ್ಕೆಗಳು ಕ್ಷುಲ್ಲಕವೆನಿಸಬಹುದು. ಇನ್ನು ಕೆಲವು ಇಡೀ ಉತ್ಪನ್ನವನ್ನೇ ಬದಲಾಯಿಸಬಹುದು. ಈ ಎರಡೂ ಒಂದಕ್ಕೊಂದು ಸಂಬಂಧ ಹೊಂದಿವೆ ಎಂಬುದನ್ನು ಮೊದಲೇ ಗುರುತಿಸುವುದೇ ಇಲ್ಲಿನ ಗುಟ್ಟು. ಅಜಾಗರೂಕತೆಯಿಂದ ಮಾಡಿದ ಸಣ್ಣ ನಿರ್ಧಾರವು ನಂತರ ದೊಡ್ಡ ಅಡಚಣೆಯಾಗಬಹುದು, ಆದರೆ ಆರಂಭದಲ್ಲೇ ಮಾಡಿದ ಕಠಿಣ ನಿರ್ಧಾರವು ಹಿಮ್ಮರಳಿದಾಗ ಅದ್ಭುತವಾಗಿ ಕಾಣಿಸಬಹುದು.

ಆರಂಭಿಕ ಆಯ್ಕೆಗಳ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿ (Blast Radius)

ನೀವು ಆರಂಭಿಕ ಹಂತದಲ್ಲಿರುವಾಗ, ನಿಮ್ಮ ತಪ್ಪುಗಳು ಒಂದು ಸಣ್ಣ ಕೋಣೆಯಲ್ಲಿ ಪ್ರತಿಧ್ವನಿಸುತ್ತವೆ. ಒಂದು ಕೆಟ್ಟ commit ಸ್ಥಳೀಯ build ಅನ್ನು ಹಾಳುಮಾಡಬಹುದು. ಒಂದು ಅಸಮರ್ಪಕ function ಒಂದು ಸ್ಕ್ರೀನ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸಬಹುದು. ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿ ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ನೀವು ಕೆಲವೇ ಜನರಿಗೆ ಪ್ರಭಾವ ಬೀರುತ್ತೀರಿ ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ವೆಚ್ಚವೂ ಕಡಿಮೆ ಇರುತ್ತದೆ.

ಆದರೆ ನೀವು ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ಆಗಿ ಅಥವಾ ಕಂಪನಿಯಾಗಿ ಬೆಳೆದಂತೆ, ನಿಮ್ಮ ನಿರ್ಧಾರಗಳು ಹೆಚ್ಚಿನ ಸಿಸ್ಟಮ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಅದೇ ಆಯ್ಕೆಯನ್ನು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ (at scale) ಮಾಡಿದರೆ ವಾರಗಟ್ಟಲೆ ಸಮಯ ವ್ಯರ್ಥವಾಗಬಹುದು. ಆದ್ದರಿಂದ, ಬೆಲೆ ಹೆಚ್ಚಾಗುವ ಮೊದಲೇ ನೀವು ಲೆಕ್ಕಾಚಾರದ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದನ್ನು ಕಲಿಯಬೇಕು.

ಮೂರು ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳನ್ನು ಗಮನಿಸಿ:

  • ನಿಮ್ಮ dependencies ಬೆಂಬಲಿಸದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಡಜನ್‌ಗಟ್ಟಲೆ ಅಥವಾ ನೂರಾರು ಎಂಜಿನಿಯರಿಂಗ್ ಗಂಟೆಗಳು ವ್ಯರ್ಥವಾಗಬಹುದು. ಆ ಗಂಟೆಗಳು ಕೇವಲ ಟೈಪಿಂಗ್ ಮಾಡಲು ಅಲ್ಲ; ಅವು ವಿಚಿತ್ರವಾದ compatibility ಸಮಸ್ಯೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು (debugging), transitive libraries ಗಳನ್ನು ಸರಿಪಡಿಸಲು ಮತ್ತು ಒಂದು ಸರಳ ಫೀಚರ್‌ಗೆ ಇಡೀ ತ್ರೈಮಾಸಿಕವೇ ಏಕೆ ಬೇಕಾಯಿತು ಎಂದು ಸ್ಟೇಕ್‌ಹೋಲ್ಡರ್‌ಗಳಿಗೆ (stakeholders) ವಿವರಿಸಲು ವ್ಯಯವಾಗುತ್ತವೆ.

  • ಉತ್ಪನ್ನದ ಆರಂಭಿಕ ಹಂತದಲ್ಲೇ session-based authentication ನಿಂದ JWTs ಗೆ ಬದಲಾಗುವುದು ನಂತರದ ದುಬಾರಿ ಮರು-ಬರವಣಿಗೆಯನ್ನು (rewrite) ತಪ್ಪಿಸುತ್ತದೆ. ಲಕ್ಷಾಂತರ ಬಳಕೆದಾರರು ಇದ್ದಾಗ ಮತ್ತು downtime ನಿಂದ ಹಣದ ನಷ್ಟವಾಗುವಾಗ ಬದಲಾಯಿಸುವುದಕ್ಕಿಂತ, ಸಾವಿರಾರು ಬಳಕೆದಾರರು ಇರುವಾಗ login logic ಅನ್ನು refactor ಮಾಡುವುದು ತುಂಬಾ ಸುಲಭ.

  • ನಿಮ್ಮ ಅಂದಾಜಿನ ಎರಡರಷ್ಟು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಕೇವಲ ಗುಣಮಟ್ಟವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಆ buffer ಅನ್ನು ಬಳಸಿದರೆ ಮಾತ್ರ ಸರಿಹೊಂದುತ್ತದೆ. ಸೋಶಿಯಲ್ ಮೀಡಿಯಾ ನೋಡಲು ಸಮಯ ಉಳಿಸಿಕೊಳ್ಳಲು ವೇಳಾಪಟ್ಟಿಯನ್ನು ವಿಸ್ತರಿಸುವುದು ವ್ಯರ್ಥ. ಆದರೆ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು, edge cases ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು observability ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಮಯವನ್ನು ಮೀಸಲಿಡುವುದು ಒಂದು ಹೂಡಿಕೆ.

ಇಲ್ಲಿನ ಮಾದರಿ ಸರಳವಾಗಿದೆ: technical debt ಕ್ರಮೇಣ ಹೆಚ್ಚುತ್ತಾ ಹೋಗುತ್ತದೆ. ಅದರ ಮೂಲ ಮೊತ್ತವು (principal) ಕಡಿಮೆಯಿರುವಾಗಲೇ ಅದನ್ನು ಪಾವತಿಸಿ ಮುಗಿಸಿ.

ಕೊನೆಯ ದಿನಾಂಕಗಳು ಮತ್ತು ನಿಯಂತ್ರಣದ ಭ್ರಮೆ

ডেಡ್‌ಲೈನ್‌ಗಳು (Deadlines) ಎಲ್ಲೆಡೆ ಇವೆ. ರಿಲೀಸ್ ದಿನಾಂಕಗಳು, ಡೆಮೋ ದಿನಾಂಕಗಳು, ಕೋಡ್ ಫ್ರೀಜ್‌ಗಳು (code freezes). ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ ಇವು ತಾಂತ್ರಿಕ ಉದ್ದೇಶಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಮಾನಸಿಕ ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಕೆಯಾಗುತ್ತವೆ. ಯಾರೂ ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಾಗದ ಸಂಕೀರ್ಣತೆಯ ಮೇಲೆ ನಿಯಂತ್ರಣವಿದೆ ಎಂಬ ಭಾವನೆಯನ್ನು ಇವು ಸೃಷ್ಟಿಸುತ್ತವೆ.

ಇದರ ಪರಿಣಾಮವನ್ನು ಮೊದಲೇ ಊಹಿಸಬಹುದು. ಕೊನೆಯ ದಿನಾಂಕ ಹತ್ತಿಬರುವಂತೆ, ಗುಣಮಟ್ಟ ಕುಸಿಯುತ್ತದೆ. ತಂಡಗಳು ಟೆಸ್ಟ್‌ಗಳನ್ನು ಕೈಬಿಡುತ್ತವೆ, error handling ಅನ್ನು ಕಮೆಂಟ್ ಮಾಡಿ ಬದಿಗಿಡುತ್ತವೆ ಮತ್ತು ಯಾರೂ ನಿರ್ವಹಿಸಲು ಇಷ್ಟಪಡದ ಕೋಡ್ ಅನ್ನು ರಿಲೀಸ್ ಮಾಡುತ್ತವೆ. ಆಗ ডেಡ್‌ಲೈನ್ ಪಾಲನೆಯಾಗುತ್ತದೆ, ಕ್ಯಾಲೆಂಡರ್ ಸುಂದರವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟ ಕೆಟ್ಟದಾಗುತ್ತದೆ.

ಎಂಜಿನಿಯರ್‌ಗಳು ಪರಿಪೂರ್ಣ ಕೋಡ್ ಮತ್ತು ಸುಂದರವಾದ architecture ಅನ್ನು ಇಷ್ಟಪಡುತ್ತಾರೆ, ಹಾಗಾಗಿ ಹೀಗಾಗುತ್ತದೆ. ಇದು ನಮ್ಮ ಸ್ವಭಾವ. ಆದರೆ ಪರಿಪೂರ್ಣವಾದ ಉತ್ತರ ಯಾವಾಗಲೂ ಇರುವುದಿಲ್ಲ. ನಿಮ್ಮ ತಂಡದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ನಿರ್ಧಾರವೇ ಸರಿಯಾದ ನಿರ್ಧಾರ. ಮೂರು ಜನರ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗೆ ನಿಯಮಬದ್ಧ ಆರೋಗ್ಯ ರಕ್ಷಣಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಷ್ಟೇ ಸಂಕೀರ್ಣ ಪ್ರಕ್ರಿಯೆಗಳ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಈಗ ಎಲ್ಲಿ ಇದ್ದೀರೋ ಅಲ್ಲಿಗೆ ತಕ್ಕಂತೆ ನಿರ್ಮಿಸಿ, ಐದು ವರ್ಷಗಳ ಹಿಂದೆ ಸಾವಿರಾರು ಜನರ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಥೆ ಎಲ್ಲಿ ಇತ್ತೋ ಅಲ್ಲಿಗೆ ನಿರ್ಮಿಸಬೇಡಿ.

ಬೆಳವಣಿಗೆಯು ಹಳೆಯ ನಿಯಮಗಳನ್ನು ಮುರಿಯುವಾಗ

ನಾಯಕತ್ವವು (leadership) ಗಮನಿಸದ ಒಂದು ವಿಷಯ ಇಲ್ಲಿದೆ. ಕಂಪನಿಯು ಬೆಳೆದಂತೆ, ডেಡ್‌ಲೈನ್‌ಗಳು ಕೂಡ ಬೆಳೆಯಬೇಕು. ಪ್ರಕ್ರಿಯೆಗಳು ವಿಸ್ತರಿಸುತ್ತವೆ. ಹೊಸಬರು ಸೇರುತ್ತಾರೆ ಮತ್ತು ಅವರಿಗೆ onboarding ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ಉತ್ಪನ್ನಗಳು ಇರುವುದರಿಂದ ಕೆಲಸಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ. ಇಂಟರ್ನಲ್ ಸೆಕ್ಯೂರಿಟಿ ರಿವ್ಯೂಗಳು, ಎಕ್ಸ್‌ಟರ್ನಲ್ ಆಡಿಟ್‌ಗಳು, ಡೇಟಾ ಗವರ್ನೆನ್ಸ್ ಚೆಕ್‌ಗಳಂತಹ ಅನುಸರಣಾ ಅಗತ್ಯತೆಗಳು (compliance requirements) ಹೆಚ್ಚಾಗುತ್ತವೆ. ಕೆಲಸದ ವ್ಯಾಪ್ತಿ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಆದರೆ ಗುರಿ (finish line) ಮಾತ್ರ ಬದಲಾಗದೆ ಹಾಗೆಯೇ ಇರುತ್ತದೆ.

ಹೆಚ್ಚಿನ ಕೆಲಸದೊಂದಿಗೆ ಅದೇ ಹಳೆಯ ডেಡ್‌ಲೈನ್‌ಗಳನ್ನು ಬಳಸುವುದರಿಂದ ತಂಡವು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ ಅವರು ಅಜಾಗರೂಕರಾಗುತ್ತಾರೆ. ಕೆಲಸದಲ್ಲಿ ಅಡ್ಡಗಾಲುಗಳನ್ನು (corners) ಎಳೆಯಲಾಗುತ್ತದೆ, ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಇನ್ಸಿಡೆಂಟ್ ರೆಸ್ಪಾನ್ಸ್ (incident response) ಕೇವಲ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕವಾಗುತ್ತದೆ. ಒಮ್ಮೆ ಸ್ವಚ್ಛವಾದ ಕೋಡ್ ನೀಡುತ್ತಿದ್ದ ಎಂಜಿನಿಯರ್‌ಗಳು, ಈಗ ಕೇವಲ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರಗಳನ್ನು (bandages) ನೀಡುತ್ತಿದ್ದಾರೆ, ಏಕೆಂದರೆ ಕಾಲಮಿತಿ ಬದಲಾಗಲು ಒಪ್ಪುತ್ತಿಲ್ಲ.

ಒಂದು ಕಂಪನಿಯು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ವೇಗವನ್ನು ಬಯಸಿದರೆ, ಅದು ಕೆಲಸದ ಸಮಾನಾಂತರ ಹಾದಿಗಳನ್ನು (parallel tracks) ಸೇರಿಸಬೇಕು ಅಥವಾ ಸಮಯದ ಮಿತಿಯನ್ನು ವಿಸ್ತರಿಸಬೇಕು. ಬೆಳೆಯುತ್ತಿರುವ backlog ಅನ್ನು ಮೂರು ಜನ ಹೊಸ ಉದ್ಯೋಗಿಗಳು ಸೇರಿದಾಗ ಕಷ್ಟವೆನಿಸಿದ ಅದೇ ಸಣ್ಣ sprint ಗೆ ಅಡಕ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಬಫರ್ ಅನ್ನು ಒಳಗೊಂಡ ನಿರ್ಮಾಣ (Building in the Buffer)

ನಿಮ್ಮ ಮಾನಸಿಕ ಸ್ಥಿತಿಯನ್ನು ಸಮತೋಲನದಲ್ಲಿಡಲು ಒಂದು ಅಭ್ಯಾಸ: ಏನಾದರೂ ತಪ್ಪಾಗಬಹುದು ಎಂದು ಭಾವಿಸಿ. ಇದು ನಕಾರಾತ್ಮಕತೆಯಲ್ಲ (pessimism), ಇದು ವಾಸ್ತವಿಕತೆ (realism).

ಸಿಸ್ಟಮ್‌ಗಳು ವಿಫಲವಾಗುತ್ತವೆ. Third-party APIs ವಿಳಂಬವಾಗುತ್ತವೆ. ಉತ್ಪನ್ನ ವ್ಯವಸ್ಥಾಪಕರು (product manager) ನಿನ್ನೆ ಗ್ರಾಹಕರೊಂದಿಗೆ ಮಾತನಾಡಿದ್ದರಿಂದ ಅಗತ್ಯತೆಗಳು ಬದಲಾಗಬಹುದು. ನೀವು ಅಡೆತಡೆಗಳಿಗಾಗಿ (friction) ಯೋಜಿಸಿದಾಗ, ನಿಮ್ಮ ডেಡ್‌ಲೈನ್‌ಗಳು ಪ್ರಾಮಾಣಿಕವಾಗಿರುತ್ತವೆ. ಆಗ ನೀವು ವೇಗ ಮತ್ತು ಗುಣಮಟ್ಟದ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಆ 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