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

טיפים קצרים וחדשות למתכנתים

ללמוד בעל פה או ללמוד עם הלב

24/08/2019

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

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

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

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

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

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

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

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

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

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

שתי שאלות שבטוח יופיעו בראיון העבודה הבא שלך

23/08/2019

״על מה עבדת בעבודה הקודמת?״

״עם מי?״

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

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

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

להרשות לעצמך ללמוד

22/08/2019

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

צריך להבהיר - זה לא דבר רע, זאת הדרך היחידה שלנו לכתוב מערכת שעובדת.

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

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

מתי שווה לדלג על הבסיס

21/08/2019

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

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

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

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

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

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

איך לעוף מהייטק בגיל 40

20/08/2019

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

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

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

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

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

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

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

פידבק לא יעיל

19/08/2019

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

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

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

כמה גבולות שיעזרו לכם להתקדם

18/08/2019

אחת הדרכים הכי טובות להשתפר במשהו היא להצר את הגבולות, וכשהמשהו שאנחנו רוצים להשתפר בו הוא כתיבת קוד יש כמה תבניות קלות שאפשר לאמץ:

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

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

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

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

עבודה בלי לקוח

17/08/2019

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

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

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

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

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

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

איפה החלק המתסכל?

16/08/2019

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

מתכנתת שעוברת מ Python ל Go תצטרך לעבוד ממש קשה אפילו בשביל תוכנית Hello World פשוטה. בגו אין מנהל חבילות, אנחנו צריכים לקמפל את התוכניות שלנו, צריך לחשוב על Types בכל צעד ועוד לא אמרנו מילה על ה Class-ים שנעלמו.

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

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

פרק חדש בקורס Node.JS - עבודה עם ספריית Sequelize

15/08/2019

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

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

בקיצור אחרי שעפתי על הספריה הזאת חשבתי לשתף את מה שלמדתי גם אתכם וכך נוסף פרק חדש לקורס Node.JS שעוסק ב Sequelize ובעבודה איתו. הפרק כולל 8 שיעורים ודף תרגול באורך כולל של כמעט שעתיים וידאו, במהלכם אני מדגים בניה של שני פרויקטים, כולל כתיבת בדיקות יחידה עם Mocha וחיבור ל API עם Express.

אם אתם כבר מנויים יכולים פשוט ללכת לצפות בסידרה החדשה מתוך דף הקורס כאן: https://www.tocode.co.il/bundles/nodejs

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