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

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

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

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