Break Point ולא בדיבאגר...

dunder

New member
שלום לכולם.

מתנצל מראש על אורך ההודעה.:)
אני בעיקר מעוניין לשתף, אבל אשמח גם לקבל פידבק מאנשים אחרים שהיו במצב דומה.

אני בתעשייה מעל לעשור. בשנים האחרונות עברתי מאוטומציה ובדיקות לפיתוח.

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

השנתיים האחרונות שלי היו מאתגרות במיוחד.💀

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

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

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

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

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

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

ספגתי את זה בשקט ותהיתי מתי ייגמרו לי ימי החסד.
אחרי 3 חודשים התחלתי לקבל רמזים מהר"צ שאני עובד לאט.
לא עזרו כל ההסברים שלי שהדיזיין השתנה ושקיבלתי כמות לא סבירה [60<] של הערות ל-PR.
בשלב הזה החלטתי להרים ידיים וביקשתי לעבור צוות.
זה רק החריף את המצב והטענה היתה שאני צריך לשפר ביצועים ולא להתחמק מהבעיה.
כשטענתי מול מנהל המחלקה שחלק מהבעיה הוא הצוות הנוכחי - הוא אמר לי או שתסתדר או שתעזוב.
אחרי חצי שנה קיבלתי את הציון הנמוך ביותר האפשרי בהערכה האישית יחד עם שורות של נזיפות על כך שאני לא משתלב.

פה נשברתי.o_O

עכשיו אני עושה חשבון נפש ותוהה פניי לאן.

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

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

אשמח לשיתוף.
תודה.(y)
 

BravoMan

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

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

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

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

לא יודע מה צופן לך העתיד, אבל שיהיה בהצלחה!
 

dunder

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

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

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

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

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

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

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

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

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

vinney

Well-known member
אני אסכם את מה שקראתי:

מהנדס עם 10+ שנות נסיון לא הצליח להשתלט על שלושה פרוייקטים רצופים.

זה סיכום נכון של המצב? כי אם כן - אז סלח לי, אבל הציפיה בתעשיה ממישהו עם 10 שנות נסיון ויותר היא לא לשבת חודש בחפיפה עם הראש צוות אלא לדעת להבין וללמוד את החומר לבד.

60 הערות לPR בחברה חדשה זה יכול להיות עגום ויכול להיות שלא, השאלה מה למדת מזה. ראיתי גם יותר מזה. דיזיינים תמיד משתנים, אנחנו לא בIBM של שנות ה80 פה. וגם מנהלי מוצר זה לא משהו שבלעדיו אי אפשר להסתדר. בחלק מהפרוייקטים אולי אפילו עדיף, הם עושים יותר נזק מתועלת.

השאלה האמיתית היא אם אתה אכן מתפקד כמו מהנדס עם 10 שנות נסיון. זה לא נשמע כך. תיאום ציפיות זה הכל פה.
 

dunder

New member
אני אסכם את מה שקראתי:

מהנדס עם 10+ שנות נסיון לא הצליח להשתלט על שלושה פרוייקטים רצופים.

זה סיכום נכון של המצב? כי אם כן - אז סלח לי, אבל הציפיה בתעשיה ממישהו עם 10 שנות נסיון ויותר היא לא לשבת חודש בחפיפה עם הראש צוות אלא לדעת להבין וללמוד את החומר לבד.

60 הערות לPR בחברה חדשה זה יכול להיות עגום ויכול להיות שלא, השאלה מה למדת מזה. ראיתי גם יותר מזה. דיזיינים תמיד משתנים, אנחנו לא בIBM של שנות ה80 פה. וגם מנהלי מוצר זה לא משהו שבלעדיו אי אפשר להסתדר. בחלק מהפרוייקטים אולי אפילו עדיף, הם עושים יותר נזק מתועלת.

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

אתה מתמצת את כל מה שכתבתי בצורה צינית.

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

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

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

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

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

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

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

טפטוף קבוע של הערות ב-PR שלא נגמר אומר מבחינתי או שהמימוש גרוע לחלוטין כי יש פה בעית תקשורת או חוסר דיזיין או שאחד מהצדדים לא יודע מה הוא רוצה.
אצלי עד היום זה היה בעיקר: פוש גדול / או חלקי של קוד -> גשם של הערות -> פושים נוספים עם תיקון -> במקרה נדיר עוד הערה או שניים -> מרג'.
 

vinney

Well-known member
שלום וויני,

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

אני לא רואה עצמי בתור ג'וניור כי אני יודע להסתדר לבד בעצמי (הקמת סביבה, GIT וכאלה) וכנ"ל לשבת וללמוד לבד (יוטיוב, יודמי וכו') ואף הצלחתי לעשות זאת יחסית טוב כאשר הייתי צריך להשתמש במודולים חיצוניים של קוד פתוח.
שתי שורות למעלה כתבת ״אני לא מהנדס עם 10 + שנות ניסיון״. אז תחליט - ג׳וניור או לא ג׳וניור?

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

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

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

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

Nuke1985

Active member
בפועל - כשנחשפתי לקוד גיליתי ליקויים קשים. סיסמאות בתוך הקוד

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

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

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

זה בעייתי מבחינה פוליטית, נניח שהיתה עובר והיה הולך לך אחלה אצל ראש צוות אחר? הוא היה יוצא לא יוצלח אז יש לו אינטרס לא לעשות את זה.

פה נשברתי.o_O

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

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

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

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

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

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

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

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

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

dunder

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

dunder

New member
קראתי את כל התגובות ותודה על העזרה.

כמה נקודות שאני חושב שכדאי להוסיף:

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

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

איך אני נמנע ממצב בו הר"צ או הצוות לא נותנים לי מספיק context ואני לא מצליח להשלים את הפערים בעצמי.

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

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

BravoMan

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

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

איך היית משתלב עד עכשיו בצוותי אוטומציה?
סיפרת שהיית מחליף מקום עבודה כל 3-4 שנים במשך יותר מעשור, אז איך יכול להיות שעד עכשיו לא למדת להשתלב בצוות?

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

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

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

Nuke1985

Active member
לא בטוח שצריך לקחת ללב את ההערה שאתה עובד לאט , זה בד"כ נאמר על יד מנהלים כדי להלחיץ את העובדים ולסחוט מהם יותר.

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

מצד שני כן יש את העניין של forced ranking וצריך להיזהר מזה.
 

user32

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

לשאלתך איך לעשות את זה: אני ממליץ להיות ממוקד מטרה. אני תמיד אומר לאנשים שאנחנו נמדדים ב3 פרמטרים עיקריים:
1. דילוור של פיצ'רים
2. לוחות זמנים
3. איכות כולל איכות הקוד
אני ממליץ להתמקד בשניים הראשונים. קח מטלה, תחשוב שאתה מקבל אפס עזרה ופשוט תדלוור הכי טוב שאתה יכול. אם עשית טוב - הרווחת. אם טעית (וכולם טועים) - תקבל פידבק: מהפרודקט, מהקיו איי, מהרוויו על הPR או במקרה הגרוע מלקוח קצה זועם. במקום להתייסר על הערות בPR, פשוט תקן אותם מהר ותשלח מחדש. אחרי 2 סבבים כאלה הקוד שלך ימוזג ותמשיך הלאה. אחרי 5 סבבים כאלה אתה כבר תדע לזהות בעצמך איזה הערות צפויות להתקבל ותמנע אותן מראש. אחרי 10 סבבים כאלה יגידו "וואלה הבחור הזה מתקתק ואפשר לסמוך עליו".

בהצלחה.
 

randomUser432

New member
1.תרשום את כל הערות בצד (אלו שבPR, אלו שאמרו לך בעל-פה, כאלו טכניות וגם אישיות - הכל) ותעבור עליהם כל תקופה כדי שלא תשכח.
2.תעבור על PR של אחרים שעברו כבר CR (אל תעשה להם CR, ואל תוסיף הערות, הם לא צריכים לדעת שאתה מסתכל) - מזה אתה יכול לראות מה נהוג בצוות, על מה אוהבים להתלונן וגם תוכל ללמוד קצת על המערכת.
3.בנוסף ממליץ אם זה נהוג אצלכם על F2F עם המנהל האישי פעם בשבוע - עוזר לתפוס בעיות כשהם קטנות.
 
למעלה