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

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

1. למידה מנסיון של עצמכם

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

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

2. למידה מנסיון של אחרים

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

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

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

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

כלל פשוט מתוך אותו הספר אומר Don't mock what you don't own. זה אולי לא מסתדר עם האינטואיציה, אבל מופיע שם עם דיון משכנע ולראיה אחרי שהפסקתי לכתוב mocks לקוד צד-שלישי הבדיקות שלי נהיו יותר יציבות. ללמוד לקח כזה בלי הספר היה דורש לכתוב חבילת בדיקות, לתחזק אותה לאורך זמן ולראות אותה נשברת מספר פעמים כתוצאה משדרוגי ספריות צד-שלישי. דיון מהספר חוסך את כל זה ומציג רק את הלקח.

3. קבלת הרגלי עבודה של מקצוענים

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

אבל הרגלי העבודה שסקוט משתף בספר הם כאלה שאפשר ליישם אותם על כל פרויקט. גם אם הפרויקט שלכם או הקוד שלכם לא יגיעו לקצוות שמתוארים בספר. הטיפ הפשוט שאומר:

Explicitly disallow the use of compiler-generated functions you do not want

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

Postpone variable definitions as long as possible

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

הספר Perl Best Practices של Conway או JavaScript: The Good Parts הם דוגמאות נוספות לספרים שמקנים הרגלי עבודה המזוהים למרחוק.

4. ואני לא היחיד שחושב כך

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

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