לכולנו כבר ברור לגמרי מדוע אנחנו רוצים למזג קוד כל הזמן (Continuous Integration), מדוע אנחנו רוצים לבדוק ולהכין קוד כל הזמן, (Continuous Delivery) או מדוע אנחנו רוצים לשחרר קוד כל הזמן (Continuous Deployment).
יש פעולות נוספות שחשוב לעשות כל הזמן, כמו לתת פידבק (חיזוקים ונקודות לשיפור), לבדוק את עצמנו שאנחנו פועלים נכון, וללמוד.
את הפוסט הזה אני רוצה להקדיש ללמידה מתמדת (או: מתמשכת). אפשר לחלק את הידע ל 2 קטגוריות:
- ידע טכנולוגי כללי, שלא קשור לארגון / המערכת הספציפיים שבה אנחנו עובדים: בסיסי-נתונים, מערכות מבוזרות, מתודולוגיות עבודה, טכנולוגיות שונות, וחידושים בטכנולוגיות קיימות…
- ידע על המערכת / ארגון / ביזנס – כיצד המערכת עובדת, וכיצד היא משתנה. הידע הזה הכרחי על מנת לבצע שינויים מהותיים ומוצלחים במערכת.
לכאורה, כשהייתי צעיר יותר – החלטתי אסטרטגית להשקיע יותר בלמידה של הידע מהסוג הראשון, במחשבה שהוא שימושי יותר, כי הוא נייד בין ארגונים. לכאורה ידע טכנולוגי כללי הוא השקעה ארוכת טווח יותר, אבל קשה לעשות אימפקט משמעותי בארגון תוכנה בעזרתו בלבד – חייבים ידע ספציפי על המערכת והארגון. לאורך השנים ראיתי גם את הידע הספציפי של ארגון אחד משמש אותי בארגון אחר – כי נתקלנו בדילמות דומות, והיה לי ידע קונקרטי על המשמעויות העמוקות של גישה כזו או אחרת. כנראה שחשוב ליצור תמהיל כלשהו של שני סוגי הידע.
אני רוצה לעזוב את הדיון ברמה האישית – ולדון בנושא ברמה הארגונית: כיצד הארגון משפיע / מאפשר / או חוסם את סוגי הלמידה הללו, שכל-כך חשובה לארגון ולעובדים. אני מאמין שלארגון תפקיד משמעותי בלמידה, ולא רק לעובד עצמו.
פעם עבדתי בארגון בו התלוצצנו שמי שמתקבל לעבוד בארגון, לא יוכל אחרי שנתיים או שלוש להתקבל לארגון מחדש: ראיונות העבודה הטכניים היו בהחלט קשים, אבל פילוסופיית העבודה לא “נשענה” על ידע עמוק של העובדים: נבנו תשתיות פנימיות שמגבילות מאוד את צורת העבודה: למשל תשתיות לעבודה מול בסיס הנתונים – סט abstractions מעל hibernate שלא היה ניתן לראות SQL והיה לאנשים רק דימיון (שגוי לרוב) מה באמת קורה מאחורי הקלעים, או מן שפת XML שתורגמה ל HTML+CSS, שהגבילה את יכולת העבודה ו”חסכה” מהאנשים חשיבה והבנה מה באמת מתרחש בדפדפן.
הכוונה הייתה טובה: לפשט את העבודה ולמנוע טעויות – אבל היא מנעה בצורה דיי גורפת למידה. שמחתי לראות אנשים שעזבו את הארגון ההוא והמשיכו להתפתח בחיים המקצועיים שלהם, אבל היו כאלו שנראה (לי, מרחוק, על בסיס שמועות) כאילו נעשה להם נזק והם אבדו שנים יקרות של למידה אפשרית.
כשהארגון קטנטן – כולם מעורבים בהכל, באופן טבעי. קל לדעת ולהתמצא במערכת. קל לגעת בליבת המערכת – ולבצע שינויים משמעותיים. אני זוכר תקופה שבה הייתי עצמאי כמה חודשים – לא הייתה חוויה מלמדת מזו. ככל שהארגון גדל – הכרת המערכת הולכת ומצטמצמת, וצוותים נוטים לשקוע “בפינה הקטנה שלהם” ולאבד את התמונה הרחבה.
לכאורה יש כאן משהו מתוכנן, אנו עובדים קשה על הכמסה במערכת – היכולת של צרכן לצרוך שירות מחלק אחר של המערכת, בלי להכיר את הפרטים. זה נדרש בכדי לגדול, אבל אם ההכמסה מצליחה יותר מדי, נראה שהפסדנו משהו. הייתי רוצה שלרוב האנשים יהיה מושג כיצד פועלת המערכת, כפי שכנראה הם יודעים את הבסיס כיצד פועל הרכב, מזגן, או שאר המכשירים / מנגנונים שהם באינטראקציה יום-יומית איתם.
גם למידה של ידע טכנולוגי כללי היא אינטרס משותף של העובד והארגון – אבל קשה לייצר אותה בצורה יעילה. קשה למצוא את זמן ללמידה, וגם אז היא הרבה פעמים אינה משמעותית. שהייתי ב SAP (ארגון גדול, ונינוח) הייתי הולך לקורסים מקצועיים פעם או פעמיים בשנה – אבל לעתים רחוקות הרגשתי שלמדתי משהו משמעותי מהם.
יותר מכל תוקפת אותי המחשבה שמפתחים רבים לא מתפתחים בצורה משמעותית לאורך הקריירה שלהם. לאורך השנים ראיינתי מאות מועמדים, פעמים רבות על תרגילי תכנות בסיסיים. ישנן מגוון סיבות לחוסר הצלחה בראיון מקצועי – אבל אני לא מצליח להסביר לעצמי את חוסר-ההצלחה של אחוז גבוה של המועמדים (חלקם עם טייטלים ושנות ניסיון לא מעטות) בתרגילי תכנות בסיסיים – מלבד המחשבה שיש מרכיב של ניוון / “עבודה בניוטרל” אצל חלק גדול מהעובדים. מאוד הייתי רוצה ש 80-90% יצליחו את אותם תרגילי יסוד בתכנות, בעוד בפועל בערך רק כ 50% מצליחים. יש פה פער שמדברים עליו מעט מדי. יש פה אחריות של הארגונים / התעשייה (וגם של העובדים) – איך להעביר יודע בצורה טובה ויעילה יותר – באופן מתמשך.
מה אפשר לעשות?
אני מגשש בנושא הגדול, המורכב והחשוב הזה, ולכן התחלתי בהשוואה זריזה בין גישות למידה שונות. נתחיל בנושא הקל יותר (נראה לי) – למידה של טכנולוגיות כלליות:
הטבלה מסכמת את הרשמים שלי, והיא אינה מדויקת. עוד חצי שנה בוודאי הייתי ממלא אותה קצת אחרת – אולי גם שבוע הבא. אנא התייחסו אליה לצורך התרשמות ודיון – ולא מקור מידע מדויק ובדוק-היטב. הנה כמה נקודות נוספות על הנ”ל:
- כנסים הם חוויה, אבל לא מקור למידה משמעותי בעיני. מאוד נהניתי מכמה כנסים – וכמה מהם היו פותחי-עיניים עבורי, אבל את הלמידה עצמה, עשיתי מאוחר יותר, מתוך ספרים ומאמרים. אם לא הייתי מוסיף את הלמידה העצמית, הייתי יודע לדקלם כמה ססמאות נוספות, עם מעט מאוד הבנה במה באמת מדובר.
- יש משהו מאוד מלמד לתת לאנשים בתוך הארגון להרצות, הם בוודאי מתפתחים באופן אישי ממתן הרצאה – אבל בשלבי ההתפתחות הראשונים הם עלולים לספק סשנים ברמה לא מספיק טובה. אולי כדאי להתחיל מפורום של צוות/קבוצה, ורק בעקבות הצלחות שם – לזמן לאנשים לבמה רחבה? (נניח: 100 איש). כל סשן בינוני ומטה שמועבר ל 100 איש – הוא פספוס לדעתי, שעלול להפוך לנזק מצטבר (איבוד אמון בפורום, הורדת הסטנדרטים).
- ספרים עדיין “עובדים”, אבל לפלח הולך ופוחת של האוכלוסייה. אני מאמין ש Video Tutorials הם המדיה העדיפה כיום. כמובן שלאנשים שונים, מתאימים דברים שונים – אבל אם לא נתתם למדיה הזו סיכוי מספיק – אני ממליץ (בתור אחד שקרא עשרות רבות של ספרים, אבל גם ראה עשרות רבות של Video Tutorials).
- למרות מוטיבציה גבוהה של אנשים להיות עם ידע, הלמידה עצמה אינה קלה, ולעתים קרובות לא מתממשת (כמו שכולם רוצים להיות בכושר, אבל קשה ליישם. מסגרת יכולה מאוד לעזור). השלב הקשה ביותר הוא כנראה הקצאת זמן – וארגון שרוצה להצליח כנראה צריך לעזור לעובדים לפנות זמן משמעותי, ולהתחייב ללמידה. למשל: לקבוע ברבעון כמה ימים קבועים מראש (ולא ניתנים להזזה) לצורך הלמידה + לבקש לסכם ולהציג את סיכום הדברים מול הצוות.
- חונך אישי הוא דיי ברירת מחדל, במיוחד כאשר מגיעים Juniors לארגון – אבל הם יקרים מכפי שנדמה: גם בכמות ההשקעה בפועל, וגם מכך שלא תמיד החונך ידע לחנוך בצורה טובה, או אפילו לספק תשובות מספיק טובות למגוון שאלות שיעלו. החניך לרוב לא יוכל לתת אינדקציה לאיכות החניכה, עד שלא צבר כמה שנים טובות בתעשייה – והפידבק יהיה בעיקר סביב זמינות ונחמדות.
בואו ננסה לעשות תרגיל דומה, על ידע פנימי / ספציפי לארגון:
כמו מקודם, הטבלה מסכמת את הרשמים שלי, והיא אינה מדויקת / לא עברה סבבים של פידבק ושיפור. שיתוף במחשבות. אנא התייחסו אליה לצורך התרשמות ודיון – ולא מקור מידע מדויק ובדוק-היטב. הנה כמה נקודות נוספות על הנ”ל:
- תיעוד טוב יכול להיות מאוד יעיל (כנראה, למשל תיעוד של ספריות OSS) – אך מעולם לא עבדתי בארגון שהצליח לייצר תיעוד בעקביות: בכמות ובאיכות.
- אני מאמין שתיעוד בקוד הוא מאוד שימושי, כפי שכתבתי באריכות בפוסט קוד ספרותי = סופן של ההערות בקוד. הפוסט מתאר אלו הערות בקוד הן מיותרות, ועדיף שייכחדו, ואלו הן שימושיות (בגדול: דברים שאפשר לפספס מקריאת הקוד, תמונה גדולה, עקרונות, עבר וכוונות עתיד). יותר קל ליצור תרבות של תיעוד בקוד – כי קל יותר לכתוב אותו ולהסביר את הערך שבו.
- כשהארגון גדל מצטבר בו ידע וכללים, כגון Coding Conventions ו Best Practices. יש כאלו שמתנגדים לכל סוג של סדר / חוקים ורוצים להיות “Rock Stars” – ראיתי שוב ושוב את הנזקים המצטברים של הגישה הזו. לא צריך להגזים, וחשוב להשאיר חופש לסגנון אישי – אבל סדר ואחידות בדברים הבסיסיים (לחווייתי ארוכת השנים) יוצרים הרבה יותר תועלת מנזק. בלי תיעוד של הכללים האלו – קשה להפיץ ותחזק אותם. גדילה מסיבית של הארגון יכולה בקלות לגרום לאיבוד של לקחי-העבר, וגם הטובים שבהם. לקחים צריך לתחזק, לחדש, ולהתאים.
- כלי שנראה מאוד שימושי ויעיל להפצה ואכיפה של קונבנציות של Coding Convention ו Best Practices פנימיים לארגון הוא כלי Static Analysis שניתן להרחיב ולקסטם לחוקים הספציפיים של הארגון. מאסתי מזמן מכלים שאוסרים על שורה להיות מערבר לאורך מסוים או מחייבים אותי להוציא constant מכל מספר שמופיע בקוד – אני מוקיע את הכללים האלו, וממליץ לבטל אותם! מצד שני, הצגתי אולי עשרים פעמים בארגון את כללי הבסיס של מבנה טבלאות שהוחלט עליון (חייב להיות primary key שהוא GUID או Autoinc, להוסיף 2 עמודות לזמני יצירה + triggers שימלאו אותם, שימוש ב UTF8 – לא משהו חריג), ושוב ושוב היו פספוסים ואנשים שלא שמעו מעולם על הכללים (שגם מתועדים היטב). פעם אחת יצרנו חוק של Static Analysis שלא מאפשר לעשות ל commit אם יש חריגות – ונראה שהידע החל לעבור, ובלי כמעט השקעה נוספת. כל כלל הוא הזדמנות ללמד, ולכן חשוב מאוד לא רק להציב את החוק אלא להסביר אותו, ולהפנות למקורות. למשל: מדוע למשל חשוב ב MySQL שיהיה Primary Key ומה העלות של Primary Key גדול (בבתים). בנקסט אנחנו משתמשים ב Detekt (לשפת קוטלין) ו Danger (לשפת TypeScript) לכתיבה של Custom Static Analysis rules.
- התאוריה המקובלת היא ש 70% מהלמידה בפועל מתבצעת מתוך או תוך-כדי עשייה בפועל, וזה הרגע המתאים ביותר ללמוד בו – כאשר הנושא 100% רלוונטי אלי, ואני זקוק לידע בו. Code Analysis tools (עם הסברים מפורטים בצד) – מצטיינים בקליעה לרגעים החשובים הללו.
- בלי קשר, כל סוג של למידה כדאי לקשור לצורך נוכחי, למשל: קורס SQL לקחת בעת עבודה על פיצ’ר מורכב בבסיס הנתונים, ולהתמקד בצרכים הספציפיים – ולא בעת ההצטרפות לחברה, שאולי שנתיים רצופות לאחר-מכן לא יעשה בידע שימוש משמעותי.
אחרית -דבר / סיכום
ציינתי ועסקתי בכמה טכניקות וכלים להפצת ידע. זו הרמה הטקטית.
הרמה האסטרטגית בהפיכת ארגון לארגון שבו “זורם ידע, באופן מתמשך” – דורשת עבודה… אסטרטגית. למשל: קביעת יעדים משמעותיים ואי התפשרות עליהם. למידה היא השקעה שפירותיה ניתנים רק לאחר זמן, ויש המון פיתויים לדחות אותה. כיצד הופכים למידה משמעותית ותמידית לערך בארגון שנלחמים עליו, ממש כמו Continous Delivery? הרבה ארגונים מוכנים להקריב הרבה בכדי להגיע ל Continuous Delivery הנכסף, אך האם לכל הארגונים הוא ייתן תרומה זהה או גבוהה יותר מ Continuous Knowledge Delivery?!
עוד אלמנט חשוב הוא מבנה הצוותים ותהליכי העבודה: עד כמה אנחנו יוצרים Silos (“מובלעות ידע”) וכמה אנחנו גורמים לערבוב וזרימה של ידע – בעיקר בידע פנימי לארגון.
הגדרת מומחיויות: איש QA, איש אוטומציה, Release Manager, איש Operations (בטעות נקרא: DevOps), DBA ועוד – עוזרות לפשט את הניהול בטווח הקצר, אבל יוצרות Silos של ידע (ואי-זרימת ידע) שיקשו עלינו בעתיד.
דוגמה קיצונית היא ארגון פלוני שעבדתי בו פעם, שבו הפרידו בין תת-הארגון שכותב קוד, לזה שמתחזק אותו. תת ארגון אחד חולם ומדמיין, ממציא ארכיטקטורה (וכותב מערכת) – ותת-ארגון אחר נתקל בלקוחות, לומד את הצרכים שלהם, מבין היכן הארכיטקטורה עובדת והיכן לא – אבל יש לו capacity מוגבל לתקן את הדברים (מתחזק את המערכת). לרוע המזל תתי-הארגונים הללו גם כמעט לא דיברו זה עם זה: העברת הידע הייתה מוגבלת ביותר. זו הייתה החלטה אומללה של מבנה ארגוני.
מימד אחר של יצירת Silos הוא ברמת הצוותים / מיקרו-שירותים: עד כמה לגיטימי לצוות אחד לשנות קוד של צוות אחר (תחת פיקוח)? ההחלטה שכל צוות נוגע רק בקוד שלו חוסכת חיכוכים, אבל עוצרת את זרימת הידע, והופכת את הארגון לפחות גמיש, שרק x אנשים יכולים לגעת בקוד מסוים – גם כאשר ידיים נוספות באזור יכולות היו לעזור.
קשה לי לאמוד עד כמה ערבוב ידע הוא כדאי. עד כמה שווה לספוג חיכוכים, מורכבות ניהולית, וטעויות קולניות (למידה = טעויות, אבל טעות של מפתח מצוות אחר בקוד שלי, לרוב לא תתקבל ברוח הזו)? אני יודע אבל שמערבוב ידע יוצאים פריצות דרך משמעותיות:
- שמתי לב לאורך השנים שרוב האנשים הבולטים והחזקים בארגונים שעבדתי בהם – עברו בין כמה צוותים ורק לעתים רחוקות “גדלו” ב silo בודד.
- אחוז ניכר מפריצות הדרך הארכיטקטוניות מגיעות מערבוב של ידע: דיון עמוק בין צוותים, מעבר של אדם מצוות x לצוות y לא פעם מעורר דיונים מעמיקים וחשובים, ובעצם אחת מנקודות-הכח היחסיות של ארכיטקטים – היא שם מכירים מגוון חלקים במערכת, ולא רק חלק יחיד. הם “מערבבים” ידע.
טכניקה אפשרית כאן היא מעבר תדיר של אנשים בין צוותים. אולי הגדרה שלאחר שנתיים בארגון מעודדים אנשים לעבור צוות? (מצד שני, בקצב המעבר בין חברות של חלק מהאנשים – זה אומר שחלק מהאנשים לא יזכו לעונג…)
עוד מודל שדיברנו בו בכמה חברות שעבדתי בהן הוא “מודל החלפת סטודנטים”, נניח אנשים מצוותים שונים מחליפים צוות לרבעון או שניים כדי להעביר ידע. זה נשמע רעיון טוב, אבל זה לא קרה בפועל, לפחות לא ב scale (בעיקר בגלל שיקולים של Delivery: כל החלפה כזו משמע אנשים עם תפוקה נמוכה לפחות חודש-חודשיים, עד שיתרגלו לחלק המערכת שעברו אליו).
בקיצור: הרבה שאלות, קצת פחות תשובות.
אתם יותר ממוזמנים להוסיף את התובנות שלכם בנושא.
שיהיה בהצלחה!
תודה על פוסט מעניין!
אני מוצא שלמידה “עמוקה” מתרחשת רק במצב של הפריה הדדית כמו שתיארת, או כאשר ממש מיישמים את הידע בפועל.
לכן לדעתי, דרך נוספת ומוצלחת של הארגון לעודד למידה (גנרית וגם ספציפית) היא ע”י מתן מקום להאקאתונים או קבוצות קבועות.
בהאקאתונים מתרחשת העברת ידע ספונטנית בין אנשים מקבוצות שונות, והרבה פעמים נבחרים פרוייקטים שמממשים טכנולוגיה חדשה, וזו דרך מעולה ללמוד באופן עמוק.
אצלנו היו קבוצות קריאה שעברו על ספר וכל משתתפ.ת הציג פרק, או לחילופין כל משתתפ.ת הציד או מימש מאמר לבחירתו בתחום (יותר מתאים ל-ML). יש גם קבוצות שלקחו על עצמן פרוייקט POC טכנולוגי ועבדו עליו לאורך זמן ביחד.
היי עמית,
תודה על התגובה!
בחוויה שלי, האקתון הוא יותר טעימה: אפשר להכיר ממנו טכנולוגיה חדשה, או אזור לא-מוכר במערכת – אבל קשה ללמוד לעומק. לחץ הזמנים (יום? יומיים? שלושה?) מחייב אותנו לוותר על התעמקות ולמצוא נתיבים אחרים במקומה.
דרך האקתונים הכרתי טכנולוגיות שונות (למשל: ReactJS, Firebase, או Jupiter Notebook) – אבל בביקור נוסף בהם, הבנתי שבעצם היה לי רק מושג קלוש על אופיין ותכונותיהם. זו החוויה שלי.
אני לא נגד טעימות, יש טעם גם בהן וגם בהתעמקויות.
קבוצות קריאה באמת יכולות להיות טובות – גם אני חוויתי כאלו. הייתי מוסיף שמעורבות של אדם מנוסה וביקורתי בקבוצה, יכולה לתרום לדיון ולעתים אף להחזיר את הדיון למציאת – בנקודות בהן קורא פירש לא נכון את הדברים, ובעצם הוא מציג תמונה שונה מהמציאות.
אלו לפחות החווית שלי.
תודה על התגובה!
אהבתי את האבחנות והחלוקה ל 2 קטגוריות של ידע.
אני חושב, שהידע על הביזנס ועל האירגון נמצא רחוק מאנשי R&D בגלל שבבסיסם זה ידע פחות מלהיב, פחות מעניין ופחות מושך מבחינתם. לרוב הם אוהבים (וגם בגלל זה הם למדו תארים או קורסים מדעיים) מתמטיקה, מדעי המחשב, טכנולוגיה. נראה לי שזה ידע שיותר מעניין אנשי כלכלה, מרקטינג, מכירות, מוצר. וגם יש סיכוי טוב שאחרי שנים מעטות הם ימצאו את עצמם בדומיין אחר ואז הידע יהיה לא רלוונטי – אז חבל “לבזבז אנרגיה” בלמידת הידע הזה.
לדעתי, הרבה מועמדים לא עוברים תרגילי תיכנות בסיסיים כי באמת עובדים על ניוטרל וגם כי רוב היום לא חושבים / עובדים עם אותם נושאים אז לא יוצא לתרגל או לחשוב על זה הרבה. מתי יוצא לחשוב על זה הרבה ולהעמיק? לפני ראיונות עבודה ואז נשאלת השאלה, כמה זמן היה לך להתכונן ומה נקודת ההתחלה שממנה התחלת להתכונן.
אני לא חושב שהאחריות נמצאת אצל האירגון בנושא זה, קל וחומר אירגון קטן (עד 100 איש).
אהבתי את הטבלאות – שמרתי – לצורך התרשמות 🙂
היי ליאור,
תודה רבה.
אני מסכים על הידע העסקי – ומדוע אנשי תוכנה לא נלהבים ללמוד אותו.
לגבי מועמדים, הייתי רוצה להאמין שמפתח אמור לפתור בעיית תכנות, ברמה של ראיון – לפחות כל שבוע או שניים בעבודה. אחרת? במה אנשים עובדים, לעזאזל? בטוח שהנדסת תוכנה?
אני יודע שזו לא בהכרח המציאות, אלא המציאות רק בחלק ממקומות העבודה. הרבה ארגונים נכנסים ל”מחזור” של שטחיות, ואז מפתחים עושים הרבה copy-paste, עבודות דומות וחוזרות, ו”spike solutions” כדי לפתור בעיה, מבלי “לשנות את הקוד מסביב שעלול להישבר”.
אני עדיין רוצה להאמין שזה פספוס, שכמעט בכל המקומות הללו, ניתן היה לעשות עבודה יותר מעמיקה, ליצור עניין ומשמעות רבים יותר למפתחים – ולהשאיר אותם חדים כקורח המציאות (ואולי גם: להטיח בפניהם של אחרים שחסרה להם חדות) – ותוך כדי כך גם לשרת טוב יותר את הביזנס.
“חזרה על הנדסת תוכנה” לקראת ראיון – הוא רעיון שגורם לגוף שלי לכאוב, על אף שאני מודע שזו מציאות נפוצה יחסית.
אני עדיין חושב שזה תפקיד של מקום העבודה, כל שדרת הניהול – ולא רק המפתחים.
לא להיכנע לשגרה של בינוניות…
תודה רבה!! פוסט מעולה.
בשבילי יש מרכיב למידת ידע גנרי משמעותי מאוד שלא מופיע בטבלה (אולי כדאי לפצל לכמה): בלוגים, רשימות דיוור ומדיה חברתית.
אני עוקב בפידלי אחרי הרבה מאוד בלוגים (לדוגמא הבלוג שלך), עוקב אחרי כמה רשימות דיוור שבועיות (במיוחד בתחום ה ML) ועוקב אחרי אנשים וקבוצות שמעניינים אותי בטוויטר ופייסבוק.
לא תמיד התוכן רלוונטי אבל עם השנים למדתי לעשות סינון ראשוני מהר (אני כותב למדתי מכיוון שהרבה פעמים אני מרגיש שקשה לי ״לוותר״ על ידע פוטנציאלי).
הידע שאני מקבל מהמקורות האלה הוא לרוב ״רוחבי״ ויותר מרחיב אופקים ונותן היכרות (לרוב לא מעמיקה) עם חדשנות, טכנולוגיה חדשה וידע בסיסי בהרבה מאוד תחומים. הרבה פעמיםי מצאתי את עצמי מושפע ממקור כזה והולך לחפש עוד חומר רלוונטי ומעמיק יותר בנושא.
אבל בנוסף… כמות פעמים רבה דברים שקראתי השפיעו על העבודה הישירה שלי ועזרו לי להביא לצוות שאני עובד בו חדשנות (ביחס למצב הקיים בצוות…) והטמעת נורמות עבודה בריאות\רעיונות.
היי גדי,
מסכים עם כל מה שכתבת. גם על המקור שלא ציינתי בפוסט, גם על הצורך (והקושי) לברור.
תודה!!
אצלינו בחברה יצרו ״טבלת ידע״ skills matrix (אמנם רחוקה ממושלמת) אמורה לעזור לכל מפתח להתקדם עפ״י קטלוג של טכנולוגיות (למשל הכרה של aws / k8s / helm / docker ושאר באזז וורדס) אבל גם ממפה עפ״י הרמה ״מה היינו מצפים מ- junior / mid / senior /principal / staff)
ה-skill matrix מתעדכן מרבעון לרבעון (השינויים לא ענקיים כמובן) וכך כל אחד יכול להעריך את הרמה שלו ולקבל גם מושג ״איך נראה השלב הבא״
יש כאן שילוב של שני סוגי הידע למשל ממפתח mid מצופה לשלוט באלמטים של k8s כגון deployment / cm /sa / values / secrets כדי שיוכל באופן עצמאי לגמרי לייצר דיפלויימנט שלם לסרויס שלו – יש כאן שילוב של ידע כללי וגם ידע ספציפי לארגון כי כמובן כמו כל ארגון יש לנו כל מיני ״שטויות״ שדחפנו לתוך הדיפלויימנט כדי שיתסדר יפה עם ci/cd שלנו וזה ידע שרלוונטי רק אלינו, ומצד שני ההבנה של הרכיבים ב-k8s זה לגמרי ידע שאפשר ״לקחת איתך״ למקום הבא.
לא מושלם, אבל בעיני זו הגישה יפה.
בנוסף, הארגון מקצה 4 שעות שבועיות קבועות ללמידה של כל נושא (גם שלא קשור לעבודה) אבל עבור junior / mid יותר קל לנצל את הזמן הזה עפ״י ה-skills matrix (מקנה מסגרת)
היי אבי,
תודה על התגובה. אכן מעניין, מעולם לא ניסתי גישה כזו – שמח לשמוע עוד היכן זה עובד יותר טוב, והיכן פחות.
תהייה גדולה שיש לי הוא החלק של ידע מקצועי בעבודה. קראתי פעם (אולי ב Peopleware? לא זוכר) מישהו שסיפר שהוא מאמין גדול בידע מקצועי, הוא רואה בו חשיבות אדירה, עד כדי כך שהוא מייחס לו כ 50% ממה שמהנדס תוכנה צריך לדעת 🙂
קל לי לחשוב ולהיזכר באנשים עם ידע מקצועי ברמה גבוהה, אבל שחסרים מיומנויות של התנהלות בארגון, השפעה על אנשים, ויותר מכל: פרגמטיות איך לקחת רעיון טוב, ולהפוך אותו למשהו מעשי ועובד.
אם יש לי את כל הידע המקצועי בעולם (נניח בהגזמה פרועה), אבל אין לי את המיומנות “לדחוף דברים”, להעריך עיקר בין תפל, או להבין את התנהלות הארגון – איך אהיה יותר מגו’ניור?
האם principle engineer זה לא הרבה יותר מידע מקצועי? זה אופי, התנהלות, וסגנון?
2 האגורות שלי.
עוד אשמח לשמוע קצת על 4 השעות בשבוע, וכיצד הן מנוצלות. גם מודל כזה לא ניסיתי, ואני תוהה אם חלק גדול מהאנשים לא מוצא עצמו חסר כיוון עם זמן פנוי כזה ללמידה?
תודה!
ליאור
פול ניוטרל זאת בעיה מאוד קשה במיוחד בארגונים גדולים ולא גמישים – בהם צוותים לעיתים עובדים בבועה טכנולוגית שצוותי התשתיות בנו להם. אתה יכול לעבוד 10 שנים שם, ולא תדע שום דבר שרלוונטי לעולם האמיתי – לא משנה כמה קורסים החברה תממן לך.
אצלינו (חברה בינונית ויחסית גמישה) מודל שעובד לא רע זה inspiration sessions פעם בשבועיים (עם פיצה כדי לעודד השתתפות ) על נושאים חדשים. והאקטון פעם בחודש כדי למצוא את אותם נושאים חדשים. בסופו של דבר זה עובד בעיקר על אלו שרוצים ללמוד – לעצרי, זה ממש לא כולם.
בנוגע לתרגילי תכנות בסיסיים : אני לא יודע בדיוק למה אתה מתכוון, אבל אם הכוונה היא לתרגילי leetcode למינהם אז לעניות דעתי, הקריטריון הזה להערכת הכשירות של מהנדס הוא לא נכון. אנשים לא יודעים לפתור את התרגילים האלה כי ב99% מהמקרים – אלו לא הבעיות שמהנדסי תכנה פותרים. מהנדסי תוכנה לרוב לא מאזנים עצים, אלא מתכננים מערכות בסקייל גדול וetl piplines שתומכים בדאטא מהמערכות הנל. או במיקרו, בנייה נכונה של קוד ואבסטרקציות גמישות אבל חזקות שמתאימות לראייה הביזנסית של המוצר.
אז אתה יודע את כל זה, ואתה יודע איך לדבג את ה classloader שכתבת בשביל לגלח עוד כמה מילישניות מאיזה חלק ספציפי במיקרוסרוויס שלך – ואתה בא לראיון ושואלים אותך על למצוא 3 מספרים הכי גדולים במערך.
בעיני זה מעיד על עצלנות של המראיין יותר משאר על סטאגנציה של המרואיין.
תודה דני על התגובה!
> בסופו של דבר זה עובד בעיקר על אלו שרוצים ללמוד – לעצרי, זה ממש לא כולם.
אתגר מוכר. זו המציאות.
אפשר לומר שהדור הצעיר אפילו יותר בררן ולא יזרום עם תוכן שלא נראה לו מעניין – זה מקשה על מארגני התוכן, אבל אני דווקא שמח על הבררנות (המרגיזה בהתחלה) הזו. סוג של אפס סבלנות לבזבוז זמן.
לגבי ראיונות תוכנה, אני מסכים שחשוב שראיון ישקף את העבודה – ולא תרגילים תאורטיים. לכן למשל אני לא אוהב שאלות על רקורסיה, אלגוריתמים לא יומיומיים (RB-Tree שהזכרת) או פינות איזוטריות של השפה (מה ההבדל בין transient מילה שמורה בג’אווה ל Transient@). אני מעדיף להסיר את כל אלו מבנק השאלות של הארגון (אציין שעל רקורסיה מעט ערערו אותי בשנים האחרונות – אולי בעצם זה תרגיל ראוי, על אף שלא סביר שיידרש בעבודה).
מצד שני, אני מאמין שיכולת לתקוף בעיה טכנית פשוטה, כמו פרסור של מחרוזת מבלבלת או מציאת 3 האיברים הגדולים – הן בעיות דומות באופיין למה שאנחנו נתקלים בהן כל כמה זמן בקוד. אני מתרשם מניסיוני שאנשי-תוכנה טובים מצליחים ב 90% מהפעמים לפתור את הבעיות הללו בלי בעייה. אנשים ש”כבד” להן להעמיק בבעיות הללו ובוחרים בהימנעות קלה יותר – מתבררים בדיעבד ככאלו שמסבכים קוד שהיה יכול להיות פשוט, ונוטים יותר להרחיב בעיות במערכת – במקום לפתור אותן מהשורש.
אני לא מכיר את leetcode, אלא כלים מתחרים – ושם היו הרבה בעיות מתמטיות מדי לטעמי, שאולי קל לבדוק – אבל באמת הולכות ומרחקות מיומיום רגיל של מפתח. אני גם מאוד אוהב תרגילי ראיונות שדומים לעולם התוכן של החברה. למשל: באימפרבה (חברת אבטחה) יצרנו סדרה של בעיות תוכנה לראיונות, הקשורות לבעיות בסיסיות באבטחה.
אני מסכים שחלק גדול הוא לא רק פתירת בעיות אלגוריתמיות, אלא יצירת הפשטות (abstractions) וכתיבת קוד נקי – וחשוב גם על זה לבחון מועמדים. לכן יש כמה ראיונות, כדי לבדוק מספר היבטים של כל מועמד, לא?
2 האגורות שלי,
ליאור
תודה על הפוסט המעניין והניתוח המעמיק!
בנושא השני שתיארת, של “ידע על המערכת/ארגון/ביזנס”, אני טרוד כבר זמן רב 🙂 בפרט, אני חושב שציינת מה קורה בקוד עצמו כדי בפועל – יש הרבה שכבות של אבסטרקציה שמונעת הבנה של מה שקורה מאחורי הקלעים, וגם המערכת פשוט גדלה ומסתבכת עם הזמן.
כחלק מהדרכים להתמודד עם זה, ציינת שתי דרכים של דוקומנטציה, ואני רוצה להתעכב קצת על מה הן מכסות:
* מחוץ לקוד – מעבר למה שציינת בטבלה (ואני מסכים), התיעוד הזה נוטה להיות מאוד high-level, ולא לכסות באמת איך עושים דברים בפועל. הסיבה היא שהוא מנותק מהקוד, וגם מתוך הבנה של כותבי התיעוד הזה שהקוד עתיד להשתנות הרבה, אז “כדאי” לתאר רק דברים מאוד “בגדול”, ברמה שלא סביר שתשתנה במהירות.
* בתוך הקוד – זה הצד השני של הסקאלה. הערות בתוך הקוד נוטות להיות מאוד טקטיות – כלומר לתאר את חלק הקוד הספציפי שהן מתארות (גם אם הן עושות זאת בצורה טובה). קשה להן מאוד (ובמקרים רבים בלתי אפשרי) לתאר תמונה גדולה יותר וחלק מ-flow – בטח אם חלקים מה-flow פשוט לא בקוד, או לא ב-repo הספציפי, או אפילו בקובץ אחר.
ולכן, שני סוגי התיעוד האלו “מפספסים” הרבה מאוד מקרים שדורשים הסבר – flows מורכבים במערכת (במובן של איך באמת הם עובדים ולמה), מוטיבציות והחלטות ארכיטקטורה (מעבר לאלו שהן הכי High-level), מקרים שחוזרים על עצמם במערכת (templates, patterns) ועוד ועוד.
תיעוד שכזה, כשהוא קיים, נותן לקורא אותו תחושה של לשבת עם מפתח/ת מהחברה שכתב/ה את הקוד – מן חוויה של “בוא אני אראה לך מה עשיתי כאן, ולמה, נעבור על זה ביחד”. זה תיעוד שכולל ממש חלקים מהקוד עם הסבר עליהם והמוטיבציה ויודע להסביר תמונה שלמה. אבל מאוד נדיר למצוא תיעוד כזה כיום.
אני חושב שיש כאן שני אתגרים מאוד גדולים:
1) כמו שציינת – ליצור תיעוד לאורך זמן, ובכלל, ליצור תיעוד כמו שתיארתי בפיסקה האחרונה בצורה טובה.
2) מאוד מהר, תיעוד נהיה לא עדכני (במילותיך – “עשוי להפוך לכמעט לא רלבנטי”). במיוחד תיעוד כמו שתיארתי – כי כדי ליצור תיעוד כזה, צריך להתייחס ישירות לקוד, שמשתנה מהר מאוד מטבעו.
צריך כלים שיאפשרו ליצור תיעוד רלבנטי באופן מהותי – כזה שמחובר לקוד, נותן לקורא שלו הבנה טובה של איך עושים דברים בארגון ולמה, וגם נשאר עדכני לאורך זמן. כתבתי על הנושא בהרחבה בפוסט שזכה לשם The continuous documentation manifesto. אני טוען שם שדוקומטנציה צריכה להיות coupled לקוד, תמיד עדכנית, ונוצרת בזמן הנכון, ומתאר את הצורך בכלים שיאפשרו לחזון הזה להפוך למציאות. מוזמנים לקרוא עוד:
https://www.infoq.com/articles/continuous-documentation
הנקודה של “עלות” כאן היא מהותית – אני מסכים שהשקעה בתיעוד לרוב דורשת השקעה משמעותית של זמן. אם אנחנו חושבים שהתיעוד יהפוך בקרוב ללא רלבנטי – לא משתלם להשקיע בו את הזמן הזה. מכאן החשיבות הגבוהה בכלים שמשנים את המשוואה הזו – ודואגים שהתיעוד באמת יהיה קשור לקוד, לאורך זמן, ובמאמץ קטן.
תודה רבה, עומר!
אקרא עכשיו את המאמר שלך.
תודה על הפוסט. כרגיל אתה מנסח בבהירות קונספטים שנמצאים אצלי בראש.
גם לי יצא לעבוד באירגונים שכפי שאתה מתאר צורת העבודה “מנעה בצורה דיי גורפת למידה”.
הפתרון שעבד עבורי במקרים כאלו היה לנצל את זמני הנסיעות לפודקאסטים מקצועיים. אמנם זו לא צורה ללמידה per se, במובן שאחרי האזנה לא רכשת skill חדש שאתה יכול להשתמש בו מיד, אבל זו כן הזדמנות להצצה והיחשפות לטכנולוגיות / מתודולוגיות חדשות שאפשר אח”כ ללמוד עליהן בצורה יזומה בכל אחד מהצורות שתיארת בטבלה של למידת ידע גנרי.
תודה על הפוסט. כרגיל אתה מנסח בבהירות קונספטים שנמצאים אצלי בראש.
גם לי יצא לעבוד באירגונים שכפי שאתה מתאר צורת העבודה “מנעה בצורה דיי גורפת למידה”.
הפתרון שעבד עבורי במקרים כאלו היה לנצל את זמני הנסיעות לפודקאסטים מקצועיים. אמנם זו לא צורה ללמידה per se, במובן שאחרי האזנה לא רכשת skill חדש שאתה יכול להשתמש בו מיד, אבל זו כן הזדמנות להצצה והיחשפות לטכנולוגיות / מתודולוגיות חדשות שאפשר אח”כ ללמוד עליהן בצורה יזומה בכל אחד מהצורות שתיארת בטבלה של למידת ידע גנרי.
תודה אבי!
בתור כותב בלוג (מושקע עמוק) – באמת קצת מוזר שלא הזכרתי בלוגים/פודקאסטים. מסכים שזו פלטפורמה חשובה להחשפות.