כמתכנתים אנחנו איומים בהערכות זמנים. כשהתחלתי לכתוב קוד כל הזמן שאלו אותי כמה זמן משהו ייקח, וכל פעם הזמן בפועל היה יותר מכפול מהתשובה שאמרתי. לימים למדתי שמנהלים נוהגים להכפיל הערכות זמנים של עובדים שלהם כשמעבירים אותן הלאה, כך שאף אחד לא באמת יודע כמה זמן משהו ייקח.

סיבה אחת לטעויות האלה בזמנים היא פערי ידע. כמתכנתים אנחנו בטוחים שאנחנו כבר יודעים הכל, ולכן יש לנו כיוון בגדול של הפיתרון שצריך לכתוב. כשהופכים את הפיתרון הזה לקוד מתגלים כל מיני דברים שלא חשבנו עליהם, בעיקר בגלל שבאמת לא ידענו מספיק על הבעיה כשגיבשנו את הכיוון הכללי.

לדוגמא קיבלתם משימה לכתוב איזה Scroll Bar מותאם אישית לאפליקציית ריאקט. כבר כתבתם Scrollbars בלי ריאקט באפליקציות ישנות יותר ולכן יש לכם מושג מה מצפה לכם, ואולי אפילו יש לכם בראש איזה ספריית Scrollbars שעבדה לכם בפרויקט ישן. אבל כשמנסים להפעיל אותה בפרויקט החדש מגלים כל מיני קונפליקטים ואי תאימויות שלא ציפיתם להם ועכשיו אתם כבר שמונה שעות בתוך משימה שהיתה אמורה לקחת שעתיים.

במצב כזה אני רואה יותר מדי חברים בוחרים בטקטיקה הלא נכונה, כלומר להמשיך להתעלם מפער הידע ולחפש ב Stack Overflow את החתיכת קוד הקטנה שתציל אותם. במקרה הטוב לא מוצאים. במקרה הרע מוצאים פיתרון שיישבר בפרודקשן.

הדבר המקצועי לעשות במצב כזה הוא להכיר בזה שגיליתי פער ידע. להכיר בזה שבעצם לא ידעתי מספיק טוב איך כל הספריות האלה משתלבות יחד ושיש כמה דברים עמוקים לגבי ריאקט או jQuery או ספריית ה Scrollbars שבעצם אני לא מבין עד הסוף. אחרי זה אפשר להמשיך למפות את פערי הידע, לסגור אותם ולהכין תוכנית חדשה.

שמונה שעות לתוך המשימה אני כבר מבין שזה לא משהו שייגמר בשעתיים עבודה. אז לפחות בואו נסיים את זה כמו שצריך.