בתשובה לכבשה, 12/04/08 19:43
 |
|
 |
||
|
||||
 |
ברשותך, אני אמשיך קצת לירוק לבאר ממנה אני שותה... אני חושב שצריך להבדיל בין HI-TEC אמיתי (חברות תוכנה וחומרה מבוססות מחקר ופיתוח מדעי) לבין HI-TEC צעצוע (חברות לפיתוח אפליקציות, אתרי אינטרנט ופרויקטי תוכנה בועתיים). התאור למעלה נראה מתאים יותר ליענו HI-TEC מהסוג השני. חברות שההתנהלות שלהן מזכירה יותר התנהלות של מתפרה (מתכנת האפליקציות כתופרת של המאה ה-21 זה דימוי ידוע) מאשר את התנהלותו של מרכז מחקר ופיתוח של על מוליכים או של הדור הבא של המאיצים הגרפיים. |
 |
 |
 |
|
|
|
||
|
||||
|
Hi-Tech
|
|
|
|
|
|
|
||
|
||||
|
High-Tech
|
|
|
|
|
|
|
||
|
||||
|
High-Technology
|
|
|
|
|
|
|
||
|
||||
|
ממש צמיחה ב-Hi-Tech, מה שקרה בפתיל הזה. | |
|
|
|
|
|
||
|
||||
|
טכנולוגיה עילית. | |
|
|
|
|
|
||
|
||||
|
אני חייב לציין שמצאתי את התגובה שלך מעט מעליבה, בעיקר בגלל שיש בה גרעין של אמת. הייתי רוצה לציין שני דברים: 1) את האבחנה שאתה מבצע כבר עשו: חברות מהסוג השני מוגדרות מזמן בתעשייה כ-IT (Information Technology) 2) לא כל חברות ה-IT מתנהלות באופן הנ"ל. אפשר לפתח אפליקציות ואפליקציות ווביות באופן מקצועי. |
|
|
|
|
|
|
||
|
||||
|
1) נכון. 2) כמובן. אבל קשה להיות מתכנת אפליקציות מבלי להתקל בחברה אחת כזו לפחות (סביר להניח שיותר) במהלך הקריירה. הדברים נכתבו במרמור מחוייך ולא מתוך רצון לדייק. |
|
|
|
|
|
|
||
|
||||
|
2א) תהיה מתפרה יעילה ומקצועית ככל שתהיה, היא בכל זאת מתפרה. | |
|
|
|
|
|
||
|
||||
|
אם זו מתפרה מקצועית ויעילה, אז מדוע הדימוי השלילי? | |
|
|
|
|
|
||
|
||||
|
חולמים על עולם מופשט של חשיבה אלגוריתמית, מכונות טיורינג, סיבוכיות, הוכחות, דיוק קפדני ומתמטיקה ומתעוררים בתוך עולם של צוארון כחול, ספריות בדוט נט, באגים בדיזיין (זין בדיבאג), שליחת XMLים משמימים, ממשקי AJAX, ישיבות ארוכות בהן מתווכחים אם הלוגו צריך להיות כחול או ירוק בהיר ותפירת מוצרי מדף (שפותחו כבר בבתי התוכנה האמיתיים) זה לזה. לא שיש משהו בצווארון כחול. חברי הטובים ביותר... |
|
|
|
|
|
|
||
|
||||
|
אני בספק כמה אנשים חולמים על הדברים שציינת. בכל אופן אצלנו לפחות מרבית המתכנתים שואבים סיפוק מהעבודה שלהם. עבורי ועבור שאר המתכנתים הבכירים, אנחנו לא מתעסקים הרבה עם "שליחת XMLים משמימים, ממשקי AJAX" וגו', אלא דווקא עם האכיטקטורה הכללית יותר של המערכת - תכנון מחלקות, תכנון בסיסי נתונים, אופטימיזציה, פלטפורמות כאלו ואחרות, פיתוח של ספריות לצרכים מסויימים, אבטחה, וכד'. כראשי צוותים אנחנו גם עוזרים ומלמדים את המתכנתים הפחות מנוסים, ומפקחים על רמת הקוד שהם מייצרים. אנחנו לא מוצאים את העבודה שלנו משמימה, אלא להיפך. זה בדיוק ההבדל בין עבודה מקצועית לעבודת כסת"ח, והיכולת לשאוב סיפוק והנאה מהעבודה בהתאם. |
|
|
|
|
|
|
||
|
||||
|
שלב תכנון המחלקות מראש, תכנון בסיסי נתונים, אופטימיזציה, השקעה בפיתוח של ספריות לשימוש חוזר, אבטחה: אוסף מושגים שגרמו למנהלי הפרויקטים, בחברה הגרועה ההיא, להכנס לויברציות ולתהות על מה המפתח הנודניק הזה מדבר, כל פעם מחדש. איזה כיף שעשיתי מעשה ואני מזמן לא שם. |
|
|
|
|
|
|
||
|
||||
|
גם אני לא, ואצלנו כל הדברים שציינו לעיל קורים, ומנהלי הפרוייקטים הם לא אלו שקובעים את המדיניות מהבחינה הזו - וכל זה בתחום של IT. ולכן שוב השאלה: למה ההכרח ש-High Tech זה טוב ו-IT זה רע? |
|
|
|
|
|
|
||
|
||||
|
''הדברים נכתבו במרמור מחוייך ולא מתוך רצון לדייק.'' | |
|
|
|
|
|
||
|
||||
|
לא הבנתי שמדובר באותו האלמוני. | |
|
|
|
|
|
||
|
||||
|
בהההה. כל האלמונים אותו הדבר. | |
|
|
|
|
|
||
|
||||
|
חברות מהסוג השני מוגדרות IT. חברות מהסוג הראשון מתנהלות כמו החברות מהסוג השני :-) |
|
|
|
|
|
|
||
|
||||
|
באמת? ז"א ברור שלא בצורה קיצונית כל כך (בדיוק כמו שחברות IT לא מתנהגות באמת כך), אבל האם בהגזמה זה נכון גם עבור חברות מהסוג הראשון? האם זה נפוץ או לא בלתי שכיח בעליל, למשל, שחברת תוכנה גדולה כמו IBM זורקת פרויקט לפח, לאחר שהושקעו בו שעות עבודה רבות ולמרות שחוות הדעת של רבים מהמהנדסים הזהירה מראש שזה הכיוון אליו הולך הפרויקט? | |
|
|
|
|
|
||
|
||||
|
אני מניח שנאסא אמורה להיות דוגמה קלאסית לרמה טכנולוגית משובחת אולם התחקירים לאחר התפוצצויות המעבורות שלהן מעוררי צמרמורת. מה יגידו אזובי הקיר? |
|
|
|
|
|
|
||
|
||||
|
היה לי מרצה להנדסת תוכנה (אאז"נ הוא עבד ב-IBM) שטען שרוב מוחלט של שורות הקוד שנכתבות בשוק התוכנה, נכתבות על מנת להזרק לפח בסופו של דבר. גם בפרויקטים שנחשבים למוצלחים בסופו של דבר. האם יש שמץ של אמת בטענה? | |
|
|
|
|
|
||
|
||||
|
מנסיוני הצנוע, יותר ממחצית זמני הושקע בפרויקטים שפני לקוח לא שזפו אותם. | |
|
|
|
|
|
||
|
||||
|
ומה אופי החברה בה אתה עובד? מה התחום? | |
|
|
|
|
|
||
|
||||
|
תוכנה. דיברנו על שורות קוד, לא? | |
|
|
|
|
|
||
|
||||
|
זה בדיוק נושא הפתיל והקונספציה המוטעת שהוא מעלה: תוכנה זו מילה כללית מידי והיא כוללת סוגי עבודה שונים ומגוונים. איזה תחום בתוכנה? | |
|
|
|
|
|
||
|
||||
|
השורות שנזרקות לפח זה לא תמיד דבר רע. כאשר אני משפר תוכנית בסוף התהליך התוכנית המשופרת היא בדרך כלל קצרה מהמקורית. |
|
|
|
|
|
|
||
|
||||
|
בנאי טוב לא מותיר את הפיגומים מסביב לבנין. (או משהו בסגנון..) |
|
|
|
|
|
|
||
|
||||
|
הלוואי והיה מדובר בפיגומים. על פי רוב במצבים כאלה אני מסתכל על הקוד המקורי ושואל את עצמי מה לעזאזל חשבתי כשכתבתי אותו. |
|
|
|
|
|
|
||
|
||||
|
"Plan to throw one away; you will anyhow."
|
|
|
|
|
|
|
||
|
||||
|
"If you plan to throw one away, you'll throw two."
|
|
|
|
|
|
|
||
|
||||
|
לתכנת קצר ונקי מלחתחילה, לאחר תכנון ארוך ומושקע בו לא כותבים אפילו שורת קוד אחת, זו הדרך אותה אני מעדיף. הבעיה היא למכור את הדרך הזו למנהלי פרויקטים שמרגישים נוח רק אם יש התקדמות ''אמיתית'' (לשיטתם). | |
|
|
|
|
|
||
|
||||
|
אני מעדיף לכתוב בחצי שעה את כל הפרוייקט בשלוש שורות קוד וללא שום באג. תכנון ארוך ומושקע לא באמת פותר את כל הבעיות. גם הגישה ההפוכה של extreme programming לא פותרת את הבעיות. בואו נכיר בזה שכנראה מדובר בבעיה קשה וששיטות הנדסת התוכנה למניהן אומנם מועילות אך בטח לא מושלמות. |
|
|
|
|
|
|
||
|
||||
|
אה, בטח. ניזכרתי מי היה זה שאמר שהעביה כנראה קשה ושנצטרך ללמוד לחיות עם זה. |
|
|
|
|
|
|
||
|
||||
|
למרות זאת, הוא גם אמר שכן יש הבדל מהותי בין מתכנתים טובים לבין מתכנתים ממש טובים. אי אפשר לפרמל, להגדיר שיטה חד משמעית או לסכם את אומנות הנדסת התוכנה למספר כללי אצבע, אבל האומנות קיימת בכל זאת. המתכנתים הלא ממש טובים צריכים ללמוד לחיות עם זה. | |
|
|
|
|
|
||
|
||||
|
נכון. אני מבכה את זה שגם המתכנתים הממש טובים יוצרים באגים לעיתים. |
|
|
|
|
|
|
||
|
||||
|
ממש לא נחון! | |
|
|
|
|
|
||
|
||||
|
עזוב אותך מתכנון. מתכנת אמיתי עובד רק בניסוי וטעיה. | |
|
|
|
|
|
||
|
||||
|
ואם הוא ממש רציני, גם אינו מתעסק עם ניסוי. | |
|
|
|
|
|
||
|
||||
|
ואם הוא עוד יותר רציני, הוא גם אינו מתעסק עם טעיה אלא מתרכז בהטעיה. |
|
|
|
|
|
|
||
|
||||
|
לא בלתי שכיח זה כמו, נניח, שכיח? | |
|
|
|
|
|
||
|
||||
|
כן. לא בלתי שכיח בעליל זה כמו, נניח, מתרחש מידי פעם גם אם לא נפוץ. | |
|
|
|
|
|
||
|
||||
|
אני לא מבין יותר מידי בניהול, אבל יצא לי לראיין כמה מהנדסים שצברו נסיון בחברות כאלה. לא יכול להיות שמהנדס תוכנה עם נסיון של 3 או אפילו 5 שנים לא ידע לקרוא 20 שורות קוד פשוטות ולדעת מה הוא עושה (שלא לדבר על לכתוב), ולא יכול להיות שבוגר מצטיין של הטכניון בהנדסת תוכנה או מדעי המחשב לא ידע מתי להשתמש בעץ בינארי (מאוזן) ומתי בהאש. בקיצור, אם אתה מהנדס צעיר, ורוצה לפתח קריירה בהנדסת תוכנה (להבדיל מניהול) פשוט על תתקרב לחברות האלה. כמראיין, הגעתי למסקנה שכל שנת נסיון בחברה גרועה זה כמו מינוס חצי שנה נסיון בחברה נורמלית. | |
|
|
|
|
|
||
|
||||
|
פורסמה רשימה של חברות גרועות? סתם, שנדע ממי להזהר. | |
|
|
|
|
|
||
|
||||
|
צ''ל ''אל'', תודה סליחה ושלום. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |