מהרהר על ההתפתחות קרירה כמפתח תוכנה מבחינת Domain

[Sniperoonie]

אני סוגר בקרוב שנתיים בעבודה הנוכחית שלי כמפתח Linux embedded שגם נגע ביצירת backend עבור אחת המכונות שלנו(בשפה שהיא high level).
זה בדיוק זמן טוב להתחיל עבודה חדשה בשביל להיחשף לדברים חדשים ולהקפיץ שכר/ כאשר חיפשתי את מקום העבודה הראשון שלי בעיקר רציתי להכניס רגל בדלת ובאותה המידה שבה לקחת תפקיד של embedded הייתי לוקח תפקיד מעולם ה-web. החשיבה שלי אז הייתה שאם אני יודע שפה X אז צריך ללכת לעבודות שמצריכות את השפה X.

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

הנחה ראשונה - domain
לא רק ששפה זה רק ה"פטיש" שאיתו מכים ב"מסמר" אלא שיש הבדל בין מפתח שכותב feature כללי בתוך domain לבין מפתח שכותב לוגיקה שקשורה ל-Domain עצמו.
יש הבדל בין מפתח C++ שכותב -Firmware עבור מכונה ספציפית לבין אחד שכותב את הקוד של דפדפן כמו Chrome שככל הנראה נותן מענה לבעיות שבהם נתקלים גם בדפדפן כמו Firefox. יש הבדל בין מפתח backend שכתב את ה-parser של Netflix לבין המפתח שהתמקד בחלק של הלוגיקה שאחראית לטפל בעומס הבקשות שאיתו מתמודד השירות וה-scale שרק הולך וגדל עם הזמן. לא רק שהמפתח השני מתמודד עם אתגר מעניין יותר(לדעתי) זה בעצם domain משל עצמו שרלוונטי לחברות web שרוצות לשרת מיליוני לקוחות בו זמנית.

הנחה שניה - לחברות הגדולות עדיף להיכנס כשאתה כבר senior
אני מניח שרמת המשימות שיקבל junior בחברה גדולה כמו facebook ברוב המקרים תהיה פחות מורכבת מהמשימות אותם הוא יקבל בחברה קטנה. זה נכון לא רק לגבי המשימות עצמן אלא גם לגבי ה-ownership שיוכל לקחת ומשתי הנקודות האלה נגזרים הדברים אותם תוכל ללמוד מהעבודה עצמה.

הנחה שלישית - עולם ה-web זז הרבה יותר מהר מעולם ה-embedded
אני בא מתחום של embedded (ומודע לזה שיש לי bias ) שלגמרי בסדר עם לעבוד עם C++11 ולא רואה סיבה לרדוף אחרי טכנולוגיות חדשות. בזמן שכשאני
מדבר עם מפתחי web מרגיש לי שהם כל הזמן צריכים ללמוד שפות וכלים חדשים שלעניות דעתי הם הטפל של עולם הפיתוח תוכנה.

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

שאלות
1. האם בעצם חברות קטנות שמתמקדות במוצר embedded שאפשר להגדיר אותן כ-B2B הן מראש מקום פחות טוב ללמוד ולגדול בו כי יש יותר סיכוי שיהיו הרבה יותר שריפות לכבות, הרבה יותר לחץ להוציא גרסה והרבה יותר סיכוי שיהיה לקוח גדול שהגחמות שלו יהיו בראש סדר העדיפויות?
2. לדעתי מפתח טוב הוא מפתח שאכפת לו מ-clean code ו-best practice עד כמה לדעתכם זה באמת מוערך בתעשיה שלנו או שכל מה שמעניין זה כמה מהר אתה יכול "to deliver" והאיכות לא מעניינת?
3. האם עולם ה-web באמת יותר כאוטי ביחס ל-embedded או שזה נטו ה-bias שלי?
4. בסוף כולם פותרים בעיות(כותבים לוגיקה, פותרים באגים, מרחיבים מוצר קיים..), כשאתם מדברים על "לעשות וללמוד דברים מעניינים", למה אתם מתכוונים והאם לדעתם זה קשור ישירות בלעסוק ב-domain?
5. עד כמה לדעתכם משחק התפקיד של front או back כאשר מתרגמים לחשיבות לארגון וגוזרים ממנו שכר בעולם ה-web?
6. שאלה קצת פילוסופית , אבל לאן צריך לכוון מעבר לעבודה הראשונה בשביל לתרגם את הנסיון לחשיבות לארגון ושכר? האם הכיוון צריך לחפש להתמקד ב-domain?

 

[yahud]

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

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

3. אתה מגיע מעולם ספציפי, ולא מכיר מאוד את העולם השני -> אז זה נראה לך כאוטי. לדעתי עולם הembedded הוא לא פשוט בכלל. בכל מקום כל מפתח מתעסק עם כמה טכנולוגיות ספציפיות. העולם הזה לא מפסיק להתפתח ובכל תחום כמעט יש חידושים לאט לאט. בגלל שבHigh Level לפי הגדרה יש יותר אופציות לבצע חידושים שונים (כשרמת האסטרקציה יותר גבוהה, יש לך יותר כלים בסיסיים להרכיב אבסטרקציה יותר גבוהה).
בסופו של דבר צוותים מדלוורים מוצר שצריך לעמוד בדרישות כלשהן. זה לא מאוד משנה אם השתמשת במוצר האחרון שנכתב כדי להרים שרת בbackend שלך.

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

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

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

- אני ג'וניור
- לא ממליץ ומייעץ, אשמח לעוד דעות

 

[הבורח מהמירוץ]

הנחה ראשונה - domain
לא רק שהמפתח השני מתמודד עם אתגר מעניין יותר(לדעתי) זה בעצם domain משל עצמו שרלוונטי לחברות web שרוצות לשרת מיליוני לקוחות בו זמנית. Scalability הוא לא בהכרח יהיה דומיין בפני עצמו בחברה, הוא יכול להיות דרישה מפיצ'ר מסויים (לדוגמה - לעשות Caching לחיפושים אחרונים בגוגל). זה גם יכול להיות עבודה של צוות Infra שלא מדלוור פיצ'רים - להקים תשתית Kubernetes שתומכת ב-horizonal scaling. לכל חברה צרכים העסקיים משלה וצורה ארגונית שבה היא מממשת אותם.

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

הנחה שלישית - עולם ה-web זז הרבה יותר מהר מעולם ה-embedded
אני בא מתחום של embedded (ומודע לזה שיש לי bias ) שלגמרי בסדר עם לעבוד עם C++11 ולא רואה סיבה לרדוף אחרי טכנולוגיות חדשות. בזמן שכשאני
מדבר עם מפתחי web מרגיש לי שהם כל הזמן צריכים ללמוד שפות וכלים חדשים שלעניות דעתי הם הטפל של עולם הפיתוח תוכנה. טכנולוגיות חדשות מאפשרות לפתח במהירות גדולה יותר / לקבל מענה לבעיה טכנית שעד עכשיו לא היה לה פתרון. Redis הומצאה לפני 12 שנים, וחברת טכנולוגיה שרוצה לעמוד בסקייל של התעבורה היום צריכה פתרון לאחסון in memory אחרת היא תשאר מאחור. אני גם חושב שלמידה מונעת התנוונות וזה חיוני, אבל זאת רק דעה אישית

חברות B2B ביחס ל חברות B2C
ברגע שמדובר בחברת B2B, ככל הנראה הקוד רץ באיזה מקום מרוחק אצל הלקוח(לפעמים בלי חיבור אינטרנט) זה אומר שמרווח הטעות מאוד קטן, כי deployment של גרסה חדשה או תיקון באג היא כאב ראש בניגוד לחברה שהיא B2C שאצלה לרוב דוחפים את התיקון לענן ומאוד גמיש ונוח לתקן באגים. מכאן אני גוזר שיש הרבה מאוד לחץ בחברת B2B בסמוך לשחרור גרסה. מעבר לזה חברות B2B יכולות בקלות רבה להפוך תלויות בלקוח גדול אחד שבמקרה כזה הופך מלקוח למנהל מה שיכול להתנגש עם החזון המקורי של החברה(להכניס לח. על קצב שחרור המוצר...). מרגיש לי גם שבחברות B2B יש יותר שריפות שצריך לכבות. B2B זה פתרון שנמכר לעסקים ו-B2C זה פתרון שנמכר לאנשים יחידים כמשתמשי קצה. יש המון פתרונות (אפילו אתן דעה לא מבוססת ואגיד שהרוב היום) שהן על ענן (כנראה ראית את המונח SaaS עד היום). עדיין יש פתרונות on prem אבל זה פחות פופולרי ובדרך כלל נעשה מאילוצים עסקיים (זה מונע CI/CD, ובדרך כלל מפותח במתודולוגיות Waterfall שחסרונותיה הוכחו כבר אין ספור פעמים)

שאלות
1. האם בעצם חברות קטנות שמתמקדות במוצר embedded שאפשר להגדיר אותן כ-B2B הן מראש מקום פחות טוב ללמוד ולגדול בו כי יש יותר סיכוי שיהיו הרבה יותר שריפות לכבות, הרבה יותר לחץ להוציא גרסה והרבה יותר סיכוי שיהיה לקוח גדול שהגחמות שלו יהיו בראש סדר העדיפויות? לא עבדתי בחברות שמתקדמות במוצרי embedded, אבל לדעתי עדיף לך לא לעבוד במקום שיש בו לחץ תמידי, שלא יודע להתמודד עם בעיות production ביעילות ושמזניח את איכות הקוד שלו
2. לדעתי מפתח טוב הוא מפתח שאכפת לו מ-clean code ו-best practice עד כמה לדעתכם זה באמת מוערך בתעשיה שלנו או שכל מה שמעניין זה כמה מהר אתה יכול "to deliver" והאיכות לא מעניינת? מהירות הדילוור חשובה לטווח קצר, חברה שלא אכפת לה ממנו תמות מהר (או שתשרוף כספי משקיעים עד אין סוף). איכות הקוד חשובה לטווח ארוך, חברה שלא אכפת לה ממנו תמות לאט (או שתשרוף המון כסף בלשכתב קוד ספגטי אין סופי). כדאי שיהיה אכפת לך משני האספקטים

שאלות מעניינות, מקווה שהצלחתי לעזור מעט

 

[go nature]

האם בעצם חברות קטנות שמתמקדות במוצר embedded שאפשר להגדיר אותן כ-B2B הן מראש מקום פחות טוב ללמוד ולגדול בו כי יש יותר סיכוי שיהיו הרבה יותר שריפות לכבות, הרבה יותר לחץ להוציא גרסה והרבה יותר סיכוי שיהיה לקוח גדול שהגחמות שלו יהיו בראש סדר העדיפויות?

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

לדעתי מפתח טוב הוא מפתח שאכפת לו מ-clean code ו-best practice עד כמה לדעתכם זה באמת מוערך בתעשיה שלנו או שכל מה שמעניין זה כמה מהר אתה יכול "to deliver" והאיכות לא מעניינת?

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

האם עולם ה-web באמת יותר כאוטי ביחס ל-embedded או שזה נטו ה-bias שלי?

אני מגיע גם מembedded כך שאל תיקח את המילה שלי(איש זר באינטרנט, בסופו של דבר), אבל לדעתי אתה צודק. לדוגמא אם אתה יודע c++11 כנראה שהשינוי המשמעותי בשפה שתצטרך להכיר יהיה ב c++20 שבטח יקח עוד 5-6 שנים שחברות יתחילו להשתמש בסטנדרט הזה. למרות זאת תמיד יש מה ללמוד בכל תחום, ודווקא בתחומי הEmbedded הרבה פעמים הידע שנדרש הוא הרבה יותר "עמוק" במובן של מרמת האיך מתנהג האסמבלי או הcache עד high level design של מערכת שלמה.

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

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

עד כמה לדעתכם משחק התפקיד של front או back כאשר מתרגמים לחשיבות לארגון וגוזרים ממנו שכר בעולם ה-web?

אין לי מושג, לא מגיע מהעולמות האלה.

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

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

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

 

[Sniperoonie]

תודה רבה לכל מי שהגיב, הרחבתם לי את הפרספקטיבה

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

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

@הבורח מהמירוץ רק אציין שאני מאוד נהנה ללמוד פשוט לא רואה בלימוד שפה או framework חדש כמשהו מאוד מעניין. כן רואה בשפה ככלי ללימוד תפיסה(כמו OOP או GC), אבל ברגע שלמדת C++ אתה לא תלמד יותר OOP אם תלמד JAVA.

@yahud - אני לגמרי מסכים, "הכי טוב לבחור domain שהוא מספיק לא ספציפי"

@go nature - מאוד מתעניין בתחום מסיבות אישיות, אשלח הודעה פרטית.