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

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

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

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

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