הבלוג של ינון פרק

אם אתם שולחים קורות חיים ולא מקבלים זימונים לראיונות יכול להיות שהסיבה היא שהמעסיקים הפוטנציאליים שמקבלים את קורות החיים לא מוצאים בהם את תשובות מספקות ל-3 שאלות פשוטות שמעניינות אותם:

1. האם אתם מסוגלים לבנות מוצר עובד בטכנולוגיה שרלוונטית להם?

2. האם הקוד שלכם יסבך לאחרים את החיים?

3. האם אתם הולכים להשקיע בעבודה לאורך זמן?

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

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

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

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

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

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

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

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

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

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

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

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

שאלת פייתון קצרה שהגיעה אליי היתה "איך אני עוברת על כמה רשימות במקביל וכל פעם לוקחת איבר מרשימה אחרת?". לפני שארוץ לענות עם zip של פייתון בואו נלך לבנות לבד את הפיתרון כדי להבין את האתגרים.

בין הסיבות שאנשים מוצאים כדי ללמוד טכנולוגיה חדשה יש לנו:

1. כדי להתקבל לעבודה.

2. כי במקום העבודה התחילו פרויקט בטכנולוגיה זו.

3. כדי להשתלב בפרויקט בטכנולוגיה זו בעבודה.

4. כי יש ציור של חד-קרן בדף הבית.

5. כי כל החברים שלי מדברים על זה.

6. כי כולם ברדיט מדברים על זה.

7. כי אני חושב שזה יעזור לי להיות מתכנת טוב יותר.

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

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

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

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

איך אפשר לכתוב קוד כל כך מתוחכם בקורס אחד, ולא להצליח לכתוב דברים מאוד פשוטים בקורס אחר?

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

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

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

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

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

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

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

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

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

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

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

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

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