עד כמה התהליך רלוונטי?

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

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

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

יש איזושהי סיבה להשקיע בתהליך הזה במצב כזה?
 

BravoMan

Active member
אני חושב שזו טעות להסתכל על השפה בלבד.
השאלה האמתית צריכה להיות "מה המוצר?"

אולי גם חלק מהסיבה שמחפשים tech lead זה כי רוצים לחדש, אבל מצד שני הרי ידוע ש-if it is not broken, don't fix it.
אם הייתי במקומך, הייתי מברר יותר על המוצר, והפיצ'רים, ואם אפשר נגיע בתוכניות החברה לעתיד וספציפית כיצד אלו נוגעות לתחום האחריות במשרה שמציעים לך.

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

זה לא התחום שלי, אבל שמעתי שב-web, במיוחד ב-front הרדיפה המתמדת אחרי ה-framework הכי חדש גורמת להרבה צרות...
 
אני חושב שזו טעות להסתכל על השפה בלבד.
השאלה האמתית צריכה להיות "מה המוצר?"

אולי גם חלק מהסיבה שמחפשים tech lead זה כי רוצים לחדש, אבל מצד שני הרי ידוע ש-if it is not broken, don't fix it.
אם הייתי במקומך, הייתי מברר יותר על המוצר, והפיצ'רים, ואם אפשר נגיע בתוכניות החברה לעתיד וספציפית כיצד אלו נוגעות לתחום האחריות במשרה שמציעים לך.

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

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

vinney

Well-known member
אני חייב להסכים עם בראבו פה, משיקולים טיפה שונים.

את צריכה לקחת את כל המכלול בחשבון. השפה זה כלי, זה לא המהות. ++C זאת שפה חזקה וגמישה שאפשר לעבוד בה בכל דומיין. סטנדרטים מלפני 35 שנה זה קצת עצוב, אבל מצד שני כשיש קוד לגאסי לעשות לו ריפקטור רק כי יצא סטנדרט מעודכן לשפה זה לא בדיוק משתלם. בתחומים יותר דינמיים אכן יש נטיה לרדוף אחרי הדבר הנוצץ הבא בכל איטרציה של המוצר, אבל בתחומים קצת יותר יציבים בהחלט ניתן למצוא קוד מלפני 20-30 שנה שרץ ועובד ועושה את שלו בלי שום בעיה. אני הסתכלתי על קוד C אתמול, ובדרך כלל הצוות שלי עובד ב++C ובסטדנרטים יחסית מודרניים. אז יש איזה מודול שמישהו כתב עוד לפני בועת הדוט-קום שאנחנו משתמשים בו כבר עשורים והוא עובד נהדר - למה לגעת? למה הסתכלתי? כי גילינו שהוא לא תומך בסטנדרט נתונים מסוים שנוצר עשורים אחרי שהקוד נכתב ורציתי לבדוק כמה קל יהיה להוסיף. בסוף הפרטנר אמר ״הא, אז לא נשתמש בסטדנרט הזה, בסדר״ ופתר לנו את הבעיה.

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

אולי גם חלק מהסיבה שמחפשים tech lead זה כי רוצים לחדש, אבל מצד שני הרי ידוע ש-if it is not broken, don't fix it.
אם הייתי במקומך, הייתי מברר יותר על המוצר, והפיצ'רים, ואם אפשר נגיע בתוכניות החברה לעתיד וספציפית כיצד אלו נוגעות לתחום האחריות במשרה שמציעים לך.

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

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

את צריכה לקחת את כל המכלול בחשבון. השפה זה כלי, זה לא המהות. ++C זאת שפה חזקה וגמישה שאפשר לעבוד בה בכל דומיין. סטנדרטים מלפני 35 שנה זה קצת עצוב, אבל מצד שני כשיש קוד לגאסי לעשות לו ריפקטור רק כי יצא סטנדרט מעודכן לשפה זה לא בדיוק משתלם. בתחומים יותר דינמיים אכן יש נטיה לרדוף אחרי הדבר הנוצץ הבא בכל איטרציה של המוצר, אבל בתחומים קצת יותר יציבים בהחלט ניתן למצוא קוד מלפני 20-30 שנה שרץ ועובד ועושה את שלו בלי שום בעיה. אני הסתכלתי על קוד C אתמול, ובדרך כלל הצוות שלי עובד ב++C ובסטדנרטים יחסית מודרניים. אז יש איזה מודול שמישהו כתב עוד לפני בועת הדוט-קום שאנחנו משתמשים בו כבר עשורים והוא עובד נהדר - למה לגעת? למה הסתכלתי? כי גילינו שהוא לא תומך בסטנדרט נתונים מסוים שנוצר עשורים אחרי שהקוד נכתב ורציתי לבדוק כמה קל יהיה להוסיף. בסוף הפרטנר אמר ״הא, אז לא נשתמש בסטדנרט הזה, בסדר״ ופתר לנו את הבעיה.

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

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

vinney

Well-known member
העניין הוא שלפחות בתחום של סי פלאס פלאס - המון מהתפקידים כן דורשים ״על הנייר״ את הסטדרטים המודרניים לפני שבכלל מזמנים לראיונות, במיוחד לאור המהפכה שהשפה עברה ב 2011.
את יכולה ללמוד את זה לבד. "מהפכה" זה קצת מוגזם, אבל כן נוספו הרבה כלים מאוד מועילים. הרבה מהספריות שנוספו כבר היו מוכרות עוד הרבה קודם במסגרת ספריות הboost, שיכול להיות שאף השתמשו בהן במוצר הזה. מבחינת שינויי שפה - לרוב הם לא שוברים ואפשר להשתמש בהם גם בקוד ישן. כך שאין שום מניעה שלא תשתמשי בהם גם בקוד קיים - אם את מוסיפה פיצ'ר מספיק גדול כדי לגעת הרבה מקומות בקוד, אולי על הדרך תעשי גם קצת ריפקטורים למודול.

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

Be1n

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

זה מבאס, אבל אם השוק בעייתי וקשה למצוא עבודה באותה הרמה, הייתי מקהה את עצמי אליהם. (מתעלם).
 
למעלה