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

ובגלל זה כל כך חשוב לשאול "איך יודעים מה צריך לעשות?" ו"איך משתפרים בזה?"

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

1. הגעתי לבעיה כשהיתה לי היכרות טובה מאוד עם הקוד.

2. הגעתי לבעיה כשהיתה לי היכרות טובה מאוד עם עולם התוכן.

3. הגעתי לבעיה אחרי שכבר פתרתי בעיות דומות בעבר.

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

וזה מביא אותנו לשאלה היותר מעניינת - "איך משתפרים בזה?". חיבור שלושת התנאים והיפוך הסדר ילמד אותי ש:

1. כדאי לפתור כמה שיותר בעיות

2. כל פעם שפותרים בעיה, כדאי להתעכב ולהבין כל פרט קטן בפיתרון שלה עד הניואנסים הקטנים ביותר

3. כל פעם שמטמיעים פיתרון של בעיה בקוד כדאי להתעכב ולהבין כמה שיותר מקומות בקוד אליהם אפשר לכתוב את הפיתרון וכמה שיותר דרכים בהן המערכת שלנו יכולה להתחבר לפיתרון שמצאנו.

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