בתשובה להוגג, 12/11/10 21:01
 |
|
 |
||
|
||||
 |
בהרבה מקרים זה יותרכמו חקלאי עם נסיון בגידול פירות. שפה זה לא רק תחביר, זה גםאוסף שלם של כלים ומתודולוגיה. |  |
 |
 |
|
|
|
||
|
||||
|
גם ג'ון דיר. | |
|
|
|
|
|
||
|
||||
|
תראה, ברור שמפתח טוב יכול ללמוד כל דבר, אבל הוא לא יכול לעשות את זה באפס עלות. להגיע למקצועיות בסביבת עבודה חדשה יכול לקחת בין חצי שנה לשנה (ברור שמפתח טוב יותר עושה את זה מהר יותר). חצי שנה עד שנה כזו של פרודוקטיביות שווה הרבה למעסיק. בנוסף, אם חסר ידע ספציפי בקבוצת פיתוח שלמה, אז למפתח חדש שכבר יש לו הידע הזה יש גם אפקט של מכפיל כוח בגלל כל העזרה, העצה וההדרכה שהוא יכול לתת למפתחים האחרים (שאולי לא פחות מוכשרים ממנו אבל לא מכירים את הטכנולוגיה הספציפית). | |
|
|
|
|
|
||
|
||||
|
אני מסכים עם כל מלה שכתבת, רק שאני לא חושב שלמרכיב ה"שפה" במכלול הידע יש משקל משמעותי. ברגע שאתה מדבר על "טכנולוגיה מסוימת" אז גם אני כבר אמרתי כאן דברים דומים למה שאתה אומר. נכון ש"שפה" זה גם ספריות, אבל אני בכל זאת לא חושב שנכון לייחס להם משקל. לגבי "חצי שנה": כשמפתחים מתחילים לעבוד בסביבה חדשה, הם צריכים לבנות היכרות עם הצוות הקיים, עם ה"תרבות" (סליחה על המלה), עם גוף התכנה הקיים, עם נוהלי העבודה, אולי גם המוצרים או הפרוייקטים השונים ויחסי הגומלין ביניהם וכולי. לא ראיתי קורלציה בין הזמן שלוקח למפתחת חדשה להתחיל להיות פרודוקטיבית ובין השאלה אם השפה (או השפות) בהן משתמש הפרוייקט היו מוכרות לה מראש. כמובן שיש זריזים יותר ויש איטיים יותר - אך אם מרכיב השפה בכלל בא לידי ביטוי אז מדובר בגורם מסדר שני או שלישי. כמובן, כדי שבכלל תוכל לגבש דעה מושכלת בשאלה אתה צריך להתחיל להיות מוכן לשכור אנשים ולהתעלם מהשאלה אם הם כבר מכירים את השפה. מאחר שכנראה אינך מוכן לעשות זאת, לעולם לא תיווכח בצדקתי... ;) |
|
|
|
|
|
|
||
|
||||
|
כל מה שאתם כותבים זה מעניין מאוד, אבל בפועל, אם תכתבו בגוגל ''דרושים תוכנה'' תקבלו פירוט על פי ידע בשפות. | |
|
|
|
|
|
||
|
||||
|
לא אמרתי שהשאלה אם לאנשים יש נסיון בשפה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" <שתיקה>. ואני לא מדבר על חברות ההשמה שבכלל לא מבינות על מה אתה שח. |
|
|
|
|
|
|
||
|
||||
|
רק ניסיתי לעזור... | |
|
|
|
|
|
||
|
||||
|
סליחה, אני ניסיתי להמשיך בויכוח... בכל אופן, העבודה שלינקקת אליה נראת מגניבה למדי, ותודה. |
|
|
|
|
|
|
||
|
||||
|
ההערכה שלי שהדוגמה שלך לא מייצגת במיוחד. נסיון בתכנות תוכנה חופשית הוא נסיון בתכנות. ההבדל העיקרי הוא שלא צריך לסמוך על המלצות כדי לבדוק את איכות העבודה. |
|
|
|
|
|
|
||
|
||||
|
אגב, ראיינתי פעם מועמד לתפקיד מפתח תוכנה/אלגוריתמאי שבמקום המלצות שלח לי קישורים לקוד פתוח שכתב. במקרה הספציפי ההוא הקוד לא היה ברמה סבירה וגם לא הצביע על פוטנציאל. | |
|
|
|
|
|
||
|
||||
|
מעניין. אני מניח שהוא מעריך את הקוד שהוא כתב קצת יותר ממך (לפחות ברמת הפוטנציאל), אחרת הוא לא היה משתמש בו ככרטיס ביקור. מדובר על פרויקט שלו בלבד / בעיקר או משהו שעבר מספיק ביקורת עמיתים? קוד שנמצא בשימוש במקומות אחרים? | |
|
|
|
|
|
||
|
||||
|
השאלות במקום, אלא שאני לא זוכר פרטים מעבר לזה. | |
|
|
|
|
|
||
|
||||
|
אני חושב שיש כאן עניין של סטנדרט. כשמישהו אומר לך שהוא עבד שנתיים וחצי על X בחברה שאפשר להסכים שהיא סבירה, אז אתה יודע בדיוק מה זה אומר: בערך כמה שעות ביום הוא עבד, שהוא היה כנראה צריך לעבוד עם מנהלים ועמיתים, לתאם דברים עם אנשי בקרת־איכות ומנהלי־מוצר, שהוא עבד עם מערכת ניהול באגים ומערכת ניהול גרסאות, שהוא ראה לכל הפחות ארבעה-חמישה מחזורי גרסאות ויודע להתאים את אופי וקצב העבודה שלו אליהם, וכיו"ב. אתה גם יודע עוד משהו: שבמשך שנתיים וחצי, שזה די והותר זמן להכיר עבודה של אדם, הוא היה לפחות טוב מספיק כדי שלא יפטרו אותו. אם מישהו אומר לך שהוא עבד על Y בקוד פתוח, אתה יכול לראות את הקוד שלו ואולי הוא מקודד טוב (או שעזרו לו, או שהוא השקיע המון זמן בכל שורה), אבל אין לך שמץ של מושג לגבי העבודה שלו המובן הרחב יותר, לא איכותה ולא היקפה ולא הקצב שלה. אז כן, אתה יכול ללכת ולנבור במערכת ניהול הגרסאות וברשימות התפוצה, לראות מה היחסים שלו עם שאר האנשים ומה קצב השינויים שהוא מכניס, ולנסות לעקוב אחרי העבודה שלו בכלל ולגבש איזו תמונה, אבל זה ידרוש ממך הרבה מאוד זמן ולא בטוח שתקבל תמונה מדויקת. אין סטנדרט. איך שאני רואה את זה, נסיון בקוד־פתוח הוא תחליף לחוסר־נסיון (חוסר־נסיון בכלל, או חוסר־נסיון בתחום מסוים). זו דרך להעשיר את ארגז־הכלים הטכני שלך, ולהציג את זה כך בקורות־חיים. זה לא קשור בכלל לסעיף של נסיון עבודה של ממש. |
|
|
|
|
|
|
||
|
||||
|
אני כמעט מסכים עם מה שאתה אומר, ואולי באמת החברות עשו בשכל שלא התעניינו יותר מדי בעניין הקוד הפתוח (זה לא שווה את ההשקעה). כמעט, כי אני לא בטוח שיש סטנדרט, אני מכיר במקומות שלא עשו בהם יותר מדי ובקוה"ח הם נראים ממש מרשימים. השאלה היא מה המשקל שנותן המעסיק הטיפוסי לנסיון בקוד פתוח במקום נסיון אמיתי (ברור שזה לא 0), ולהערכתי המשקל כ"כ נמוך, שאם אתה נכנס לעניין הקוד פתוח רק בשביל "להכנס לתחום", חבל לך על המאמץ. אתה יכול להגיד ששיחקת עם זה בבית, להדגים ידע בראיון ותקבל תוצאה דומה. |
|
|
|
|
|
|
||
|
||||
|
"לשחק עם זה בבית" זה אחלה. יש מצב שקל יותר, ויש יותר מה ללמוד, במסגרת של פרוייקט גדול וקיים, מאשר סתם לכתוב מחשבון דואודצימלי ולשמור אותו במגירה, אבל זה עניין של העדפה אישית. לגבי היוקרה של מעורבות בפרוייקט ממש, אני מניח שזה תלוי באיזה פרוייקט. יש פרוייקטים שיש להם יוקרה בתחומים מסויימים. נגיד, אם הכנסת קוד לקרנל לינוקס והוא יצא בגרסה רשמית של לינוס טורוולדס (במיוחד אם הוא לא דרייבר, אבל גם אם כן), יש מצב שיהיה לזה משקל משמעותי בראיון למשרה שמערבת תכנות לקרנל, כי ללינוקס יצא שם שקשה להכניס לשם קוד. אם מצאת ותיקנת חור אבטחה בOpenSSL, כנ"ל, בתחום אבטחת־תוכנה. אם אתה מפתח דביאן רשמי והמשרה קשורה להתעסקות עם הפצה מבוססת־דביאן (נגיד, לתחזק את הappliance של המוצר), כנ"ל. מה שמשותף לשלושת הפרוייקטים האלה זה שהם מפורסמים בסטנדרטים הגבוהים שלהם, כל אחד בתחומו (גם אם בפועל אנחנו מגלים שהם אולי לא תמיד ראויים לסנדרטים האלה...), ועדיין צריך ליפול על מראיין ששמע על הסטנדרטים הגבוהים של הפרוייקט. |
|
|
|
|
|
|
||
|
||||
|
ברור שתלמד יותר במסגרת פרוייקט קיים מאשר לבד, אבל אנחנו לא רוצים ללמוד אנחנו רוצים לקבל עבודה וללמוד על חשבון המעסיק. אז השאלה היא כמה חשיבות המעסיק ייתן ל"תרמתי קוד" לעומת "שיחקתי עם זה", לא רלוונטי כמה אתה באמת לומד. מבחינתך הכי זול זה לשחק עם זה בבית, אז אם התשואה של שני הדברים דומה - עדיף לשלם פחות. אתה באמת צודק שיש פרוייקטים מסויימים בהם המעסיק בוודאי מודע ומסתכל על קוד פתוח (אם מישהו כותב את הגרסא שלו לקרנל, כנראה שהוא יודע מה זה להכניס קוד לקרנל ויתרשם ממך אם הכנסת) לדעתי תחום המחקר באבטחת מידע לא קשור, שם חברה רצינית בתחום קוראת פרסומים של אנשים פרטיים על פרצות שהם מצאו, וייתנו לך כבוד בין אם מצאת פירצה בקוד פתוח או בקוד סגור. אני דווקא לא מעריך שייתרשמו מעובדת היותך מתחזק של דביאן אם אתה מכוון לעבודה של sysadmin, כי למנהלים שחפשו sysadmin-ים שפגשתי, לא היה מושג מה כרוך בלהיות מפתח דביאן. אבל יכול להיות. |
|
|
|
|
|
|
||
|
||||
|
ההבדל בין "תרמתי קוד" לבין "שיחקתי עם זה" הוא בדיוק העובדה שלא מדובר רק על כך שזה משחק פרטי שלי. יש עוד מישהו אחר שחושב שזה מספיק מועיל כדי שהוא ישקיע מזמנו בשילוב תרומת הקוד הזו. יש עוד עיניים שהסתכלו על הקוד. הייתי שותף לתהליך של בקרת עמיתים. סתם לדוגמה: ארזנו אצלנו בחברה חבילות תוכנה באריזות deb בצורה עצמאית. זה עבד. לאחר שנה הבננו שזה לא חכם לתחזק מאגרים נפרדים ועדיף להעלות את כל התיקונים שאפשר למעלה. כמובן שהתברר שכל מיני דברים ש"עובדים" הם אינם הדברים הנכונים, וגם אינם מוצלחים במיוחד (עלולים להכשל בדרכים מאוד נחמדות בנסיבות המתאימות). זה בדיוק התהליך של בקרת עמיתים. והוא לא קרה כשהתוכנה לא היתה (מספיק) חשופה למפתחים חיצוניים. אני לא אעז להעלות שטויות לדביאן כי יעלו עלי מהר (בהסתברות גבוהה למדי). מעורבות בפרוייקט תוכנה (ובפרט תוכנה חופשית) אינו מעשה חד-פעמי של כתיבת קוד עצמאית. אתה כותב לפי צרכי הסביבה, מגיב למשוב מהסביבה. מגיב לבעיות שהעלו. וכמובן: אתה מספיק סומך על איכות הכתיבה שלך כדי לשים אותה באינטרנט. |
|
|
|
|
|
|
||
|
||||
|
על זה אין ויכוח. השאלה היא מתי ועד כמה האתגרים האלה וההתמודדות המוצלחת שלך איתם חשופים למעסיקים פוטנציאליים כשאתה מפרט את התרומות שלך בקורות־החיים. | |
|
|
|
|
|
||
|
||||
|
אדרבא, ספר על נסיון אחר (אולי שלך) בו היה משקל לקוד הפתוח שכתבת. אני לא מדבר על זה שלינוס טרובלדס מצא עבודה בגלל קוד פתוח, אלא סטודנט למדעי המחשב שתרם קוד לפרוייקטי קוד פתוח במהלך לימודיו, והמעסיקים התלהבו מעובדה זו כך שהיה לו יותר קל להתקבל לחברה בזכות תרומתו לקוד פתוח. | |
|
|
|
|
|
||
|
||||
|
אצלי זה הודית... | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |