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

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

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

2. לא היה קהל - הפרויקט עלה לאוויר אבל אף אחד לא רצה להשתמש בו.

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

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

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

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

אני יכול להשתמש ב Web Sockets כדי לייצר חווית משתמש טובה יותר לגולשים; אבל קודם אני צריך לבנות אתר ריספונסיבי ונגיש כדי שאנשים יוכלו להשתמש בו מכל מכשיר.

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

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

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

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

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

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

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

3. מריץ את הבדיקות (כן אני יודע אני אופטימי שיש בדיקות אוטומטיות).

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

5. נכנס למערכת בתור משתמש רגיל ומשחק עם הכפתורים

6. כותב בדיקה חדשה ל Flow שגיליתי כששיחקתי עם המערכת (זה לא משנה אם כבר קיימת בדיקה ל Flow הזה. לא חייבים לעשות קומיט).

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

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

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

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

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

function MyTripleComponent(props) {
  const { text } = props;

  if (text === 1) {
    return <p>Hello</p>;
  } else if (text === 2) {
    return <p>Bye bye</p>;
  } else {
    return <p>I don't understand</p>;
  }
}

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

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

function MyTripleComponent(props) {
  const { type } = props;

  if (type === 1) {
    const [text, setText] = React.useState("");

    return (
      <label>
        <input
          type="text"
          value={text}
          onChange={(e) => setText(e.target.value)}
        />
        {text}
      </label>
    );
  } else if (type === 2) {
    return <p>Bye bye</p>;
  } else {
    return <p>I don't understand</p>;
  }
}

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

Rendered more hooks than during the previous render.

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

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

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

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

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

1. אני רוצה לקבוע כמה להתעמק בכל נושא לפי מידת העניין שלי בו.

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

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

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

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

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

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

נתקעתם עם ענף שיש בו יותר מדי שינויים ואתם פשוט צריכים לקחת את כל הקוד משם בתור קומיט יחיד אליכם לעץ? ככה תוכלו להשתמש ב merge squash כדי לעשות בדיוק את זה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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