ಅವರು ಹೇಳಿದಂತೆ, ನಿಮ್ಮ ಹಳೆಯ ಕೋಡ್ ಬಗ್ಗೆ ನೀವು ನಾಚಿಕೆಪಡದಿದ್ದರೆ, ನೀವು ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ ಬೆಳೆಯುತ್ತಿಲ್ಲ - ಮತ್ತು ನಾನು ಈ ಅಭಿಪ್ರಾಯವನ್ನು ಒಪ್ಪುತ್ತೇನೆ. ನಾನು 40 ವರ್ಷಗಳ ಹಿಂದೆ ವಿನೋದಕ್ಕಾಗಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ ಮತ್ತು ವೃತ್ತಿಪರವಾಗಿ 30 ವರ್ಷಗಳ ಹಿಂದೆ, ಆದ್ದರಿಂದ ನಾನು ಬಹಳಷ್ಟು ತಪ್ಪುಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಬಹಳಷ್ಟು. ಕಂಪ್ಯೂಟರ್ ಸೈನ್ಸ್ ಪ್ರೊಫೆಸರ್ ಆಗಿ, ನಾನು ನನ್ನ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ತಪ್ಪುಗಳಿಂದ ಕಲಿಯಲು ಕಲಿಸುತ್ತೇನೆ-ಅವರ, ನನ್ನ ಮತ್ತು ಇತರರಿಂದ. ನನ್ನ ನಮ್ರತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳದಂತೆ ನನ್ನ ತಪ್ಪುಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಇದು ಸಮಯ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಅವರು ಯಾರಿಗಾದರೂ ಉಪಯುಕ್ತವಾಗುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಮೂರನೇ ಸ್ಥಾನ - ಮೈಕ್ರೋಸಾಫ್ಟ್ ಸಿ ಕಂಪೈಲರ್

ರೋಮಿಯೋ ಮತ್ತು ಜೂಲಿಯೆಟ್ ಅನ್ನು ದುರಂತವೆಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನನ್ನ ಶಾಲಾ ಶಿಕ್ಷಕರು ನಂಬಿದ್ದರು ಏಕೆಂದರೆ ಪಾತ್ರಗಳು ಯಾವುದೇ ದುರಂತ ಅಪರಾಧವನ್ನು ಹೊಂದಿಲ್ಲ - ಅವರು ಹದಿಹರೆಯದವರಂತೆ ಮೂರ್ಖತನದಿಂದ ವರ್ತಿಸಿದರು. ಆಗ ನಾನು ಅವನೊಂದಿಗೆ ಒಪ್ಪಲಿಲ್ಲ, ಆದರೆ ಈಗ ನಾನು ಅವರ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ತರ್ಕಬದ್ಧತೆಯ ಧಾನ್ಯವನ್ನು ನೋಡುತ್ತೇನೆ.

ನಾನು ಎಂಐಟಿಯಲ್ಲಿ ನನ್ನ ಎರಡನೆಯ ವರ್ಷವನ್ನು ಮುಗಿಸುವ ಹೊತ್ತಿಗೆ, ಜೀವನದಲ್ಲಿ ಮತ್ತು ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ನಾನು ಚಿಕ್ಕವನಾಗಿದ್ದೆ ಮತ್ತು ಅನನುಭವಿಯಾಗಿದ್ದೆ. ಬೇಸಿಗೆಯಲ್ಲಿ, ನಾನು C ಕಂಪೈಲರ್ ತಂಡದಲ್ಲಿ ಮೈಕ್ರೋಸಾಫ್ಟ್‌ನಲ್ಲಿ ತರಬೇತಿ ಪಡೆದಿದ್ದೇನೆ. ಮೊದಲಿಗೆ, ನಾನು ಪ್ರೊಫೈಲಿಂಗ್ ಬೆಂಬಲದಂತಹ ದಿನನಿತ್ಯದ ಕೆಲಸಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ನಂತರ ಕಂಪೈಲರ್‌ನ ಅತ್ಯಂತ ಮೋಜಿನ (ನಾನು ಭಾವಿಸಿದಂತೆ) ಭಾಗವಾದ ಬ್ಯಾಕೆಂಡ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನನಗೆ ವಹಿಸಲಾಯಿತು. ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಾನು ಶಾಖೆಯ ಹೇಳಿಕೆಗಳಿಗಾಗಿ x86 ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸಬೇಕಾಗಿತ್ತು.

ಪ್ರತಿಯೊಂದು ಸಂಭವನೀಯ ಪ್ರಕರಣಕ್ಕೂ ಸೂಕ್ತವಾದ ಯಂತ್ರದ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ನಿರ್ಧರಿಸಿ, ನಾನು ಪೂಲ್ ಅನ್ನು ತಲೆಕೆಳಗಾಗಿ ಎಸೆದಿದ್ದೇನೆ. ಮೌಲ್ಯಗಳ ವಿತರಣಾ ಸಾಂದ್ರತೆಯು ಅಧಿಕವಾಗಿದ್ದರೆ, ನಾನು ಅವುಗಳನ್ನು ನಮೂದಿಸಿದೆ ಪರಿವರ್ತನೆ ಕೋಷ್ಟಕ. ಅವರು ಸಾಮಾನ್ಯ ವಿಭಾಜಕವನ್ನು ಹೊಂದಿದ್ದರೆ, ಟೇಬಲ್ ಅನ್ನು ಬಿಗಿಯಾಗಿ ಮಾಡಲು ನಾನು ಅದನ್ನು ಬಳಸಿದ್ದೇನೆ (ಆದರೆ ವಿಭಾಗವನ್ನು ಬಳಸಿಕೊಂಡು ಮಾಡಬಹುದಾದರೆ ಮಾತ್ರ ಬಿಟ್ ಶಿಫ್ಟ್) ಎಲ್ಲಾ ಮೌಲ್ಯಗಳು ಎರಡು ಶಕ್ತಿಗಳಾಗಿದ್ದಾಗ, ನಾನು ಮತ್ತೊಂದು ಆಪ್ಟಿಮೈಸೇಶನ್ ಮಾಡಿದೆ. ಮೌಲ್ಯಗಳ ಒಂದು ಸೆಟ್ ನನ್ನ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸದಿದ್ದರೆ, ನಾನು ಅದನ್ನು ಹಲವಾರು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬಹುದಾದ ಪ್ರಕರಣಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇನೆ ಮತ್ತು ಈಗಾಗಲೇ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಕೋಡ್ ಅನ್ನು ಬಳಸಿದ್ದೇನೆ.

ಅದೊಂದು ದುಃಸ್ವಪ್ನವಾಗಿತ್ತು. ಹಲವು ವರ್ಷಗಳ ನಂತರ ನನ್ನ ಕೋಡ್ ಅನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದ ಪ್ರೋಗ್ರಾಮರ್ ನನ್ನನ್ನು ದ್ವೇಷಿಸುತ್ತಿದ್ದನೆಂದು ನನಗೆ ಹೇಳಲಾಯಿತು.

ಪಾಠ ಕಲಿತೆ

ಡೇವಿಡ್ ಪ್ಯಾಟರ್ಸನ್ ಮತ್ತು ಜಾನ್ ಹೆನ್ನೆಸ್ಸಿ ಕಂಪ್ಯೂಟರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಕಂಪ್ಯೂಟರ್ ಸಿಸ್ಟಮ್ಸ್ ಡಿಸೈನ್‌ನಲ್ಲಿ ಬರೆಯುವಂತೆ, ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಡಿಸೈನ್‌ನ ಮುಖ್ಯ ತತ್ವವೆಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದು.

ಅಪರೂಪದ ಪ್ರಕರಣಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದಕ್ಕಿಂತ ಸಾಮಾನ್ಯ ಪ್ರಕರಣಗಳನ್ನು ವೇಗಗೊಳಿಸುವುದು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ. ವಿಪರ್ಯಾಸವೆಂದರೆ, ಸಾಮಾನ್ಯ ಪ್ರಕರಣಗಳು ಅಪರೂಪದ ಪ್ರಕರಣಗಳಿಗಿಂತ ಸರಳವಾಗಿರುತ್ತವೆ. ಈ ತಾರ್ಕಿಕ ಸಲಹೆಯು ಯಾವ ಪ್ರಕರಣವನ್ನು ಸಾಮಾನ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ - ಮತ್ತು ಇದು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರೀಕ್ಷೆ ಮತ್ತು ಅಳತೆಯ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಮಾತ್ರ ಸಾಧ್ಯ.

ನನ್ನ ರಕ್ಷಣೆಯಲ್ಲಿ, ನಾನು ಶಾಖೆಯ ಹೇಳಿಕೆಗಳು ಆಚರಣೆಯಲ್ಲಿ ಹೇಗಿವೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ (ಉದಾಹರಣೆಗೆ ಎಷ್ಟು ಶಾಖೆಗಳಿವೆ ಮತ್ತು ಹೇಗೆ ಸ್ಥಿರಾಂಕಗಳನ್ನು ವಿತರಿಸಲಾಗಿದೆ), ಆದರೆ 1988 ರಲ್ಲಿ ಈ ಮಾಹಿತಿಯು ಲಭ್ಯವಿರಲಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಾನು ಮಂಡಿಸಿದ ಕೃತಕ ಉದಾಹರಣೆಗಾಗಿ ಪ್ರಸ್ತುತ ಕಂಪೈಲರ್ ಸೂಕ್ತ ಕೋಡ್ ಅನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ನಾನು ವಿಶೇಷ ಸಂದರ್ಭಗಳನ್ನು ಸೇರಿಸಬಾರದು.

ನಾನು ಅನುಭವಿ ಡೆವಲಪರ್‌ಗೆ ಕರೆ ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅವನೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಪ್ರಕರಣಗಳು ಏನೆಂದು ಯೋಚಿಸಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ವ್ಯವಹರಿಸಬೇಕು. ನಾನು ಕಡಿಮೆ ಕೋಡ್ ಬರೆಯುತ್ತೇನೆ, ಆದರೆ ಅದು ಒಳ್ಳೆಯದು. ಸ್ಟಾಕ್ ಓವರ್‌ಫ್ಲೋ ಸಂಸ್ಥಾಪಕ ಜೆಫ್ ಅಟ್‌ವುಡ್ ಬರೆದಂತೆ, ಪ್ರೋಗ್ರಾಮರ್‌ನ ಕೆಟ್ಟ ಶತ್ರು ಪ್ರೋಗ್ರಾಮರ್ ಸ್ವತಃ:

ನಾವೆಲ್ಲರೂ ಮಾಡುವಂತೆ ನೀವು ಉತ್ತಮ ಉದ್ದೇಶಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ನಾವು ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ಕೋಡ್ ಬರೆಯಲು ಇಷ್ಟಪಡುತ್ತೇವೆ. ನಾವು ಹೇಗೆ ಮಾಡಲ್ಪಟ್ಟಿದ್ದೇವೆ. ಡಕ್ಟ್ ಟೇಪ್, ಮನೆಯಲ್ಲಿ ತಯಾರಿಸಿದ ಊರುಗೋಲು ಮತ್ತು ಪಿಂಚ್ ಕೋಡ್‌ನಿಂದ ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದು ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಕೋಡರ್‌ಗಳು ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು ಎಷ್ಟು ನೋವುಂಟುಮಾಡುತ್ತಾರೆ, ಉತ್ತಮ ಕೋಡ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕೋಡ್ ಆಗಿದೆ. ಪ್ರತಿ ಹೊಸ ಸಾಲಿಗೆ ಡೀಬಗ್ ಮಾಡುವಿಕೆ ಮತ್ತು ಬೆಂಬಲದ ಅಗತ್ಯವಿದೆ, ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನೀವು ಹೊಸ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ನೀವು ಇಷ್ಟವಿಲ್ಲದೆ ಮತ್ತು ಅಸಹ್ಯದಿಂದ ಹಾಗೆ ಮಾಡಬೇಕು ಏಕೆಂದರೆ ಎಲ್ಲಾ ಇತರ ಆಯ್ಕೆಗಳು ಖಾಲಿಯಾಗಿವೆ. ಅನೇಕ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ, ಅದನ್ನು ನಮ್ಮ ಶತ್ರುವನ್ನಾಗಿ ಮಾಡುತ್ತಾರೆ.

ಸಾಮಾನ್ಯ ಪ್ರಕರಣಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸರಳವಾದ ಕೋಡ್ ಅನ್ನು ನಾನು ಬರೆದಿದ್ದರೆ, ಅಗತ್ಯವಿದ್ದರೆ ನವೀಕರಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಯಾರೂ ನಿಭಾಯಿಸಲು ಬಯಸದ ಅವ್ಯವಸ್ಥೆಯನ್ನು ನಾನು ಬಿಟ್ಟುಬಿಟ್ಟೆ.

ಎರಡನೇ ಸ್ಥಾನ: ಸಾಮಾಜಿಕ ಜಾಲತಾಣಗಳಲ್ಲಿ ಜಾಹೀರಾತು

ನಾನು ಸಾಮಾಜಿಕ ಮಾಧ್ಯಮ ಜಾಹೀರಾತಿನಲ್ಲಿ Google ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾಗ (ಮೈಸ್ಪೇಸ್ ನೆನಪಿದೆಯೇ?), ನಾನು C++ ನಲ್ಲಿ ಈ ರೀತಿ ಬರೆದಿದ್ದೇನೆ:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

ಪ್ರೋಗ್ರಾಮರ್ಗಳು ತಕ್ಷಣವೇ ದೋಷವನ್ನು ನೋಡಬಹುದು: ಕೊನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ j ಆಗಿರಬೇಕು, i ಅಲ್ಲ. ಘಟಕ ಪರೀಕ್ಷೆಯು ದೋಷವನ್ನು ಬಹಿರಂಗಪಡಿಸಲಿಲ್ಲ ಮತ್ತು ನನ್ನ ವಿಮರ್ಶಕನೂ ಮಾಡಲಿಲ್ಲ. ಉಡಾವಣೆ ನಡೆಸಲಾಯಿತು, ಮತ್ತು ಒಂದು ರಾತ್ರಿ ನನ್ನ ಕೋಡ್ ಸರ್ವರ್‌ಗೆ ಹೋಯಿತು ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಪ್ಯೂಟರ್‌ಗಳನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಿದೆ.

ಕೆಟ್ಟದ್ದೇನೂ ಆಗಲಿಲ್ಲ. ಯಾರಿಗೂ ಏನೂ ಮುರಿಯಲಿಲ್ಲ, ಏಕೆಂದರೆ ಜಾಗತಿಕ ಉಡಾವಣೆಯ ಮೊದಲು ಕೋಡ್ ಅನ್ನು ಒಂದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಯಿತು. SRE ಇಂಜಿನಿಯರ್‌ಗಳು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಬಿಲಿಯರ್ಡ್ಸ್ ಆಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಸ್ವಲ್ಪ ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡದ ಹೊರತು. ಮರುದಿನ ಬೆಳಿಗ್ಗೆ ನಾನು ಕ್ರ್ಯಾಶ್ ಡಂಪ್‌ನೊಂದಿಗೆ ಇಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ, ಕೋಡ್ ಅನ್ನು ಸರಿಪಡಿಸಿದೆ ಮತ್ತು ದೋಷವನ್ನು ಹಿಡಿಯುವ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಸೇರಿಸಿದೆ. ನಾನು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅನುಸರಿಸಿದ್ದರಿಂದ - ಇಲ್ಲದಿದ್ದರೆ ನನ್ನ ಕೋಡ್ ಚಲಾಯಿಸಲು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ - ಬೇರೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ.

ಪಾಠ ಕಲಿತೆ

ಅಂತಹ ಪ್ರಮುಖ ತಪ್ಪು ಖಂಡಿತವಾಗಿಯೂ ಅಪರಾಧಿಯನ್ನು ವಜಾಗೊಳಿಸುವುದನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ ಎಂದು ಹಲವರು ಖಚಿತವಾಗಿ ನಂಬುತ್ತಾರೆ, ಆದರೆ ಇದು ಹಾಗಲ್ಲ: ಮೊದಲನೆಯದಾಗಿ, ಎಲ್ಲಾ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಅವರು ಅಪರೂಪವಾಗಿ ಎರಡು ಬಾರಿ ಅದೇ ತಪ್ಪನ್ನು ಮಾಡುತ್ತಾರೆ.

ವಾಸ್ತವವಾಗಿ, ನಾನು ಒಬ್ಬ ಅದ್ಭುತ ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದ ಒಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್ ಸ್ನೇಹಿತನನ್ನು ಹೊಂದಿದ್ದೇನೆ ಮತ್ತು ಒಂದೇ ಒಂದು ತಪ್ಪು ಮಾಡಿದ ಕಾರಣದಿಂದ ವಜಾ ಮಾಡಲಾಯಿತು. ಅದರ ನಂತರ, ಅವರನ್ನು Google ನಲ್ಲಿ ನೇಮಿಸಲಾಯಿತು (ಮತ್ತು ಶೀಘ್ರದಲ್ಲೇ ಬಡ್ತಿ) - ಅವರು ಸಂದರ್ಶನದಲ್ಲಿ ಮಾಡಿದ ತಪ್ಪಿನ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮಾತನಾಡಿದರು ಮತ್ತು ಅದನ್ನು ಮಾರಣಾಂತಿಕವೆಂದು ಪರಿಗಣಿಸಲಾಗಿಲ್ಲ.

ಅದು ಏನು ಹೇಳು IBM ನ ಪೌರಾಣಿಕ ಮುಖ್ಯಸ್ಥ ಥಾಮಸ್ ವ್ಯಾಟ್ಸನ್ ಬಗ್ಗೆ:

ಸುಮಾರು ಒಂದು ಮಿಲಿಯನ್ ಡಾಲರ್ ಮೌಲ್ಯದ ಸರ್ಕಾರಿ ಆದೇಶವನ್ನು ಪ್ರಕಟಿಸಲಾಯಿತು. IBM ಕಾರ್ಪೊರೇಷನ್ - ಅಥವಾ ಬದಲಿಗೆ, ಥಾಮಸ್ ವ್ಯಾಟ್ಸನ್ ಸೀನಿಯರ್ ವೈಯಕ್ತಿಕವಾಗಿ - ನಿಜವಾಗಿಯೂ ಅದನ್ನು ಪಡೆಯಲು ಬಯಸಿದ್ದರು. ದುರದೃಷ್ಟವಶಾತ್, ಮಾರಾಟ ಪ್ರತಿನಿಧಿಯು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು IBM ಬಿಡ್ ಅನ್ನು ಕಳೆದುಕೊಂಡಿತು. ಮರುದಿನ, ಈ ಉದ್ಯೋಗಿ ಶ್ರೀ. ವ್ಯಾಟ್ಸನ್ ಅವರ ಕಚೇರಿಗೆ ಬಂದು ಅವರ ಮೇಜಿನ ಮೇಲೆ ಲಕೋಟೆಯನ್ನು ಇರಿಸಿದರು. ಶ್ರೀ ವ್ಯಾಟ್ಸನ್ ಅದನ್ನು ನೋಡುವ ಮನಸ್ಸಿಲ್ಲ - ಅವರು ಉದ್ಯೋಗಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದರು ಮತ್ತು ಅದು ರಾಜೀನಾಮೆ ಪತ್ರ ಎಂದು ಅವರು ತಿಳಿದಿದ್ದರು.

ವ್ಯಾಟ್ಸನ್ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂದು ಕೇಳಿದರು.

ಮಾರಾಟ ಪ್ರತಿನಿಧಿ ಟೆಂಡರ್ ಪ್ರಗತಿಯ ಬಗ್ಗೆ ವಿವರವಾಗಿ ಮಾತನಾಡಿದರು. ಅವರು ತಪ್ಪಿಸಬಹುದಾದ ತಪ್ಪುಗಳನ್ನು ಹೆಸರಿಸಿದರು. ಅಂತಿಮವಾಗಿ, ಅವರು ಹೇಳಿದರು, “ಮಿ. ವ್ಯಾಟ್ಸನ್, ನನಗೆ ವಿವರಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ಈ ಆದೇಶ ನಮಗೆ ಎಷ್ಟು ಬೇಕು ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ಅವನು ಎಷ್ಟು ಮುಖ್ಯ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ, ಮತ್ತು ಹೊರಡಲು ಸಿದ್ಧನಾದನು.

ವ್ಯಾಟ್ಸನ್ ಅವನ ಬಳಿಗೆ ಬಂದನು, ಅವನ ಕಣ್ಣುಗಳಲ್ಲಿ ನೋಡಿದನು ಮತ್ತು ಲಕೋಟೆಯನ್ನು ಹಿಂದಿರುಗಿಸಿದನು: “ನಾನು ನಿನ್ನನ್ನು ಹೇಗೆ ಹೋಗಲು ಬಿಡುತ್ತೇನೆ? ನಾನು ನಿಮ್ಮ ಶಿಕ್ಷಣಕ್ಕಾಗಿ ಒಂದು ಮಿಲಿಯನ್ ಡಾಲರ್ ಹೂಡಿಕೆ ಮಾಡಿದ್ದೇನೆ.

ನನ್ನ ಬಳಿ ಟಿ-ಶರ್ಟ್ ಇದೆ: "ನೀವು ನಿಜವಾಗಿಯೂ ತಪ್ಪುಗಳಿಂದ ಕಲಿತರೆ, ನಾನು ಈಗಾಗಲೇ ಮಾಸ್ಟರ್ ಆಗಿದ್ದೇನೆ." ವಾಸ್ತವವಾಗಿ, ದೋಷಗಳ ವಿಷಯಕ್ಕೆ ಬಂದಾಗ, ನಾನು ವಿಜ್ಞಾನದ ವೈದ್ಯ.

ಮೊದಲ ಸ್ಥಾನ: ಅಪ್ಲಿಕೇಶನ್ ಇನ್ವೆಂಟರ್ API

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

ಕೆಟ್ಟದ್ದು ಉತ್ತಮ

ನಾನು ಓದುತ್ತೇನೆ ರಿಚರ್ಡ್ ಗೇಬ್ರಿಯಲ್ ಅವರ ಪ್ರಬಂಧ ತೊಂಬತ್ತರ ದಶಕದಲ್ಲಿ ಪದವೀಧರ ವಿದ್ಯಾರ್ಥಿಯಾಗಿ ಈ ವಿಧಾನದ ಬಗ್ಗೆ, ಮತ್ತು ನಾನು ಅದನ್ನು ನನ್ನ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ಕೇಳಲು ತುಂಬಾ ಇಷ್ಟಪಡುತ್ತೇನೆ. ನಿಮಗೆ ಚೆನ್ನಾಗಿ ನೆನಪಿಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಸ್ಮರಣೆಯನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡಿ, ಅದು ಚಿಕ್ಕದಾಗಿದೆ. ಈ ಪ್ರಬಂಧವು "ಅದನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯಲು" ಮತ್ತು "ಕೆಟ್ಟದ್ದು ಉತ್ತಮ" ವಿಧಾನವನ್ನು ಸರಳತೆ ಸೇರಿದಂತೆ ಹಲವು ವಿಧಗಳಲ್ಲಿ ವ್ಯತಿರಿಕ್ತಗೊಳಿಸುತ್ತದೆ.

ಅದು ಹೇಗೆ ಇರಬೇಕು: ವಿನ್ಯಾಸವು ಅನುಷ್ಠಾನ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸರಳವಾಗಿರಬೇಕು. ಇಂಟರ್ಫೇಸ್ನ ಸರಳತೆಯು ಅನುಷ್ಠಾನದ ಸರಳತೆಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.

ಕೆಟ್ಟದು, ಉತ್ತಮ: ವಿನ್ಯಾಸವು ಅನುಷ್ಠಾನ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸರಳವಾಗಿರಬೇಕು. ಇಂಟರ್ಫೇಸ್ನ ಸರಳತೆಗಿಂತ ಅನುಷ್ಠಾನದ ಸರಳತೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.

ಒಂದು ನಿಮಿಷ ಅದನ್ನು ಮರೆತುಬಿಡೋಣ. ದುರದೃಷ್ಟವಶಾತ್, ನಾನು ಅದನ್ನು ಹಲವು ವರ್ಷಗಳಿಂದ ಮರೆತಿದ್ದೇನೆ.

ಅಪ್ಲಿಕೇಶನ್ ಇನ್ವೆಂಟರ್

Google ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ನಾನು ತಂಡದ ಭಾಗವಾಗಿದ್ದೆ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ವೆಂಟರ್, ಮಹತ್ವಾಕಾಂಕ್ಷಿ Android ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಡ್ರ್ಯಾಗ್ ಮತ್ತು ಡ್ರಾಪ್ ಆನ್‌ಲೈನ್ ಅಭಿವೃದ್ಧಿ ಪರಿಸರ. ಇದು 2009, ಮತ್ತು ನಾವು ಆಲ್ಫಾ ಆವೃತ್ತಿಯನ್ನು ಸಮಯಕ್ಕೆ ಬಿಡುಗಡೆ ಮಾಡುವ ಆತುರದಲ್ಲಿದ್ದೆವು ಇದರಿಂದ ಬೇಸಿಗೆಯಲ್ಲಿ ನಾವು ಶರತ್ಕಾಲದಲ್ಲಿ ಬೋಧಿಸುವಾಗ ಪರಿಸರವನ್ನು ಬಳಸಬಹುದಾದ ಶಿಕ್ಷಕರಿಗೆ ಮಾಸ್ಟರ್ ತರಗತಿಗಳನ್ನು ನಡೆಸಬಹುದು. ನಾನು TI-99/4 ನಲ್ಲಿ ಆಟಗಳನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತಿದ್ದೆ ಎಂಬ ಬಗ್ಗೆ ನಾಸ್ಟಾಲ್ಜಿಕ್ ಅನ್ನು ಅಳವಡಿಸಲು ನಾನು ಸ್ವಯಂಸೇವಕನಾಗಿದ್ದೆ. ಗೊತ್ತಿಲ್ಲದವರಿಗೆ, ಸ್ಪ್ರೈಟ್ ಎನ್ನುವುದು ಎರಡು ಆಯಾಮದ ಚಿತ್ರಾತ್ಮಕ ವಸ್ತುವಾಗಿದ್ದು ಅದು ಇತರ ಸಾಫ್ಟ್‌ವೇರ್ ಅಂಶಗಳೊಂದಿಗೆ ಚಲಿಸಬಹುದು ಮತ್ತು ಸಂವಹನ ಮಾಡಬಹುದು. ಸ್ಪ್ರೈಟ್‌ಗಳ ಉದಾಹರಣೆಗಳಲ್ಲಿ ಅಂತರಿಕ್ಷಹಡಗುಗಳು, ಕ್ಷುದ್ರಗ್ರಹಗಳು, ಗೋಲಿಗಳು ಮತ್ತು ರಾಕೆಟ್‌ಗಳು ಸೇರಿವೆ.

ನಾವು ಜಾವಾದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಆ್ಯಪ್ ಇನ್ವೆಂಟರ್ ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಕೇವಲ ಒಂದು ಗುಂಪಿನ ವಸ್ತುಗಳು ಇವೆ. ಚೆಂಡುಗಳು ಮತ್ತು ಸ್ಪ್ರೈಟ್‌ಗಳು ಒಂದೇ ರೀತಿ ವರ್ತಿಸುವುದರಿಂದ, ನಾನು ಗುಣಲಕ್ಷಣಗಳು (ಕ್ಷೇತ್ರಗಳು) ಎಕ್ಸ್, ವೈ, ಸ್ಪೀಡ್ (ವೇಗ) ಮತ್ತು ಶಿರೋನಾಮೆ (ದಿಕ್ಕು) ಜೊತೆಗೆ ಅಮೂರ್ತ ಸ್ಪ್ರೈಟ್ ವರ್ಗವನ್ನು ರಚಿಸಿದ್ದೇನೆ. ಘರ್ಷಣೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು, ಪರದೆಯ ಅಂಚಿನಿಂದ ಪುಟಿಯುವುದು ಇತ್ಯಾದಿಗಳಿಗೆ ಅವರು ಅದೇ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದ್ದರು.

ಚೆಂಡು ಮತ್ತು ಸ್ಪ್ರೈಟ್ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ನಿಖರವಾಗಿ ಚಿತ್ರಿಸಲಾಗಿದೆ - ತುಂಬಿದ ವೃತ್ತ ಅಥವಾ ರಾಸ್ಟರ್. ನಾನು ಮೊದಲು ಸ್ಪ್ರೈಟ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದರಿಂದ, ಚಿತ್ರವು ಇರುವ ಮೇಲಿನ ಎಡ ಮೂಲೆಯ x- ಮತ್ತು y- ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ.

ಸ್ಪ್ರೈಟ್‌ಗಳು ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ನಾನು ಬಾಲ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಕಡಿಮೆ ಕೋಡ್‌ನೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದೆಂದು ನಿರ್ಧರಿಸಿದೆ. ಒಂದೇ ಸಮಸ್ಯೆಯೆಂದರೆ, ನಾನು ಚೆಂಡನ್ನು ರೂಪಿಸುವ ಬಾಹ್ಯರೇಖೆಯ ಮೇಲಿನ ಎಡ ಮೂಲೆಯ x- ಮತ್ತು y- ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ಸೂಚಿಸುವ ಸರಳ ಮಾರ್ಗವನ್ನು (ಅನುಷ್ಠಾನಕಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ) ತೆಗೆದುಕೊಂಡೆ.

ವಾಸ್ತವವಾಗಿ, ಯಾವುದೇ ಗಣಿತದ ಪಠ್ಯಪುಸ್ತಕದಲ್ಲಿ ಮತ್ತು ವಲಯಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಯಾವುದೇ ಮೂಲದಲ್ಲಿ ಕಲಿಸಿದಂತೆ ವೃತ್ತದ ಮಧ್ಯಭಾಗದ x- ಮತ್ತು y- ನಿರ್ದೇಶಾಂಕಗಳನ್ನು ಸೂಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.

ನನ್ನ ಹಿಂದಿನ ತಪ್ಪುಗಳಂತಲ್ಲದೆ, ಇದು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಮಾತ್ರವಲ್ಲ, ಲಕ್ಷಾಂತರ ಆಪ್ ಇನ್ವೆಂಟರ್ ಬಳಕೆದಾರರ ಮೇಲೂ ಪರಿಣಾಮ ಬೀರಿದೆ. ಅವರಲ್ಲಿ ಹಲವರು ಮಕ್ಕಳು ಅಥವಾ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸಬರಾಗಿದ್ದರು. ಚೆಂಡು ಇರುವ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಅವರು ಸಾಕಷ್ಟು ಅನಗತ್ಯ ಕ್ರಮಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗಿತ್ತು. ನಗುವಿನೊಂದಿಗೆ ನನ್ನ ಇತರ ತಪ್ಪುಗಳನ್ನು ನೆನಪಿಸಿಕೊಂಡರೆ, ಇದು ಇಂದಿಗೂ ನನಗೆ ಬೆವರು ಮಾಡುತ್ತದೆ.

ನಾನು ಅಂತಿಮವಾಗಿ ಈ ದೋಷವನ್ನು ಇತ್ತೀಚೆಗೆ, ಹತ್ತು ವರ್ಷಗಳ ನಂತರ ಸರಿಪಡಿಸಿದೆ. "ಪ್ಯಾಚ್ಡ್", "ಸ್ಥಿರ" ಅಲ್ಲ, ಏಕೆಂದರೆ ಜೋಶುವಾ ಬ್ಲೋಚ್ ಹೇಳುವಂತೆ, API ಗಳು ಶಾಶ್ವತವಾಗಿವೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರೋಗ್ರಾಮ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ, ನಾವು OriginAtCenter ಆಸ್ತಿಯನ್ನು ಹಳೆಯ ಪ್ರೋಗ್ರಾಂಗಳಲ್ಲಿ ತಪ್ಪು ಮೌಲ್ಯದೊಂದಿಗೆ ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಭವಿಷ್ಯದ ಎಲ್ಲಾ ಪ್ರೋಗ್ರಾಂಗಳಲ್ಲಿ ಸರಿ. ಬಳಕೆದಾರರು ತಾರ್ಕಿಕ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಬಹುದು: ಪ್ರಾರಂಭದ ಬಿಂದುವನ್ನು ಕೇಂದ್ರವನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆಡೆ ಇರಿಸಲು ಯಾರು ಯೋಚಿಸಿದ್ದಾರೆ. ಯಾರಿಗೆ? ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಸಾಮಾನ್ಯ API ಅನ್ನು ರಚಿಸಲು ತುಂಬಾ ಸೋಮಾರಿಯಾಗಿದ್ದ ಒಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ.

ಕಲಿತ ಪಾಠಗಳು

API ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ (ಬಹುತೇಕ ಪ್ರತಿ ಪ್ರೋಗ್ರಾಮರ್ ಕೆಲವೊಮ್ಮೆ ಮಾಡಬೇಕು), ನೀವು ಜೋಶುವಾ ಬ್ಲೋಚ್ ಅವರ ವೀಡಿಯೊದಲ್ಲಿ ವಿವರಿಸಿರುವ ಉತ್ತಮ ಸಲಹೆಯನ್ನು ಅನುಸರಿಸಬೇಕು "ಉತ್ತಮ API ಅನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಮತ್ತು ಅದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ"ಅಥವಾ ಈ ಕಿರು ಪಟ್ಟಿಯಲ್ಲಿ:

• API ನಿಮಗೆ ಹೆಚ್ಚಿನ ಲಾಭ ಮತ್ತು ದೊಡ್ಡ ಹಾನಿ ಎರಡನ್ನೂ ತರಬಹುದು.. ಉತ್ತಮ API ಪುನರಾವರ್ತಿತ ಗ್ರಾಹಕರನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಕೆಟ್ಟದ್ದು ನಿಮ್ಮ ಶಾಶ್ವತ ದುಃಸ್ವಪ್ನವಾಗುತ್ತದೆ.
• ಸಾರ್ವಜನಿಕ API ಗಳು, ವಜ್ರಗಳಂತೆ, ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುತ್ತವೆ. ನಿಮ್ಮ ಎಲ್ಲವನ್ನೂ ನೀಡಿ: ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಲು ಮತ್ತೊಂದು ಅವಕಾಶವಿರುವುದಿಲ್ಲ.
• API ಬಾಹ್ಯರೇಖೆಗಳು ಸಂಕ್ಷಿಪ್ತವಾಗಿರಬೇಕು - ವರ್ಗ ಮತ್ತು ವಿಧಾನದ ಸಹಿಗಳು ಮತ್ತು ವಿವರಣೆಗಳೊಂದಿಗೆ ಒಂದು ಪುಟ, ಒಂದು ಸಾಲಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಇದು ಮೊದಲ ಬಾರಿಗೆ ಪರಿಪೂರ್ಣವಾಗದಿದ್ದರೆ API ಅನ್ನು ಸುಲಭವಾಗಿ ಪುನರ್ರಚಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
• ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ವಿವರಿಸಿAPI ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಅಥವಾ ಅದರ ನಿರ್ದಿಷ್ಟತೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ಮೊದಲು. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸದ API ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಮತ್ತು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತೀರಿ.

ನಾನು ಕೃತಕ ಲಿಪಿಯೊಂದಿಗೆ ಸಣ್ಣ ಸಾರಾಂಶವನ್ನಾದರೂ ಬರೆದಿದ್ದರೆ, ಹೆಚ್ಚಾಗಿ ನಾನು ದೋಷವನ್ನು ಗುರುತಿಸಿ ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತೇನೆ. ಇಲ್ಲದಿದ್ದರೆ, ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಲ್ಲಿ ಒಬ್ಬರು ಖಂಡಿತವಾಗಿಯೂ ಅದನ್ನು ಮಾಡುತ್ತಾರೆ. ದೂರಗಾಮಿ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ನಿರ್ಧಾರವನ್ನು ಕನಿಷ್ಠ ಒಂದು ದಿನದವರೆಗೆ ಯೋಚಿಸಬೇಕು (ಇದು ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವುದಿಲ್ಲ).

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

ತೀರ್ಮಾನಕ್ಕೆ

ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಪ್ರತಿದಿನ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ, ಅದು ದೋಷಯುಕ್ತ ಕೋಡ್ ಬರೆಯುತ್ತಿರಲಿ ಅಥವಾ ಅವರ ಕೌಶಲ್ಯ ಮತ್ತು ಉತ್ಪಾದಕತೆಯನ್ನು ಸುಧಾರಿಸುವ ಯಾವುದನ್ನಾದರೂ ಪ್ರಯತ್ನಿಸಲು ಬಯಸುವುದಿಲ್ಲ. ಸಹಜವಾಗಿ, ನಾನು ಮಾಡಿದಂತಹ ಗಂಭೀರ ತಪ್ಪುಗಳನ್ನು ಮಾಡದೆಯೇ ನೀವು ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿರಬಹುದು. ಆದರೆ ನಿಮ್ಮ ತಪ್ಪುಗಳನ್ನು ಗುರುತಿಸದೆ ಮತ್ತು ಅವರಿಂದ ಕಲಿಯದೆ ಉತ್ತಮ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಲು ಅಸಾಧ್ಯ.

ಅವರು ಹಲವಾರು ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಆದ್ದರಿಂದ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಹೊರಗುಳಿಯುವುದಿಲ್ಲ ಎಂದು ಭಾವಿಸುವ ವಿದ್ಯಾರ್ಥಿಗಳನ್ನು ನಾನು ನಿರಂತರವಾಗಿ ಎದುರಿಸುತ್ತೇನೆ. ಐಟಿಯಲ್ಲಿ ಇಂಪೋಸ್ಟರ್ ಸಿಂಡ್ರೋಮ್ ಎಷ್ಟು ಸಾಮಾನ್ಯವಾಗಿದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ನಾನು ಪಟ್ಟಿ ಮಾಡಿದ ಪಾಠಗಳನ್ನು ನೀವು ಕಲಿಯುವಿರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ - ಆದರೆ ಮುಖ್ಯವಾದದನ್ನು ನೆನಪಿಡಿ: ನಮ್ಮಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರೂ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ - ಮುಜುಗರ, ತಮಾಷೆ, ಭಯಾನಕ. ಭವಿಷ್ಯದಲ್ಲಿ ನಾನು ಲೇಖನವನ್ನು ಮುಂದುವರಿಸಲು ಸಾಕಷ್ಟು ವಸ್ತುಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ನಾನು ಆಶ್ಚರ್ಯಪಡುತ್ತೇನೆ ಮತ್ತು ಅಸಮಾಧಾನಗೊಳ್ಳುತ್ತೇನೆ.

ಮೂಲ: www.habr.com