פול ריקווסט מהיום הראשון

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

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

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

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

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

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

אז איך עושים את זה? זה פחות עניין של העובד ויותר עניין של מקום העבודה

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

IT מוצלח

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

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

תוכנות וסביבת פיתוח

טוב, זה אחלה – אבל יש עוד דברים שצריך במחשב ורלוונטיים פחות ל-IT ויותר לצוות או קבוצת הפיתוח שעובדים בה. למשל סביבת פיתוח – אם זו קבוצה שעובדת ב-Node.js אז nvm מותקן עם גרסאות מותקנות ואם זו קבוצה שעובדת בפייתון אז (למשל) Pipenv וגם כלים נוספים – מפייצ׳ארם ועד VSCode ודרך AWS CLI ועוד שפע של כלים שמהווים בעצם את סביבת הפיתוח.

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

בשעה 13:00 היה לי מחשב עם סביבת עבודה שאינה שונה מהותית מסביבת העבודה של חבריי לצוות וכל עובד פיתוח שהוא בקבוצת הפיתוח.

Good First Issues

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

סיכום

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

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

פוסטים נוספים שכדאי לקרוא

תמונה של עציץ, רספברי פיי ורמקול
רספברי פיי

לגרום לעציץ שלכם לדבר

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

רספברי פיי

מה זה AIoT? ואיך אפשר להתחיל?

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

בינה מלאכותית

Safeguards על מודל שפה גדול (LLM)

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

גלילה לראש העמוד