התפתחות מקצועית

[hadooper]

התפתחות מקצועית

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

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

 

[Astroo]

יש הרבה שיקולים חוץ מהתפתחות מקצועית

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

 

[N i X]

לדעתי לא שורדים הרבה זמן בתפקיד משעמם

אלה אם אתה מוצא איך להפוך אותו למעניין. ( נושא בפני עצמו )
&nbsp
כל שיקול הוא לגיטימי בעיני להחליף מקום עבודה (למה לא בעצם?), מה שצריך להזהר בו, לדעתי הוא לבדוק שאתה אכן תחזיק ״קדנציה״ במקום החדש, ולא ״תשרף״ אחרי כמה חודשים כי
התפקיד משעמם בטירוף.
&nbsp
אני דיי מסכים עם מודל המוטיבציה של:
Autonomy, Mastery, Purpose
https://www.brainpickings.org/2013/05/09/daniel-pink-drive-rsa-motivation/
&nbsp
אם לא יהיה לך לפחות חלק מהנ״ל, תקום לעבודה בבאסה.

 

[user32]

עם הזמן והוותק, עניין ההתפתחות פחות חשוב

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

 

[choo]

זה נכון, עד שיש שינויי פרדיגמות בתעשייה:

&nbsp
כמה דוגמאות:
&nbsp
עד אמצע שנות ה-80 עבדו בעיקר עם בשיטות פרוצדורליות. משם (או קצת מאוחר יותר) התחיל להיכנס לשימוש תיכנות מונחה עצמים ותיכנון מונחה עצמים. מי שלא הצליח לבצע את המעבר הזה, היום נמצא בעיקר בסביבות משובצות ויתקשה לצאת משם.
&nbsp
עד תחילת/אמצע שנות ה-90 עבדו ללא שימוש ב-threads במרבית התעשיה שמחוץ למערכות משובצות מסויימות. ואז זה נכנס, במקום שימוש בריבוי תהליכים (או יותר משמעותי - במקום שימוש בתיכנות מונחה ארועים). מי שלא הכיר את זה - היה צריך ללמוד להכיר את זה, וזה משנה מאוד את העולם שחיים בו.
&nbsp
עד שלב מסויים תחילת שנות האלפיים התיכנות היה בעיקר על מערכות בעלות מעבד אחד וליבה אחת. אנשים ידעו שהתוכנה שלהם תשתפר כי כל דור מעבדים היה מהיר מקודמיו, מבחינת כמות פעולות לשניה, רוחב פס לזכרון, גודל cache וכדומה. בשלב התדרים של המעבדים כמעט הפסיקו לעלות, ובמקום זה ההתקדמות היום היא בעיקר בכמות הליבות למעבד (משיקולי צריכת אנרגיה, התחממות וכדומה). מי שלא ילמד לכתוב קוד שיודע לגדול לינארית עם כמות המעבדים, ימצא את עצמו במצב בעייתי כשבמעבד סטנדרטי תהינה עשרות ליבות, ועבודה לא יעילה עם נעילות לא תצליח לנצל את הליבות הללו כמו שצריך.
&nbsp
דוגמא נוספת היא עבודה עם תכנות וספריות קוד פתוח. עד נקודה מסויימת, היה מקובל שכל דבר כותבים לבד, או לכל היותר משתמשים בספריות מסחריות שכוללות תעוד נרחב ותמיכה טכנית. בשלב מסויים השימוש בספריות קוד פתוח החליף את זה, ושם לרוב אין לך תמיכה טכנית והתעוד לוקה בחסר - מי שלא לומד כיצד לתמוך בעצמו על ידי שימוש נאות בפורומים, חיפוש בגוגל, או קריאת הקוד של הספריות - מוצא את עצמו תקוע. ההרגל הזה שנראה היום די מובן מאליו, כמעט שלא היה קיים בתעשייה בשנות ה-90, ואנשים נאלצו ללמוד להשתנות גם אחרי שהיו להם הרבה מאוד שנות נסיון.
&nbsp
&nbsp

 

[user32]

נראה שלא הבהרתי את עצמי

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

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

 

[יבגניי34]

מדוייק. היחידים שחושבים שצריך איזה paradigm shift כדי

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

 

[choo]

הדוגמאות שתארתי אינן סתם "עוד כלי"

&nbsp
זה לא כמו מעבר לשפת תיכנות אחרת, או לשימוש בספריה ב במקום ספרייה א - מדובר בשינוי של הרגלי מחשבה שיש אנשים שהתקבעו עליהם במשך שנים.
&nbsp
ראיתי אנשים שמסרבים להבין מדוע תיכנות מונחה עצמים עוזר לייצר קוד סקיילאבילי יותר (מבחינת גודל בסיס הקוד או הפונקציונאליות) לעומת תיכנות פרוצדורלי - ואנשים שלקח להם זמן להתרגל לצורת החשיבה הזו (לא ברמה של ימים - אלא של מספר חודשים).
&nbsp
כנ"ל המעבר מקוד סדרתי לינארי לקוד מרובה נימים - יש כמה שינויים בהרגלי המחשבה שצריך לאמץ, שלאנשים שבמשך 20 שנה התרגלו לעבוד אחרת ולחשוב אחרת, לוקח זמן להתרגל אליהם ולשלוט בהם.
&nbsp
לא כל המעברים הם גדולים, ולא כל שינוי דורש הרבה זמן להתרגל אליו (למשל להתחיל שימוש בבדיקות יחידה זה משהו שאפשר לבצע תוך כמה ימים ברמה שבלונית, ולאחר מכן זה בעיקר fine tuning של כיצד כותבים בדיקות יחידה יעילות. להשתמש בספריית angular במקום ספריית jquery גם זה לא קפיצה גדולה במיוחד לאדם מנוסה. אבל יש מעברים שדורשים להשתחרר מקבעונות של שנים - ולחלק מהאנשים זה לוקח זמן - בין אם מסיבות פסיכולוגיות, ובין אם מסיבות שגם למפתח מתחיל זה ייקח זמן (כי הנושא מאוד שונה ממה שמוכר ויש לאותו אדם פחות על מה לבנות את השיטה החדשה).

 

[user32]

תלוי בבנאדם

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

 

[zaske]

מסכים לגמרי ואני מנסה להסביר את זה לרבים

ללא הצלחה

 

[hadooper]

אני קצת מתקשה להעריך אם הגעתי למצב כזה

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

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