Why should you care about Developer Experience in a young, fast-growing startup?, Linoy Shkuri

בפרק זה, לינוי שקורי, מנהלת R&D בחברת ג׳אסט מספרת למה חשוב חוויית מפתח.ת - גם בסטארטאפים קטנים, ואיך דואגים שזה יקרה.

In this episode, Linoy Shkuri, R&D Manager at Justt tells us why Developer Experience is important at fast growing startups, and why
.'today is a great day to fail at something new'

Episode Transcript תמליל הפרק

Hebrew, then English בעברית ואז אנגלית:

 (מוזיקת פתיח)

פיתוח בהפרעה עם ישי  ולינוי שקורי

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

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

בפרק הזה, אנחנו שמחים לארח את לינוי שקורי, מנהלת פיתוח ב JUSTT . היי לינוי, איזה כיף שאת פה.

לינוי: ממש כיף, תודה רבה שהזמנת אותי.

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

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

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

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

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

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

לינוי: כמעט רק בלנהל. זה עדיין הלב מושך לכיוון הפול  ריקווסטים (pull requests),
אבל אבל כמעט רק בלנהל.

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

לינוי: חד משמעית להרים סטארט אפ משל עצמי, CTO  ,VP R&D זה החלום ולשם אני אגיע בקרוב, אני מקווה.

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

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

ישי: הידוע….

לינוי: כן,  מעבר לזה, אני גם מתנדבת ב-;she codes. העברתי הרצאות ארכיטקטורה לנשים, שיש להן ניסיון בתעסוקה, בעצם מלמדת אותם לעשות high level design.
אני מתנדבת  כמנטורית, ועושה mock interviews.  והרבה דברים בסגנון הזה, וגם כמו שאתה יודע כותבת, בלוגים להנאתי. לאחרונה כתבתי בלוג בנושא של דבר פיננסי. הזכרתי שם את
LinearB. בעצם ככה הגענו ליום הזה.

ישי: שמחנו….
הזכרת את ;she codes. מילה על איך את רואה את השינוי באתגרים של נשים - נשים בניהול פיתוח נשים בתפקידי פיתוח? לאן זה הולך?

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

ישי: יש לנו לאן להתקדם.

לינוי: עובדים על זה.

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

לינוי: וואו, תדמיין את הדבר הזה.

ישי: איזו תשובה…

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

ישי: הספיקו הרבה.

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

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

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

ישי: יש לך  דוגמא לשאלה או נושא שהוא דיל ברייקר למועמדים. ״אם אין טסטים אני לא בא!״ כאלה דברים?

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

ישי: יומיים שלמים.

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

ישי: של און בורדינג…  בואי נעשה להם פלאג, תספרי לנו!

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

ישי: וואלה, וזה על פי ארים אמיתיים בריפו של הארגון או שהכל-

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

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

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

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

לינוי: כן, לי מאוד חשוב ה ownership  של מפתחים, בסדר? אני יכולה בתור מנהלת פיתוח, לתת לעובדים שלי לעשות פיצ'רים - בגלל שאני גם הייתי מפתחת בעברי, אז אני גם יודעת  להגדיר את זה בצורה מאוד מדוייקת של איך לעשות ומה לעשות בדיוק, אבל זה ההפך המוחלט ממה שאני מאמינה בו. אני מאמינה שהחלק היצירתי הוא החלק שמושך עובדים להישאר הרבה זמן בחברות והחלק של ה אקונטביליטי (accountability). לקוד נגיד או בהקשר שלנו, זה מיקרו סרוויסז (microservices). אקונטביליטי לסרוויס מסוים יכול ממש לקשר את העובד לארגון בצורה טובה. במקרה שלנו אז אם נחזור שנייה, תחשוב לעצמך היום הראשון שלי בארגון ומאה מיקרו סרוויסים ומה אני עושה? אז אחת השאלות שעלו זה באמת איזה צוותים אחראים, על איזה סרוויסים? או איפה נמצא כל סרוויס בתוך
הרפוזיטורי שלנו, או איפה נמצא הסוואגר ( Swagger) של אותו… מה הכתובת אשכרה של הסוואגר של הAPI?

ישי: איפה ה-Architecture Diagram עם כל ה-....

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

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

ישי: חוץ מאותם סרוויסים  שאף אחד לא הכניס לקטלוג.

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

ישי: מה זה,  wall of shame  כזה של..?

לינוי: אז כן, אז זה לא לגמרי shame,  זה דווקא סביב ה glory בסדר נגיד סרוויס שהוא טוב, אז הוא מקבל ברונזה, או יש לו אפילו gold medal בסדר, אז אתה ממש רואה איזה סרוויסים הכי טובים.

ישי: וזה גם דינמי ברמה של זה בודק את ה health של הסרוויס ואם האפ טיים (uptime) שלו גבוה?

לינוי: כן. אתה יכול ממש להגדיר איזה רולים בדיוק  אתה רוצה להכניס בשביל בשביל לנקד את הסרוויס הזה. וממש זה ישפיע באופן מיידי על הסרוויס. עוד משהו שהוא לנו היה קשה להכניס
בארגון וזה חלק מה dna של דיבלופר (developer). זה חלק של initiatives שהם קרוס - ארגוניות ב R&D. אני לא יודעת אם אתה תזדהה, אני מניחה שכן, נגיד initiatives
כמו לעדכן גירסה של Node.

ישי: בטח, איזה כיף.

לינוי: מי אחראי על הדבר הזה?

ישי: הוא, לא אני.

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

ישי: אז ביזרת את הטאסק הזה ל-service owners, כל אחד יש לו מוטיבציה, אבל זה לא שמישהו אחד מרים את הגירסת Node across the board

לינוי: נכון.

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

לינוי: זאת שאלה מאוד יפה, git owners אתה מכיר?

ישי: מכיר…

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

ישי: כל אחד יכול לדפוק כל סרוויס.

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

ישי: זה לא באג זה פיצ׳ר.

לינוי: בדיוק. אז נגיד היפותטית.

ישי: המערכת לא למטה, היא רק קצת איטית.

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

ישי: אבל שינויים בסרוויס, תוספות, גם מישהו מבחוץ, מחוץ לקבוצה הזאת, ירים pr, האונרז יעשו ריויו (review) זה לרוב השיטה?

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

ישי: מעבר לקוד, לראות ולהגיד זה נראה לי טוב?

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

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

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

ישי: טיפ למועמדים…

לינוי: מעבר לזה יש לנו נגיד, פרודוקט ריביו, בסדר, יש לנו סביבה של פיצ'ר ברנצ׳ס (branches) ברגע שאתה עושה פול ריקווסט עולה סביבה שלמה, שאפשר לעשות את הפרודוקט ריביו.
UI ריביו,  UX ריביו לפעמים יש סקיוריטי ריביו, יש, אני יכולה לחשוב על עוד שפיספסתי קווליטי (quality) ריביו.

ישי: כל אלה מבחינתך, קורים ב PR.

לנוי: כן,

ישי: כי אחרי המרג',  זה automatically deployed?

לינוי: כן

ישי: אוקיי, אז עשינו CD. אנחנו חייבים שהאפרוב או המרג' יהיו אחרי כל הבדיקות, אחרי כל האישורים.

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

ישי: בין אפרוב למרג'. או אפרוב 1 אפרוב 2 אפרוב 3  ואז מרג'?

לינוי: או לפחות איזשהו צ'ק ליסט, משהו שיש שם בשלב הזה.

ישי: ראיתי אנשים שעושים טמפלייט לPR ואז אנשים צריכים לסמן.

לינוי: נכון אז עשינו את זה.

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

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

ישי: דקה לכל 100.

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

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

לינוי: אז ממש תלוי כי נגיד UX ריביו. אני מניחה שUX person בחברה יעשה.

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

לינוי: אז אצלינו המרג' קורה בצורה אוטומטית, אנחנו משתמשים באפליקציה שנקראת MergeQueue

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

לינוי: לגמרי.

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

לינוי: כן

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

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

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

לינוי: בדיוק, חד משמעית.

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

לינוי: כן

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

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

ישי: אם אפשר להזיז את זה לאיזה feature flag system שהוא זה יהיה בעצם דאטה ולא קוד - מה טוב.

לינוי: בדיוק.

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

לינוי לקצר תהליך.

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

לינוי: נכון.

ישי: מעולה.

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

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

ישי: מי אני שאני אכתוב משהו ואגיד משהו?

לינוי: לגמרי, מצד שני, כשאני מגיעה לנגיד…קרה לי לאחרונה שארחנו, מיטאפ של NodeJS אצלנו בחברה, וכשביקשתי מאחד העובדים שלי שיציג משהו נורא נורא מגניב שעשינו לאחרונה ברמה הטכנית. אז הוא היה בשוק שביקשתי ממנו. ואני זוכרת ששיכנעתי אותו, בזה שאמרתי לו It's a great day to fail at something new. ופשוט הלכתי לזה בגישה הזאת. של בוא נעשה את זה כי זה חוויה בסדר. הכי הרבה זה לא יצא מוצלח. ואני יכולה להגיד שאחר כך הוא קיבל הרבה מאוד אהבה מהקהילה של NodeJS ישראל וקיבל הרבה פידבקים מאוד מאוד טובים, כתבו על הדברים שהוא עושה בלינקדין וגם החבר׳ה ב-R&D. כולם היו כזה, פירגנו לו מאוד. ושיתפו את זה ומאוד היו גאים בעבודה שלהם. בעצם משהו שהם עשו בעבודה הוא מספיק מעניין כדי שכל העם ישמע על זה. אנחנו גם כותבים בלוגים ודברים באמת, כל מיני דברים טכניים שאנחנו נתקלים בהם אנחנו משתפים חזרה.

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

לינוי: זה עניין של תורנות. מבחינתי, כשאני מובילה, בדרך כלל אני אני מאמינה ב-lead by example, אז אני תמיד תמיד אהיה הראשונה לנסות. ואמרתי לך להכשל ביום חדש וכשהם רואים שזה לא כזה נורא שזה doable וזה שזה אפילו יכול להיות כיף - כי אתה רוכש חברים, אתה רוכש, אתה שומע אנשים מעניינים, ויוצא, קצת מהעבודה היומיומית שלך, ואתה גם באמת מרגיש גאווה. בסוף בסוף אתה מרגיש גאה שיצרת משהו, שהוא מעניין שיש פה. זה לא סתם rest API וכפתור בסוף זה משהו עם מספיק תוכן כדי שאנשים יקחו ויממשו ממש. אני יכולה לספר לך שכתבתי את הבלוג הזה בגיקטיים. אנשים בתגובה אמרו לי  "וואו. לא הכרתי את הכלים האלה. אני הולך ומנסה אותם עכשיו."

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

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

ישי:כמו זה שירות משמעותי או איזה מילואים? זה בדיוק אפילו מורה, מורה, מורה לחיים מבית הספר.

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

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

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

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

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

ישי: שאלה ראשונה של מועמד…זה SaaS?

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

ישי: חכי למיילים שאתה תקבלי עכשיו.

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

ישי: זה שווה את ה-attention שאולי זה לא פתרון הכי טוב או הקריטי שאני צריכה עכשיו, אבל?

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

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

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

ישי: זה גם איזה badge,  מפתח אומר ״אני עשיתי קומיט ב Node״.

לינוי: חד משמעית כן.

ישי: או ספריה משמעותית, זה ממש…

לינוי: ממש…

ישי: להתגאות בו, לקחתי אותו לקחת אותו הלאה.

לינוי: לגמרי. אז כן, זה מאוד תורם למוטיבציה של המפתחים אצלנו, וזה גם משהו שמתאפשר לך בגלל שאנחנו בעולם של של SaaS וקצת יכולים. הדברים שאנחנו מתעסקים בהם הרבה סטארטאפים נתקלים בהם. לתרום לגמרי ספריות עוד לא יצא לנו, אנחנו מכוונים לשם מאוד. אנחנו ממש עכשיו כזה בדיונים על זה בתוך R&D נשאל איזה סוג של דברים. אני יכולה לספר שאחד הדברים שאני נמשכת אליהם זה dev efficiency ו-github actions זה אחד הכלים שאני מאוד מאוד אוהבת וממש מתעקשת לעשות בידיים. עדיין אם כבר דיברנו על hands-on  אז github actions זה ה…

ישי: זה האונרשיפ שלך בסרוויס קטלוג.

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

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

לינוי: וואו אחד או שניים?

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

ישי: או דיאגרמה

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

ישי: את קוראת לזה אתגרים של המפתח.ת. זה לא אתגרים של delivery למה הוא לא מספיק מהר אלא מה כואב לי כמפתח.

לינוי:נכון

ישי: בסוף זה הdeveloper experience למה אני קם בבוקר? מה מעצבן אותי?

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

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

לינוי: זאת התוכנית! תודה לך.

ישי: תודה רבה.
הכנסו ל-https://devinterrupted.com להירשם. תוכלו למצוא שם גם את כל הפרקים שלנו
באנגלית. אני מזכיר לכם שאנחנו ב LinearB בצמיחה מהירה, מגייסים למגוון של תפקידים בכל התחומים. בואו למצוא את האתגר הבא שלכם https://linearb.io/careers.

אני ישי  בארי, נשתמע בפרק הבא.

(מוזיקת סיום)

** לינקים לכילים והעזרים המגניבים שהוזכרו בפרק - כאן.**

(Opening music)

Dev Interrupted with Yishai Beeri and Linoy Shkuri

Yishai: Welcome to the Hebrew version of Dev Interrupted,  LinearB's successful podcast for engineering managers. Here we will talk about everything that concerns engineering managers.

I'm Yishai Beeri, LinearB’s CTO. Following the announcement of our large funding round, we’re excited to bring you the podcast in Hebrew. We will host leaders from the industry, to talk about everything that concerns or interests engineering managers, those who work with them, and those who want to one day lead an engineering organization.

In this episode, we are happy to host Linoy Shkuri, R&D Manager at JUSTT

Hi Linoy, nice to have you here.

Linoy: Really fun, thank you very much for inviting me.

Yishai: With great pleasure. So as always, we start by hearing from our guest. What is the path that brought them to here and now? What has your career looked like? From the moment you started until where you are now?

Linoy: My beginnings are quite classic. I started in the IDF's Center of Computing and Information Systems, as a developer in the Navy. I was in the Navy’s ops unit, serving for 7 years in total. After that I joined a small medical start-up. I stayed there for a few months, and I can say this is definitely not the field for me. Then I worked for a company called Kryon, which was sold not long ago, in the field of automation, and now I work as an engineering manager at Justt, which is a company in the financial services industry. It's been about two years since it was founded.

Yishai: So, is this your first position where you are an engineering manager or have you done this before and moved with this experience to Justt?

Linoy: This is the first time I started as an engineering manager. In the army I also managed several engineering teams and later also in Kryon, but this is the first time I entered as an engineering manager and this is a completely new challenge in my opinion.

Yishai: Do you still get to write code? Or are you just managing today?

Linoy: Almost only in management. The heart still pulls me towards the pull requests, but I’m almost only in the management.

Yishai: And if you look ahead, what, do you have any thoughts? Where do you want to go in the future to manage groups? Something bigger?

Linoy: Without a question, to kick start my own start-up, as CTO or VP R&D. That’s the dream, and I will get there soon, I hope.

Yishai: Be sure to tell us, and we’ll host you on our podcast again!  You yourself also have some history in the podcast world, want to tell us a little about this world of community involvement?

Linoy: Yes, in general I really, really like to contribute my knowledge and share with people. I started the Barvazgumi (rubber duck) podcast with my girlfriend.

Yishai: The very popular Barvagzumi…

Linoy: Yes. Besides that, I also volunteer at shecodes; , I gave architecture lectures to women, who have experience in employment, basically teaching them to do high level design. I volunteer as a mentor, and do mock interviews. And many things like that, and also as you know I write blogs for my pleasure. I recently blogged about a financial thing. I mentioned LinearB there, actually that's how we got here.

Yishai: We were happy :).  You mentioned shecodes; . A word about what you have seen change in the challenges of women - women in engineering management, women in engineering positions? Where has it been going?

Linoy: I want to hope it’s going to a good place. And I’ve also been working hard to make that happen. My mentorship program is also targeted as mentoring for women. Right now I can tell you that I arrived as the first woman in our R&D at Justt. After that a few more women joined, but I can say that this is really something that is challenging, in the context of recruiting women in general, and especially for management positions.

Yishai: We have room to improve.

Linoy: We are working on it.

Yishai: Great! We are with you. Justt, a young company, a company that is growing fast, and your first role, where you enter as an engineering manager. What does it mean? What, how did you feel about the challenge of leading the engineering in a very young company? And growing fast - where does this meet you?

Linoy: Wow, imagine this thing.

Yishai: What an answer…

Linoy: Let's close our eyes and think about me, on my first day or my first days in the company. I come to a company that is relatively young,  one engineering team in total, that they split into two engineering teams when I joined. - -  There are already hundreds of microservices in the company that have already been written.

Yishai: They kept busy…

Linoy: Yes, and within this process of my on-boarding, I also have to do very intensive recruiting, recruit a lot of developers, so like that, you have a lot of questions that come up at the same time. Like what are our engineering processes, where do we want to go in the context of the product? In the context of our technical roadmap? And many questions that occupy us in general in the world of our developer identity, to the developers who work for us in the company. After all, I’m selling much more than just technologies, our stack. A standard stack can be talked about. There's all the interesting technology you could want, but it's not enough. I need to create an identity for my developers, within the organization, within Justt, and because it is a new company these things come to the table as real questions. What does it mean to be a developer at Justt? What are the values around which we gather within the organization? Or even within the team, and how do we create an organization that is proud of itself? It's easy to recruit employees to it, it's easy to retain the employees. I create processes for the promotion of employees within R&D and many, many other questions.

Yishai: So before we dive into the content of these questions, what does it mean to be a developer at Justt? And how do we actually work and so on. You mention it specifically in the context of it making things easy, or it helps us recruit. This helps us retain employees. Have you come across or seen employees or more correctly candidates, who ask about these things? I mean, trying to choose the next company they're going to work for through Developer Experience questions? About how does this company work and does it suit me?  Is it modern enough? Efficient, fun?

Linoy: Unequivocally yes. Look -  technologically, there are many technologies in the world, and many startups can offer fun or interesting technologies in their stacks. And we're fine too in that regard, I’m not disregarding that for a moment. But you choose a company, you also have to believe in the purpose, of course, but you also have to imagine yourself there every day. What does your day-to-day look like in such an organization? And how does it affect your career over time. I mean writing Justt on my resume. How will this affect me? What will they think of me when I get to the next interview, and because the company is young and many times you’ll hardly have heard about it, in the context of a candidate, that comes for an interview - who are  not completely familiar with what we do from a technical perspective, and these are the many questions that actually arise in this context.

Yishai: Do you have an example of a question or topic that is a deal breaker for candidates? “If there are no tests, I’m not coming”…such things?

Linoy: Wow, I wish … “if there are no tests I’m not coming….”. Yes, there are many questions about the on-boarding process, for example, many candidates who come to interview at a start-up company think that the on-boarding process will be either difficult or non-existent or they will be thrown into the deep end, and asked to start writing code after two days.

Yishai: Two whole days.

Linoy: Yes, exactly.. so many concerns around this issue thatI need to address in the interview process. The truth is that we even have some kind of cooperation with a new start-up on this exact issue.

Yishai: for onboarding, let's give them a plug - do tell!

Linoy: There is a new company that just came out of stealth, called Wilco, an Israeli company. What they do, they do quests for the on-boarding process of developers, you sit in front of an application and it creates your own repo. You create pull requests, talk in Slack with your manager, and with DevOps, and a lot of the entire process of onboarding, which is basically learning how to work within your organization becomes a kind of game.

Yishai: Wow, and this is on real PRs in the organization's repo or all…

Linoy: No, that's all, it's an app, you're actually employed by a made-up company called Anything, and you actually create a fun process for yourself for on-boarding employees.

Yishai: Cool, I'll definitely look into it, it sounds like a great way to add some fun to on-boarding processes, which is often full of stress.

Linoy: Totally.

Yishai: It's not clear either, again this goes back to the questions of the definition of who we are . It is not at all clear when on-boarding starts, when does it end. Did I finish on-boarding? Am I already qualified? What are the expectations during onboarding so-

Linoy: This is actually part of the things I started to define when I came to the company, what is the process of moving through the recruitment process, which is also a process in itself that you have to define, but also after you recruit a person, what are the processes he goes through within the company, and setting expectations of candidates.

Yishai: Let's talk for a minute about the content of the previous questions we discussed - how do we work? What does my everyday look like? Let's say we've already done onboarding, it's about a collection of qualified developers on a team, everyone knows each other. What is important to define in this unwritten contract between us as developers? Regarding how we work? How do we generate value by modifying the codebase?

Linoy: Yes, developer ownership is very important to me, okay? I can, as a engineering manager, let my employees develop features - because I was also a developer in the past, so I also know how to define [the requirements] in a very precise way - how and what to do exactly, but this is the complete opposite of what I believe in. I believe that the creative part is the part that attracts employees to stay for a long time in companies and the accountability part. With regards to  code, say in a  microservices context. Accountability for a certain service can really connect the employee to the organization in a good way. In our case, if we go back for a second, think to yourself about my first day in the organization –  a hundred microservices – and [I’m thinking] what am I doing? So one of the questions that came up is which teams are really responsible for which services? Or where is each service in our repository, or where is the Swagger of the …, what is the actual address of the API’s Swagger?.

Yishai: Where is the architecture diagram with all the…

Linoy: Exactly, so an architecture diagram, also, all these things, think for yourself that there are many, many products, which have many, many things in common, but on the other hand, it is very difficult to find the person who is accountable, and to find the person who can explain to you about this service. And also not. Its status is not always entirely clear to you . Ok. Because let's say… I can tell you that at the beginning we started with an Express infrastructure and then we moved to Nest. So some services are written like that, and some services are written differently and we all know it. There is some kind of evolution within the architecture. And all these things, they are not completely transparent to you. So let's say for example..I recently introduced a system–that is still in POC– this system called a service catalog, which basically comes to create some order in this whole world of services, and I can define there who is responsible for each service, which is important in itself because it gives a person some real and clear ability to understand what they are responsible for. On-boarding can be much simpler because you go into each service and see exactly where it is located within the repository, where its documentation is, its Swagger as we mentioned earlier and many other things.

Yishai: Except for those services that no one included in the catalog.

Linoy: That's it, it already happens automatically. And one of the most interesting things about this product is that there is also gamification around rules. You can define, for example, that a service that is not in Nest, will have its score reduced, and then there is an incentive for a person who is accountable for this service to transfer it to Nest.

Yishai: What is it like a Wall of Shame of…?

Linoy: So yes, so it's not entirely about shame, it's actually around the glory, okay, let's say a service is good, so it gets a bronze, or he even get a gold medal, okay, so you really see which services are the best [edit for clarity: maintained].

Yishai: And it's also dynamic at the level of checking the service health and its uptime is high?

Linoy: Yes. You can really set, you can really define exactly which rules you want to include to score this service. And really this will immediately affect the service. Another thing that was difficult for us to introduce in the organization and it is part of Developer’s DNA. It's part of initiatives that are cross-organizational in R&D. I don't know if you will sympathize, I guess you will, let's say initiatives like updating the version of Node(JS) .

Yishai: Sure, what fun!

Linoy: Who is responsible for this thing?

Yishai: They are, not me.

Linoy: Exactly. So I, as a developer, can tell you that these are the things that are the least fun to deal with, because you don't fully get recognition for them. In the end it’s a task that needs to get done, that starts and ends in a way that's usually unadventurous, fine, unless you get into some kind of backwards compatibility downward spiral, but we'll leave that aside. This app, so starting with the fun things in it. The fact that you get some kind of recognition for these things is also because, in the end, your service is not running the updated version of Node. So your score has gone down, not significantly, but it goes down a bit and gives an incentive [to upgrade to the latest version].

Yishai: So you decentralized this task to service owners, everyone has a motivation, but it's not like someone owns the Node version upgrade across the board.

Linoy: That  is correct.

Yishai: But you say - it's two more points if you upgraded – and then everyone runs to upgrade because it makes them feel better. What does it mean when I am a service owner? Do I get up at night? I'm the only one who merges code, where do you put ownership versus the possibility of collaboration?

Linoy: That's a very good question, are you familiar with git owners?

Yishai: Yes, I am.

Linoy: So then these questions are necessary questions, follow-up questions. I'm still setting it up somewhere - it’s still vague, okay. We just started talking about these things in the organization. I do see how these things can go in the direction of anti- collaboration, but first of all we do currently work in a monorepo, where any line of code can be accessed by anyone.

Yishai: Anyone can knock down any service.

Linoy: Exactly, but also our owners, we defined these as teams, and not as specific people, so that really, if there is now some kind of problem in the production––it doesn't happen that much because we are excellent – but….

Yishai: It's not a bug, it's a feature.

Linoy: Exactly. So let's say hypothetically.

Yishai:  The system is not down, it is just a bit slow.

Linoy: Exactly. Hypothetically there is some problem that the team would be responsible for, but actually whoever is most free at that moment could take care of the problem and not a specific person. So while you do not receive recognition as an individual, it is a sense of collective responsibility.

Yishai: But changes in the add-on service, also someone from outside, outside of this group, will raise PR, the owners will do a review, is this usually the method?

Linoy: Yes, nice, you touched on another point, that’s  interesting. The Pull Request process is also a process that you have to define and set up in a new organization, fine, we all know Github and the Approve Button is very, very unequivocal, but we have a lot of requirements at this stage of the review.

Yishai: Beyond the code, just reviewing it and saying it Looks Good To Me?

Linoy: Yes, for sure, we have the part of the peer review that tests the nature of the code. But we have many questions that pop up in this world, let's say how good your documentation is. OK, I don't know if you've been listening to the Barvazgumi podcast. I'm  pretty crazy strict  in the context of documentation, and as far as I'm concerned, let's write documentation all day.

Yishai: I'm sure that the developers you interview ask first thing, can I write  a lot of documentation?! I have to do it - otherwise I won't come.

Linoy: Anyone who wants me to hire them should talk about documentation.

Yishai: A tip for candidates.

Linoy: Beyond that we have, say, the  product review, okay, we have a feature branches environment, where as soon as you create  a pull request, a whole environment comes up, where the product review can be done. UI reviews, UX reviews, sometimes there is a Security review, yes, I can think of more that I missed Quality review.

Yishai: All of these, according to you, happen in the PR process?

Linoy: Yes,

Yishai: Because after the merge,  it's automatically deployed?

Linoy: Yes

Yishai: Okay, so we have CD. We need the final approval to come after all the tests, after all the approvals.

Linoy: True. If some of our listeners are thinking about founding startups, here is an idea: [approval] stages.

Yishai: Between approval and merge. Or approve 1, approve2, approve 3 and then merge?

Linoy: Or at least some kind of checklist, something that is there at this stage.

Yishai: I've seen people make a template for PR and then people have to mark it.

Linoy: That's right, so did we.

Yishai: But it's  text, in the end it's  text. It's interesting, we've been thinking a lot lately about this world of pull requests and you describe a complex structure, there's also some element of, not all pull requests needing the same structure or needing the same treatment. To the more extreme end of the spectrum, where  there are even pull requests that may not need review at all. What do you make of it - are you  trying to be more dynamic around these decisions?

Linoy: Right now it's still in the experimentation stage. But we totally see this. Let's say, we have an amazing monitoring tool called LinearB, which helps us analyze these exact steps in the engineering process. The pull request process, the collaboration and how long it actually takes and what exactly happens there. Okay, so what kinds of comments do we have in this process at this stage of the code, and yes absolutely. I mean, I can say there are a lot of cases that pull requests  that you expect to have a long review, suddenly you go in and they have a review  time that is short, let's say 300 files and it took 3 minutes to review.

Yishai: 1 minute per 100 files.

Linoy: Right then, yes. So these are things you don't want to happen in the organization, and you need to really see why these things happen. And really how to turn it into something that is methodical. OK? It's not good or bad, but hey and it's something that could very well be that all those 300 files are configuration files, and in this case it would make sense to have 3 or however many seconds for review, but yes I would like to see someone who at least  paid attention to security or PII - Private Information.

Yishai: And from your point of view, these different issues require different people to do the review, or do I sit and do the review and have to think about the code, about security, about PII. But it's still all me.

Linoy: So it really depends because let's say a UX review. I guess a UX person in the company will do it.

Yishai: About the dynamic environment according to which and if I look at approve  vs. merge at the end of these two significant actions, do you see any advantage of one over the other? In terms of where to concentrate the complexity, the definition of the process.

Linoy: So with us, the merge happens automatically, we use an application called MergeQueue. Then.

Yishai: So, according to you, Approve is the same as Merge? Okay, so.

Linoy: Absolutely.

Yishai: You saved [some complexity] and actually the Merge and the MergeQueue are only used for you to do another set of automatic tests before this code actually is merged into the codebase.

Linoy: Yes

Yishai: What about, like, the review process - how do you make sure it happens after the tests and checks have run and successfully passed the PR, even before I look at it?

Linoy: A lot of these things I mentioned can really be solved at the CI level. It's true, we talked a little bit about the security reviews. You might trust an app to do it for you. OK, there are many tools you can integrate into your CI that will check the code. And actually when I come and approve the code, it's already after this test has run. We have another tool that we recently integrated in the world of static code analysis, so I can see, let's say, there is no code duplication or more broadly, basic code issues that software can actually check for me, and also code coverage. That checks for us if we have hit the code coverage, and maybe even do some kind of threshold, in order to check in this pull request at all.

Yishai: And then the thought is that if I integrate tools, I can reduce the load on the reviewer or reduce manual steps.

Linoy: Exactly, absolutely.

Yishai: And at least in the simple cases, with Security tools, you may not need Security's review. I said -  maybe.

Linoy: Yes

Yishai: Of course if you have to think about in which cases would you say this pull request - in my opinion,  doesn’t require a review  at all.

Linoy: So there are all kinds of cases like that, for example. I mentioned, let's say, configuration changes that are relatively easy, and now we've made an integration with a third-party service for Feature Toggles, which actually comes to answer this need in the first place. Because I don't want to have a pull request for changing configurations at all, by definition. But sometimes it's just that, that is the situation. Then such a pull request is yet another pull request. And I have a lot of operational  costs around it.

Yishai: If it is possible to move it to some feature flag system, it will actually be data and not code, which is good.

Linoy: Exactly.

Yishai: But you say where it is still code I can define some kind of wrapper, I mean. Those pull requests…

Linoy: To shorten the process.

Yishai: Merge them automatically. They are not, of course, there are tests, there are systems, but I don't need any more developer time just to look and understand that this is a config change.

Linoy: True.

Yishai: Great. Let's talk about - about community again. Not exactly your personal activity, but as a manager of developers in the company? How to tie them to contribution back to the community. I'm not talking about volunteering, in some daycare or building something, but in our community as developers. Do the developers want to participate? Want to talk, produce content, what are they interested in, how do you touch these things?

Linoy: First of all, I really believe it's important. Wholeheartedly,  as far as I'm concerned, they should do it as much as possible. It contributes a lot to the organization as well, and even if we were talking about the recruitment process, then obviously it helps me in the recruitment process, and to enable candidates to get to know the company, because it is a new company. It needs to build itself a name. Speaking for myself, both as a developer, and also now as an engineering manager––I think it motivates the employees, the fact that the company's name is associated with something that is professional. We are used to looking at people who write blogs about NodeJS as people who are very, very professional and that really impresses us, at least from my personal experience. And when you do that, of course, imposter syndrome comes up immediately with all of my developers.

Yishai: Who am I to write something and say something?

Linoy: Absolutely, on the other hand, when I get to… this recently happened to me. We hosted a NodeJS meetup at our office, and when I asked one of my developers to present something pretty cool that we did technically, he was shocked  that I asked him. And I remember that I convinced him, by telling him It's a great day to fail at something new. And I just went at it with this attitude of 'let's do it because it's an experience' okay. Worst case it won’t be successful.  And I can say that afterwards he received a lot of love from the NodeJS Israel community and received a lot of very, very good feedback, the things he worked on were written about on LinkedIn and also in the company R&D, everyone showed him a lot of respect and appreciation. And they all shared it and were very proud of their work. Something they did at work was actually interesting enough for the whole nation to hear about it. We also write about our work,  blogs and such, all kinds of technical stuff we come across and share back.

"Today is a Great Day to Fail at Something New"

Yishai: You manage to reach a wide part of your engineering group with these activities, or it's one or two that it suits them, turns them on, they like to stand in front of an audience. And then there’s all the rest.

Linoy: It's a matter of taking turns. For me, when I lead, I usually believe in leading by example, so I will always always be the first to try, and I told you to fail at something  new each day. And when they see that it's not so bad that it's doable, and that it can even be fun because you make friends, you hear interesting people speak, and get out of your daily work a bit, and you also really feel pride. At the end of the day, you feel proud that you created something, which is interesting to have here. It's not just a rest API and a button, at the end it's something with enough content so that people will take it and really implement it. I can tell you that I wrote this blog on Geektime. People in response told me “Wow. I wasn’t familiar with  these tools. I'm going to try them now”.

Yishai: I always encounter this gap with people, doing cool things, writing and solving problems in code. When you talk to them about ‘hey - let's talk about this, let's write about it’. So the response is usually  a combination of “who am I to talk about this? After all, in the end I solved it, so it's probably not that difficult and not that complicated. It won't interest anyone,..” Which is also not true. And sometimes eventually developers don't always feel comfortable in this realm of speaking, speaking in front of an audience, to demo….

Linoy: You don't know this about me, but I really, really like audiobooks and am very intrigued by Soft Skills, half the time I’m a psychologist in our organization, and I really drive them to this by  explaining that everyone feel the same way in such a  situation and everyone will feel it during the situation. And when you're excited and your heart beats fast, it means you're doing something that makes a difference. You don't finish a normal work day, with a constant feeling of satisfaction. And when you do something new then, yes, it stresses you out, but this pressure is good, it means that you will remember this period in your life, or this moment in your career, you will remember. And that is exactly what I came to do, that the time my developers are with me, will be a time they remember, that they’ll be able to say during this time I earned this thing or I did this other thing.

Yishai: So this is like [how we remember] a significant [military] service or reserve duty? It's exactly even a “teacher for life” from school.

Linoy: And it's not necessarily connected to me. I mean, it's something they do on their own, but the very fact that they did this thing, and put themselves in front of people or exposed themselves will actually make them appreciate that moment later. Really a day after that you already feel really more significant.

Yishai: In the end, people like feedback. Even after all the difficulties I mentioned, and the desire to stay away from the spotlight. The feedback, I think, produces different feelings in all of us than feedback about an excellent pull request I picked up or an excellent feature I wrote.

Linoy: We'll hardly remember those, that's all. And by the way, the same thing about the developer on my team, which while the  feature was a very significant feature to me, but if we had continued on our way and not talked about it, I'm not sure that it would have been something that he thought was that significant. Or his impact inside the organization or outside the organization would have been  as significant as when he stood up at NodeJS Israel, Israel at a meetup and talked about it.

Yishai: You mentioned some of the startups and companies whose products you  have integrated with, it seems that beyond the value that you get from these products, you choose to work specifically with young startups for such things. Do you see that as a certain role in this world?

Linoy: Definitely, this is the first time in my position at Justt, it's the first time I've been in an organization that makes a real SaaS solution, so it's really the first time I've been exposed…

Yishai: The candidate’s first question…is it SaaS?

Linoy: So yes, but really. SaaS, CI/CD, it’s amazing, it's just a world that until you enter it—you don't know how it feels, right? And I'm suddenly exposed to the ability to use Israeli startups. Startups in all kinds of fields. We talked about on-boarding, but it's also about the service catalog, or LinearB, but really, I almost manage to integrate with every party who talks to me or I manage to make contact with. And yes, I'm totally enjoying it. Recently I even had a technical conversation with some start-up - Helios, that they are building microservices tracking capabilities, to create a kind of dependency graph, and this also helps you with testing. I'm very, very good at advertising here.

Yishai: Wait for the emails you’ll receive now.

Linoy: Yes, and when I went up to talk with them, then suddenly I met someone, volunteering with me in the mentorship program. And it was simple, wait a minute, very fun to see that it's not just that you’re coming to listen about possibly integrating a  new tool for a start-up that's just getting started, and provide them with feedback,but in the end, it's also people you meet in the industry, and it's your friends, and it comes  back to you.

Yishai: It's worth the effort, maybe it's not the best or the most critical solution I need now, but?

Linoy: No, I never push it. I'm really me. I always ask the questions, do I need this tool and what exactly does it provide? There are also examples

And there are also examples of startups I didn't integrate with, but yes, I make connections all right, so it's possible that I'll do it for some startup that won't fit Justt, but I do know other startups that can use this tool and make connections to them  as well.

Yishai: What about Open Source, working with the community? Ultimately contributing value back, through code––is that something you look at and touch?

Linoy: Yes, I can say that with us it's a bit challenging, since just because you write something that is suitable for open source, that doesn't mean it's ready for open source, and there is quite a heavy dev effort that you have to invest in order to push it out as open source. When it comes to small pull requests, of course if we find some kind of bug in an open source project we use at Justt, we will definitely fix it upstream.

Yishai: It's also an important badge when a  developer says, I committed to NodeJS.

Linoy: Absolutely -  yes.

Yishai: Or an important library..

Linoy: Really.

Yishai: It’s something to take pride in, to take it forward.

Linoy: Absolutely. So yes, it greatly contributes to the motivation of our developers, and it is also something that is possible for you because we are in the world of SaaS and can contribute a little bit. The things we deal with a lot Startups encounter as well. We haven't had the chance to contribute complete libraries yet, we are very much aiming for that. We are right now in discussions about this within R&D, asking what kind of things. I can say that one of the things I am drawn to is Dev Efficiency, and Github Actions is one of the tools that I really, really like and really insist on doing manually.  if we've already talked about  hands-on - for me it’s Github Actions.

Yishai: This is your ownership in the catalog service.

Linoy: Yes, not really though, most of the things our DevOps configures, but it's still hard for me to let go completely because I really like this tool. So let's say recently I had the chance to build a Github Action related to the world of end-to-end testing, and we thought of contributing it as open source.

Yishai: Amazing! Towards the end, If you think about an engineering manager who is just getting started in a position in a young start-up or a first role as an engineering manager, or even a developer you are looking at–who would say that’s what I want to do, I want to move toward that role. One or two tips you can offer, on what to pay attention to and what to invest in?

Linoy: Oh wow - one or two?

Yishai: Or ten…

Linoy:I have, I have a lot. This is just part of what we talked about here today. I am concerned, at first, with what developers suffer from? It may be a bit of a harsh word, let’s maybe change it to - what are developers' challenges? So I would start first of all, really with monitoring tools. This is the first thing you need when you enter an engineering organization that is already functioning, and you enter in a management position, so you need to learn a little what their day-to-day looks like to identify– what is difficult for them? OK, I can say that at Justt, I recognized that the on-boarding process was complicated, because it lacked documentation and lacked a catalog.

Yishai: Or a diagram

Linoy: Yes diagrams and confluence and such. So I will say something that is an important tip, but first of all be on the side that sees and does not criticize;  analyze and validate with people what their challenges are, and try to address it. Try to address each of these challenges.

Yishai: You call it the challenges of the developer. It's not delivery challenges––why it's fast enough––but what pains me as a developer.

Linoy: True

Yishai: In the end it's a Developer Experience thing. When I get up in the morning - what’s going to annoy me today.

Linoy: I look at my role as having  two main things that I do, when I get up in the morning. The delivery - and that’s relatively straightforward;  and the people–either to recruit people or retain people–  basically to retain my employees and make this work something they love and are proud of. And wanting to stay for a long time is fine. I never looked at developers as temporary. I really look at this as  a stage of every developer’s career on their way up, and it needs to be as meaningful as possible and as much fun as possible.

Yishai: Excellent, Linoy, thank you very much for being with us. We were very happy to host you. We learned a lot about what it means to manage engineering in a young company, about how to think and define the everyday, and the role of a developer in a company. About the importance of the Developer Experience - and I leave here with a feeling that the developers that work for you won't forget this phase of their career so quickly.

Linoy: That's the plan, thank you.

Yishai: Thank you very much.

Visit https://devinterrupted.com to register - you can also find all our episodes in English there. I remind you that we are rapidly growing at LinearB, recruiting for a variety of positions. Come find your next challenge at https://linearb.io/careers.
I am Yishai Beeri. We'll meet in the next episode.

(Closing music)

Links to the nifty tools and resources mentioned in the episode:

• BarvazGumi
• SheCodes;
• MentorMe
• NodeJS Israel
• Wilco
• MergeQueue
• Helios
• Github Actions