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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פנדה הוא בהחלט כל מה שאפשר לדמיין כשחושבים על פריימוורק ל CSS in JS. היתרון הגדול שלו הוא התמיכה המלאה בקומפוננטות צד-שרת, כלומר בבניית כל הגדרות העיצוב בצד בתור קלאסים ושימוש אוטומטי בקלאסים אלה בתוך הקוד, בסגנון Tailwind CSS. אבל בניגוד לטיילווינד, פה יש לנו גם חיבור ל TypeScript כדי לקבל השלמה ואימות טיפוסים על כללי העיצוב ואינטגרציה טובה עם ריאקט כדי לייצר עיצובים מתוך קוד.

וכמו שאומרים קוד שווה יותר מאלף מילים, אז הנה דוגמה קטנה ל Panda בקומפוננטת ריאקט:

function App() {
  return (
    <div className={css({ background: 'red.400'})}>
      <div className={css({ fontSize: "2xl", fontWeight: 'bold' })}>Hello 🐼!</div>
    </div>
  )
}

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

ודוגמה שניה קצת יותר מתוחכמת-

function App() {
  const [clicked, setClicked] = useState(false);
  return (
    <div>
      <button
        className={css({
          color: {
            base: 'blue',
            _hover: 'green',
          },
          cursor: 'pointer',
          background: '#dadada',
          padding: '10px',
          borderRadius: '5px',
        })}
        onClick={() => setClicked(true)}
      >
        Click Here
      </button>
      <p className={css({
        color: clicked ? 'green' : 'red'
      })}>{clicked ? 'Passed' : 'Failed'}</p>
    </div>
  )
}

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

כדי לשחק עם Panda תצטרכו קודם להוסיף אותו לפרויקט ריאקט שלכם. אלה ההוראות לפרויקט שבנוי ב Vite: https://panda-css.com/docs/getting-started/vite

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

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

import "./styles.css";

function Counter() {
  function handleClick() {
    const btn = document.querySelector(".counter button");
    const count = Number(btn.textContent);
    btn.textContent = count + 1;
  }

  return (
    <div className="counter">
      <button onClick={handleClick}>0</button>
    </div>
  );
}

export default function App() {
  return (
    <div className="App">
      <Counter />
    </div>
  );
}

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

1. הקוד לא יציב - אם App ישתנה, למשל אם יוסיפו עוד Counter, אז אחד מהם יפסיק לעבוד בגלל השימוש ב document.querySelector. יותר מזה, אם יוסיפו משתנה State או Props ל Counter אז ברינדור הבא הערך שכתוב בכפתור יימחק.

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

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

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

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

אם רק זה היה כל כך פשוט.

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

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

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

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

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

איך זה ירגיש להשתמש בשפה אחרת, אולי שפה פונקציונאלית בשביל הפיצ'ר הבא?

איך זה ירגיש לבנות סרביס במקום להרחיב את המונולית?

איך מרגיש לעבוד עם מנגנון Deployment אוטומטי? או ידני?

ומה אם הפעם נכתוב את הבדיקות לפני שנכתוב את הקוד? או שנוותר לגמרי על הבדיקות?

ומה יקרה אם בפיצ'ר הבא ננסה לפתח רק על ה Trunk בלי Branch-ים ב git?

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

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

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

אבל זו עצה מאוד תמימה.

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

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

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

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

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

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

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

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

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