הצעה מגאמפא

[מלפפון במלח]

אז מה הדרך לעשות את זה?

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

 

[Henchman34]

אני קצת late to the party ואתחיל מזה שאגיד שאני חושב שההחלטה הספציפית שלך לעבור לדעתי נכונה. אני כן חושב שיש פערי ציפיות מסוימים בין מה שאתה חושב שאתה הולך לקבל לבין מה שאתה ככל הנראה תקבל בפועל. אני כותב מפרספקטיבה של מי שעבר מחברה ישראלית קטנה יחסית ל-corporate אמריקאי מאוד גדול שהוא לא גאמפא.

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

ואז יש את

אני אלמד ואתפתח הרבה יותר בתפקיד בגאמפא

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

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

הדרך הכי ישירה היא על ידי משימות. אם קיבלת משימה שכוללת יצירת docker ואתה לא יודעה מה זה docker אז אחרי המשימה הזו אתה לא תהיה מומחה docker ולא תדע איך בדיוק לשלב אותו ב-flow הרגיל שלך אבל תהיה לך רשומה חדשה ברשימת הדברים של "הדבר הזה שאתה עושה".

אז איך המשימות שלך ב-corporate גדול ביחס לחברה קטנה?
אני לא מתיימר לטעון שכל ה-corporate הם שבלונה. אבל בדיוק כמו ש-"Software Engineering is all about managing complexity" ככה לכל corporate יש את ה-complexity בצורת scale שצריך לנהל באיזשהו אופן. או אם להיות פחות פילוסופי אז התהליכים ב-corporate יוצרים קופסאות מוגדרות היטב שהגודל שלהן גדל עם עליה בדרגות והרבה מהזמן נשרף על סנכרון בין אותן קופסאות ולהגעה לקונסנזוס.

אם לצטט את עצמי מהודעה אחרת:
"בקורפורייט בהחלט יש תהליכים אבל הם סוג של רועה הכרחי לניהול מורכבות של גודל. אז הם בעיקר שומרים שלא תזוז שמאלה וימינה.
יש הגדרות מאוד ברורות, למשל לפחות אצלנו מפתחים לא עושים design זה לא שזה לא קורה(בטח אם אתה מפתח principle) אבל בשביל זה יש ארכיטקטים. אתה יכול לנסות ליזום אבל הכל זה uphill battle לכל פיסת קוד יש owner ויש subject matter expert... והכל נמרח.

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

בחברה הישראלית הקטנה עשיתי design ואז פיתוח ואז מצאתי את עצמי עוסק ב-devops(כי היה צריך) כמות החשיפה שלי כתוצאה מסוג המשימות שלי היתה עצומה. לעומת זאת החשיפה שה-corporate סיפק לי בצורה של משימות ישירות הייתה נמוכה בהרבה וזה לא השתנה משמעותית עם הזמן בלי תלות בביצועים.

אפשר לעבור לדבר על כל האנשים האיכותיים שעובדים ב-גאמפא וללא ספק אתה תמצא הרבה יותר כאלה בחברות שמשלמות את ה-$$$ big. אבל השאלה היא איך הם תורמים לחשיפה שלך? לי בחברה יש יותר מכמה אנשים שהרבה יותר מיומנים ממני. מהראש אני יכול לחושב על שלושה כאלה. הראשון יודע לעשות דברים end to end אבל לא אוהב לתעד, לשתף, או ללמד. השני מרוב שהוא נשאב לכל פגישה שניה בורח מכל פגישה(נמצא בחול) שניסיתי לקובע איתו ובמקום זה עונה בהודעות ופעם אחרונה שהיה לנו "face to face" הייתה לפני בערך שנה. השלישי מאוד נחמד אוהב לדבר ולשתף... אבל אין לנו שום משימות משותפות אז בפועל אין לנו כמעט שום נקודות חיתוך והידע שלנו הוא מאוד ספציפי לתחום שפחות רלווניטי לי.

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

יש את הנושא של לימוד "טכנולוגיות חדשות" שקצת קשה לי להגדיר כי מה זה טכנולוגיות כאשר מדברים על פיתוח תוכנה. האם זה שפות חדשות אז מעבר ללימוד ראשוני של קונצפט(נגיד ניהול זיכרון דרך C, ו-OOP דרך CPP) כמה ערך יש ללמוד RUST אחרי שמכירים C/CPP? מה החשיפה החדשה שמקבלים? אם זה containers אז אחרי שמשתמשים ב-Docker ומבינים את ה-use case כמה כבר קשה לעבור ל-podman? האם יש צורך לעבור על QEMU, VirtualBox, ו-vmware בשביל להבין את הכוח של סביבות מבודדות בקליק אוו שמספיק אחד מהם?

אפשר לדבר על הנושא של כלים לשימוש פנימי בתוך הארגון. יש ערך לחשיפה לכלי שפותר בעיה באופן מוצלח ואתה רואה את זה בפעם הראשונה. למידה של כלי פנימי(לא משנה כמה מהפכני) ברמת ה-API שלא תפגוש מחוץ לארגון לא תורמת למיומנות הכללית שום דבר.