בתשובה למנדי, 01/11/10 10:31
 |
|
 |
||
|
||||
 |
החיים נעשו אמנם ארוכים יותר אבל שנות הפרנסה הפוטנציאליות נעשות קצרות יותר אצל כמה מהמגזרים. נניח מהנדס טרי בן 30, שסיים את התבגרותו הארוכה ( טיול ארוך, התאוששות ממערכת יחסים ארוכה, התפרקות האנסמבל הבארוקי שלו ועוד קלישאות מהסוג הזה), עשוי להשתלב בהי-טק ולהשתכר יפה עד בערך גיל 50. אלו אמנם צרות של עשירים, אבל גם שכירים אחרים סובלים מהבעיה הזאת, אולי יותר. (ראובן- מובטל הי-טק טרי, שמעולם לא השתתף ביודעין באנסמבל בארוקי) |
 |
 |
 |
|
|
|
||
|
||||
|
צר לי לשמוע. מקווה שמצב העניינים הזה יימשך מעט ככל האפשר. | |
|
|
|
|
|
||
|
||||
|
לא, לא, רק אל תאחלי לי להצטרף לאנסמבל בארוקי! | |
|
|
|
|
|
||
|
||||
|
אף פעם לא מאוחר! | |
|
|
|
|
|
||
|
||||
|
זה המוטו שלי (כשאני מאחר להביא את הבת שלי לבית הספר). | |
|
|
|
|
|
||
|
||||
|
עולם ההיטק הוא עולם צעיר יחסית, ולכן העובד המבוגר הוא חריג בו. אך יש יותר מיסוד למחשבה שבעוד עשור-שניים, או אפילו לפני, יעבדו בהייטק גם אנשים מבוגרים, כבכל התעשיות האחרות. (כלום נראה לך שעשרות אלפי עובדים בגיל חמישים פשוט ישבו מובטלים בביתם?) אם כי לא באתי כלל לעמוד כנגד ההשתנות האוניברסלית (כפי שהיא מתוארת בכתבה), שהיא דבר כמעט טריוואלי, רק רציתי להאיר על נקודה שלא עמדו עליה. בהחלט, אדם שיודע כי תוחלת החיים היא שמונים שנים, אין לו מה למהר להנשא ולהביא ילדים ולקבע את חייו כבר בגיל 23 ... |
|
|
|
|
|
|
||
|
||||
|
"כלום נראה לך שעשרות אלפי עובדים בגיל חמישים פשוט ישבו מובטלים בביתם?" למה לא? כמה זה כבר יוצא באחוזים, ומה המצב היום? |
|
|
|
|
|
|
||
|
||||
|
עובדה היא שענף ההיי-טק היום כבר הרבה יותר מבוגר (בממוצע) ממה שהיה לפני עשר שנים, נניח. | |
|
|
|
|
|
||
|
||||
|
האם זאת אכן עובדה? | |
|
|
|
|
|
||
|
||||
|
אני סבור שכן. ראה למשל כאן: הנר: "במשבר הקודם, בשלהי 2000 תחילת 2001, הגיל הממוצע של עובדי ההייטק עמד על 20 פלוס. החבר'ה היו בדרך כלל צעירים כבני 26 וכשאדם צעיר כזה "נופל" וחוטף, הוא מהר מאוד קם על הרגליים. מקסימום 'חוזר לגור אצל אמא' כמה חודשים ואח"כ קם וחוזר לשוק. היום, הענף כולו התבגר והפרופיל הממוצע של העובדים בהייטק עומד על גילאי 35, עם משפחה משכנתא וילדים. מטבע הדברים, אנשים בגיל הזה כבר רוצים יותר ביטחון ויותר יציבות תעסוקתית". |
|
|
|
|
|
|
||
|
||||
|
עם כל הכבוד להנר, נראה לי שהוא משך את המספרים, במחילה, מעכוזו. לא לפני עשרים שנה, לא לפני עשר שנים ולא היום היה "הגיל הממוצע של עובדי הייטק עשרים פלוס" (אלא אם כן אתה מוכן לקבל גם "עשרים פלוס חמש עשרה" בתור "עשרים פלוס") ואם תשאל אותי מניין משכתי *אני* את המספרים, אז ממקום דומה (כלומר מעכוזי שלי) אבל ותיק יותר. נכון שאם האופק שלך ל"ענף ההייטק" זה הסטרטאפ שלך וזה של ידידך, שניכם מאותו המחזור בטכניון או ב־8200 קל מאד לקבל את הרושם הזה, אבל לא לפני עשרים ולא לפני עשר שנים לא היה הגיל הממוצע באלביט (ואלסינט ז"ל), גילת, לנט, סאייטק, רד-בינת, קומוורס (או בשמה הקודם "אפרת") ובחברות רבות נוספות שמילאו את נוף ההייטק - באף אחת מהחברות הללו לא היה הגיל הממוצע עשרים ושש (תזכורת קצרה: פרויקט הלביא התחיל לפני שלושים שנה וחוסל לפני יותר מעשרים - ותאמין לי שהיה שם הרבה מאד הייטק, ולא כל כך הרבה בני עשרים). למעשה, בישראל עשרים ושש זה הגיל האופייני לכניסה לענף (עתודאים וערבים הם עדיין מיעוט, אפילו בהייטק) - בוודאי לא הגיל הממוצע. יש פתגם עתיק שאומר: "אמור לי מי שכנך ואומר לך ליד מי אתה גר" - או בפרפרזה, "אמור לי מי שכנך ואומר לך איפה אתה גר". או כמו שאמר ראובן - כשהייתי בכתה ג' (ואפילו ב־ח'!) היו רוב חבריי רווקים. תתפוס פעם בן או בת חמשים שעוסקת בהייטק ודבר אתה על ענף ההייטק בארץ לפני עשרים שנה, ותופתע לשמוע שכהיא נכנסה לענף כבר היו שם הרבה אנשים ונשים, ורובם היו מבוגרים ממנה. |
|
|
|
|
|
|
||
|
||||
|
אין ספק שהגיל הממוצע לא היה עשרים ושש. מצד שני, למרות החברות הותיקות (וגם חברות בינלאומיות ותיקות, כמו IBM, אינטל ו-HP שפעילות כאן עוד מתחילת שנות השבעים) קשה להתעלם מהעובדה שהענף הזה שינה את פניו באופן דרמטי במחצית השניה של שנות התשעים. ההתרחבות היתה עצומה, ורובה הגדול התבטא בכניסה של צעירים לשוק (חלקם בהחלט צעיר מעשרים ושש). הגיל הממוצע צנח אז, גם אם בחברות הותיקות (שהתרחבו הרבה פחות) זה לא הורגש באותה מדה. בשנים שחלפו מאז התפוצצות הבועה בשנת 2000 הענף עבר (וממשיך לעבור) תהליך בריא של התבגרות - אני מנחש שבעשר השנים האלה הגיל החציוני של העובדים עלה במשהו כמו חמש שנים, נניח משלושים לשלושים וחמש. כמובן, הדיבור על "ענף ההיי טק" הוא מטעה. יש בענף תתי-ענפים ותתי-קבוצות בעלי מאפיינים שונים. בחומרה הגיל הממוצע גבוה מבתוכנה, יש הבדלים בין פיתוח, בדיקות איכות ובחומרה גם ייצור וכן הלאה. בעיני רוב האנשים הדימוי האופייני של הענף הוא של מתכנתים - ובתחום הזה התמורות שדיברתי עליהן היו, אולי, המובחנות ביותר. |
|
|
|
|
|
|
||
|
||||
|
אני לא מתיימר לייצג את הענף, אבל לפני 10 שנים כמעט כל עובדי הפיתוח שהכרתי (חומרה, תוכנה, בדיקות) היו מתחת לגיל 35 ולרובם לא היו ילדים. היום, בחברה שבה אני עובד לרוב המפתחים יש ילדים, הגיל הממוצע הוא בהחלט מעל 30 ויש לא מעט עובדים בשנות ה-40 של חייהם. | |
|
|
|
|
|
||
|
||||
|
השאלה האם אין כאן הטיה. כשהייתי בכיתה גימל, רוב חברי היו רווקים. | |
|
|
|
|
|
||
|
||||
|
אני מניח שגם לפני 10 שנים וגם היום, אני מכיר כמעט את כל אנשי הפיתוח שבקבוצה שלי, חברים ואלו שאני רק אומר להם בוקר טוב כשנפגשים במסדרון בבוקר. | |
|
|
|
|
|
||
|
||||
|
אני חושב שראובן מתכוון שחברות נוטות ל''התמחות'' בעובדים בשכבות גיל מובחנות, אפילו אם רק בגלל שיטת ''חבר מביא חבר'' או שיטות גיוס אחרות, אבל גם בגלל העדפות טכנולוגיות והבדלים בדרישות נסיון. לכן לא מדובר רק בבחירה-עצמית של האנשים מתוך החברה שלך, אלא בבחירה של החברה עצמה. | |
|
|
|
|
|
||
|
||||
|
גם בתעשיות אחרות קשה לבן 50 למצוא עבודה. מה, הרי יש לו רק 27 שנים עד הפנסיה, זה כלום. והמעסיק מעדיף למצוא צעירים שיעבדו בשבילו שנים רבות. לפחות שנתיים! |
|
|
|
|
|
|
||
|
||||
|
17 (אבל מי סופר?) | |
|
|
|
|
|
||
|
||||
|
נכון. אודה ואבוש. |
|
|
|
|
|
|
||
|
||||
|
אין מה לעשות ,השנים עושות את שלהן | |
|
|
|
|
|
||
|
||||
|
מן הצד השני, לא קל למצוא מהנדסים איכותיים לעבודה בלתי-זוהרת. מזה כמה חודשים של חיפוש, כל המועמדים שנמצאו מתאימים היו צעירים מתלהבים שהעדיפו בסופו של דבר איזה סטארט-אפ מגניב-לכאורה על פני ההצעה שלנו. | |
|
|
|
|
|
||
|
||||
|
שלמו יותר. | |
|
|
|
|
|
||
|
||||
|
כסף זה לא הכל בחיים. אם העולם ממילא שייך לצעירים אז מה כבר הם יכולים לעשות עם עוד קצת כסף? | |
|
|
|
|
|
||
|
||||
|
רעיון מדהים. איך לא חשבנו עליו לבד? ולענייננו: למרות המשבר הכלכלי העולמי, השוק הישראלי צמא למהנדסים מנוסים. היה זה רמז למובטלנו הטרי לשנס מותניים, לשפץ את קורות החיים, ללמוד שפת תכנות חדשה (אם צריך), ולצאת לראיין מעסיקים פוטנציאלים. |
|
|
|
|
|
|
||
|
||||
|
אבל מי שלומד שפת תיכנות הוא בהגדרה *לא* מהנדס מנוסה בתחום הספציפי. נכון? לעומת זאת, אם המעסיק מחפש ניסיון "כללי" וחושב ששפת תוכנה (או חומרה, לצורך זה) היא משנית, עדיף שהמעסיק יגדיר מה חסר למועמד וידאג שישלים מאשר שהמועמד ינסה לנחש מראש מה כל המעסיקים צריכים. גם האמירה "לצאת לראיין" היא מוזרה. אם לא מזמנים לראיון, לא תצא, נכון? לגבי אישית, אני מעדיף לא לעשות את הדיונים האלו בפומבי, ציינתי את מצבי האישי רק לצורך הקוריוז. |
|
|
|
|
|
|
||
|
||||
|
מתכנת מנוסה שיודע רק פורטרן עושה רושם פחות טוב מאחיו התאום ששלח פאץ' ראשון ברובי לפני שבועיים. מפתיע שלא מגיעות בקשות לראיון - מדוע אתה חושד שהסיבה היא שנת הלידה המתנוססת על קורות החיים? אולי קורות החיים לא מפורסמות במקומות הנכונים? סליחה על ההתקרצצות האישית והחדירה לתחום הפרט. חשתי הזדהות נוכח הקוריוז. |
|
|
|
|
|
|
||
|
||||
|
לא אמרתי שדווקא הגיל קשור לכך. במקרה הספציפי שלי אני מצד אחד מעט ייחודי בתפקידי (סוג של הנדסת מערכת+אלגוריתמים), ואקלקטי ברקע ההשכלתי שלי (פיסיקה תאורטית). כשאני בא לנסות למנף את הנסיון, מרחב הפאזה הוא קטן. כשאני בא למנף את ההשכלה שלי לתפקיד שאינו דורש ניסיון, אני כנראה באמת נחשב מבוגר (או אובר קווליפייד) מדי. מצד שני, אני "בחוץ" רק מספר שבועות, אז יכול להיות שיש זמן דגירה מסויים. |
|
|
|
|
|
|
||
|
||||
|
אני מציע שתפנה את המעסיקים לכאן - אותי זה היה משכנע. | |
|
|
|
|
|
||
|
||||
|
כן, אם אתה מחפש עובד פובליציסט פרי-לנסר. אולי אני צריך לזרוק הכל ולכתוב קומדיות מצבים (עוד חלום נעורים). |
|
|
|
|
|
|
||
|
||||
|
''קומדית מצבים'' זה הכינוי שאני תמיד נותן לאסל''ד. | |
|
|
|
|
|
||
|
||||
|
אלפי סיבובים לדקה? ארוחת סלט לא דיאטתית? אי ספיקת לב דיאסטולית? אירועי סינכרון לא דטרמניסטיים? |
|
|
|
|
|
|
||
|
||||
|
אוטומט סופי לא דטרמיניסטי [ויקיפדיה] | |
|
|
|
|
|
||
|
||||
|
הוא היה קרוב. לו נתת לו עוד צ'אנס הוא היה עולה על זה, שלא לדבר על כל הזמן הפנוי שיש לו עכשיו. | |
|
|
|
|
|
||
|
||||
|
לאחר הכשלון ניסיתי לעשות את מה שאתם, הצעירים, עושים וחיפשתי בגוגל, אבל לאחר שמצאתי, הראומטיזם מנע ממני לשלוח תגובת תיקון. | |
|
|
|
|
|
||
|
||||
|
אולי אפשר לחשוב על קו-פרודוקציה, כמו זאת של אילף איליה ויבגני פטרוב? | |
|
|
|
|
|
||
|
||||
|
אהבתי (לפני הרבה שנים) את הסרט של מל ברוקס אבל מעבר לזה אינני מכיר את הצמד. באופן כללי נראה לי שעבור כתיבת סיטקום צריך צוות כתיבה, אני מתלבט אם צריך מבנה מטריציוני- כל כותב יהיה ממונה על חלק אחר ( פאנצ'ים, יחסים בין אישיים, התפתחות עלילתית) או על בסיס ''מוצרים''- כל כותב יהיה אחראי על דמות מסויימת. |
|
|
|
|
|
|
||
|
||||
|
עכשיו, כשעיתותיך בידיך, תפוס לך עותק של ''שנים עשר הכסאות'' ואם הוא ימצא חן בעיניך תוכל לקרוא גם את ''עגל הזהב''. ההתחלה קצת מיגעת, גם בגלל השמות הרוסיים הבלתי אפשריים בעליל, אבל ככל שהספר מתקדם הוא משתבח. על כתיבה בצוות אין לי מושג או דיעה. |
|
|
|
|
|
|
||
|
||||
|
זה מה שאתה ממליץ לראובן? כחבר מערכת, אתה צריך להתבייש. לאור תגובה 541081 היית צריך לכתוב: "עכשיו, כשעיתותיך בידיך, שב ותכתוב לנו שני מאמרים". | |
|
|
|
|
|
||
|
||||
|
כחבר מערכת אני באמת מתבייש. כחבר מערכת וכקולגה אתה צריך להתבייש שכתבת בשמי "שב ותכתוב" ולא "שב וּכתוב". | |
|
|
|
|
|
||
|
||||
|
אתה כל כך איש הציווי הישן. תסתכל1 כאן: הציווי_החדש [ויקיפדיה] ________________ 1. ולא "הסתכל" |
|
|
|
|
|
|
||
|
||||
|
הסתכל? אולי דווקא "הסכל"? (וזה עוד בהודעה שמכוונת לשוטה). | |
|
|
|
|
|
||
|
||||
|
אם כבר רגיסטר נמוך אז ''סתכל''. | |
|
|
|
|
|
||
|
||||
|
אם במשלב גבוה עסקינן אזי אולי "שורו!"? | |
|
|
|
|
|
||
|
||||
|
''מבחינה לשונית-חברתית, ''הציווי החדש'' מסומן כשייך למשלב (רגיסטר) נמוך של השפה העברית'' ואני תמיד חיבבתי את הרגיסטרים הגבוהים יותר. | |
|
|
|
|
|
||
|
||||
|
כמוזיקאי, ובפרט כנגן בס, אני מעדיף את הרגיסטר הנמוך. (אתה צודק כמובן, ואני סתם מתחכם כבר שתי תגובות.) | |
|
|
|
|
|
||
|
||||
|
אני מציע שנפסיק כאן לפני שהמערכת תתעצבן עלינו. | |
|
|
|
|
|
||
|
||||
|
כָּל-הַבֵּן הַיִּלּוֹד, הַיְאֹרָה תַּשְׁלִיכֻהוּ, וְכָל-הַבַּת, תְּחַיּוּן. עתיד במקום ציווי איננו ב"רגיסטר" נמוך ובטח שאינו שגיאה, הוא מופיע אפילו בתנ"ך ומותר להשתמש בו בכל מקום שלא מתאימה לנו צורת הציווי המעומלנת. |
|
|
|
|
|
|
||
|
||||
|
פרעה? זאת האינסטנציה שלך לעברית תקינה? | |
|
|
|
|
|
||
|
||||
|
:-) | |
|
|
|
|
|
||
|
||||
|
אתה באמת חושב שהוא לא עבר עריכה לפני שנכנס לתנ"ך? | |
|
|
|
|
|
||
|
||||
|
"אז בתנ"ך יש את צורות הפועל שאנו מכירים בעבר ועתיד, אך הן למעשה מסמנות דברים שונים – אספקט מושלם (כן כן, זה הפרפקט משיעורי אנגלית) ואספקט המשכי (כן כן, זה כל השאר)." |
|
|
|
|
|
|
||
|
||||
|
או שהן מסמנות מודאליות (השארתי תגובה בדגש עם טיפה יותר פרטים), כלומר פעולה שמובעת לגביה מידה של אפשריות או של הכרחיות. | |
|
|
|
|
|
||
|
||||
|
מתוך ההקדמה ל"עגל הזהב": "...אחר כך התחלנו לענות ביתר קיצור... - איך אנחנו כותבים ביחד? פשוט כותבים ביחד. כמו האחים גוֹנקוּר. אֶדמוֹן מתרוצץ בין מערכות עתבי עת, וז'ול משגיח שאת כתב היד לא יגנבו מכּרים." |
|
|
|
|
|
|
||
|
||||
|
אגב, חשבת אולי לשלב בין שאיפה זו לבין יכולותיך בתחום האלגוריתמיקה והתכנות ולכתוב מחולל קומדיות מצבים? | |
|
|
|
|
|
||
|
||||
|
מעסיקים מסוימים נותנים משקל מוגזם בראיונות עבודה לידע בשפת תכנות ספציפית. מהנדס מנוסה באמת מסוגל לסכם את העיקרים של כמעט כל שפת תכנות במספר משפטים קצרים וממצים. יש לך נסיון במספר שפות תכנות שונות יש לך נסיון מסוים בכולן. את הדקויות של השפה הוא יכול ללמוד תוך שבוע שבועיים לאחר שתקבל אותו לעבודה. | |
|
|
|
|
|
||
|
||||
|
לא הייתי מקבל לעבודה מישהו שמאמין שהוא יכול ללמוד דקויות של שפה תוך שבוע. קרוב לוודאי שהוא לא ממש מבין על מה הוא מדבר. | |
|
|
|
|
|
||
|
||||
|
אני לא מדבר על הכרת השפה על בוריה. את זה אין למפתחים אחרי חמש שנות נסיון (אך יש יותר למהנדסים מנוסים שמכירים מספר שפות תכנות אחרות). כמה זמן אתה מעריך שצריך מהנדס ג'אווה עם נסיון רב להגיע לרמת פיתוח ב #C כולל הבנה מסוימת של דקויות השפה בתחום בו הוא מתמכה? נניח שהתפנתה משרה למפתח בטכנולוגיות מיקרוסופט בחברתך. אם יש לך כמעסיק אופציה לבחור ילד שהתמקצע ב - #C עם שלוש שנים נסיון רק בשפה זו או מהנדס עם נסיון של יותר מעשר שנים בג'אווה ובעוד שפות תכנות שונות ומשונות האם לא היית מעדיף את השני? למה? |
|
|
|
|
|
|
||
|
||||
|
ג'אווה ו־C# הן שפות דומות למדי (סביבות העבודה יכולות להיות שונות לחלוטין). אני לא מכיר אותה טוב במיוחד, אבל מהמעט שראיתי, מי שיודע לחשוב בג'אווה, ידע בד"כ גם לחשוב ב־C#. המעבר בין שפות אחרות יכול להיות קצת פחות חלק. מהבחינה הזו יש יתרון למי שמכיר כמה שפות שונות. אבל שפה אינה הדבר היחיד. יש תחומי התמחות אחרים. אני הייתי יכול להעדיף אולי מישהו שמכיר את התחום הכללי (לדוגמה: פרוטוקולי רשת) היטב גם אם הוא לא מכיר בדיוק את השפה שבה אנו עובדים. (ומי שידע לכתוב כאן C++ ידע גם לכתוב C#. כל מה שצריך הוא LRM). |
|
|
|
|
|
|
||
|
||||
|
זו בדיוק היתה הנקודה שלי. בהנחה שלמועמד היכרות נרחבת עם שפות תכנות שונות, תחומי ההתמחות זה בדרך כלל חשוב ורלבנטי יותר מאשר הכרות עם שפת תכנות ספציפית. | |
|
|
|
|
|
||
|
||||
|
בתנאים שסיפקת, הייתי מעדיף את ההיא עם הציצים הגדולים. (במילים אחרות: מעבר לרף מסוים, יש עוד הרבה שיקולים מעבר לשנות הניסיון בשפת תכנות). |
|
|
|
|
|
|
||
|
||||
|
הבמילים אחרות הוא אמירה טריביאלית. השטן הוא בניואנסים. הטענה היא שמעבר לרף מסוים, יש להוסיף גם את הניסיון בשפת תכנות ספציפית למערכת השיקולים ולא להיפך. מעבר לרף מסוים של ניסיון, המעבר בין שפות תכנות הופך להיות קל וחלק יותר (גם אם נניח שהוא לא טריביאלי, למרות שברובו הוא דווקא כן טריביאלי). לשים את ההכרות עם שפת תכנות במרכז ראיון העבודה, במקום את ההבנה בהנדסת תוכנה, את הניסיון הכללי בפיתוח, את תחומי ההתמחות, את ההבנה האלגוריתמית ואת יכולות התקשורת המקצועית של המועמד, זה פשוט להתרכז בשטויות. מפתח טוב עם הכרות מעמיקה ונסיון רב הן במספר שפות סטאטיות והן במספר שפות דינאמיות, מסוגל לקפוץ אל תוך המים העמוקים של כמעט כל שפה עילית נפוצה בשוק, לאחר שפשוף קל. אי אפשר להגיד את אותו הדבר על תחומי התמחות. |
|
|
|
|
|
|
||
|
||||
|
האמנם תחומי התמחות הם קשים יותר ללמידה? אתה יכול לתת דוגמה או שתיים? אני מניח שנשארים בתוך התחום הכללי של תוכנה, ולא קופצים לפיזיקה או תכנון מעבדים; משהו שמקביל לקורס באקדמיה ולא לתואר. עיבוד מקבילי הוא אולי דוגמה, אבל זה בגלל שלא מדובר רק בתחום ידע אלא בצורת חשיבה שונה. אם אני חושב על פרוטוקולי תקשורת, או אפליקציות אינטרנט, או GUI - אז נדמה לי שמהנדס טוב יכול ללמוד אותם בערך באותה קלות או קושי של לימוד שפה חדשה. אגב, בשני הראשונים נגעתי רק לרגעים קצרים ומרחוק, בשלישי יותר אבל רק בזווית צרה. |
|
|
|
|
|
|
||
|
||||
|
אני לא יודע אם "תחומי התמחות הם קשים יותר ללמידה". אני יודע שיש מהנדסים שמתאימים יותר לצורת חשיבה הנחוצה בתחום מסוים. >>> עיבוד מקבילי הוא אולי דוגמה, אבל זה בגלל שלא מדובר רק בתחום ידע אלא בצורת חשיבה שונה. גם "עיבוד אותות" זו צורת חשיבה שונה, ו־device drivers זו צורת חשיבה שונה, ו־embedded systems זה משהו אחר לגמרי. הכרתי מהנדסים שידעו לבנות gui באופן שעורר את קנאתי - יותר יפה ובעיקר יותר פונקציונלי ממה שיכולתי לחלום, וברבע הזמן שהיה לוקח לי. לעומת זאת עם הקוד שהם כתבו בלב המערכת לא היה מה לעשות חוץ מאשר לעטוף בשטר של עשר לירות ולזרוק למקום בו השמש לעולם לא זורחת. אולי אפשר להשוות זאת להבדל בין מהנדס בניין ומעצב פנים, רק שבענף שלנו קוראים לשניהם "מהנדס תכנה" ובמקרים רבים הם משתמשים באותה שפת תכנות. לעומת זאת אין שום קשר בין זה ובין שפה. מעולם לא ראיתי מישהו שעשה עבודה טובה בשפה אחת וגרועה באחרת. מי שהתוצרת שלו גרמה לי סחרחורת ובחילה, זה עבד בשלוש שפות באותה מידה; ומי שהרשים אותי בבהירות, פשטות ואלגנטיות של התוצרת זה נשאר משפת אסמבלי דרך ג'אווה ועד פייתון. |
|
|
|
|
|
|
||
|
||||
|
הגיוני. | |
|
|
|
|
|
||
|
||||
|
בעניין "מעולם לא ראיתי מישהו שעשה עבודה טובה בשפה אחת וגרועה באחרת" - זה נכון בד"כ, אבל הנה דוגמא הפוכה: גייסתי פעם עובד ששלט היטב בפייתון והיה מהיר כברק בשפה זו. הוא גם פתר בע"פ חידות מתמטיות/אלגוריתמיות מהר יותר מכל מרואיין שהיה לי. מסיבות אלו ואחרות גייסתי אותו כאיש אלגוריתמים למימוש אזורי קוד תובעניים (מבחינת ביצועים) בשפת ++C. לאחר חודשיים של עבודה הסתכמו הישגיו בקרוב לאפס. לבקשתי מן הממונה עליו לרדת לפשר העניין, התברר שהבחור סובל מהפרעת קשב. הוא הסביר שיש לו משהו כמו עשר דקות (לפעמים קצת יותר) בהן הוא חד ומהיר, מה שמספיק למשימות קטנות ואפילו ביינוניות בפייתון, כמו גם לפתרון חידות אלגוריתמיות מן הסוג שנתתי לו. לאחר מכן, הוא זקוק ללפחות שעה של "התרעננות". מאחר וב++C המשימות הן בד"כ חלק מפרוייקט גדול, די בניסיון להכנס למשימה, תוך בהבנת מקומה הנכון בפרוייקט והבנה/היזכרות באופן בו צריך לבצעה, כדי לעבור את זמן הקשב שלו. "מדוע אין הוא לוקח ריטלין" שאלתי את המנהל? התשובה שבאה הוא שהבחור בדק באינטרנט וחושש שהריטלין מרעיל אותו אז הוא מנסה בלעדיו. "תגיד לו שהניסיון נכשל והטענות נגד הריטלין הן אמונות טפלות שמופצות ע"י כת של עובדי אלילים, ואם הוא רוצה להמשיך לעבוד כאן כדאי לו שיחזור לקחת" (או מה שסביר יותר - גירסה עדינה של זה). ואכן כעבור כמה זמן היה שיפור מסויים (אם כי לא מספיק). |
|
|
|
|
|
|
||
|
||||
|
הו הא. שעה התרעננות אחרי עשר דקות עבודה? זה לא מתכנת פייתון. זה עובד הסתדרות! דוגמה יפה, אבל אתה רק מחזק את טענותיו של הוגג. הרי מה הקשר בין פייתון לבין הקשיים של המתכנת הנ"ל? הנ"ל יהיה מפתח גרוע גם במימוש פרויקטים מסוימים בשפה זו. במקום העבודה הקודם שלי, בו הרוב המוחלט של המערכות נכתב בפייתון, המתכנת הנ"ל לא היה מוצא לא את ידיו ולא את רגליו. פייתון היא שפה של ממש ולא סתם שפה לכתיבת סקריפטים קצרים או משהו שרק ניתן להדגים איתו שעשועים ופתרון חידות אלגוריתמיות קצרות. ניתן לממש בה אפליקציות שלמות, תשתיות ו/או פרוייקטים מאוד מורכבים. |
|
|
|
|
|
|
||
|
||||
|
אני מניח שאתה צודק. להלן המשך אותו המקרה: לאחר שהחלטתי לפטרו, עיכב הבוס שלי את מימוש ההחלטה, לפחות עד שנמצא מישהו במקומו. בינתיים העברתי את הבחור למחלקת המחקר שקירטעה מאז המתכנת היחיד בה (אני) קודם. הרעיונות שהבחור הגה שם והמימושים להם הקפיצו אותה שנות אור קדימה1. אנקדוטה הקשורה בבחור: לאחר שלב הראיונות, כשהתקשרתי לממליצים, טען אחד מהם שהנזקים שהבחור עשה אצלם נוראים עד כדי כך שהוא אפילו לא יכול לספר לי. 1 פיסיקה הוא לא ידע (: |
|
|
|
|
|
|
||
|
||||
|
סיפור מעניין ומאלף. שאלה מעניינת (כלומר מעניינת אותי) היא האם לדעתך ההבדל בין הביצועים המרשימים של מהנדס זה במשימה אחת מול ביצועים עלובים במשימה אחרת קשורים יותר לשפה\סביבה, או לטיב המשימות עצמן? גם אני הזכרתי מהנדסים (למשל החתום מעלה) עלובים ב-gui וטובים בדברים אחרים וההפך - אבל במקרה זה מעבר שפה לא שינה לא את הטוב ולא את הרע. |
|
|
|
|
|
|
||
|
||||
|
אני חושב שהצלחתו של הנ"ל בפייתון נבעה מכך שבשפה זו ישנו יחס גבוה מאוד של תפוקה ביחס להשקעה, גם בזמני עבודה קצרים, המתאימים לאורך הקשב שלו. משום כך לדעתי הוא גם התמחה בשפה זו, ולא למשל בג'אווה או ++C בהן הדבר בד"כ אינו ניתן, אך הן כן טובות יותר לפרוייקטים גדולים (מסויימים) וכמובן, מבחינת ביצועים (מהירות, צריכת זיכרון). התשובה משום כך היא שהסיבה הראשונית היא כאן טיב המשימות, ולא השפה. | |
|
|
|
|
|
||
|
||||
|
אני מכיר כמה פרויקטים (ואפילו מוצלחים) בפייתון, אולי לא "גדולים" אבל משהו כמו 50KLOC (שכנראה שקול לפחות ל 150KLOC, ויש אומרים 300, בג'אווה). מאד יתכן שאותו מהנדס היה נכשל גם שם. מצד שני יש סוג משימות מהאופי של "פגע וברח" גם בפרויקטים גדולים וסבוכים ב ++C ("תמצא איפה הבעיה ותגרום לנביילה הזו לרוץ פי שלוש יותר מהר") - שבהחלט יכולות להתאים למהנדסים מסוימים שלא מסוגלים לתכנן ולהריץ פרויקט שלם, אפילו קטן. |
|
|
|
|
|
|
||
|
||||
|
אלו בדיוק הבעיות המצומצמות אותן הוא קיבל. אבל כאן נכנס גורם נוסף, לדעתי הספקולטיבית מאוד: אצל חלק מבעלי בעיות הריכוז הן מחמירות באופן קיצוני כאשר הם עוסקים בדבר (שפה במקרה זה) שאינו מלהיב אותם, גם אם הם מאוד היו רוצים לסיים את המשימה. | |
|
|
|
|
|
||
|
||||
|
ג'אווה? מילא מהירות, אבל טובה בצריכת זיכרון!? | |
|
|
|
|
|
||
|
||||
|
מה שהיה לי בראש כשכתבתי זאת היא השפה בה אני עובד בשבועיים האחרונים (VBA) ופייתון. לא בדקתי אז אני חוזר בי מן הטענה שבג'אווה ניצול הזיכרון טוב יותר מאצלן. | |
|
|
|
|
|
||
|
||||
|
ג'אווה אכן טובה בצריכת זיכרון. לא סתם טובה, ג'אווה מתמכה בצריכת זיכרון! צריכת (עוד ועוד) זיכרון זה אחד מהפיצ'רים המרכזיים ביותר של השפה. | |
|
|
|
|
|
||
|
||||
|
תסריט בו העובד הזה היה מגיע אל מעסיק שלא היה מצליח להבין מהן נקודות החוזק והחולשה שלו הוא תסריט סביר. היו מתאכזבים ממנו שוב ושוב ומפטרים אותו. בקלות היו יכולים לקטלגו כמהנדס תוכנה כושל שאת התוצרת שלו אפשר רק לעטוף בעשר לירות ולזרוק לפח. מזל שהוא הגיע אליך. בין השאר, הסיפור הזה מלמד אותנו את החשיבות והמרכזיות שיש להחלטות ההנהלה בהצלחתו או כשלונו של העובד (ושל פרוייקטי תוכנה באופן כללי). אם היה לי שקל על כל פעם שראיתי קוד גרוע שנכתב בגלל מנהלים גרועים ע''י מהנדסים מוכשרים (שמוצאים את עצמם כותבים ובוכים) הייתי יכול לעשות אקזיט. |
|
|
|
|
|
|
||
|
||||
|
איך מסתדרים עם הפרעות קשב וריכוז במקום העבודה? | |
|
|
|
|
|
||
|
||||
|
באופן מוזר יצא לי לראות כמה פעמים קוד של מהנדסים (ולפעמים גם צוותים שלמים) שעברו משפה "נמוכה" לשפה "גבוהה" (ז"א מ-c ל-c++ ומ-C++ לג'אווה - הכרתי גם צוות שעבר כולו מדלפי לג'ווה אבל בגלל שאני לא מכיר דלפי אז אני לא יכול לדעת אם זאת הסיבה שהקוד שלהם היה כל כך מוזר), ובהחלט אפשר להבחין בזה. יש דברים שמהנדס ששולט בשפה מסויימת לא יעשה (לא שהם בהכרח לא נכונים או לא עובדים, נגיד להגדיר את כל המשתנים בתחילת הפונקציה ולא בסקופ שלה, אבל הקוד שנוצר הוא פחות קל לתחזוקה) ויש דברים שמי שלא מכיר את השפה מספיק טוב יפחד לעשות (למשל exception בג'אווה, וכמובן שאפשר לעקוף את זה על ידי החזרת ערך, אבל...) בלי צידוק מספק. שינוי ההרגלים הזה לוקח זמן, ועולה כסף, וכשמדובר על צוות שלם אז הרבה פעמים ההרגלים האלה גם לא משתנים (זה גם תלוי באופי של הצוות) אחרי שנים. | |
|
|
|
|
|
||
|
||||
|
מהניסיון האישי שלי ובהכללה גסה: אנשים עם ניסיון המתרכז בשפות "גבוהות" או אפילו חסרי ניסיון לחלוטין, מסתגלים מהר יותר לכתוב קוד נכון יותר ב - python מאשר מפתחים עם ניסיון מסוים או רב שנים ב - ++C. לא פשוט לדרוש ממפתחים שרגילים לכתוב בצורה מסוימת לכתוב כמו כל שאר החבר'ה על פי המלצות PEP 8. היה אפילו אחד שהתעקש, כמו פרד, להוסיף נקודה פסיק בסופי שורות פקודה, כאילו הסימן הזה מחובר אצלו במקלדת למקש ה - enter. |
|
|
|
|
|
|
||
|
||||
|
תלוי מה אני מחפש. אם אני רוצה קבוצה קטנה של אנשים שיפתחו פרוייקט נסיוני, אני מעדיף את המעולה והמגוון. אם יש לי מחסור באנשי #C אני אעדיף את זה שיוכל לפחות לסייע או לייעץ לשאר המפתחים. | |
|
|
|
|
|
||
|
||||
|
זה כמו לחפש חקלאי ''עם ניסיון בג'ון דיר''. אתה כמובן יכול לעשות זאת (ורבים אכן נוהגים כך) אבל זו לא הבחירה האינטליגנטית. | |
|
|
|
|
|
||
|
||||
|
בהרבה מקרים זה יותרכמו חקלאי עם נסיון בגידול פירות. שפה זה לא רק תחביר, זה גםאוסף שלם של כלים ומתודולוגיה. | |
|
|
|
|
|
||
|
||||
|
גם ג'ון דיר. | |
|
|
|
|
|
||
|
||||
|
תראה, ברור שמפתח טוב יכול ללמוד כל דבר, אבל הוא לא יכול לעשות את זה באפס עלות. להגיע למקצועיות בסביבת עבודה חדשה יכול לקחת בין חצי שנה לשנה (ברור שמפתח טוב יותר עושה את זה מהר יותר). חצי שנה עד שנה כזו של פרודוקטיביות שווה הרבה למעסיק. בנוסף, אם חסר ידע ספציפי בקבוצת פיתוח שלמה, אז למפתח חדש שכבר יש לו הידע הזה יש גם אפקט של מכפיל כוח בגלל כל העזרה, העצה וההדרכה שהוא יכול לתת למפתחים האחרים (שאולי לא פחות מוכשרים ממנו אבל לא מכירים את הטכנולוגיה הספציפית). | |
|
|
|
|
|
||
|
||||
|
אני מסכים עם כל מלה שכתבת, רק שאני לא חושב שלמרכיב ה"שפה" במכלול הידע יש משקל משמעותי. ברגע שאתה מדבר על "טכנולוגיה מסוימת" אז גם אני כבר אמרתי כאן דברים דומים למה שאתה אומר. נכון ש"שפה" זה גם ספריות, אבל אני בכל זאת לא חושב שנכון לייחס להם משקל. לגבי "חצי שנה": כשמפתחים מתחילים לעבוד בסביבה חדשה, הם צריכים לבנות היכרות עם הצוות הקיים, עם ה"תרבות" (סליחה על המלה), עם גוף התכנה הקיים, עם נוהלי העבודה, אולי גם המוצרים או הפרוייקטים השונים ויחסי הגומלין ביניהם וכולי. לא ראיתי קורלציה בין הזמן שלוקח למפתחת חדשה להתחיל להיות פרודוקטיבית ובין השאלה אם השפה (או השפות) בהן משתמש הפרוייקט היו מוכרות לה מראש. כמובן שיש זריזים יותר ויש איטיים יותר - אך אם מרכיב השפה בכלל בא לידי ביטוי אז מדובר בגורם מסדר שני או שלישי. כמובן, כדי שבכלל תוכל לגבש דעה מושכלת בשאלה אתה צריך להתחיל להיות מוכן לשכור אנשים ולהתעלם מהשאלה אם הם כבר מכירים את השפה. מאחר שכנראה אינך מוכן לעשות זאת, לעולם לא תיווכח בצדקתי... ;) |
|
|
|
|
|
|
||
|
||||
|
כל מה שאתם כותבים זה מעניין מאוד, אבל בפועל, אם תכתבו בגוגל ''דרושים תוכנה'' תקבלו פירוט על פי ידע בשפות. | |
|
|
|
|
|
||
|
||||
|
לא אמרתי שהשאלה אם לאנשים יש נסיון בשפה1 תמיד חשובה. אמרתי שהשאלה תלויה בסט היכולות שכבר יש לך בצוות ובמטרות של הצוות הזה. היה לי הרבה נסיון מוצלח של לעבוד עם הרבה אנשים שהגיעו בלי נסיון בשפה הרלבנטית (למעשה, כל אחת מהמשרות שאני-עצמי התקבלתי אליהן היתה בשפה שלא היה לי נסיון משמעותי בה). אבל בתנאים שונים, הדרישות שונות. שפה היום זה לא כמו שהיה בשנות השמונים. שפה (ביחוד השפות החדשות, כמו Perl, Python, ובצורה בולטת Java ו#C) באה עם הרבה מאוד הנחות, הרגלים קבוצתיים, תבניות עיצוב, העדפות, כללי עשה ואל תעשה, קונבנציות, וזה עוד לפני שדיברנו על קוד ממש, מסגרות, כלים, סטנדרטים ופרוטוקולים לעבודה שנאספו סביבה. בהרבה מקרים אתה יכול להגיד שחלק גדול מההיכרות שפירטת עם תרבות, גוף תוכנה, נוהלי עבודה, ואפילו יחסי הגומלין בין פרוייקטים ומוצרים עברו סטנדרטיזציה במסגרת של "שפות", עד־כדי־כך שמתכנת שעובר מחברה אחת לחברה אחרת באותה שפה יכול להרגיש די בבית. לוקח הרבה זמן ללמוד את זה. 1 למרות שאתה כתבת "מכירים את השפה". |
|
|
|
|
|
|
||
|
||||
|
קודם כל מוזר לראות התייחסות ל "Perl, Python, ובצורה בולטת Java ו#C" בתור "שפות חדשות". נדמה לי שהגיל הממוצע הוא בערך 20, לא? (אכן #C באמת קצת יותר צעירה1). בכל אופן אחרי שכתבתי תגובה ארוכה ומלומדת גם קראתי אותה, וראיתי שלא אתה ולא אני לא נצא מהמשך הדיון הזה יותר חכמים, נבונים ויודעים את התורה מאשר אנחנו עכשיו אז החלטתי להיכנע. ושאלה לראובן: היכרות עם איזו שפה או סביבה עומדת כרגע למחסום בדרך למשרות שנראות מעניינות? יכול להיות שיש טריק שעוזר לשבור את פרדוקס הביצה והתרנגולת (מעסיקים דורשים נסיון מוכח בשפה, אבל ללא עזרת מעסיק לא ניתן לייצר ניסיון מוכח). ה"טריק" הוא לתרום לפרויקט קוד פתוח שמתנהל בשפה\סביבה המבוקשות. נכון שיתכן שהניסיון המוכח החסר הוא בשפה\סביבה שלא ניתן למצוא בהן פרויקט קוד פתוח (אני למשל מאד אופתע אם יש פרויקט קוד פתוח ש DB2 מהווה בו קומפוננטה מרכזית), אבל יתכן שהשורות החסרות ברזומה הן דווקא כאלו שקל מאד למצוא פרויקטים שמתרכזים בהם - למשל php, RoR, פייתון ועוד. _____________ 1 בפועל, #C זה שיבוט של ג'אווה שלא טורח להשמע לכללים של סאן בגלל איזו תביעה משפטית בעבר הרחוק או משהו. |
|
|
|
|
|
|
||
|
||||
|
מצאתם כפתור, תפרתם חליפה ועכשיו אתם שואלים אותי איזה שרוול קצר לי? איפה ראית שאמרתי שמה שחסר לי זה ידיעת שפת תיכנות כלשהי? אם יש שפה שידיעתה עשויה היתה לעזור לי אני מניח שזאת סינית (כמו לכל ההי-טק הישראלי). | |
|
|
|
|
|
||
|
||||
|
>> מצאתם כפתור, תפרתם חליפה ועכשיו אתם שואלים אותי איזה שרוול קצר לי? איפה ראית שאמרתי שמה שחסר לי זה ידיעת שפת תיכנות כלשהי? אם יש שפה שידיעתה עשויה היתה לעזור לי אני מניח שזאת סינית (כמו לכל ההי-טק הישראלי). קודם כל אתה צודק - השאלה שלי לא נוסחה טוב. מה שהתכוונתי היה בתגובה למשהו שכתבת כאן: >> כל מה שאתם כותבים זה מעניין מאוד, אבל בפועל, אם תכתבו בגוגל "דרושים תוכנה" תקבלו פירוט על פי ידע בשפות הבנתי מכאן שהכוונה שמעסיקים אכן מחפשים כשרון מסווג לפי קריטריון ה"שפה", וכן שעובדה זו מהווה לפעמים מכשול בפני מהנדס מוכשר שמסיבות אלו ואחרות אין התאמה טובה בין ה"ניסיון המוכח" שהוא יכול להדגים ובין מה שהשוק מחפש ברגע מסוים (במקרה זה, כרגע). השאלה ששאלתי אותך הייתה שאלה של סקרנות - עבר כבר זמן מאז בדקתי את שוק חיפוש העבודה והתעניינתי לדעת אילו כישורים נחשבים "חמים" היום. ההערה האחרונה שלי, לגבי האפשרות לצבור "ניסיון מוכח" דרך פרויקט קוד פתוח וכך לעקוף את בעיית הביצה והתרנגולת לא כוונה דווקא אליך - הכוונה הייתה לאמירה כללית שמעלה דרך התמודדות אפשרית (תאורטית - כאמור לא ניסיתי) למישהו שנמצא במצב הזה. |
|
|
|
|
|
|
||
|
||||
|
מנסיוני הדל, את המעסיקים לא מעניין הנסיון עם פרוייקטי קוד פתוח. בדיוק דחו אותי ממשרת ג'אווה בגלל שאין לי נסיון מוכח בג'אווה, למרות שיש כמה פרוייקטים משמעותיים של ג'אווה שתרמתי להם קוד. | |
|
|
|
|
|
||
|
||||
|
למה הם מתכוונים בנסיון מוכח? | |
|
|
|
|
|
||
|
||||
|
יענו שקיבלת עליו כסף. אף מעסיק לא שאל אותי על עברי בקוד הפתוח, למרות שהוא מוזכר אחר כבוד בפסקה שלמה בקורות החיים שלי. | |
|
|
|
|
|
||
|
||||
|
כאן לפחות יש דרישה מפורשת לתרומה לקוד פתוח: "Active contributor to open source software" (אבל עדיין נדרש ניסיון בעבודה). | |
|
|
|
|
|
||
|
||||
|
נו באמת, לקחת את יאהו!, זה לא באמת דוגמא למעסיק טיפוסי. ברור לי שיש כאלה שמחפשים את זה (למשל lingnu.com), אבל מנסיוני את הרוב זה לא מעניין. כולל מעסיקים שלינוקס עומדת בבסיס המוצר שהם מפתחים (למעשה כמעט כל החברות שפניתי אליהם מבוססים באופן כזה או אחר על קוד פתוח). יכול להיות שהנסיון שלי מוטה (באמת יכול להיות), ונפלתי במקרה על חברות שלא מעניין אותן והרוב כן, אבל בכל זאת לפי נסיוני האנקדוטלי, את החברות בארץ לא מעניין אם עשית קוד פתוח או לא (קרי, לא שואלים אותך על הנושא, על אף שזה מופיע בקורות החיים, ועל אף שהזכרתי את זה בריאיון. לדוג' אני מספר על העבודה הקודמת "עשיתי X..." "ומה עוד? עם מה?", "עשיתי קוד פתוח Y" <שתיקה>. ואני לא מדבר על חברות ההשמה שבכלל לא מבינות על מה אתה שח. |
|
|
|
|
|
|
||
|
||||
|
רק ניסיתי לעזור... | |
|
|
|
|
|
||
|
||||
|
סליחה, אני ניסיתי להמשיך בויכוח... בכל אופן, העבודה שלינקקת אליה נראת מגניבה למדי, ותודה. |
|
|
|
|
|
|
||
|
||||
|
ההערכה שלי שהדוגמה שלך לא מייצגת במיוחד. נסיון בתכנות תוכנה חופשית הוא נסיון בתכנות. ההבדל העיקרי הוא שלא צריך לסמוך על המלצות כדי לבדוק את איכות העבודה. |
|
|
|
|
|
|
||
|
||||
|
אגב, ראיינתי פעם מועמד לתפקיד מפתח תוכנה/אלגוריתמאי שבמקום המלצות שלח לי קישורים לקוד פתוח שכתב. במקרה הספציפי ההוא הקוד לא היה ברמה סבירה וגם לא הצביע על פוטנציאל. | |
|
|
|
|
|
||
|
||||
|
מעניין. אני מניח שהוא מעריך את הקוד שהוא כתב קצת יותר ממך (לפחות ברמת הפוטנציאל), אחרת הוא לא היה משתמש בו ככרטיס ביקור. מדובר על פרויקט שלו בלבד / בעיקר או משהו שעבר מספיק ביקורת עמיתים? קוד שנמצא בשימוש במקומות אחרים? | |
|
|
| חזרה לעמוד הראשי |  |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |