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

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

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

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

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

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

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