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

לבנות צוות =! לאסוף מומחים

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

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

דרושים מפתחי ג'אווה

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

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

מדענים .vs מהנדסים

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

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

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

זמן אמיתי

באחת החברות בהן עבדתי, בנינו ארכיטקטורה חדשה ומבוזרת למנוע BackEnd מורכב, שכלל משימות רבות. חלק מן המשימות הוטרגו על ידי אירועים שונים, ואחרות התעוררו לחיים כל פרק זמן נתון, באמצעות Cron או מנגנוני תזמון אחרים. הרקע שלי היה קצת שונה משל מרבית הצוות; לפני שהגעתי לשם, התעסקתי פחות במערכות מהסוג הזה. בין היתר, ביליתי זמן רב בעבודה על מערכת אלקטרו-מכנית שדרשה עבודה בסביבת Hard Real Time.

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

מלחמת הכוכבים

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

השלם הוא יותר מסך חלקיו

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