מסקנות מהשנה - מה למדתי השנה בנסיונותיי ללמד Java

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

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

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

“כי פה זה ככה”

קחו את ההסבר שלי ל-main ב-Java, בפוסט שבו אני מציג איך מדפיסים לפלט ב-Java. הנה ציטוט ממה שכתבתי שם:

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

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

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

אז, במילים אחרות, הגישה שהייתי איתה לפני כמה זמן היא “כרגע קחו את זה ונבין את זה בהמשך”. בואו נביט רגע בדוגמת קוד ל-main ב-Java:

package package_name;

public class Main {
    public static void main(String[] args) {
        // your code here
    }
}

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

אבל יש גם דברים שאי אפשר היה להסביר אחרת, כנראה. אולי אפשר להסביר מה static ו-void לפני שכותבים את פקודת ההדפסה “שלום עולם” הראשונה שלנו, אבל אני לא רואה סיבה לעשות את זה. גם את String[] args אני לא רואה סיבה להסביר לפני שנכנסים יותר עמוק ל-Java (אגב, למי שעוד לא מכיר את הדברים האלה - כבר אמרתי היום שאגיע לזה בהמשך סדרת הפוסטים הראשית? אבל זה ייקח לי קצת זמן כי בסדרה הזו אני כותב הרבה יותר בפירוט מאשר במצגות שלי). ניסיתי, לצורך ההדגמה, לפוסט הזה, לכתוב פירוק של כל הדברים האלה ברמה שמתאימה למי שעוד לא כתבה תוכנת “שלום עולם” - זה יוצא מוזר, מייגע, ואין סיכוי שזה מחלחל באיזה שהיא צורה. אז ויתרתי.

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

תחביר, אוצר מילים, פילוסופיה ותרגול

אני חושב שהדבר ששמתי עליו הכי הרבה דגש בשלוש השנים שבהן אני מדריך Java ב-Ladies FIRST #4319 הוא ההבדל בין תחביר ואוצר מילים של שפה לפילוסופיה של שפה. מה הכוונה?

אני לא היחיד שחושב שכדי להבין שפות תכנות ואת ההבדלים והדמיונות ביניהן, עוזר להקביל את זה לבלשנות, שבה מנסים להבין שפות אנושיות ואת ההבדלים והדמיונות ביניהם. בעברית למשל, במשפט “אני הייתי בשיחת טלפון”, אם נשמיט את המילה “אני” מהמשפט ונשאיר במקומה blank (“השלם כאן”, “__”), נקבל “__ הייתי בשיחת טלפון”, ואת ה-blank הזה לא ניתן להשלים ב”אנחנו” או “אתה” או “הן”, כי במילה “הייתי” מובנֵה שמדובר בגוף ראשון יחיד. לעומת זאת באנגלית, במשפט “I was on a phone call”, אם נשמיט את המילה “I” ונשאיר במקומה blank, נקבל “__ was on a phone call”, אותה אפשר להחליף גם ב-“he”, “she” או “it”, אבל לא ב-“we” או “they” - ה-“was” מרמז על זה שזה יכול להיות כל אחד מהמאזכרים האלה, ולא מבדיל בין גוף ראשון לשלישי.

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

double mass;
mass = 29.8;

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

mass = 29.8

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

mass = "65.69775 lbs"

ב-Java לא יכולנו לעשות את זה; כל משתנה צריך שיוגדר לו טיפוס, ואסור לנסות להכניס לו משהו שלא מהטיפוס הזה - זו שגיאת קומפילציה, כלומר Java לא יכולה בכלל להפוך את הקוד שלנו לדבר שאפשר להריץ, הקוד לא הגיוני עבור Java.

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

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

נחזור לשורת ההצהרה על המשתנה:

double mass;

המבנה: שם הטיפוס, רווח, שם המשתנה, נקודה-פסיק. אפשר לשנן את המבנה (תחביר) הזה שוב ושוב, או שאפשר לנקוט בגישה שלי ולהגיד שהחומר תמיד פתוח ואם את לא זוכרת את זה, אז תחזרי לחומר הכתוב מתי שתרצי. כנ”ל לגבי המילה double שצריך להתרגל לזה שהיא אומרת “מספר עשרוני”. אני עדיין מאמין שעקרונית תמיד צריך שהחומר יהיה זמין, אבל אולי כשאני יושב עם תלמידות פרונטלית, בין אם בקבוצה ליד מקרן או בארבע עיניים מול המחשב עם תלמידה שמנסה לתרגם את מה שלמדנו עכשיו לקוד שהיא מקלידה בידיים, כדאי שאם התלמידה לא מצליחה להיזכר באותו רגע במבנה התחבירי (לא רק של הצהרה על משתנה כמובן, זו רק הדוגמה המנחה), לעודד אותה לנסות להיזכר בזה בכל מקרה. במצגות שבהן אני נותן תרגילים לתלמידות, אני לפעמים מצרף ליד, באותה שקופית, מלבנים קטנים בצד ובהם תזכורות לחומר הרלוונטי; אבל אם הוא לא נמצא ליד, אולי שווה לנסות לבקש מהתלמידה “רגע, אנחנו נוכל להסתכל אם לא תזכרי, זה מותר, אבל אני חושב שאת תצליחי להיזכר אם תנסי בעצמך - בואי קחי רגע, תנסי קצת מול ה-IDE, מקסימום תטעי ואז תטעי שוב ואז תצדקי”. אבל למה? למה לנסות לתרגל את הזיכרון האנושי שלנו, ועוד כשאנחנו מראים איך ליצור בתוכנית שלנו יחידת זיכרון ולתת לה שם? כשניסיתי לחשוב על זה, שאלתי את עצמי איך לימדו אותי דברים במסגרות הכן-פורמליות.

כשהייתי ילד ביסודי, המורה לחשבון הייתה אומרת שלא תמיד יהיה לנו מחשבון בכיס. כן, בשנות ה-2000 המוקדמות מורות עוד היו אומרות את זה; אני מניח שהיום הן כבר לא אומרות את זה, אבל בזמני הן כן היו, אפילו שאני חושב שאז הן כבר ידעו שזה לא נכון. כלומר, אני לא יודע אם הן ידעו לחזות שאפילו במכולת השכונתית נשלם באשראי דרך הצמדת טלפון נייד למשטח שיותר מדי אנשים יקראו לו בטעות “Wi-Fi”, ולא נצטרך בכלל לחשב כמה עודף מגיע לנו בחזרה על שטר חמישים השקלים שנתנו אחרי שהמוכר אמר לנו “עשרים ושלוש תשעים”, אבל כבר אז, אם זכרוני אינו מטעה אותי, היינו יכולים, ממקומנו בְתור הלקוח שליד הקופה, לראות אותה מחשבת עבור המוכר כמה עודף הוא חייב לנו, וגם אם הייתה לנו סיבה לחשוד שהמוכר אינו כנה או סתם לא שם לב או לא טוב בחשבון, לא הייתה לנו סיבה לחשוד שהסכום שמראה הקופה בספרות LED ירוקות אינה העודף הנכון. ובכל זאת למדתי לעשות חיסור. וגם בלוח הכפל אני לא משתמש ביומיום, ובכל זאת מה שהמורה לחשבון אמרה שיקרה בסוף אכן קרה: תוך כמה זמן, הייתי יכול לענות על השאלה “מהר, כמה זה שמונה כפול שבע?” גם אם היו מעירים אותי איתה מתוך שינה. האם באמת העירו אותי בשתיים בלילה לוודא שאני אכן יודע להגיד כמה זה שש כפול שבע - אני בטוח ב- שלא. והיום אני מסוגל לכפול מספרים חד-ספרתיים בראש, אפילו אם בפועל אני משתמש במחשב רוב הפעמים שאני צריך לעשות את זה.

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

וכשלמדתי מדעי המחשב בתיכון, היה מותר להביא כל חומר פתוח למבחן למעט מחשב, ואכן הבאתי את כל החומר המודפס שיכולתי, אבל מן הסתם, ככל שהייתי פחות צריך אותם זה היה סימן שהכרתי את החומר יותר טוב: אפילו שיכולתי לוודא שכתבתי public static void main(String[] args) נכון בכל פעם (כן, זה חלק מזה, וכן, אלו מבחנים בנייר ועט), לא הייתי חייב לעשות את זה.

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

צליל של משהו מתקווצ’ץ’

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

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

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

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

מארק רובר (Mark Rober) הוא מהנדס לשעבר ב-NASA שהקים ערוץ יוטיוב בז’אנר ה-edu-tainment (בידור-חינוך) שבו הוא מסביר עקרונות בתחום ה-STEM באופן מהנה, וזה אולי מסביר למה הוא גם חבר טוב של FIRST. הוא פעיל כבר הרבה זמן, אבל אני גיליתי אותו רק השנה (דרך FIRST, למען האמת - הוא הופיע ברצף הסרטונים המקדים לקיקאוף). והוא רוצה לעזור לאנשים לראות כמה כיף - ונגיש - לחשוב כמו מהנדס. לפני כמה שנים הוא הגשים את החלום שלו ושל רבים מאיתנו, ויצר לעצמו סדנה של המצאות מטורפות ושטותיות והפך את עצמו לווילי וונקה של המדע והטכנולוגיה. ולסדנה שלו הוא קרא Crunch Labs, ומעבר ל”ניסויים” הבודקים מה משמיד אבטיח יותר טוב - ברקים או לייזרים, Crunch Labs גם מציעה חבילות בניה לילדים ולנוער ולמבוגרים שבהן בונים פרויקטים קטנים ומגניבים, וכמו שהוא מסביר:

חשוב לדעת שזה לא רק בסדר אלא שזה חשוב להיכשל הרבה פעמים כדי להגיע לפריצת הדרך הגדולה. זו הסיבה שזה נקרא Crunch Labs - כדי שנוכל לקווצ’ץ’ ולשבור ולהיכשל בדברים כדי ללמוד מהר

ולפני כמה שבועות, כשצפיתי לראשונה בסרטון הזה ושמעתי אותו אומר את זה, גם לי הייתה פריצת דרך: ההבנה שזה כנראה הדבר הכי חשוב שהיה חסר לי. זה היה רגע ה”אאוריקה” שלי. ולמרות שאני לא ממליץ לשרוף ציוד יקר של אנדי-מארק או REV או CTRE בכוונה, ולמרות שחשוב לעצור אקטיבית תלמידה שעומדת עכשיו לקצר מעגל חשמלי, אני חייב להודות שזה חשוב להיכשל כדי ללמוד. וזה אולי הדבר הכי חשוב שלא יישמתי מספיק השנה בתור מנטור, ושאני מתחייב ליישם יותר טוב בעתיד. חששתי - באמת חששתי - שאם דברים לא יעבדו מספיק מהר, תלמידים יחשבו שהתחום הזה לא בשבילם, ולעורר השראה לתחום הזה זה הדבר החשוב ביותר שאני בא לעשות כאן. ובהתאם, אני אמשיך לקרוא לתלמידים צעירים לבוא ללמוד תכנות כדי שיוכלו לתכנת דברים מגניבים כמו רובוטים, אבל גם משחקי מחשב, וגם לפתור בעיות שונות ומשונות, אבל גם, אני אתן להם את ההזדמנות לכתוב קוד שהוא לא מושלם, ולתת להם לחקור לבד למה הוא לא עובד; או לחלופין, שיגיעו לתוצר שכן עובד, אבל עובד אחרת מאשר איך אני הייתי מתכנן אותו, אולי קוד שהוא בעיניי פחות “איכותי”, אבל שהוא עדיין קוד שהוא שלם ושעושה את העבודה. תמיד נוכל לשייף אותו אחר כך. ואני כמובן אמשיך להיות זמין לעזרה לתלמידים שלי, אני לא מתכוון להיות עציץ כשאני נוכח בהכשרות - אבל אני אזכיר לעצמי שכל הודעת שגיאה היא משקולת שאני צריך לתת להרים כדי לחזק את השרירים. כלומר, כמובן שלפעמים מישהו לוקח משקולת כבדה מדי או מגיע לגבול שלו עם הסט הנוכחי שהוא עושה, ואז צריך להרים את המשקולת ממנו ולהניח אותה בחזרה על המוט, אבל יש סיבה שיש בכלל משקולות בחדר הכושר. ואם קורא את זה מנטור או רש”צ או קפטן שרוצה לדעת עוד בנושא, הייתי ממליץ מלהתחיל מלחפש מידע על מודל הטווח המלא של Bass ו-Avolio (שגם הוא בגדר משהו שהכרתי לפני אבל לא יישמתי מספיק טוב בעצמי).

התלמידות שלי מכירות את הכפפות הלבנות שלי - מטפורה שבה אני משתמש כדי להזכיר שכמנטור, אני לא אמור לגעת בדברים בעצמי, ולכן, אמורות להיות עליי כפפות לבנות שיהיה קל לזהות עליהן מיד כתם שמציין שלכלכתי את ידיי ונגעתי בגריז (הבהרה: הכפפות מטפוריות וגם הגריז מטפורי, צוות מכניקה הם אלה שמתעסקים בגריז ואנחנו הצוות שיש לו את הפריווילגיה שהאצבעות שלנו יהיו פחות שומניות, אלא אם כן המקלדת שלכן ממש מגעילה, ואז תנקו אותה בבקשה). היו גם פעמים שבהן התלמידות שלי אמרו לי, בזו הלשון, “יובל, הכפפות שלך”, כדי להבהיר לי שעליי לתת להן לעשות יותר בעצמן, ובחיי שמעטים הרגעים בחיי בהן הרגשתי כל כך הרבה גאווה (בפעם הראשונה שזה קרה, ניגבתי דמעה). לפעמים לכלכתי את הכפפות כי לא היה זמן והיינו צריכים לתקן תקלה לפני מקצה, אז יכולתי לסדר את התקלה מהר ולהסביר לתלמידות מה עשיתי אחרי זה ומה הייתה התקלה - במקרים האלה, התלמידות לא הפסידו יותר מדי ערך לימודי וגם עלינו למקצה עם רובוט שעובד ועם זה אני יכול לישון בסדר בלילה; אבל לפעמים כנראה שבאמת חששתי יותר מדי שאם דברים לא יעבדו, התסכול יניא את התלמידות מהתחום, וזו הייתה בדיעבד טעות. אני מכיר את הקלישאה שהיא ציטוט של מייקל ג’ורדן אומר שמעריצי כדורסל יודעים לצטט כמה פעמים הוא קלע בקריירה אבל לא כמה הוא פספס, אני אפילו מצטט את זה בעצמי באוזניי התלמידות שלי, אבל כנראה שגם אני צריך ליישם את זה קצת יותר טוב בעצמי. אבל גם כשאני לא מיישם את זה טוב בעצמי, תזכרו - do as I say, don’t do as I do.

תרגיל באמפתיה

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

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

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

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

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

לקחים

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