Developer Experience - Why is it So Important Really? Dan Leshem, Creator - Dark Mode, and Yshay Yaacobi, Livecycle

בפרק הזה נצלול פנימה לבאזוורד הכי חם כרגע - Developer Experience  עם שני אנשים שמכירים את זה מקרוב. דן לשם, יוצר הסדרה Dark Mode שחוקר את הנושא עם קבוצות פיתוח בחברות הגדולות בישראל, וישי יעקובי CTO ו Co-Founder ב Livecycle שמנסים לפתח מוצר שיענה בדיוק על הצרכים הללו.  ישי בארי שואל לא רק על איפה זה פוגש ארגוני פיתוח היום אבל גם דואג שתצאו עם כילים כדי לשפר את חווית המפתח אצלכם בארגון.

In this episode we take a deep dive on the current resident buzzword - Developer Experience -  with two folks who have quite a bit of firsthand experience. Dan Leshem, creator of the series Dark Mode that investigates this topic with engineering organizations of large companies in Israel, and Yshay Yaacobi, CTO & Co-Founder of Livecycle who are building a product to solve for these exact problems.  Yishai Beeri asks how this impacts engineering organizations and ensures you leave this episode with tools to improve DevEx in your organizations as well.

Transcript

Episode Transcript תמליל הפרק

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

(*Translated with Google Translate - so there may be some errors. Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)

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

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

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

ישי: בפרק הזה אני שמח לארח את ישי יעקבי, מייסד ושותף ו-CTO ב Livecycle, היי ישי.

ישי יעקבי: היי.

ישי: ואת דן לשם, היוצר של Dark Mode ומייסד של FineDev, אהלן.

דן: שלום, שלום.

ישי: איזה כיף שאתם פה.

דן: כיף גדול.

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

ישי יעקבי: אוקיי, אני אשמח. אז בעצם תמיד אהבתי לתכנת, זה היה משהו שמאוד עניין אותי גם מגיל מאוד צעיר, גם שהייתי ילד וגם אח"כ בתיכון לקחתי עוד מסלול של מחשבים, בצבא יצא לי טיפה להתעסק בתכנות, גם במדור כזה של מיחשוב, ואחרי שהשתחררתי בעצם התחלתי לעבוד בחברה שהתעסקה בבניית אתרים וגם קצת בעולם של מובייל וסושיאל, ובעצם ההתחברות הממש גדולה שלי למקצוע הייתה שהתחלתי לעשות בחברת Soluto, הייתי שם 8.5 שנים, שם יצא לי לעבוד בערך בכל תפקיד מבחינת תפקידים טכניים. בתור מפתח, frontend, backend, DevOps, ארכיטקטורה, ושם גם מאוד התאהבתי בעולם הזה של גם כלי מפתחים וכל מה שקשור ל-developer experience, ואחרי שהייתי 8.5 שנים שם החלטתי להקים חברה, עשיתי את זה עם שני שותפים שהם חברים טובים, אחד הכרתי ב Soluto, שהוא עבד איתי, החבר השני הכרתי בעקיפין דרך "סולוטו" כי אשתו עבדה שם, וככה התחיל המסע לעבר ה"לייף סייקל" שעכשיו אנחנו נמצאים בזה בערך שנתיים, וזה באמת חברה, אני אדבר עליה בהמשך יותר בהרחבה, שמתעסקת בעולם הזה של איך באמת לשפר את החיים של צוותי פיתוח.

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

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

ישי: וואלה, אז אנחנו נשמע עוד על "לייף סייקל" ונעמיק, דן, תספר לנו על הקריירה שלך.

דן: טוב, אני חייב את קריירת הטק שלי להארי פוטר, אני בתור ילד הייתי פריק של הארי פוטר ורציתי להקים אתר, אז קראתי הארי פוטר בספרייה וליד הארי פוטר היו ספרים של תכנות אז למדתי ככה PHP והקמתי את האתר של הארי פוטר ומשם התגלגלתי. שנה אח"כ כבר התחלתי לחלטר בפיתוח אתרים ומפה לשם אני עושה את זה 15 שנה, בתור מנהל צוותי פיתוח, הייתם ב OrCam כמה שנים, ניהלתי שם את צוות המובייל וזהו, הקמתי. אני גם יזם בנשמה שלי אז הקמתי, אחרי "אורקם" הקמתי סטארטאפ שלי, עשינו קצת צ'אט בוטים ל customer support, היה לנו good run של שנתיים ונסגר וזהו, היום אני עושה את Dark Mode ודברים אחרים.

ישי: אז בוא תספר לנו קצת על Dark Mode, מה זה Dark Mode למי שלא מכיר?

דן: Dark Mode זה סדרת רשת על developer experience, על חווית הפיתוח ותרבות ה engineering בחברות פה באקו סיסטם, בישראל. בעצם לפני שנה אני וכמה חברים שמענו על developer experience, שמענו על זה קצת מ Netflix ושמענו מ Spotify ושמענו שנהיה קצת הייפ סביב הדבר הזה ורצינו לעשות על זה דאבל קליק, להבין מה יש שם, והתחלנו לייבא את הקונספט הזה לישראל, ותוך כדי שאנחנו חוקרים אז עלה רעיון לעשות סדרת רשת ביחד עם חברות כמו Wix ו AppsFlyer ו Ziprecruiter ו Taboola ועוד כמה שמות גדולים פה בתעשייה. שבעצם במסגרת הזאת באנו אליהם, למשרדים שלהם, ישבנו עם כל המפתחים והמפתחות במשך שעות, היה לנו אני חושב כמעט 80 שעות של תוכן שהקלטנו איתם ועוד הרבה שעות של תחקיר, ורצינו להבין כאילו מה, צרות של מתכנתים, כאילו העולם הזה כל כך מורכב, מה זה באמת developer experience, מה יש שם. אז שמענו מהם ולקחנו בסוף את כל ה-60, 80 שעות של תוכן הזה וכיווצנו את זה ל-10 פרקים, כל פרק 10 דקות, הייתה לנו עבודת עריכה מאוד מאוד קשה, זהו, וכל פרק מתמקד בעולם תוכן אחר, בשלב אחר בתהליך הפיתוח.

ישי: ואיזה מן תגובות אתם מקבלים לDark Mode? אוקיי, יש סדרה, מי מקשיב לזה? מה אתם שומעים, איזה אימפקט זה עושה על העולם, על התעשייה כאן?

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

ישי: אז ב Dark Mode אני אמצא הד למה שכואב לי? הנה, גם זה כואב לאחרים, הנה, נתנו לזה שם? או שאני גם אמצא פתרונות?

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

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

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

ישי: אוקיי, אז FineDev זה מוצר? זה קומיוניטי?

דן: זה מוצר.

ישי: שמה, תן לי את הפיטצ' בכמה,

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

ישי: זאת אומרת מתחבר ל codebase שלי ומבין את הארכיטקטורה הנוכחית ומשם ממליץ מה לשפר, מה לשנות?

דן: כן.

ישי: וואלה. איזה אזורים בקוד? ה Terraform שלי? דברים כאלה או ממש הקוד האפליקטיבי?

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

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

ישי יעקבי: אז Livecycle בעצם זה מוצר sas שנועד לאפשר לצוותי פיתוח לעבוד בצורה יותר יעילה, בעצם יש פה שני מרכיבים, מרכיב אחד זה המרכיב ה infrastructure. Livecycle בעצם בונה סביבות preview מה repository, כאשר המטרה היא שלכל PR תהיה סביבה חיה שאפשר לחוות מה קורה במוצר. במוצר נגיד ויזואלי הדבר הזה נותן המון המון כוח לאיך אפשר לעשות review בצורה יותר טובה, כי מלא פעמים נגיד אם אני עושה code review על משהו ויזואלי, אני לא רואה את זה נגיד בעיניים שלי. אני לא רואה מה הבעיה, איפה הבאגים, אני רואה בעיקר קבצי טקטס. ומעבר לזה, במוצר ויזואלי אנחנו רוצים אולי להכניס את שאר הצוות, זה יכול להיות אנשי מוצר, יכול להיות מעצבים, יכול להיות QA לתהליך ה review בשלב יותר מוקדם, הרבה לפני סטייג'ינג, בעצם ככה אנחנו יכולים לעשות שבזמן שהמפתחים עובדים על ה-PR, הם כבר מתחילים לקבל את הפידבק כמו שהיו מקבלים את זה ממפתחים, והם לא צריכים לחכות שזה יגיע לסטייג'ינג או להשתמש ב feature flag, הכל יכול לקרות הרבה הרבה יותר מוקדם, והמטרה היא בסוף לחסוך המון פינג פונג שמפתחים מכירים את זה, פינג פונג שקורה הרבה בין אנשי פיתוח לדיזיין, לפרודקט. והשאיפה היא שברגע ש-, בעצם כדי לפתור את הבעיה הזאת יש שני אלמנטים שאנחנו משלבים במוצר. אחד זה איך אנחנו מנגישים את מה שקורה בקוד, בעצם הסביבות preview האלה, והבעיה השנייה זה איך אנחנו יוצרים תקשורת יותר טובה. בשביל לתת תקשורת יותר טובה, בעצם בסביבות preview אנחנו ממש מטמיעים כלים שהם embedded, כזה ב overlay, שמאפשרים להציע שינויים של קופי, שינויי CSS, להקליט תמונות, לצייר, להקליט וידאו-ים, ובעצם יוצרים כזה ת'רד של תקשורת שכל הצוות יכול לדבר בו, שהוא גם ממש מסונכרן לפול-ריקווסט או לג'ירה טיקט שמחובר או ליניאר טיקט או סלאק או מה ש-, הכלים שהארגון משתמש בהם.

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

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

ישי: אז הכול מרוכז ב-PR בעצם.

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

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

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

(מוסיקת מעבר)

ישי: אז אני רוצה דן להשתמש ב-, הזכרת את המונח הזה DX, בוא נצלול קצת, בוא ננסה להבין, מה זה DX בעיניים שלכם? מה זה developer experience?

דן: כשאנחנו התחלנו לחקור את הסיפור הזה של DX מה שראינו, אם אתה תחפש עכשיו what is DX בגוגל או ב-ChatGPT, אתה תקבל הקבלה של, זה כמו user experience, אבל למתפתחים, developer experience. אני חושב שההגדרה הזאת היא קצת חסרה, משהו שמה לא ברור לי עד הסוף, מה זה אומר user experience למפתחים? השאלה שקודם כל נשאלת היא למה בכלל לדבר על experience של מפתחים? אנחנו צריכים, אנחנו חברת מוצר, אנחנו צריכים לדבר על הוואליו שאנחנו נותנים ללקוחות שלנו, וזה מה שחשוב. ואני חושב שאיפה שהדברים מתחילים להתחבר זה שאתה מבין כשהדברים מתחילים לזוז לאט יותר בתוך החברה שלך. ולמפתחים לוקח זמן לעשות את המשימה שלהם או מתעסקים יותר מידי בתשתיות. וכל דבר הוא כזה קצת יותר איטי או תלוי בהרבה גורמים ובאנשים אחרים, זה איפה שה-developer experience הזה מתחיל להישבר, וזה איפה שבסופו של דבר אתה רואה שזה משפיע גם על ה value שאתה נותן ללקוחות שלך. כי הדברים מתחילים לזוז לאט יותר, הדברים מסורבלים יותר, ובסופו של דבר מי שנפגע מזה זה הלקוחות שלך. יש, אני לא יודע, אולי המאזינים שלנו כבר מכירים, אבל יש את המחקר המפורסם של מקינזי שהראה שחברות שהפרודוקטיביות של המתכנתים שלהם גבוהה יותר, בסופו של דבר מראים שורת רווח גבוהה יותר או ביצועים של פי 4 או 5 יותר ב revenue אז אולי לא עניתי לשאלה שלך מה זה developer experience, אבל התחלנו לדבר קצת על ה-למה developer experience.

ישי: אוקיי, אז אתה אומר כמה קל או קשה למפתחים לייצר value באפן שוטף, ואז אתה אומר לפחות בעיניים של velocity ו productivity, אם ה experience לא טוב, החברה תזוז לאט, חברה שהיא נשענת על פיתוח וטכנולוגיה תיפגע.

דן: כן. 

ישי: ישי, איך בעיניך מגדירים developer experience?

ישי יעקבי: אני גם חושב שהמושג עצמו עדיין לא לגמרי ברור, כאילו אפשר לדבר על משהו שהוא יותר קרוב ל-UX שבו אנחנו מדברים למשל איך טרמינל או API אמורים להיראות או דוקיומנטציה, אבל אני באמת יותר מתחבר לכיוון שבו אנחנו מסתכלים מה הכאב שבו מפתחים חווים ביום יום ובעצם איך אנחנו הופכים את זה להיות משהו שהוא יותר קל. בעצם כמפתח, ואני חושב שכל מי שלמד תוכנה בשלב מסוים נכווה, חווה את הדבר הזה שאתה לומד איך לתכנת, אתה לומד איך לכתוב אפליקציה, אתה לומד איך לכתוב קוד, אבל המון מהבעיות שאתה הולך להתעסק בהן בחיים הן לא קשורות לזה, הן קשורים בעצם לדברים שקשורים אולי ל delivery, או release, אולי לsource control אפילו, עבודה בצוות, קוד ריביו, באגים בלהרים את הסביבה, כלי שלא עובד, ובעצם המון מהיום יום שלנו זה מן כזה לשרוד בין המון כלים ומערכות ולנווט ביניהם בצורה כזאת שעדיין נהיה פרודוקטיביים, שרצינו לעשות איזה משהו והצלחנו להגיע לשם ולא כאילו נתקלנו בהמון מכשולים, וזה יכול להיות בכל מקום, זה יכול להיות נגיד בפרודקשן שקשה לנו לדבג איזה בעיה או אנחנו לא מצליחים לנטר משהו, ויכול להיות שה-IDE שלנו לא עובד בגלל איזה אקסטנשן או בגלל איזה plugin, בעצם היום יום שלנו כמפתחים זה מן כזה שדה מוקשים.

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

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

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

דן: אני חושב שנהייה מסובך. נהיה מסובך, אנחנו, כאילו כשאני התחלתי לכתוב קוד לפני 15 שנה, היית כותב איזה HTML, פותח שרת FTP, וזהו, היית עושה דליברי. והיום יש רק את הפוסטר הזה של ה-CNCF של הכלים, אני חושב פעם אחרונה שבדקתי זה היה 1,117 כלים, זה בטח מאז עלה בעוד איזה אלף. וכאילו נהייה מסובך לפתח תוכנה, יש המון context שצריך להחזיק, המערכות נהיו יותר מסורבלות, ובסוף אתה, מה שאמרת לפני רגע, בתור מפתח אתה רוצה רק לשנות שורה קטנה ואתה בא לעשות את זה ואתה מגלה שאתה מבזבז שבועיים.

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

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

ישי יעקבי: כן, אני חושב שזה גם נובע, אלף, מפתחים הם היום הרבה יותר owners על דברים שבעבר הם לא התעסקו בהם. כלומר היום מפתחים, בטח מוצר, דבר שמפתח יכול להיות fullstack, הוא גם מתעסק frontend וגם נגיד backend, DevOps, זה גם משהו שמפתחים היום כן נוגעים בו. פעם מפתחים לא נגעו בהכרח בפרודקשן, כאילו זה משהו שהוא מאוד empowering, אבל מצד שני זה פתאום הופך למן, אני בתור מתכנת אני לוקח ownership על ה quality של המוצר, על זה שהוא יעבוד טוב בפרודקשן, על ניטור שלו, על המון דברים שבעבר לצוו פיתוח הוא לא היה ה owner של זה. עכשיו זה בא ביחד עם תחום שמאוד מתפתח ובעצם גם בהמון כלים שונים, אבל כאילו אף אחד מהם עדיין לא, כאילו לא הגיע למצב של אולי סטביליטי שהוא נהיה כאילו סטנדרט, אפילו נגיד בבק אנד אנחנו רואים את זה כל הזמן שעכשיו בעצם כל הסטק בעצם נבנה מחדש סביב נגיד קונטיינרים ו Kubernetes, אפשר להגיד שגם בפרונט אנד זה קרה סביב ה frontend frameworks הם כל הזמן משתנים ואני חושב שיש כאן מן אבולוציה שעכשיו היא מאוד טובה, היא מאוד מעניינת, היא מאפשרת יותר, כי גם הביקוש למה שתוכנה יכולה לעשות ואיפה היא נכנסת ונהיה יותר בכל מקום, מפתחים נכנסים בכל פינה, מהפרונט אנד לבק אנד ולדב-אופס, והמערכת הזאת מאוד זזה ותוך כדי שאנחנו זזים יש מלא בלגן, דברים נשברים, דברים אולי זזים.

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

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

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

ישי: ואז זה אומר שיש צוות אחר? יש מישהו אחר שאחראי למורכבות הזאת בשבילי? צוות ה DevOps או Platform Engineering?

ישי יעקבי: פלאטפורם, כן.

ישי: שם בונים בעצם cookie cutters ודואגים לזה שאני יכול לעשות רק את השינוי בקוד וכל השאר זורם?

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

ישי: תגיד דן, מה ראית בעבודה על Dark Mode ובעצם ניתקלתם או דיברתם עם הרבה מפתחים על הכאבים האלה, אתה יכול להציף מה הן הנקודות שהכי הרבה עלו? שעלו בצורה חזקה? שחברות שונות נתקלות שוב ושוב באותה בעיה? איפה הכאבים הגדולים של ה-DX?

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

ישי: עשיתם word cloud על הדבר הזה?

דן: כן, עשינו סוג של word cloud ומיפינו 81, אנחנו קוראים לזה DX killers או DX blockers, 81 דברים שכולם התלוננו עליהם. שחזרו יותר מ-3 פעמים בשיחות שלנו עם מפתחים, והיה שם באמת הכל מהכל, היינו מאוד מאוד רחבים. זה לא היה רק בתשתיות, ואת הדבר הזה אני חושב שאני יכול לצמצם ל-5 דברים. ל-5 קטגוריות כלליות. הדבר הראשון זה מן הסתם כל מה שקשור ל infrastructure, אני לא רוצה להתעסק ב logs, אני לא רוצה להתעסק בחיבור ל database, אני לא רוצה להתעסק ב-, אני לא רוצה להיות איש DevOps. אני לא רוצה לדעת מה זה Kubernetes ואני לא רוצה Helm Chart ואני לא רוצה Terraform. תנו לי בבקשה לכתוב קוד, תנו לי לעשות git push, ושהוא ימצא את דרכו לפרודקשן. אז זה היה המון DX killers בקטגוריה הזאת. דברים אחרים, היה לנו coupling, ברגע שאני תלוי בעבודה שלי, ברגע שאני מחכה ל code review ממישהו וזה לוקח קצת יותר מידי זמן, ברגע שאני תלוי במישהו שלתאם איתו את העבודה שלי, זה מתסכל, אני שוב מחכה, אני עושה קונטקט סוויץ', אני הולך למשימה אחרת.

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

דן: אז גם וגם, וגם דברים בסגנון של מישהו שובר לי את ה-API, אני עושה איזשהו שינוי ומישהו שובר לי את זה.

ישי: זה לא קורה אף פעם (צוחק).

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

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

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

ישי: אתה אומר כל המקומות שאני משלם את החוב הטכני שנצבר או האמת היא משלם רק את הריבית.

דן: כן, בדיוק.

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

דן: בדיוק.

ישי: ועוד הזכרת את התפר הזה בין פרודקט ל engineering.

דן: נכון.

ישי: Requirements מה, לא ברורים מספיק? 

דן: Requirements אף פעם לא ברורים מספיק, אף פעם לא ברור מה זה definition of done.

ישי: Acceptance.

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

ישי: וכיוון שאנחנו רואים שהעולם הזה של DX תופס פתאום ניראות ותאוצה, מהניסיון שלכם והעבודה שלכם, ב Livecycle זה בטח מול לקוחות או מול prospects, איך אתם רואים את השינוי הזה בארגונים, מבחינת, פתאום יש owners? אנשים שזה התפקיד שלהם? יש VP Developer Experience? איך השינוי הזה קורה?

ישי יעקבי: אנחנו רואים שיש יותר מפתחים שהם platform engineers, שהם בד"כ יכולים להיות הלקוח למוצר שלנו, אנחנו רואים שיש פשוט גם מודעות הרבה יותר גבוהה לעניין הזה, כלומר שמתעסקים בשאלות של דליברי אז מתעסקים באיפה המפתחים בעצם מבזבזים זמן, איפה יש פינג-פונגים. מה גורם להם להגיע ליעילות גבוהה כמו שהם יכולים להגיע, והרבה מהדברים האלה הם באמת סביב או דברים שקשורים לארכיטקטורה שבאמת אנחנו רואים שמדברים עליהם בשלב יותר, כלומר שאנחנו דיברנו עם חברות אז כל השאלות שלמשל אם זה monorepo או כמה repositories או איך עושים CI/CD או כל הדברים האלה, בעצם כולם מתעסקים בשאלות האלו, הם שאלות שהם כאילו מעניינות כי בסוף הם רוצים לאפטם את התהליך דליברי שלהם כדי לדחוף את הביזנס וואליו כמה שיותר מהר. אז כאילו זה כן מרגיש משהו שתמיד מעניין ברמת ה-VP R&D או ברמת אפילו גם, הייתי אומר אפילו בכל level, גם כשאנחנו מדברים עם המפתחים עצמם הנושאים האלה,

ישי: אתה אומר יש מודעות ו platform engineers מקבלים יותר ויותר משימות או דגשים שקשורים ל-DX, אתה רואה אבל גם אנשים שממש כאילו הגדרות תפקיד סביב DX? ומישהו שהוא owner?

יעקבי: עדיין לא יצא לי להיתקל בזה, אבל זה כן משהו שכאילו גם אם זה לא במסגרת תפקיד, זה משהו שקורה, יכול להיות שה tech leads מתעסקים בזה, יכול להיות שה platform engineers, לפעמים זה אפילו DevOps, זה מאוד,

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

יעקבי: כן.

ישי: מה אתה רואה דן?

דן: אני דווקא רואה שזה משהו שמפעפע מלמטה, בד"כ יהיה איזשהו צ'מפיון בתוך החברה, זה יהיה איזשהו אולי אפילו IC או טים ליד שלוקח על עצמו להעלות את המודעות של הנושא של DX בתוך החברה. ואז אנחנו רואים את זה בכמה אופנים, או שזה באמת בא מלמטה, ויש מישהו שהוא עכשיו ה owner של זה וזה נוסף לתפקיד. או שיש ממש צוותים, ראינו חברות שיש להם ממש Head of Developer Experience, בחברות מסוימות זה נקרא פלאטפורם אינג'נירינג, בחברות אחרות זה צוות שהוא רק אחראי על ה-CICD, נגיד ב-wix, הצוות DX שלהם בעיקר אחראי על ה-CI/CD. בחברות אחרות זה הם אחראים גם על ההכשרה של המפתחים, כלומר זה תחום מאוד מאוד רחב, לא כל כך מוגדר היטב, משתנה, הוא הולך ומתכנס לכיוון של ה platform engineering, של תשתיות, וזה מה שאנחנו רואים, ועוד מודל שאנחנו רואים זה משהו ביניים כזה של גילדות, אנחנו רואים הרבה חברות שעכשיו מקימים גילדה שתחום האחריות שלה זה developer experience. לאתר את הבעיות ולמצוא פתרונות באופן שוטף כדי להגביר את הפרודוקטיביות של מפתחים בחברה. 

ישי: אתם נתקלתם או שמעתם מאנשים, ממפתחים, אולי seniors שמתחילים להסתכל על developer experience בתור עוד אינפוט כשהם מחליטים איפה ללכת לעבוד? כלומר אני הולך לעבוד במקום שבו ה experience הוא טוב? או פעם היו את ה-12 נקודות של גו'אל ספולסקי, בתחילת שנות ה-2000, רואים כבר טרנד כזה שאנשים אומרים אני הולך לעבוד במקום שבו פתרו את ה-XYZ וה experience הוא טוב, אני יכול להתמקד בעיקר ולא להתעסק בכאבים האלה. 

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

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

ישי: אז הן מרגישות שעובדים עוזבים או בוחרים גם על שאלות של developer experience.

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

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

דן: כן, ואם אתה שואל אותי, אני חושב שזה אולי הסיבה מספר אחת להשקיע ב-developer experience. בסופו של דבר, כאילו אנחנו כל הזמן עסוקים, נכון, כל החברות שלנו עסוקות בלהגדיל velocity, זה מה שאנחנו רוצים לשפר, ואם אנחנו רוצים לשפר velocity, כנראה שאחת הדרכים הכי משמעותיות לעשות את זה––אני שם פה סימן שאלה, אתם מוזמנים להגיד את דעתכם––זה פשוט להגדיל את ה-, שעובדים יישארו יותר זמן בחברה, כאילו בסופו של דבר כשעובד עוזב אחרי שנה וחצי או אחרי שנתיים הוא לוקח איתו ידע, הוא לוקח איתו שיטות, מי שייכנס אח"כ לקוד שלו יעשה rework או איזשהו refactor. אם אנחנו יכולים להשפיע על הישארות של עובד במקום עבודה באמצעות developer experience, באמצעות זה שאנחנו נותנים לו את הכלים והתשתיות הנכונות, הרווחנו, שיפרנו את ה velocity.

ישי יעקבי: כן, אני חושב ש-developer experience בא גם המון עם, כאילו ביחד עם ownership יותר גבוה שיש למפתחים, ובעצם גם יכולת לתת הרבה יותר impact, והדברים האלה באמת עוזרים ל retention, בסופו של דבר אם אני ביום יום שלי לא מצליח לדלבר או לשחרר פיצ'רים או אני מרגיש שאני מתעסק בטפל ולא בעיקר, אז הדברים האלה משפיעים. בנוסף לזה גם הרבה מה-developer experience בא עם שימוש בסטאקים שהם יותר נגיד מודרניים, שמראש כבר חשבו על developer experience בשלב המוקדם. נגיד אם אני מסתכל על הפרונט אנד, אפשר להסתכל על Vite וכלים שהם נהיים מאוד פופולריים כיום שהם דואגים לזה למשל שה hot reloading יהיה ממש מהיר, כאילו ממש מהיר, זה לא היה מספיק מהיר קודם, אנחנו הולכים לשפר את זה. ומפתחים מלא פעמים לא אוהבים להרגיש שהם נשארים מאחור, שהם נגיד מפתחים בכלים שהם ישנים, בדיוק כמו שלא אוהבים שיש legacy או דברים שהם slowing us down. אז אני חושב שכל הדברים האלה הם באים ביחד ובסוף כאילו ארגון שהדברים האלה מתקתקים ושהוא יכול לעשות גם חלק מהדברים האלה זה לראות כמה שינויים אתה יכול להכניס לארגון כדי לשפר את ה-developer experience, כי זה לא משהו שהרי נגמר. אז ככל שהארגון משקיע בזה יותר והמפתחים מרגישים את זה ומרגישים שגם הם עוברים סוג של אבולוציה באיך שהיכולת שלהם לעשות אימפקט או בכלים שהם משתמשים, אז הם נשארים יותר זמן בארגון. 

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

(מוסיקת מעבר)

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

ישי יעקבי: אפשר להסתכל על מטריקות של דליברי, מלא פעמים כמו שנאמר, היכולת לשחרר דברים לפרודקשן בד"כ דורש developer experience ברמה טובה כי אחרת פשוט הדברים תקועים. אולי גם להסתכל על כמה זמן לוקח ל review להיות מאושר, כמו שמסתכלים על DORA Metrics נגיד בעולם של DevOps, אני גם חושב על זה ברמת העיקרון וגם משהו שמרגישים שמדברים עם הצוות, אם אני מסתכל על דיילי ואני שואל אנשים על DSM. כל אחד מספר מה הוא עבר, אז פתאום כמה פעמים אומרים התעסקתי בדבר שאני לא אמור להתעסק איתו בעצבים כזה, הסביבה נתקעה לי, לא הצלחתי לשחרר משהו.

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

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

דן: אני חושב ש-, אני רוצה להתחבר למה שאתה אמרת, אני חושב שביטחון זו מילת המפתח כאן. אנחנו רוצים למדוד את ה confidence שיש לנו בלעשות שינויים. בסוף ככל שה-developer experience שלי יותר טוב, אני מרגיש יותר בטוח להיכנס לקוד, לבצע שינויים, זה הולך יד ביד עם עוד דברים כמו טסטים ודברים אחרים, אבל ביטחון זה דבר שחשוב למדוד. אפשר לעשות את זה באמצעות גוגל פורם פשוט. והדבר השני אני חושב, זה קונטקסט משנה כאן. בגלל שיש כל כך הרבה בעיות ב-DX ויש כל כך הרבה דברים ש-that can go wrong בתהליך הפיתוח, מאוד חשוב לשאול שאלות שהן קונטקסטואליות וספציפיות. כלומר כי בסוף הבעיות ב-DX מתחבאות, זה בפרטים הקטנים. זה בזה שהלוגים, היה לי באג עכשיו, והלוגים שלי היו על הפנים, זה האט אותי. הייתי צריך לעשות פיצ'ר חדש ולקח לי המון זמן להקים את התשתיות של ה database ושל ה microservice והייתי צריך אישורים מפה ואישורים משם, אני חושב ששאלות קונטקסטואליות יעזרו לנו להציף את הבעיות שיש לנו ב-DX.

ישי: אבל אם אני מסתכל על ארגון טיפה'לה יותר גדול ומישהו, אפילו VP Engineering מסתכל ואומר רגע, אני שומע מהשטח שיש בעיות, אני רוצה לעשות השקעה מסודרת ב-developer experience, אולי אפילו למנות צוות ולהגיד להם רוצו עם שיפורים. איך אני יודע אחרי רבעון, אחרי שניים, שהשתפרנו? כאילו תמיד אנשים יתלוננו ותמיד יש מה לשפר, זה אף פעם לא יהיה perfect, אז איך אני יכול לייצר לעצמי baseline או איזושהי הבנה שהיא קצת נשענת על דאטה שאומרת וואלה, התחלנו, השקענו וזה שווה, רק שאלונים? רק לשאול כאילו לשאול אנשים לדעתם? איך אני עושה את זה  at scale ועם ביטחון שאני עושה את זה נכון?

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

ישי: אז אולי אני יכול לייצר איזשהו, לדבר על וקטור של לא יודע, נגיד 10 מטריקות שונות, בחלק מהארגונים המטריקות האלה יהיו מעולות, אבל flakey tests אני יכול למדוד, או כמה זמן לוקח ל-CI/CD לרוץ.

דן: כן, כן.

ישי: ואני יכול להגיד אוקיי, אצלי לוקח 20 שניות, הכול טוב, אם לוקח לי שעתיים אני כנראה שמה אני אוכל אותה ב-developer experience. אם הטסטים של flakey ברמה מעל X, כנראה אני צריך להשקיע שם. אז אתם חושבים שאפשר לתפוס עם מספיק מטריקות מרחב מעניין של DX או שצריך תמיד גם ללכת ל forms ושאלונים וגם את הסופט.

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

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

ישי: תלוי למה הוא התרגל.

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

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

דן: זה ממש הנקודה אני חושב, כן.

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

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

ישי: זאת אומרת אם אתה שואל אז תעשה משהו עם התשובות.

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

ישי: וואלה.

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

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

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

ישי: ולהפיץ את הלינקים של Dark Mode.

דן: ולהפיץ את הלינקים של Dark Mode, כן, כמובן.

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

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

ישי יעקבי: משהו חדש וקטן, כן.

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

ישי: Quick Wins, אחלה עצה. ישי ודן תודה רבה לכם.

יעקבי: תודה רבה.

דן: תודה לך.

ישי: וכיף שבאתם.

דן: כיף גדול.

(מוסיקת מעבר)

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

 (opening music)

Welcome to the second season of Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's podcast for engineering managers. Where we will host leaders in the industry and talk with them about everything that interests engineering managers, those who work with them and those who might want to manage an engineering organization some day. This season we will place a special emphasis on developer experience. I'm Yishai Beeri, CTO at LinearB, let’s get started.

(transitional music)

Yishai: In this episode I am happy to host Yshay Yaacobi, co-founder and CTO at Livecycle, Hi Yshay.

Yshay: Hey.

Yishai: And Dan Leshem, the Creator of Dark Mode and founder of FineDev, ahalan.

Dan: Hello Hello.

Yishai: How fun to have you here.

Dan: Great fun.

Yishai: So as usual I will start by asking everyone how you got to this point, come on Yeshi, tell me a little about your career and how you got to where you are today, CTO and founder and partner at Livecycle.

Yshay: Okay, I'd love to. So actually I always loved programming, it was something that really interested me even from a very young age, both when I was a child and later in high school I took another computer track, in the army I got to dabble a bit in programming, also in such a role of computing, and after I was released I actually started working in a company that was involved in building websites and also a little in the world of mobile and social, and in fact my really big connection to the profession was that I started at Soluto. I was there for 8.5 years, where I got to work in almost every role in terms of technical roles. As a developer, frontend, backend, DevOps, architecture, and so on I also really fell in love with this world of developer tools and everything related to the developer experience, and after being there for 8.5 years I decided to start a company. I did it with two partners who are good friends, one I met at Soluto, who worked with me, the other friend I met indirectly through Soluto because his wife worked there, and that's how the journey towards the Livecycle began, which we've now been in for about two years, and it's really a company. I'll talk about it in more detail later, that deals in this world of how to really improve the lives of development teams.

Yishai: So basically you were a developer in all kinds of positions in the technical worlds and then you jumped to starting a company, where we will build this, let's build something new.

Yshay: By and large, yes, entrepreneurship has always interested me in general, I've always loved creating, this thing of building things. Even when I worked at Soluto, it was always an area I was most interested in, like entrepreneurship and creating projects, but yes, the big jump was the moment I left Soluto to establish Livecycle.

Yishai: Well, then we'll hear more about Livecycle and go deeper, Dan, tell us about your career.

Dan: Well, I owe my tech career to Harry Potter, as a child I was a Harry Potter freak and I wanted to set up a website, so I read Harry Potter in the library and there were programming books next to Harry Potter, so I learned PHP that way and set up the Harry Potter website and I rolled from there. A year later I already started dabbling in website development and from there I've been doing it for 15 years, as a manager of development teams, I was at OrCam for a few years, I managed the mobile team there and that's it. I'm also an entrepreneur in my soul so I founded, after OrCam I founded my startup, we did some chatbots for customer support, we had a good run of two years and closed and that's it, today I do Dark Mode and other things.

Yishai: So come tell us a little about Dark Mode, what is Dark Mode for those who don't know?

Dan: Dark Mode is a network series about the developer experience, about the development experience and the engineering culture in companies here in the ecosystem, in Israel. Actually, a year ago me and some friends heard about developer experience, we heard about it a little from (engineering organizations like) Netflix and we heard from Spotify and we heard that there would be some hype around this thing and we wanted to double click on it, understand what is there, and we started importing this concept to Israel,. While we were researching - an idea came up to do a network series together with companies like Wix and AppsFlyer and Ziprecruiter and Taboola and some other big names here in the industry. That actually in this framework we came to them, to their offices, sat with all the developers for hours, I think we had almost 80 hours of content that we recorded with them and many more hours of investigation, and we wanted to understand, as it were, problems of programmers, as this world is so complex. What is developer experience really, what is there? So we heard from them and in the end we took all 60, 80 hours of this content and shortened it to 10 episodes, each episode 10 minutes. We had very, very difficult editing work, that's it, and each episode focuses on a different content world, at a different stage in the development process .

Yishai: And what kind of responses do you get to Dark Mode? Okay, there's a series, who's listening to it? What do you hear, what impact does it have on the world, on the industry here?

Dan: The truth is that the feedback I hear and such makes me say okay, there is a return for all the investment we put into this thing. The fact that ICs come to us and tell us listen, it changes the way we work in the company. It's as if you gave us ammunition that we can then send to our managers and raise awareness of the developer experience within the company. We are suddenly aware of these things that slow us down, that make us uncomfortable, all these things that are like some kind of gravel in the shoe.

Yishai: So in Dark Mode I will find an echo of what hurts me? Here, it also hurts others, here, we give it a name? Or will I also find solutions?

Dan: Both and, it's mostly, mostly you'll find an echo, and you'll get a little taste of how others solve this thing, what others face and what can be done. Mainly a basis for discussion, I would say, within the team.

Yishai: Ok, so ICs can bring it into the discussion and say I'm not making this up, it hurts others too, there is a name for this pain I feel. What is the next step? What’s after Dark Mode? Is there a series? Where do you take it next?

Dan: So maybe Dark Mode might have a second season, I don't know, it was really a very long project. I personally continue to work within this world, I am now working on a new venture, FineDev, we want to help developers make better architecture, together with AI.

Yishai: Ok, so is FineDev a product? Is it a community?

Dan: It's a product.

Yishai: Now that we know the name, give me the pitch in a few words,

Dan: We know the cost of bad design, right? We will probably also talk about it, also in the context of developer experience apropos. And, what we do, we actually connect to the existing codebase and through AI turn empower every programmer to become the architect in them and help make a more correct architecture, a better design for his code.

Yishai: I mean it connects to my codebase and understands the current architecture and from there recommends what to improve, what to change?

Dan: Yes.

Yishai: Walla. What areas of the code? My Terraform? Things like that or the actual applicative code?

Dan: Right now the actual applicative code, i.e. what you came up with in your repository, later we might also connect to the cloud. Yes, it's still preliminary, experimental, but we're excited for it.

Yishai: Excellent, so Yshay you mentioned, we talked about the fact that you are the founder of Livecycle, come tell us a little about what it is, what Livecycle is, what you do.

Yshay: So Livecycle is actually a SaaS product designed to allow development teams to work more efficiently, there are actually two components here, one component is the infrastructure component. Livecycle actually builds preview environments from a repository, where the goal is for every PR to have a live environment where you can experience what's happening in the product. In a visual product, this thing gives a lot of power to how you can do a review in a better way. Because many times let's say if I do a code review on something visual, I don't see it with my eyes. I don't see what the problem is, where are the bugs, I mainly see text files. And beyond that, in a visual product we want to maybe bring in the rest of the team, it could be product people, it could be designers, it could be QA for the review process at an earlier stage, long before staging. Basically this is how we can do that while the developers are working on the PR, they are already starting to receive the feedback as they would receive it from developers, and they don't have to wait for it to reach staging or use a feature flag, everything can happen much, much sooner. And the goal is to save a lot of ping pong in the end, developers know this, ping pong that happens a lot between development and design people, for the product. And the ambition is that as soon as -, actually to solve this problem there are two elements that we integrate into the product. One is how we make accessible what happens in the code, actually in these preview environments, and the second problem is how we create better communication. In order to provide better communication, actually in preview environments we actually implement tools that are embedded, such as in the overlay, that allow us to propose changes to copy, CSS changes, record images, draw, record videos, and basically create such a thread of communication that the whole team can communicate within it, which is also really synchronized with Pull Requests or Jira Tickets which is connected or to a LinearB Ticket or Slack or whatever, the tools that the organization uses.

Yishai: I understand, so you actually identified a pain in this area of engineering building something and then the design or the product basically tells us it's not what we wanted or it's not what we intended or it's not exactly like in Figma. And it happens at a relatively late stage of the development or we have already put it, deployed it to some kind of environment to show, because this deployment is sometimes expensive and the feedback comes late.

Yshay: True, and actually as a developer I receive a lot of context switches and the ambition is that I can receive the feedback at an earlier stage, in a more orderly manner, not even with many tools that sometimes it appears in my Slack, sometimes it appears in Notion or Jira or in any other form,

Yishai: So everything is focused on PR basically.

Yshay: Exactly, like we do with the code review, because let's say this process of the code review we feel it works very well––so if we make changes to the product that are more let's say visual, like it doesn't have to be but the case of a visual product, to see it with the eyes, it is very clear and very easy to explain to customers what they are getting in this situation.

Yishai: Yes, this is also one of the areas that gets the most late feedback. Because when you do the demo, then everyone has something to say and in many cases it's "excellent, but this button should be green". By the way, in many cases the feedback is about the product, not about the developer, but it always comes down to changing something. Now you have to write new code or change the code because basically we decided that the button should move or the text is wrong or

Dan: The truth is that it is interesting because one of the things we discovered in Dark Mode while we were doing this research - this issue of developer experience and somehow many of the problems in DX are actually communication problems between the product and the programmers. Like it's incorrect definitions of a product or this circle of the feedback loop, which goes to the product and QA and returns back to the developer, and all this in the end complicates the whole process even more.

(transitional music)

Yishai: So I want Dan to use, you mentioned this term DX, let's dive in a little bit, let's try to understand, what is DX in your eyes? What is developer experience?

Dan: When we started researching this story of DX what we saw, if you search now what is DX on Google or ChatGPT, you will get a response of,  it's like user experience, but for developers, developer experience. I think that this definition is a bit lacking, something whose name is not entirely clear to me, what does user experience mean for developers? The first question that is asked is why even talk about the experience of developers? We need to, we are a product company, we need to talk about the value we give to our customers, and that is what is important. And I think where things start to connect is that you realize when things start to move more slowly within your company, and the developers take time to do their task or are too busy with the infrastructure., and everything is a little slower or depends on many factors and other people, this is where this developer experience starts to break down. This is where in the end you see that it also affects the value you give to your customers. Because things start to move slower, things are more cumbersome, and in the end the one who gets hurt by this is your customers. There is, I don't know, maybe our listeners already know, but there is the famous McKinsey study that showed that companies whose programmers' productivity is higher, in the end show a higher profit line or 4 or 5 times more performance in revenue, so maybe I didn't answer your question what is developer experience, but we started talking a little about why developer experience.

Yishai: Okay, so you say how easy or difficult it is for developers to generate value on an ongoing basis, then you say at least in terms of velocity and productivity, if the experience is not good, the company will move slowly, a company that relies on development and technology will be harmed.

Dan: Yes.

Yishai: Yshay, how do you define developer experience?

Yshay: I also think that the concept itself is still not completely clear, as if we can talk about something that is closer to UX where we talk for example how a terminal or API should look or documentation, but I really connect more with the direction where we look at the pain that developers experience on a daily basis, and actually how do we turn it into something that is easier. Actually as a developer, and I think everyone who studied software at some point gets burned, experiences this thing that you learn how to program, you learn how to write an application, you learn how to write code, but a lot of the problems you're going to deal with in life are not related to that, they are actually related to things that may be related to delivery, or release, maybe even source control, working in a team, code reviews, bugs in setting up the environment, a tool that doesn't work. And in fact a lot of our day-to-day life is like surviving among a lot of tools and systems and navigating between them in such a way that we are still productive, that we wanted to do something and we managed to get there and not as if we ran into a lot of obstacles. And it could be anywhere, it could be say in production that it's hard for us to debug a problem or we can't monitor something, and it could be that our IDE doesn't work because of some extension or because of some plugin, actually our day to day as developers is such a minefield.

Yishai: I only have one line to fix, I know exactly what needs to be changed in the code, but to bring it to a state where it is really tested and works in a local environment and then I was able to deploy it in a staging or QA environment, is 100 times more work.

Yshay: Yes, and in my mind developer experience is a lot about how to navigate these things, how to reach a situation where the experience of the development team is very optimal to develop, to produce this value.

Yishai: So why now? Let's say we've been developing software for decades, probably 15-20 years already in cloud worlds, worlds we'll call a bit more modern, why now suddenly we're starting to hear about DX, why are we suddenly there, a name was created, it's interesting to do a network series about what it is, What changed?

Dan: I think everything has become more complicated. It’s complex. We, like when I started writing code 15 years ago, you'd write some HTML, open an FTP server, and that's it, you'd do delivery. And today there is only this CNCF poster of the tools, I think last time I checked it was 1,117 tools, it must have gone up another thousand or so since then. And it's like it's getting complicated to develop software, there's a lot of context that needs to be maintained, the systems have become more cumbersome, and finally you, what you said a moment ago, as a developer you just want to change a small line and you come to do it and you find out that you're wasting two weeks.

Yishai: You say it gets more complicated, what, it's microservices? Is that the big name in this complication? Because in the end we moved to the cloud, it should be easier, we moved to Source Control and Git compared to Subversion and CVS and all kinds of pre-historical tooling, it should be easier, simpler. Today, at the price of deploying and doing a reversion to it compared to 15 years ago, it's much simpler, much easier to protect yourself, on the other hand, you say it's much more complicated.

Dan: Yes, I think much more complicated maybe for several reasons, at least in my perception. The first thing is that you have crazy fragmentation of tools, like this DevOps that brought the tools revolution, it's probably worth it in the bottom line, I can't really say. But eventually you find yourself dealing with so many tools to do something and you want to F5, refresh the browser and see it happen. This process is as if fragmented in a very, very complex way, and I think it makes it difficult for everyone.

Yshay: Yes, I think it also stems from, firstly, the fact that developers today are much more owners of things that in the past they didn't bother with. I mean, today developers, certainly of a product, sometimes a developer can be fullstack, they also deal with frontend and let's say backend, DevOps, this is also something that developers today do touch. In the past, developers didn't necessarily touch production, as if it was something that was very empowering, but on the other hand, it suddenly becomes - as a programmer, I now have to take ownership of the quality of the product, of it working well in production, of monitoring it, of many things that used to be out of the scope of development - he was not the owner of it. Now it comes together with a field that is very developing and in fact also within a lot of different tools, but as if none of them have yet, as if it has not reached a state of maybe stability that will become like a standard. Even let's say on the back end we see it all the time that now basically the whole stack is actually being built again around containers and Kubernetes, you can say that this also happened in the frontend around the frontend frameworks that are constantly changing and I think there is an evolution here that is now very good, it is very interesting, it allows more, because the demand is also what software can do and where it enters and we will be more everywhere, developers enter in every corner, from the front end to the back end and dev-ops, and this system is very moving and while we are moving there is a lot of mess, things break, things may move.

Yishai: So the developers got a lot more power, but that power complicates their lives and now a DX challenge is created. So what, developer experience solutions take a step back and say I'll make it simpler for you, I'll take some of the power or some of the responsibility away from you, so that it flows easily for you? You are no longer responsible for Terraform, for infrastructure, for deploying, make a change in the code and you already have a system that works? That's the spirit?

Dan: I think that when we come to do good DX, we need a moment to think about what we are trying to achieve, maybe we can really try to define a moment together what good DX is. In my view, a good DX is something that allows me to do my task, and give value to my clients without having to worry too much about infrastructure or dependencies among other things. I want to set up my task, set up the product and get in and get it done as quickly as possible. I think that everything that takes me on this path as quickly as possible, without me now having to dive in and understand what Kubernetes is or without me having to even choose Serverless or not Serverless, like anything that will help me give the value faster to my client, I think that takes me one step forward on the way to better DX.

"In my view, a good DX is something that allows me to do my task, and give value to my clients without having to worry too much about infrastructure or dependencies among other things." - Dan Leshem

Yshay: Yes, I completely agree, I think in the end, when I look at DX it's more things that help control this complexity so that it doesn't bother me, or things that eliminate this complexity. That is, we found another way that is simpler and now this flow is easier and simpler and I don't get the penalty of tools that are very complicated because in the end the more powerful and more enabling the tools are, many times they come with another penalty of complexity.

"In the end the more powerful and more enabling the tools are, many times they come with another penalty of complexity."  - Yshay Yaacobi

Yishai: And does that mean there is another team? Is there someone else responsible for this complexity for me? The DevOps team or Platform Engineering?

Yshay: Platform, yes.

Yishai: They actually build cookie cutters there and make sure that I can only make the change in the code and everything else flows?

Yshay: So this is a question, in my mind it depends on, one of the things that seem to allow teams to move quickly is that they have, let's say, a very high autonomy. Now the platform team can help them but if it suddenly becomes a bottleneck, if they can't do things themselves and get there faster, then suddenly you've created a new problem. As if in general I was, I am of the attitude that I would try as much as possible to cut off a team's dependence on an external team, but this comes together with the fact that how will this team get, for example, the knowledge or certain tools, many times it can also be tools that are open source, not necessarily tools within the organization, so that he doesn't have to deal with these things all the time.

Yishai: Say Dan, what did you see working on Dark Mode and actually encountered or talked to a lot of developers about these pains, can you highlight what are the points that came up the most? That rose most strongly? That different companies repeatedly encounter the same problem? Where are the big pains of the DX?

Dan: So really after we finished the project ofDark Mode, we transcribed all our conversations with developers,

Yishai: Did you do a word cloud on this thing?

Dan: Yes, we did a kind of word cloud and mapped 81, we call it DX killers or DX blockers, 81 things that everyone complained about. Stuff repeated more than 3 times in our conversations with developers, and there was really everything from everything, we were very, very broad. It wasn't just in the infrastructure, and I think I can reduce this thing to 5 things, into 5 general categories. The first thing is probably everything related to infrastructure, I don't want to mess with logs, I don't want to mess with connecting to a database, I don't want to mess with, I don't want to be a DevOps person. I don't want to know what Kubernetes is and I don't want Helm Charts and I don't want Terraform. Please let me write code, let me do a git push, and let it find its way to production. So it was a lot of DX killers in this category. Other things, we had coupling, as soon as I depend on my work, as soon as I wait for a code review from someone and it takes a little too much time, as soon as I depend on someone to coordinate my work with, it's frustrating, I wait again, I do a context switch, I'm going on another mission.

Yishai: Are you talking about coordination at the level of I have to have his component ready before I can write mine or before I can deploy? Or do I really need input from him about my work?

Dan: So both and, and things in the style of someone breaking my API, I make some kind of change and someone breaks it for me.

Yishai: It never happens (laughs).

Dan: This has never happened to any of us. So coupling, and another thing we heard were problems of knowledge flow. In the end, a lot of the problems we have, also the dependencies, is that I just don't know how to do things, I don't know how to run this pipeline.

Yishai: Ok, so discovery of who is responsible for this, where do I even find an answer to questions about what this service is, who is responsible for it, who knows how to change it or who knew how to give me feedback on what I do there.

Dan: Yes. And the last thing we probably had, and that's why we rolled into our startup, was design problems. That in the end I have a hard time with the code or every task feels like a new adventure to me because I have to deal with some kind of legacy or technical debt that I took or a design problem and I don't know, we made some wrong design decision and now we are dealing with it for a year, two years, three years ahead. So this is how we mapped the world of DX.

Yishai: You say all the places that I pay the accumulated technical debt or the truth is that I only pay the interest.

Dan: Yes exactly.

Yishai: And dealing with problems that they may have made a decision that was right at the time, but now I'm paying the price they took then.

Dan: exactly.

Yishai: And you also mentioned this seam between product and engineering.

Dan: Right.

Yishai: Requirements what, not clear enough?

Dan: Requirements are never clear enough, it is never clear what the definition of done is.

Yishai: Acceptance.

Dan: Exactly. Deadlines, which is a topic in itself, wait, are we doing tests? Are tests considered within the deadline? It is not considered within the deadline? Is the monitoring included? Is it out of scope? So all the friction around the definition of a product can also slow us down a lot.

Yishai: And since we see that this world of DX is suddenly gaining visibility and acceleration, from your experience and your work, in Livecycle it must be in front of customers or prospects, how do you see this change in organizations, in terms of, suddenly there are owners? People that's their job? Are there VPs of Developer Experience? How does this change happen?

Yshay: We see that there are more developers who are platform engineers, who can usually be the customer for our product. We see that there is simply also a much greater awareness of this matter, meaning that those who deal with delivery questions then deal with where the developers are actually wasting time, where there are ping-pongs. What makes them reach as high an efficiency as they can reach, and a lot of these things are really around or things related to the architecture that we really see being talked about at a more advanced stage, meaning that we talked to companies so all the questions that for example if it's a monorepo or how many repositories or how to do CI/CD Or all these things, actually everyone is dealing with these questions, they are questions that seem to be interesting because in the end they want to optimize their delivery process in order to push the business value as quickly as possible. So it seems like it does feel like something that is always interesting at the VP R&D level or even Also, I would say even at every level, even when we talk to the developers themselves these issues,

Yishai: You say that there is awareness and platform engineers are getting more and more tasks or emphasis related to DX, you see but also people who literally seem to define roles around DX? And someone who is an owner?

Yshay: I haven't come across this yet, but it is something that even if it's not within the scope of a job, it's something that happens, maybe the tech leads deal with it, maybe the platform engineers, sometimes it's even DevOps, it's very

Yishai: They are busy with it even if it doesn't always have a name, and it is not called in the title.

Yshay: Yes.

Yishai: What do you see Dan?

Dan: I actually see that it is something that flickers from below, usually there will be some kind of champion within the company, it will be some kind of maybe even IC or team lead who takes it upon himself to raise the awareness of the issue of DX within the company. Then we see it in several ways, or that it really comes from below, and there is someone who is now the owner of it and this is added to the position. Or there are actually teams, we have seen companies that actually have a Head of Developer Experience, in some companies it is called Platform Engineering, in other companies it is a team that is only responsible for the - CICD, say at wix, their DX team is mainly responsible for the CI/CD. In other companies they are also responsible for the training of the developers, that is, it is a very, very broad field, not so well defined, changing, it is converging towards of platform engineering, of infrastructures, and this is what we see, and another model that we see is something in the middle of guilds, we see many companies that are now establishing a guild whose area of ​​responsibility is developer experience. To locate the problems and find solutions on an ongoing basis in order to increase the productivity of Developers in the company.

Yishai: Have you come across or heard from people, developers, maybe seniors who are starting to look at developer experience as another input when they decide where to go to work? I mean I'm going to work where the experience is good? Or there used to be Joel Sapolsky's 12 points, in the early 2000s, you can already see such a trend that people say I'm going to work where they solved the XYZ and the experience is good, I can mainly focus and not bother with these pains.

Dan: I can say that we are seeing a trend perhaps, the same trend but from its other angle. That we see companies that invest in developer experience and that's how they attract talent or the reason they invest in it is to increase the retention of their employees, even in the current climate.

Yishai: So they feel that employees leave or choose also on questions of developer experience.

Dan: Yes, and I think it also ultimately makes sense because you don't want to get up in the morning and feel like you're struggling with your code to get the task done. You want to feel that you are solving problems, that you are giving value to the company, to the customers. You don't want to feel that you are fighting with the logs and you are fighting with the infrastructure of the data bases or that there is a lot of friction, so companies work to reduce this friction.

Yishai: Also for questions of hiring and retention, not only for productivity to bring out the value, but they also understand that the developers are starting to look at this as another parameter in their decision.

Dan: Yes, and if you ask me, I think that might be the number one reason to invest in developer experience. In the end, it's like we're constantly busy, isn't it, all our companies are busy increasing velocity, that's what we want to improve, and if we want to improve velocity, probably one of the most significant ways to do it--I put a question mark here, you are welcome to say In your opinion--it is simply to increase the, that employees will stay longer in the company, as if in the end when an employee leaves after a year and a half or after two years, he takes knowledge with him, he takes methods with him, whoever enters his code later will do rework or something refactor. If we can influence the retention of an employee in a workplace through the developer experience, through the fact that we give him the right tools and infrastructure, we have gained, we have improved the velocity.

Yshay: Yes, I think that developer experience also comes with a lot of people, as if together with the higher ownership that developers have, and in fact also the ability to give much more impact, and these things really help with retention, in the end if I am not able to brainstorm or release in my day to day Features or I feel like I'm messing around take care of And not mainly, so these things have an effect. In addition to that, a lot of the developer experience also comes with the use of stacks that are more modern, say, that already thought about developer experience in the early stage. Let's say if I look at the front end, you can look at Vite and tools that are becoming very popular today that take care of it for example that hot reloading will be really fast, like really fast, it wasn't fast enough before, we're going to improve it. And developers often do not like to feel that they are left behind, that they are, say, developing with tools that are old, just as they do not like that there is a legacy or things that are slowing us down. So I think all these things come together and in the end it seems like an organization that these things are ticking and that it can also do some of these things is to see how many changes you can introduce to the organization to improve the developer experience, because it's not something that ends. So the more the organization invests in it and the developers feel it and feel that they are also undergoing a kind of evolution in how their ability to make an impact or in the tools they use, then they stay longer in the organization.

Dan: The truth is that one of the companies we were with inDark Mode She shared that at some point they decided that they simply rewrite their entire codebase, they switched from Angular I think to React, because they saw that they had a problem recruiting people, because people said we don't want to work in Angular. Like it's not a base code that I want to get into, and they just made the decision and worked for two weeks so that from now on it will be possible to put React code into their framework.

(transitional music)

Yishai: Towards the end, I would like to ask you how developer experience is measured, how do I know if my situation is good, not good, has improved, do you have any ideas on how to measure it? Besides asking everyone, are you satisfied and getting answers like that from the gut?

Yshay: You can look at delivery metrics, many times as said, the ability to release things to production usually requires a good level of developer experience because otherwise things are simply stuck. Maybe also look at how long it takes for a review to be happy, like you look at DORA Metrics say in a world of DevOps, I also think about it at the level of principle and also something that you feel talking to the team, if I look at Daily and I ask people about DSM. Everyone tells what they have been through, then suddenly several times they say I messed with something that I shouldn't mess with in such a nervous manner, the environment I got stuck, I couldn't release anything.

Yishai: Okay, so you're saying a combination of metrics on the delivery process, we all here assume that a better developer experience is aligned with the ability to work faster and more frequently, perhaps also with higher production confidence. And combine it with simply asking people, hearing what they are frustrated about.

Dan: I think that, I want to connect with what you said, I think confidence is the key word here. We want to measure the confidence we have in making changes. In the end, the better my developer experience is, the more confident I feel entering the code, making changes, it goes hand in hand with other things like tests and other things, but confidence is something that is important to measure. This can be done using a simple Google Form. And the second thing I think, is sub-context here. Because there are so many problems with DX and there are so many things that can go wrong in the development process, it is very important to ask questions that are contextual and specific. In other words, because in the end the problems in DX are hidden, it's in the small details. It's that the logs, I had a bug now, and my logs were on the face, It slowed me down. I had to make a new feature and it took me a lot of time to set up the infrastructure of the database and the microservice and I needed approvals from here and approvals from there, I think that contextual questions will help us overcome the problems we have in DX.

Yishai: But if I look at a slightly larger organization and someone, even VP Engineering looks and says wait, I hear from the field that there are problems, I want to make an orderly investment in the developer experience, maybe even appoint a team and tell them they want improvements. How do I know after a quarter, after two, that we have improved? As if people will always complain and there is always something to improve, it will never be perfect, so how can I create a baseline for myself or some kind of understanding that is a little based on data that says voila, we started, we invested and it's worth it, just questionnaires? Just asking as if to ask people their opinion? How do I do it at scale and with confidence that I'm doing it right?

Dan: It's a good question, I think questionnaires will help you understand where the problems are, and in the end you'll have to determine some kind of metrics, I'm not sure that DORA Metrics is like the metric I'd use to measure developer experience, because I feel it's a bit too narrow in developer experience. But surely this and maybe other metrics that are contextual, that is, if I now have a problem with CI/CD, then I will measure it, and if I know that my problem is in the infrastructures, then I will perhaps create some kind of specific metric for this, I think that in the end it does depend That you ask the people.

Yishai: So maybe I can produce some, talk about a vector of I don't know, say 10 different metrics, in some organizations these metrics will be great, but flakey tests I can measure, or how long CI/CD takes to run.

Dan: Yes Yes.

Yishai: And I can say okay, for me it takes 20 seconds, everything is fine, if it takes me two hours I'll probably eat it in the developer experience. If the flakey tests are above X level, I should probably invest there. So do you think it is possible to capture with enough slams an interesting space of DX or should always go to forms and questionnaires as well as the software.

Dan: This is a question, like if possible, at the end of developer experience it touches people. So the question is whether it is possible to bring here some hard metric that will indicate, that will say whether our DX is good or not, I don't know.

Yshay: I also think of it in a similar way, meaning that a lot of these things are also really relative. So I can say for example a slow CI/CD, if I managed to improve it then as if I had already made a very positive impact here. But in the end it's like, I don't know if it's the thing that developers seem to dwell on or if now it's still fast enough, because in the end it's also an individual matter, I can say that now 10 minutes CI is slow, and someone else can say that a minute is slow.

Yishai: Depends on what he got used to.

Yshay: Yes, and there is a lot of interest here that is from an ongoing process. I do think that as an organization a lot of the questions that deal with what frustrates people will be things that can be pointed out because people will report the same problems. If for that matter, for example, the environment is complex and difficult, let's say setup for a new position. So I'll say something that the way I would measure it later if I were to get into it, it's just new developers, how long did it take to do onboarding to their environment for example. If my problem is related to analytics or monitoring or the Ribio code, then anything like that can be talked about specifically Do a metric and see it, but in the end the whole organization suffers as if it seems to me that things are a bit different then,

Yishai: Yes, you talked about 81 points, that's already a lot, and it's hard to talk about such a space of dimensions. To me, this is a super interesting question, the ability to say here, there is some kind of set of best practices or a set of benchmarks even, again, I return to Joel Sapolsky's example, you can perhaps imagine 12 new points that are related to the developer experience, and that they will catch most cases, It will never capture everything, but it gives a picture of what's going on, it's probably problems or challenges that are common to most development processes, and now each organization might also add questionnaires, maybe even a microservice, tell me how you felt about this specific task, now.

Dan: That's really the point I think, yes.

Yishai: And do you think the developers like to give feedback? Will they cooperate with such questionnaires? Will they really give what hurts them? Or they'll say it's bothering me now, it's another problem in the developer experience, who are pestering me with questions about how it was.

Dan: You know, I think it depends, I think that developers actually like to give feedback, obviously you can speak in generalities and there are and there are, but I think it really depends on what they will do with this feedback.

Yishai: I mean if you ask then do something with the answers.

Dan: If you're asking then do something about it or at least reflect on why you're not doing it. As if there is a lot here, there is a challenge of communication here, the truth is, we talked about DX teams earlier, so when we met them, these teams, we hear from them that there really is a challenge of communication. There are 500 problems, why are we working on problem 7 and not on problem 8. So if you are already asking, then ask contextually and make sure to reflect what you did with the one you asked.

Yishai: Walla.

Yshay: I also think that teams are full of times, and as if on a daily basis some kind of past haunts them, decisions that were in the past or legacy code or problems that are there. And I always find it interesting as a MAN programmer, the question of if tomorrow we were to do it again, how would we do it, so that it would be the best experience, and from that they also have the solution and also what are the problems we are suffering from, as if getting in the way.

Yishai: Great, so in closing I want to ask each of you a suggestion for someone in the organization who maybe doesn't, doesn't have a neat DX function or hasn't read a problem in the name, and feels like they want to start touching those areas or move the organization there. What, what one piece of advice or one thing that can be taken practically, not necessarily to improve the DX but how to start bringing the organization into awareness, about what I can do as a developer or as a team lead, how to start. Dan.

Dan: First of all call it by name and form a group which is what she cares about, which is her agenda, find the champion who starts talking about DX in the company.

Yishai: and distribute the links ofDark Mode.

Dan: and distribute the links ofDark Mode, Yes of course.

Yshay: I'm thinking of actually trying to make a situation where we have some kind of small project in the company, if there is any opportunity. I don't know what, something new that can be developed a little differently and try to build how we would like to work and take this thing as a use case and then try to throw it into the other bigger projects.

Yishai: You say it's easier to solve the problem with something new, which is successful, then to say ok, let's apply it to the more things, our legacy.

Yshay: Something new and small, yes.

Dan: The truth is that this is an excellent point because quick wins is perhaps the most important thing in DX, in a world that is so, as if it has so many problems and it is also soft and you can take it in so many directions, so quick wins, find the small thing from which you start and there Make the change, I really think good advice.

Yishai: Quick Wins, great advice. Yeshi and Dan, thank you very much.

Yshay: Thank you.

Dan: Thank you.

Yishai: And it's nice that you came.

Dan: Great fun.

(transitional music)

Go to devinterrupted.com where you will find both our episodes in English and our discord server, and I would like to introduce you to Gitstream, our smart engine for continuous merge, only 2 minutes of installation and of course it is free. Go to gitsream.com I'm Yishai Beeri, we'll hear from you in the next episode.

(closing music)

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

• Dark Mode
• Livecycle
• Kubernetes
• Helm
• Vite
• Figma