לגלישה באתר בגירסה המותאמת לסלולאר
| הוספת הודעה
הגדרות תצוגה

הגדרות עץ הודעות

מאפייני צפייה

הצג טקסט בתצוגה
הצג תגובות באופן
עדכן
2181221,812 עוקבים אודות עסקים

פורום עבודה בהיי-טק

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

הנהלת הפורום:

אודות הפורום עבודה בהיי-טק

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

לצפיה ב-'עד כמה "כימיה" חשובה בראיונות עבודה?'
עד כמה "כימיה" חשובה בראיונות עבודה?
<< ההודעה הנוכחית
18/05/2020 | 08:49
103
528
במהלך השנים יצא לי לחפש עבודה כמה פעמים - ובכל סבב ראיונות היה לי לפחות ראיון אחד שבו הרגשתי כבר מהדקות הראשונות של הראיון שאני לא הולכת לעבור אותו בהצלחה, גם אם בשלב זה רק התחלתי לתאר את התפקיד האחרון שלי. זה היה למשל מראיין שהתעקש להכנס לפרטים של תחום שאמרתי שאני מכירה בגדול באופן תיאורטי בלבד ולא עבדתי בו (לפחות לא בשנים האחרונות), כאילו להוכיח בכוח שאני גרועה ולא מתאימה לו. או מראיין שכבר מתחילת הראיון, שבו אני מתארת את התפקיד האחרון שלי, קוטע אותי כל משפט וחצי בערך עם שאלות לגבי מה שאני מנסה לתאר - בלי לתת לי לתאר את מה שאני רוצה ברצף שמתאים ונוח לי. 
 
במקביל, היו לי ראיונות אחרים שבהם די מהר היה ברור שהמראיין מתרשם ממני לטובה. אני מצליחה לתאר את התפקיד האחרון שלי בצורה שבהירה לו, ומראה יכולת חשיבה טובה כשאני עונה על שאלות. במצב כזה לא פעם נראה שהמראיין מוכן לקבל למשל צורך שלי בהכוונה בשאלה כזו או אחרת או טעות בפרטים כי בעצם הראיתי שיש לי יכולת חשיבה. לא תמיד זה הוביל להצעת עבודה בסופו של דבר בגלל כל מיני גורמים (למרות שלפעמים כן), אבל תמיד הצלחתי להתקדם כך לשלבים מתקדמים בתהליך.
 
פעם שמעתי שמראיינים קובעים את דעתם על המועמד בדקות הראשונות לראיון, לא פעם עוד לפני שהראיון המקצועי התחיל - ואז מבלים את שאר הראיון בניסיון להוכיח את הרושם הזה. זו אמנם קלישאה, אבל האם היא נכונה?
עבודה בהיי-טק >>
לצפיה ב-'מן הסתם כל מראיין זה משהו אחר'
מן הסתם כל מראיין זה משהו אחר
18/05/2020 | 09:16
95
117
אין איזה אלגוריתם זהה לכל המראיינים.
 
לשאלתך: הכימיה חשובה. יש על זה אינספור מחקרים בנושא של רושם ראשוני וההשפעות הפסיכולוגיות כולל הטיות וקבלת החלטות לא רציונליות. יש אפילו ניסויים שבהם שלחו מועמדים לראיונות עבודה וביקשו מהם להתנהג או להופיע באופן מסויים כדי לחקור את ההשפעה.
 
עם זאת, זה שמראיין מתנהג קשוח בתחילת הראיון לא אומר שהוא חרץ את דעתו. הרבה פעמים לוקח זמן לשבור את הקרח וצריך לדאוג לא לאבד את הקור רוח והבטחון העצמי בדקות הראשונות.
 
לגבי הקלישאה: לא יודע מה עם מראיינים אחרים אבל אני יכול להעיד על עצמי. בדרך כלל ה10-15 דקות הראשונות מכריעות. יש מועמדים שישר אני מבין שזה בדיוק מה שאני מחפש, יש כאלה שברור לי שהם לא מתאימים. יש מקרים לא נפוצים של 50-50 ואז להמשך הראיון יש השפעה מכרעת.
במקרה הרגיל שבו אחרי רבע שעה כבר יש דעה די ברורה, ממשיכים את הראיון כדי להתעמק בפרטים. אם זה מישהו טוב, אז רוצים לוודא שלא פספסנו איזה משהו קריטי, וגם לעשות ווידוא ולשלול מקרים שמועמד גרוע הצליח להבריק בכמה דקות.
אם זה מישהו לא מתאים, ממשיכים את הראיון גם מתוך נימוס וגם בשביל לוודא את ההפך: שלא מדובר במועמד שאולי כשל בלשונו מתוך התרגשות אבל בעצם הוא כן מתאים. יש גם עניין של בדיקת A/B טסטינג. כשיש מועמד חלש, אתה בכל זאת שואל אותו את השאלות הרגילות שלך. כנ"ל לגבי מועמד חזק. ככה אתה מתקף שהשאלות הטכניות שלך טובות. מועמד חזק יענה עליהן טוב, מועמד חלש לא ידע לענות.
לי היתה עוד שיטה: במקום בו ייעצתי הייתי מראיין הרבה ואת המועמדים מעביר לVP פיתוח לראיון סופי. אותו בחור היה מפתח מנוסה, ממייסדי החברה, בוגר טכניון ואדם מאוד חכם. הייתי שולח אליו מועמדים בלי להגיד לו מה אני חושב עליהם. ככה מצאתי שמועמד שנכשל אצלי היה נופל גם אצלו, ומי שעבר אצלי היה גם עובר אצלו. אגב, אלה שהיו ככה-ככה אצלי, היו נופלים אצלו, היו לו סטנדרטים גבוהים. זה עזר לי לבנות מודל דירוג שקיבל תוקף אצל עוד גורם.
עבודה בהיי-טק >>
לצפיה ב-'ברור שלכל מראיין יש טכניקות שונות...'
ברור שלכל מראיין יש טכניקות שונות...
18/05/2020 | 12:23
93
98
ופרמטרים אחרים למועמד מתאים, וכמובן שזה תלוי במשרה שאליה מגייסים. וכמובן שיש מתכנתים גרועים שמצליחים להרשים לעומת מתכנתים טובים שלא מצליחים להרשים.
 
אני לא בהכרח מדברת על מראיין קשוח לעומת מראיין מתלהב. אני מדברת למשל על מראיין שלא נותן לי לתאר את התפקיד הנוכחי שלי אלא מיד מתפרץ לתיאור שלי (שהכנתי מראש בסדר מסוים כדי שאוכל לתאר לאדם חיצוני את החלק שלי במערכת שהוא לא מכיר אבל אני מכירה כבר לעומק) ומתחיל לשאול שאלות שאם הוא היה נותן לי לספר לו דברים עוד דקה או שתיים הוא כבר היה שומע לבד ובצורה מובנת יותר, אבל התחושה שלי היתה שהוא ניסה להלחיץ או לבלבל אותי בצורה מכוונת (אני הרגשתי בעיקר עצבנית על זה שהוא לא נתן לי לסיים משפט, והיה ברור לי שזה אדם שאני לא ארצה לעבוד איתו).
 
או ראיון אחר שבו למשל נשאלתי האם אני יודעת איך משלבים קבצי C בתוכנה של C++ אמרתי שבאופן כללי כן (ונתתי דוגמא כזו) אבל שלא השמשתי בזה מאז התואר. הוא התעקש לשאול אותי שאלות עומק על הנושא, למרות שהיה די ברור שאני אגיד "אני לא יודעת" ו"אני לא מכירה".
 
שיטות הראיון שלך נשמעות הגיוניות מנקודת מבט של מראיין, אבל בתור מרואיינת אני לרוב רואה במעבר לשלב הבא של הראיונות אינדיקציה לזה שהמראיין ראה בי איזשהו פוטנציאל (למרות שברור לי שבכל שלב משקללים גם את מה שנעשה בשלבים הקודמים, ולא פעם מקדמים אנשים שלא עברו את הראיונות הקודמים בצורה אידאלית). כך שאולי הבדיקה שלך היתה קצת מבלבלת אותי מבחינת ההבנה שלי של המצב (זה כמובן אומר הרבה עלי ולא בהכרח עליך).
עבודה בהיי-טק >>
לצפיה ב-'מה יש לדעת בשילוב של C ו-C++?'
מה יש לדעת בשילוב של C ו-C++?
19/05/2020 | 03:33
92
72
איזה שאלות עומק למשל הוא שאל על הנושא הזה?
למיטב ידיעתי זה נושא טריוויאלי לגמרי.
 
עבודה בהיי-טק >>
לצפיה ב-'אני אתן לך דוגמא לשאלה'
אני אתן לך דוגמא לשאלה
19/05/2020 | 04:04
88
73
״למה אתה חושב ששילוב של C ושל ++C הוא טריויאלי?״
 
מהשאלה הזאת אפשר לפתח דיון שיגלה את עומק הידע שלך בשתי השפות, הכרות עם הסטנדרטים העדכניים, הבעיות שיצא לך לפתור, ועומק ההכרות שלך עם שילובי כלים שונים. תלוי באיך תענה ומה יש לך בקורות חיים - אפשר להמשיך ולדון בשאלה ״אוקי, ומה עם שילוב של C ופייתון?״ למשל, או Java, או שילוב של C בקוד אנדרואיד, וכו׳ וכד׳.
 
כמובן שהשילוב של שפות שונות עם פרדיגמות שונות הוא ממש לא טריויאלי, שלא לדבר על בעית התאימות לאחור שפעם הייתה ואיננה עוד בין ++C לC, מה שיוצר הרבה בעיות לא מעט בזכות מתכנתים שלא יודעים שהתאימות הזאת איננה עוד, וכו׳ וכד׳.
 
עבודה בהיי-טק >>
לצפיה ב-'כי עשיתי את זה וזה היה טריוויאלי...'
כי עשיתי את זה וזה היה טריוויאלי...
19/05/2020 | 04:29
87
74
למעשה לא זכרתי איך בדיוק עושים את זה (מה שאומר שבראיון לא הייתי יודע לענות בדיוק) ולכן העליתי עכשיו בזריזות את אחד המקרים. שילוב של C++ שאני כתבתי עם C שנלקח ממקור חיצוני. אני רואה בהדר של ה-C שההכרזות עטופות ב- extern C. זהו. המוצר הזה עובד יופי. עוד משהו?
לשאלות ההמשך אם אני הייתי יושב מול החבר המראיין הייתי דבר ראשון שואל אותו: האם יש לכם בעיה כזו? זה אקטואלי למשרה? כי אם כבודו מתכוון לחקור אותי על עולם התוכנה באופן כללי ובלי קשר הכרחי למשרה, אני כבר מודיע לכבודו שבוודאות אני לא אדע לענות לרוב השאלות. בתכנות יש אינסוף סוגיות. אי אפשר להכיר את כל התחומים ובוודאי אי אפשר לסחוב בראש את כל הפרגמות ואת כל ההגדרות הטריוויאליות שלוקח חמש דקות לברר בגוגל ואחרי כן שוכחים מזה.
ואם אקטואלי למשרה לקרוא ל-C מפייתון, אני לא יודע את התשובה אבל אני מבטיח לך שנוכל לברר את זה בכזו מהירות שתקבל סחרחורת.
כך שאפשר כבר לעבור לדבר על המשכורת.
 
 
 
עבודה בהיי-טק >>
לצפיה ב-'טוב, כבר הבננו שאין לנו שום זכות לשאול אותך שאלות '
טוב, כבר הבננו שאין לנו שום זכות לשאול אותך שאלות
19/05/2020 | 05:03
77
61
איזו בעיה פתרת עם ״extern C״? למה זאת בעיה מתכלתחילה? אילו עוד בעיות יכולות להיות שהכלי הזה לא פותר?
עבודה בהיי-טק >>
לצפיה ב-'זכות לשאול שאלות יש לכל אחד'
זכות לשאול שאלות יש לכל אחד
19/05/2020 | 05:16
76
59
אנחנו חיים במדינה דמוקרטית ויש כאן, למרבה הצער, חופש ביטוי. אז לשאול מותר, אבל יש שאלות שמעידות שהשואל לא מבין את המקצוע כמוני, ולכן על פניו אנחנו לא מתאימים. כי אם הוא הולך במהלך שיתוף הפעולה להציק לי עם שאלות טפלות אני לא אוכל לעבוד.
לשאלתך איזו בעיה פתרתי, התשובה היא "את הבעיה של שילוב C עם C++"
נתת לי C (כנראה ממקור חיצוני), הסכמנו שאנחנו עובדים ב-C++, צריך לשלב את ה-C, הנה בוצע.
יש בתור עוד 150 בעיות רק להיום, הצטברו כי אתה מתחפר בשטויות ומזמן ישיבות של 3 שעות לדון ב"למה שילוב של C ו-C++ זו בעיה", וכל יום זורמות פנימה עוד 10-20 פר מפתח. בגישה שלך על כל בעיה שנכנסת אנחנו נפתח דיון שלם בלמה וכמה. בגישה שלי מוצאים פתרון לבעיה במהירות המירבית ועוברים לבעיה הבאה. אז השאלה היא: אתה רוצה לבנות מערכת תוכנה שיהיה לך מה למכור, או אתה רוצה להתפלסף? 
עבודה בהיי-טק >>
לצפיה ב-'שמע, אם אתה יודע להעתיק פתרונות מהאינטרנט'
שמע, אם אתה יודע להעתיק פתרונות מהאינטרנט
19/05/2020 | 06:25
75
65
אבל לא יודע להסביר אותם - אתה לא באמת מתכנת, אתה קוף קוד.
 
אם אתה לא יודע מה הבעיה - איך אני יכול להיות בטוח שתמצא את הפתרון? איך אני יכול להיו תבטוח שתמצא את הפתרון הנכון? אין לך מושג מה הבעיה הייתה, העתקת איזה קוד מאיפשהו, ראית שעובד, מבחינתך זה יופי?
 
אני מצטער, אבל אתה לא מועמד שמתאים לנו, תודה על הזמן שלך.
עבודה בהיי-טק >>
לצפיה ב-'אם המוצר שאתה מתכנן ניתן לבנייה מקוד שמוצאים באינטרנט'
אם המוצר שאתה מתכנן ניתן לבנייה מקוד שמוצאים באינטרנט
19/05/2020 | 08:17
74
60
אז אדרבא, תן לי 150K, אני אחפש את הקוד באינטרנט ותקבל את המוצר מחרתיים. בשביל מה לך הסברים? מה תעשה בהם? יש לך מוצר, לך תמכור.
אם המוצר שלך דורש גם פיתוח מקורי אז בהכרח אי אפשר יהיה למצוא את הפתרונות באינטרנט, עם הסברים או בלעדיהם.
 
אני יודע מה הבעיה, אתה זה שמנסח בעיות שלא קיימות. זיהוי הבעיה הנכונה הוא יכולת קריטית של מתכנת. כי זיהוי לא נכון של בעיה יוביל להשקעת משאבים במסלולים מיותרים. וזה מה שיקרה בהשקפת העולם וכושר הניתוח שאתה מציג.
 
אני יודע שאני לא מועמד מתאים לכם. אתם צריכים לוחות חלקים שאתם יכולים לעצב כרצונכם או אנשים שאין להם הבנה של המקצוע בו בחרו.
עבודה בהיי-טק >>
לצפיה ב-'תגיד, אתה אמיתי?'
תגיד, אתה אמיתי?
19/05/2020 | 08:23
73
58
אם אתה לא מבין לעומק את הפתרון שאתה מציע - איך אתה יכול להבין שהוא פותר את הבעיה בצורה מלאה ולא רק מקרים ספציפיים? מבחינתך אם זה רץ נכון על המחשב שלך על דוגמא קטנה זה גם אומר שזה ירוץ על כל סט של נתונים בכל גודל אצל הלקוח?
אלא אם אתה עובד בחברה שמתפרנסת מזה שהיא נותנת תמיכה ללקוחות על בסיס כמה באגים היא פותרת להם (ולכן מנסה להכניס בכוח באגים למערכת) - לא ברור לי איך הצלחת לכתוב מערכת שעדיין שורדת בשוק.
עבודה בהיי-טק >>
לצפיה ב-'זו טענה מוזרה'
זו טענה מוזרה
19/05/2020 | 08:27
72
57
איך אני יודע שאלגוריתם המיון שבא בספריות של השפה, תהא איזו שתהא, פותר את כל המקרים ואין בו באגים? איך אני יודע שיחידת חישוב נקודה צפה של המעבד פותר את כל המקרים? איך אני יודע ששכבות התקשורת של ה-TCP עובדות נכון בכל המקרים?
 
עבודה בהיי-טק >>
לצפיה ב-'האם אתה יודע?'
האם אתה יודע?
19/05/2020 | 08:47
67
50
אם אני אשאל על אלגוריתם מיון - תוכל להראות לי נכונות של האלגוריתם? תוכל להסביר לי איך הוא עובד? או שתגיד "הנה, הרצתי מיון וזה ממוין, מה עוד אתה רוצה?"
עבודה בהיי-טק >>
לצפיה ב-'אני יכול ללמוד'
אני יכול ללמוד
19/05/2020 | 09:15
66
49
אבל זה לא בחוזה העבודה שלי ולכן שכרי עבור שעות הלימוד האלה יהיה פי ארבע.
אתה רוצה לשרוף כסף על ידע שלא יתרום דבר לפרויקט, בבקשה.
מה שכן אם אתה תמשיך להציק לי עם שאלות ומשימות שלא מקדמות את העבודה, תהיה לכולנו בעיה. יכול להיות אפילו שנצטרך לערב את המחלקה המשפטית.
("אתה" לא אתה אישית אלא מי שחושב שהוא נמצא בעמדה שהוא יכול לפנות אלי בשאלות חסרות טעם ולהטיל עלי משימות שרירותיות, ויש כאלה)
 
עבודה בהיי-טק >>
לצפיה ב-'אני לא יודע מה בחוזה העבודה שלך'
אני לא יודע מה בחוזה העבודה שלך
19/05/2020 | 11:00
65
45
אני לא רוצה לשכור מתכנת שלא מסוגל להראות נוכונות של הפתרון שלו ודורש שאני "אסמוך עליו" וש"יהיה בסדר".
עבודה בהיי-טק >>
לצפיה ב-'אתה דרשת ממני להראות נכונות פתרון של מישהו אחר'
אתה דרשת ממני להראות נכונות פתרון של מישהו אחר
19/05/2020 | 11:30
64
52
למשל הנכונות של אלגוריתמי מיון מוכנים שכלולים בשפה. לא של פתרון שלי. זו הגישה שמתכנת צריך להבין אלגוריתמים אלה ואחרים למרות שלא הוא יצר אותם ולא הוא אחראי עליהם, כחלק מידע כללי במדעי המחשב.
בכל אופן אצלנו כשאני הייתי בנתיב הקריטי הוכחת תקינות המערכת היתה תפקיד מובהק של המומחים לתחום העסקי, שהם מבינים את התחום, הם ניסחו את הדרישות, הם יודעים להכין מקרי מבחן, והם יודעים לבקר את התוצאות.
לי כמתכנת יש הבנה של התחום העסקי אבל לא כי זה התפקיד שלי, ובכל אופן אני לא יכול לבדוק את עצמי. אם הבנתי את הדרישות לא נכון, או שאני עיוור לחלק מהמצבים שהמערכת אמורה להתמודד איתם, ולכן כשלתי במימוש שלהם, הבדיקה העצמית שלי לא תחשוף שגיאות ובעיות.
אני עבדתי לבד וכיום הם עובדים בצוותים, אז אולי הם עושים סקירת קוד. אני לא מעורב שם אז לא יודע. בזמני לא היה מי שיבחן אותי בצורה הזו, ובכל אופן האינטראקציה הזו עם הזולת לא מתאימה לאישיות שלי. זו בוודאי עוד סיבה שאני לא מתאים לעבודה בצוות.
עבודה בהיי-טק >>
לצפיה ב-'לפי מה שסיפרת עד כה, אתה לא מתאים לעבודת פיתוח בכלל...'
לפי מה שסיפרת עד כה, אתה לא מתאים לעבודת פיתוח בכלל...
19/05/2020 | 14:49
63
44
ככל שאתה כותב יותר, גובר בי הביטחון שסיפוריך מצוצים מהאצבע, אבל אני לא יכול לפסול אותך סופית רק מסיבה אחת:
 
ייתכן, שכשהתחלת לעבוד בחברה שבה אתה עובד, המוצר שלה היה ייחודי.
בלי מתחרים, גם אם המוצר שלך הוא המיץ של הזבל, אנשים עדיין ישתמשו בו כי אין משהו אחר.
 
מקרים כאלה הם סופר נדירים בתחום התוכנה.
 
אם אתה לוקח אלגוריתם מיון, ואין לך מושג מה הוא עושה, כשתגיע ללקוח לתוכנה שלך ייקח שעות למיין את הנתונים.
כאשר מתחרה שיש לו מפתח שהוא אשכרה מפתח, ולא אחד שעושה copy paste בלי להבין יוציא מוצר שממין את אותם הנתונים תוך שניות, החברה שאתה עובד בה תפשוט את הרגל, וגם אישתך המנכ"לית תלך הבית יחד איתך במהירות מסחררת.
 
אז או שבאמת נפלת על נישה שאין בה מתחרים בכלל, או שעכשיו חברה שלך מעסיקה מפתחים אמתיים ואתה שם רק בקומבינה, או שכל הסיפורים שלך מצוצים מהאצבע.
עבודה בהיי-טק >>
לצפיה ב-'זה הרבה יותר נפוץ ממה שנדמה לך'
זה הרבה יותר נפוץ ממה שנדמה לך
19/05/2020 | 15:25
62
45
בעולם מעולם היישומים, איכות הקוד וכותבי הקוד הוא הרבה פעמים פחות חשוב. יותר חשוב דברים כמו חווית משתמש, הבנת צורכי לקוח, פתרון נכון לbusiness cases  ועם החומרה של היום לפעמים אין משמעות עסקית לדברים כמו יעילות, זמני ריצה, סיבוכיות וכו'.
עבודה בהיי-טק >>
לצפיה ב-'הנהלה עסקית לא מתעניינת ב"איכות הקוד"'
הנהלה עסקית לא מתעניינת ב"איכות הקוד"
19/05/2020 | 15:55
58
44
מה גם שזה מונח פילוסופי לגמרי ועניין של טעם אישי, אבל אין סתירה בין זה לבין האפשרות לפתח מוצר מהיר, יעיל, חסכני במשאבים, וכל זאת ע"י מתכנת יחיד. יש מוצרי תוכנה מסחריים רבים שפותחו ומתוחזקים ע"י מתכנתים יחידים, שעובדים אפילו כעצמאים, והם מוצרים מעולים ומובילים.
יש הרבה דרכים לפתח תוכנה טובה, ושוב חברי הפורום צריכים להפנים שכמו שהניסיון שלהם לא מספק להם את התמונה המלאה על התהליכים שמתרחשים בחברות הייטק (כמו בכל חברה), כך הוא לא מספק להם את התמונה המלאה על מה שאפשר להשיג בדרכי עבודה שונות משלהם ועם הבנה של מקצוע התכנות, השונה משלהם.
מעבר לכך אני רואה פה ברור צורך עז של המשתתפים להגן על הדרך שלהם תוך תקיפה עלובה של מי שנראה להם שונה. זה מעיד רק עליהם.
 
עבודה בהיי-טק >>
לצפיה ב-'מסכים עם מה שכתבת'
מסכים עם מה שכתבת
19/05/2020 | 16:05
39
41
אבל זה באמת לא המצב ברוב המקומות בתעשיה. אולי זה יישמע לך מעליב אבל סוגי המוצרים והעסקים שתיארת (וכעצמאי, ראיתי הרבה כאלה) נחשבים לתחתית של התעשיה גם אם הם רווחיים.
המשרות במקומות הללו בדרך כלל לא מאוד מתגמלות, בהנחה שאתה לא בעל העסק בעצמך או נשוי למנכ"ל.
עבודה בהיי-טק >>
לצפיה ב-'אני לא נעלב ולא רוצה להעליב, זו לא אינטראקציה שמעניינת אותי'
אני לא נעלב ולא רוצה להעליב, זו לא אינטראקציה שמעניינת אותי
19/05/2020 | 16:23
6
39
אבל אציין שמי שמדרג מוצרים או קוד וקובע להם מקום "בתעשייה" כנראה עושה זאת כי יש לו צורך לשים את עצמו גבוה ביחס לאחרים, וזאת באופן מלאכותי. אז הוא אומר "כן הם רוחיים ומצליחים וקיימים כבר עשרות שנים, אבל המוצר שלהם זבל והקוד שלהם גרוע". לטעמי הדבר מעיד על חוסר הביטחון שלו בעצמו ובדרכו. מי שבטוח בעצמו לא צריך לדרג את עצמו ביחס לאחרים. אני לא מתכוון לנוכחים בדיון אלא באופן כללי.
אני ממליץ למדרגים למיניהם לזכור את הפתגם הידוע, שעם הצלחה לא מתווכחים. ואם מוצר שורד עשרות שנים כנראה שהקוד שלו מעולה ואנשי המקצוע שמאחוריו מעולים. פשוט כי הם מצליחים. ואם למדרגים למיניהם הקוד והמתכנת נראים זבל ותחתית התעשייה אז אני מציע להם לבחון שוב את קני המידה לפיהם הם שופטים עבודה של מישהו אחר ואת המקצועיות שלו.
 
 
 
עבודה בהיי-טק >>
לצפיה ב-'יש לא מעט ספרות בנושא...'
יש לא מעט ספרות בנושא...
19/05/2020 | 16:32
31
שמקשרת בין איכות הקוד לאיכות התוכנה מבחינת היכולת לתחזק אותה, כמו למשל להוסיף לה פיצ'רים חדשים בצורה שלא תגרום לבאגים במערכת.
עבודה בהיי-טק >>
לצפיה ב-'יש דירוג שקשה להתווכח איתו: הסכום בתלוש שכר'
יש דירוג שקשה להתווכח איתו: הסכום בתלוש שכר
19/05/2020 | 16:40
2
42
באופן מפתיע הסכום גבוה משמעותית במקומות שמגייסים אנשים שמתעניינים באופן שבו הקוד מתקמפל, או בשיטות למיון רשימה.
אז לא מדובר בדירוג של משתתפי הפורום אלא בדירוג שהשוק קבע.
 
אבל אני מסכים איתך שיש המון חברות שבעיניי המתכנתים אולי נחשבות "נחותות" אבל מבחינה עסקית הן הצלחה מסחררת. הרבה נכתב פה על אמדוקס למשל שכבר עשרות שנים מרוויחה מליארדים בעוד שהמוניטין של הקוד שלה הוא לא משהו בלשון המעטה.
עבודה בהיי-טק >>
לצפיה ב-'יש לי מכרה שעבדה בתור "מתכנתת" באמדוקס...'
יש לי מכרה שעבדה בתור "מתכנתת" באמדוקס...
19/05/2020 | 17:03
36
וה"תכנות" שהיא עשתה היתה שינוי של כל מיני פרמטרים בקובץ XML מסוים, שליחה שלו למחולל קוד ג'אווה- ואז לשנות פה ושם מילה בקוד שהמחולל ייצר בשבילה.
 
ממה שהבנתי פעם ממראיין בחברה אחרת שראיין "מתכנתי ג'אווה" מאמדוקס, מי שכותב פנימית את המחוללים האלו (שהם המיעוט שבמיעוט) כנראה מתכנת לא רע. אבל מי שמשתמש בהם פשוט לא יודע לתכנת. אותה מכרה שלי ידעה  שאין לה מה לחפש מחוץ לאמדוקס כמתכנתת, וכשהתפקיד שלה הועבר להודו היא פשוט הפכה למנהלת מוצר בתוך אמדוקס, בתקווה שזה יהיה משהו שהיא תוכל למצוא בו עבודה בחוץ לחברה עם ניסיון.
עבודה בהיי-טק >>
לצפיה ב-'זה דירוג לאיכות תוכנה או קוד?'
זה דירוג לאיכות תוכנה או קוד?
19/05/2020 | 17:10
39
מעבר לכך שאני לא יודע איך השכר בבתי תוכנה קטנים שמאד מצליחים - אני יודע על הבחור בן ה-57 עליו סיפרתי שישב בשנים האחרונות על 60K והמשכורת האחרונה שלו עמדה על 80K, אבל אולי זה חריג - הרי שכר הוא לא מדד יחיד לתגמול שמקבל עובד. יש עוד דברים כמו האוירה במקום העבודה והיחסים עם המעסיק, אולי ההשכלה שלו לא מספיקה להתקבל למקומות שציינת, אולי כן מספיקה וניסה להתקבל אבל התחרות והראיונות התישו אותו ובבית התוכנה הזה הוא התקבל בלי זיוני שכל, אולי בית התוכנה בו מצא עבודה נמצא 5 דקות מביתו, אולי תחום העבודה יותר מתאים לו. כל אלה לא משליכים על הרמה שלו כאיש מקצוע ועל רמת הקוד שהוא או היא יוצרים.
 
עבודה בהיי-טק >>
לצפיה ב-'אתה אוהב מטפורות נכון?'
אתה אוהב מטפורות נכון?
19/05/2020 | 17:33
1
33
אסבסטוס שרד עשורים בשימוש ועשה היטב את עבודתו בהגנה מפני שרפות.
 
עד שגילו שהוא מאוד מסרטן, ובין לילה כל התעשייה הזו התנדפה, ואנשים השקיעו מליונים בהוצאת אסבסטוס ממבני מגורים.
 
שמעת פעם על DDT?
נפנפו בו כפתרון מהפכני לבעיית היתושים, ואמרו שהוא יעזור למגר מלריה.
ואז גילו שיש לו השפעות על הסביבה ובני אדם כ"כ חמורות, שכבר עדיף את היתושים.
 
כשאני התחלתי לעבוד בפיתוח תוכנה, החברה שבה עבדתי פיתחה לפלטפורמה של Microsoft, והשתמשה אך ורק בכלים של Microsoft.
 
אם היית אומר באותם שנים שחברת ענק כמו MS תוכל בין לילה להיזרק משוק מסוים, היו צוחקים לך בפרצוף, ואומרים שאתה הזוי!
מה זה משנה כמה המערכת שלהם גרוע? זו חברה ענקית, ורווחית, והיא שולטת בכל שוק שהיא נכנסת אליו, ובלא בלא בלא...
 
ואז הגיע שנת 2007, ו-Apple יצאה עם iPhone.
ושנה אחרי, Google הוציא את Android.
 
ושנה אחרי, ב-2009, אף אחד חוץ מכמה אספנים כבר לא החזיק במחשב כף יד או טלפון חכם מבוסס מערכת של Microsoft.
 
למזלי, המנהלים במקום בו עבדתי ידעו טוב מאוד לבדוק לאן הרוח נושבת, ובהחלט דירגו מי נגד מי ולמי יש מוצר מנצח, והחכימו מהר מאוד להסב את המפתחים ואת מוצרי החברה לפלטפורמות החדשות.
 
אם הם היו חושבים כמוך, כל עובדי החברה היו גומרים ברחוב, ואולי גם הבעלים של החברה.
 
אבל כאמור, זה לא קרה.
 
מוגש כחומר למחשבה.
עבודה בהיי-טק >>
לצפיה ב-'יש את הסרטון הידוע של סטיב באלמר שנשאל על האייפון...'
יש את הסרטון הידוע של סטיב באלמר שנשאל על האייפון...
19/05/2020 | 17:36
38
והוא צחק על זה שלאייפון אין מקלדת, וממש היה בטוח שהמוצר של מייקרוסופט טוב יותר משמעותית.
עבודה בהיי-טק >>
לצפיה ב-'אתה מסכים שאיכות הקוד זה עניין פילוסופי?'
אתה מסכים שאיכות הקוד זה עניין פילוסופי?
19/05/2020 | 17:22
31
11
לצפיה ב-'כתוב בויקיפדיה'
כתוב בויקיפדיה
19/05/2020 | 17:46
30
38
למוצר איכותי שתי פרשנויות:
סובייקטיבי – התלוי בעיני המתבונן, כתוצאה מתפיסת המוצר בתודעתו ממניעים פסיכולוגיים.
אובייקטיבי – נקבע על ידי תקן רשמי, שיעור העמידה במפרט הטכני (על-פי ההגדרה).
 
גם אם תגיד שיש אכיפה של תקן קוד רשמי, זה לא המדד של איכות הקוד שאתה מדבר עליו. אפשר לכתוב קוד מיושר, פונקציות קצרות וכו' אבל עובדות בצורה מזעזעת. כל השאר הוא אכן פילוסופי או ליתר דיוק בעיניי המתבונן.
זה לא אומר שאין דבר כזה איכותי ולא איכותי. רובינו כאן בפורום אפילו יסכימו על דברים שייחשבו כ"לא איכותיים" אבל בהגדרה, זה עדיין בעיניי המתבונן וגם אתה יודע טוב מאוד שבין השחור והלבן יש המון באמצע וכל code reviewer שיסתכל על הקוד יגיד לך משהו אחר.
עבודה בהיי-טק >>
לצפיה ב-'זו לא רק אכיפה של תקן.'
זו לא רק אכיפה של תקן.
19/05/2020 | 19:56
24
הפסקה מדבר את מצב בינארי - איכותי מול לא איכותי.
 
אני מסכים שאם עושים קביעה כזו, זה נתון לפרשנות הקובע.
אבל, בפועל איכות היא דבר יחסי, היא ספקטרום, ומדידה על הספקטרום הזה היא אבסולוטית, לפחות כשזה נוגע למוצרים הנדסיים כגון מכונות או קוד.
 
אני מסכים שיש ממד פסיכולוגי לאיכות שנתפסת בעיני מקבל המוצר, או אפילו איכות שנתפסת בעיני מי שעושה קוד רוויו, אבל כמו לכל מוצר הנדסי לקוד יש גם מדדי איכות אבוייקטיביים שאינם בהכרח קשורים לתקן, ואין בהם שום מקום לפילוסופיה.
 
עובדתית, אם התוכנה קורסת בפעולה סטנדרטית, לא תוכל לטעון שהקוד איכותי.
 
כמובן, לקוד יש כמה אספקטים, ולכל אחד מדד איכות משלו, אבל זה עדיין לא "פילוסופיה".
זה בחינה של מוצר הנדסי ממשי.
 
בדיונים בפורום השכן, יש מספר אנשים שאוהבים לנצל טענות בנוסך "זה פילוסופיה", "זה הכל בעיני המתבונן", "זה עניין של פרשנות" כדי לפסול ראיות מוחשיות, או לנגח תאוריות מדעיות מבוססות, מבלי שיש להם שמץ של ידע אמתי בנושא או ראיות נגדיות.
 
זו מאין שיטה של "תייצר ספק, תגרום לצד השני להודות שאין 100% וודאות, ומזה תסיק שהצד השני טועה לגמרי ואתה צודק".
 
אני מרגיש שגם כאן יש משתתף שמנסה לשפר את מעמד התוצר שלו (אם בכלל יש לו תוצר) ע"י טענה שאין אפשרות למדוד איכות של קוד.
טענה שאני לא מקבל לחלוטין, ואני בספק אם אתה תקבל אותה.
 
אני בטוח שבחייך ראית מספיק קוד כדי לדעת מה הם סממנים מובהקים לקוד רע, ושלא תמצא לא רק כאן בפורום, אלא בתעשייה הרחבה שיצא לך להכיר הרבה יותר ממני, אנשים שיתווכחו שאלה לא סממנים לקוד רע.
 
למעט כמובן משתתפים שמחפשים להטריל.
 
אני אתן לך דוגמה מוחשית:
מפתח אחד עשה טעות, כנראה תמימה ביותר, וכתב קוד שמחלץ קובץ דחוס בלולאה בית אחד בכל פעם.
 
התוצאה היית שקובץ שעבוד שלו שהיה אמור להסתיים תוך דקה בערך לקח יותר משעתיים עבודה.
 
האם לדעתך יש מקום להתפלסף על איכות של קטע קוד מסוים זה?
עבודה בהיי-טק >>
לצפיה ב-'אני אתן לך כמה דוגמאות לאכיפת תקן רשמי'
אני אתן לך כמה דוגמאות לאכיפת תקן רשמי
19/05/2020 | 21:08
27
35
כיסוי קוד בUT - מדד פשוט ואכיף שיכול לבדוק שהUT שלך מבצע כל שורת קוד. זה לא כיסוי מספיק, כמובן, אבל זה אחד המדדים הבסיסיים שהכי קל ליישם.
 
סיבוכיות הקוד - אחד המדדים הראשונים שהומצאו אי שם בשנות ה70 שנותן ציון לכמה קל לבדוק את הקוד שלך. ככל שסיבוכיות הקוד נמוכה יותר ככה יותר סביר שתוכל לבדוק את כל האפשרויות בתהליך הבדיקות. זה בדרך כלל מתקשר עם מדדי כיסוי של UT כי מעבר לבדיקות יחידה כיסויי בדיקות מלא כנראה לא יהיה סביר.
 
מדדי ביצועים - למשל benchmarking, או שינויים במדדים בעבקות שינויים בקוד (שינוי נפח קוד, שינוי זכרון נדרש, שינוי בlatency, וכד׳).
 
אלה דוגמאות למדדים אובייקטיביים. זה לא רק קוד מיושר או מספר שורות קוד בפונקציה. את כל המדדים האלה אפשר ליישם בקלות. יש עוד הרבה מדדים שונים שיהיה קצת יותר קשה ליישם אבל גם אפשרי (למשל - כמה זמן לוקח להכניס שינוי בקוד? כמה זמן לוקח לעשות roll-out לפרודקשן? כמה זמן לוקח לתיקון באג ממוצע? וכו׳ וכד׳).
 
אם תשאל אותי, זה נראה שקלייטון מעולם לא נתקל באף אחד מהמדדים האלה. מה איתך?
עבודה בהיי-טק >>
לצפיה ב-'אכיפה באיזה מובן?'
אכיפה באיזה מובן?
20/05/2020 | 00:24
10
27
אם במובן של רשות כלשהי אז אני לא יודע איך זה בקליפורניה אבל בישראל אין שום אכיפה בתחום פיתוח התוכנה.
וטוב שכך כי כל אכיפה תחנוק את המקצוע ותביא לחיסולו.
עבודה בהיי-טק >>
לצפיה ב-'אכיפה במובן של דרישות לקוח/פנימיות'
אכיפה במובן של דרישות לקוח/פנימיות
20/05/2020 | 02:20
9
23
תלוי במוצר, חלק מהמדדים האלה יבדקו על ידי גורמים חיצוניים/לקוחות. למשל בתחום תחבורה, רפואה, ניהול מערכות גדולות (כמו למשל ניהול תחנת כוח או רשת תקשורת), יש רשויות (גם בארץ וגם בכל שאר העולם) שיבדקו גם את המוצר שלך וגם את תהליכי הפיתוח שלך.
 
במקרים בהם זה לא מחוייב על פי חוק, עדיין יש דרכים לאכוף את זה. למשל, כל מיני תקני איכות של ISO שכדי לקבל אותם צריך לעבור ביקורת תהליכים. בחברות ציבוריות יש וועדת ביקורת של הדירקטורים שיכולה לדרוש מעקב אחרי מדדי איכות של המוצרים.
 
אבל מה שהכי חשוב זה הביקורת הפנימית בתוך הצוות. למשל במסגרת code review, כלים אוטומטיים במסגרת הcontinuous build, מעקב אחרי המדדים בידי ראשי צוותים ומנהלי הבטחת איכות, וכד׳. זה חלק מניהול צוות פיתוח ומחלקת פיתוח, וכמו שבכל מפעל ייצור יש הבטחת איכות גם אם החוק לא מחייב עמידה בתקנים רשמיים - כך צריך להיות גם בצוותי פיתוח תוכנה. כי בסופו של דבר אם אתה מאבד נתח שוק כי לאפליקציה שלך לוקח שניה יותר להפתח מהמתחרים שלך - אתה זה שתשאר בלי העבודה.
עבודה בהיי-טק >>
לצפיה ב-'הבנתי, אבל זו לא "אכיפה" שונה מכל הגדרת דרישות'
הבנתי, אבל זו לא "אכיפה" שונה מכל הגדרת דרישות
20/05/2020 | 02:44
8
22
אם הלקוח הוא מזמין של פיתוח עבורו הוא בהכרח מכתיב דרישות שונות, ואם הוא רוצה להכתיב מתודולוגיות פיתוח, ומוכן לשלם, ובית התוכנה מוכן לסבול שהלקוח אומר לו איך לעבוד, אז האפשרות הזו נתונה לו. הוא יכול להכתיב גם שיטות פיתוח שגויות בדיוק כפי שלקוחות מכתיבים דרישות שגויות, ואחר כך משנים את דעתם לעיתים מהקצה לקצה. אחרי הכל מגדירי הדרישות אצל הלקוח הם בני אדם כמו כולם והם יכולים לטעות כמו כולם.
גם מנהל צוות יכול וצריך להכתיב לחברי הצוות שיטות עבודה. אם יש שיטה זו או אחרת שמישהו אחר פיתח והמנהל מאמין שהיא טובה, אז בהחלט שישתמש בה. עצם העובדה שיש צוות מייצרת בעיות ואתגרים שלא קיימים אצל מתכנת יחיד אז מובן שצריך להפעיל כלים נוספים.
 
אבל אין בזה שום דבר אובייקטיבי. זה עדיין הכל ענין של טעם וגישה ופילוסופיה. גם אם היא של גורם טכני אצל הלקוח (שבעצמו כנראה עשה מעט מאד פיתוח, אחרת היה מפתח בעצמו ולא מזמין בחוץ), וגם אם היא של ראש צוות או מנהל פיתוח.
 
עבודה בהיי-טק >>
לצפיה ב-'תלוי מי זה הלקוח'
תלוי מי זה הלקוח
20/05/2020 | 03:03
7
20
אם הלקוח שלך הוא צה״ל - אז כן, תקבל מסמך מפורט של כל הדרישות והמדדים ותראה חבר׳ה במדים מסתובבים אצלך במשרד ונוברים לך בקוד.
 
אם הלקוח שלך זה משתמש קצה שקונה את האפליקציה שלך בappstore - אין לו מושג וחצי מושג מהדברים האלה ולא איכפת לו. הוא רק רוצה שלא יציגו לו פורנו בזמן שהוא עושה שיחות ועידה של הילדים עם סבתא.
 
ויש הכל בין לבין.
 
בסופו של דבר - זה עניין של חינוך וניהול נכון של תהליך הפיתוח. אם הלקוח בכלל צריך להגיד לך שאתה צריך מדדי איכות - אתה כבר בבעיה. זה לא ״מתודולוגיות פיתוח״, זה פיתוח. מתודולוגיות פיתוח זה אג׳ייל מול מפל מים, זה מסמך דרישות לפני מסמך דיזיין או לא, זה סטאנדאפ יומי או לא. בכל המתודולוגיות פיתוח אתה צריך בסופו של דבר לייצר מוצר ואתה צריך בסופו של דבר לדעת למדוד ולהעריך את איכות המוצר. אתה צריך לקוח שיגיד לך את זה? מה קרה לך?
עבודה בהיי-טק >>
לצפיה ב-'הלקוחות שלנו מקבלים מוצר מדף'
הלקוחות שלנו מקבלים מוצר מדף
20/05/2020 | 03:30
6
26
יש מערכות שולחניות ויש מקוונות אבל בכל מקרה המערכת מוכנה והלקוח רוכש זכויות שימוש, וחבילת תמיכה. ללקוח שלנו אין אפשרות לייעץ לנו איך לעבוד, כפי שאין לו אפשרות לייעץ למיקרוסופט או לגוגל איך לעבוד.
 
עבודה בהיי-טק >>
לצפיה ב-'נכון, אין לך אפשרות לייעץ למייקרוסופט איך לעבוד'
נכון, אין לך אפשרות לייעץ למייקרוסופט איך לעבוד
20/05/2020 | 05:36
5
27
אבל ראית את הצגת חלונות 98? רענן את זכרונך: https://www.youtube.com/watch?v=IW7Rqwwth84
 
אני לא ממש מבין מה הטענה שלך.  אתה מנסה לטעון שאסור לראיין אותך וצריך להעסיק אותך רק על סמך מילתך שאתה יודע דברים ויודע ללמוד דברים. אתה טוען שאסור לשאול אותך על הבנת בעיות ופתרונות וצריך פשוט להאמין לך בלי שום אסמכתא.
 
כשאתה רוכש מוצרים - איך אתה בודק את איכותם? המוכר אומר לך ״סמוך עליי״ ואתה מה, סומך עליו?
עבודה בהיי-טק >>
לצפיה ב-'הדיון בכלל לא על ראיון איתי'
הדיון בכלל לא על ראיון איתי
20/05/2020 | 06:08
4
22
הדיון הוא על השקפת העולם שלי בנושא פיתוח תוכנה מול השקפת העולם שאתה מייצג פה. 
אני לא יכול לבדוק שום דבר שאני רוכש. המוכר גם יכול להגיד לי מה שהוא רוצה, אני בין כה וכה לא מתעניין במה שיש לו להגיד מעבר למחיר. כשאני רוכש מוצר מדף אני מניח שהוא בסדר כי נמכרו ממנו עוד עשרות אלפים או מיליונים, והיצרן כבר טיפל בבעיות העיקריות. לא בטוח אבל זה סביר. מעבר לכך כל דבר תמיד יכול להתקלקל. יש אחריות, יש שירות, ומקסימום נזרוק את זה וניקח מוצר של מישהו אחר (שבין כה וכה יכול לסבול מאותן צרות).
עבודה בהיי-טק >>
לצפיה ב-'אבל אתה טוען שלא צריך לטפל בבעיות'
אבל אתה טוען שלא צריך לטפל בבעיות
20/05/2020 | 06:18
3
20
אתה היצרן. ואתה טוען שאתה מוכר מוצר מדף ולכן הלקוח לא יכול להכתיב לך כלום - יקנה או לא יקנה, לא בעיה שלך. אתה טוען שזה מוצר מדף. אתה לא יכול להכתיב למייקרוסופט וגוגל, זוכר שאמרת?
 
למה שהם יתקנו משהו, אם כך? ולמה שהם בכלל ידעו שהם צריכים לתקן משהו?
 
מה עם אחריות - אתה בודק אם למוצרים יש אחריות? לא לוקח אותו למבחני בדיקה? לא בודק ביקורות של קונים אחרים? לא משווה מוצרים של מתחרים? לא בודק התאמה לדרישות שלך? בשום צורה? אתה מחליט ״אני קונה טלויזיה״, שם מכסה עניים ונכנס לחנות אקראית ברחוב ולוקח טלויזיה אקראית מהמדף וזהו? כך אתה קונה?
עבודה בהיי-טק >>
לצפיה ב-'איפה טענתי דבר כזה?'
איפה טענתי דבר כזה?
20/05/2020 | 07:38
2
19
ברור שצריך לטפל בבעיות. אחרת הלקוח  יחזיר את המערכת או לכל הפחות לא יחדש חוזה תמיכה. שלא לדבר על כך שלקוח לא מרוצה נוהג להפיץ את חוסר שביעות הרצון שלו (אבל לקוח מרוצה שותק) ולכן עדיף שהלקוחות יהיו מרוצים.
מה שאמרתי שאי אפשר להכתיב זו צורת העבודה. אני אטפל בבעיות אבל בדרך שלי ולא לפי שיטות העבודה של הלקוח. וכך גם מיקרוסופט.
(אני לא קונה טלויזיות אבל קניתי לפני 10 שנים מכונת כביסה. נכנסתי לחנות החשמל הראשונה שראיתי ברחוב, אמרתי בערך מה הסכום שיש לי להוציא, סיפר לי על דגם שמתאים למחיר אבל אין לו בחנות. שילמתי, סגרנו אספקה, המכונה הגיעה, ועובדת עד היום)
 
עבודה בהיי-טק >>
לצפיה ב-'הא, אז יש חוזי תמיכה?'
הא, אז יש חוזי תמיכה?
20/05/2020 | 09:14
1
26
אני מכיר חוזי תמיכה. הם מדברים על מדדים כמו זמן בין תקלות, מינימום זמינות, זמן תגובה לתלונה, הגדרות של מחזור טיפול בתקלות, אתה יודע, דברים ש... נמדדים?
 
וודאי שאתה תטפל בבעיות בדרך שלך. אבל תהיה דרך, והיא לא תהיה "סמוך עליי".
 
או שזה מה שכתוב לך בחוזי תמיכה? "סמוך על קלייטון, יהיה בסדר"?
 
ובדוגמא של מכונת הכביסה היה לך... מדד. הכסף. משהו שמאפשר לך לשים מספר על המוצר ולבדוק התאמה לסף שקבעת.
עבודה בהיי-טק >>
לצפיה ב-'לא, חוזי התמיכה אצלנו מספקים רק שני דברים'
לא, חוזי התמיכה אצלנו מספקים רק שני דברים
20/05/2020 | 09:32
23
את הזכות לקבל עדכונים (במערכות המקוונות יש מודל אחר של הרשאות גישה) ואת האפשרות (בהתאם לחוזה) לקבל תמיכה מנציג תמיכה. מיעוט קטן מהמשלמים עבור האפשרות לקבל תמיכה מנציג מגיעים אי פעם למצב שהם צריכים אותה, וזו הסיבה העיקרית שהעסק הזה כל כך רווחי. זה אותו מודל של החברות שנותנות שירות תיקונים למכשירי החשמל בבית תמורת תשלום שנתי, כאשר בדרך כלל שום דבר לא מתקלקל, ורוב הלקוחות שילמו על שום דבר. רק שפה המוצר שמבוטח הוא מערכת תוכנה.
 
לא בדקתי שום דבר לגבי המכונת כביסה, אפילו לא ראיתי את הדגם. לא חיפשתי אם אפשר להשיג את אותו דגם יותר בזול במקום אחר. כל המהלך לקח לי 10 דקות, מהרגע של הכניסה לחנות ועד ליציאה ממנה. מכונת כביסה כמו טכנולוגיות רבות אחרות בחיינו היא דבר רגיל שסביר מאד שהיא תעבוד, שהמחיר שלה בחנות זו דומה מאד למחיר בכל חנות, בהפרשים שלא כדאי לבזבז עליהם אנרגיה. אלה דברים שצריך לתת בהם אמון כי אי אפשר לבדוק כל דבר ודבר בחיים. המשאבים שיבוזבו על הבדיקות האלה יכולים להועיל במקום אחר. יכול להיות שנטעה ואפילו נפסיד אבל בדרך כלל יהיה בסדר. וגם אם נפסיד נתאושש מזה.
 
עבודה בהיי-טק >>
לצפיה ב-'המדדים האלה אובייקטיביים אבל בדרך כלל לא מה שמתכוונים אליהם'
המדדים האלה אובייקטיביים אבל בדרך כלל לא מה שמתכוונים אליהם
20/05/2020 | 08:31
15
26
כיסוי קוד בUT למשל. יש את בדיקות האחוזים, הרבה פעמים היא חסרת משמעות. ראיתי מערכות עם טסטים מצויינים שכיסו 60% ומערכות דפוקות עם כיסוי של 90%. זה כמו למדוד מתכנת לפני מספר שורות שהוא כותב בחודש. מוטב טסט שבודק לוגיקות ומצבים שחשובים למוצר מאשר טסט שנכנס לכל שורת קוד עם אינפוט בנאלי.
מדדי בנצ'מרק רלוונטיים לחלק קטן מהפרוייקטים. רוב מתכנתי שפות VM לא טורחים לעשות בדיקות של שינוי נפח קוד, זכרון ודברים כאלה אלא אם כן יש סיבה מיוחדת.
נשאר סיבוכיות שזה אכן משהו שמעיד על איכות וגם נהוג לבדוק בreview ובשלבי הפיתוח השונים (דיזיין וכו').
 
שאר הקריטריונים לאיכות הם דברים פחות מדידים:
טיפול בכל המצבים האפשריים בקוד.
חשיבה לטווח ארוך. מודולריות: כמה מסובך יהיה להחליף רכיבים איפה שצריך (בלי לעשות absuse לקוד), למצוא בעיות בסביבת ייצור. קוד קריא, שימוש בסטנדרטים, וכן גם המילה המקוללת: שימוש בפרימוורקים ובדפוסים מוכרים.
עבודה בהיי-טק >>
לצפיה ב-'אתה טועה.'
אתה טועה.
20/05/2020 | 09:07
14
25
כמובן שהמספר עצמו לא קדוש, אבל מערכות דפוקות עם 90% כיסוי יהיו דפוקות יותר ממערכות עם 100% כיסוי. מערכות עם 60% כיסוי - מה זה משנה שהטסטים מצויינים אם הם מכסים בקושי חצי מהקוד? מה עם השאר, מדוע לא צריך לכסות אותו גם בטסטים מצויינים?
 
זה לא כמו לספור שורות כי לספירת שורות אין משמעות ולטסטים יש. גם אם לא בדקת את כל המצבים הלוגיים (ויש מדדי כיסוי גם לזה, יש מדדי כיסוי לולאות, מדדי branching, וכו' וכד', אני יכול לתת לך הרצאה שלמה על זה, זה משהו שאני יודע טוב מאוד), עדיין בדקת שכל שורת קוד רצה לפחות פעם אחת. אתה יודע כמה באגים מצאו בצוות שלי רק כי אני מתעקש שכל שורת קוד תרוץ בטסטים? וזה עוד לפני שמגיעים לבדיקות אינטגרציה וend to end.
 
רוב מתכנתי שפות VM לא טורחים לעשות בדיקות של שינוי נפח? לא יודע מי אמר לך כזאת שטות, יש לנו מלא אפליקציות מובייל בחברה ואחד מהדרישות לפני שגרסה חדשה יוצאת לפרודקשן זה אודיט של הfootprint וכמה זכרון האפליקציה זוללת. אם אתה מתכוון לאוכלוסיה רחבה עם מכשירים מכל הסוגים אתה צריך להתאים את עצמך לשוק ולבדוק אם האפליקציה שלך בכלל תעלה על האנדרואיד הצ'וקומוקו בזימבבווה שעלה 20 דולר ביבוא מסין.
 
הדברים הנוספים שאתה מדבר עליהם מדידים. כמו שאמרתי, אם אתה בודק כמה זמן לוקח לך להכניס שינויים, כמה זמן לוקח לך לתקן באגים, כמה זמן לוקח עד שהעובד החדש נהיה פרודוקטיבי - אלה גם מדדים לבדוק. אולי לך עם צוותים קטנים ולקוחות קטנים זה לא ישים, אבל בחברה בה אני עובד עושים את זה כל הזמן. אם יש קוד שכל עובד חדש צריך ללמוד אותו חצי שנה, אם יש קוד שכל פעם שיש איזה באג או איזה פיצ'ר קטן צוות שלם צריך לעבוד חודש - אז זה לא קוד איכותי והוא ישוכתב. למעשה, לא מזמן סיימתי פרוייקט שכתוב כזה. לקח לצוות שלי שנתיים ועדיין חסכתי שנות אדם תוך כמה רבעונים.
 
זה פשוט קנה מידה שאתה לא מכיר כנראה.
עבודה בהיי-טק >>
לצפיה ב-'טוב, בסדר'
טוב, בסדר
20/05/2020 | 09:34
13
24
אתה לוקח את מקום העבודה שלך ומשליך אותו על כל השוק. מספיק שתראה שבחנויות האפליקציות, עדכוני תוכנה אקראיים מכפילים ומשלשים את הנפח וכנראה שכולם חיים עם זה בשלום. יש מקומות שבודקים ברמת הבייט, ויש מקומות שבהוספת dependency מתווסף עוד 7 MB וזה לא מזיז לאף אחד. הדרישות של המשתמשי מובייל הן בעיקר זלילת סוללה, ומהירות. כל עוד אין חריגות גדולות, לא טורחים להתעסק יותר מדי בדברים שהזכרת.
 
לגבי הטסטים: אתה טועה. בשפות מסויימות יש הרבה boilerplate קוד. למשל אלפי קלאסים שטוחים של get וset והם נכנסים לסטטיסטיקה של הכיסויים. גם תרחישים כמו catch() - > logError נכנסים לזה. הרבה אובייקטי פרוקסי חסרי לוגיקה שרק קוראות לשכבות תחתונות, ועוד ועוד. באחוזים, יש מקומות שזה מנפח את הקוד ומשפיע על תוצאות הכיסוי.
 
זה מזכיר לי סיפור: נתקלתי במשרד הפתוח שאני שוכר בו באיזה מתכנת סיילספורס מתוסכל. מסתבר שכדי להעלות קוד לSF, צריך שיהיה לו כיסוי טסטים באחוז מסויים. היה לו קוד ענק שעוטף מאות קריאות לפונקציות והוא נאלץ לעשות עבודת נמלים. עזרתי לו לרמות ולכתוב פרוקסי שמייצר טסטים בצורה אוטומטית וקורא לכל הפונקציות.
התוצאה: כיסוי של 100% עם אפס בדיקות אמיתיות.
אני מבין שבחברה שלך זה היה מתקבל כהצלחה מסחררת. אכן, מאוד אמריקאי.
עבודה בהיי-טק >>
לצפיה ב-'למה אתה קורא "בדיקות אמיתיות"?'
למה אתה קורא "בדיקות אמיתיות"?
20/05/2020 | 09:53
12
21
טיפול בשגיאות לא צריך לבדוק בעולם שלך? דווקא בנקודות הכשל יש בדרך כלל הכי הרבה באגים כי מתכנתים נוטים להתרכז בhappy path. לבדוק שset אכן שומר נתון וget אכן מאחזר אותו לא צריך? אתה לא תאמין, אנשים טועים גם בזה!
 
וכן, אם יש לך תבניות קבועות - תבנה test factory, אדרבא - זה מצוין! יש לך תבניות של קלאסים עם מלא getters/setters - תייצר טסט עם פרמטרים שכל מה שאתה צריך זה להכניס לו שם של מחלקה והוא יעבור על כולם בreflection, אז מה? למה אתה חושב שלא צריך לבדוק את זה? ואחרי זה תרוץ אחרי איזה באג איזוטרי כי במצב שגיאה התוכנה שלך נכנסת לאיזה מקום בוא יש getter שהsetter שלו אף פעם לא נבדק ומישהו כתב שם "==" במקום "=".
 
אתה בעצם אומר אותו דבר כמו קלייטון - "סמוך עליי". למה? זה לא קשה לכתוב טסטים, אם כותבים כמו שצריך, ויש מלא כלים בשביל לעשות את זה יעיל ומהר, לא צריך שזאת תהיה עבודת נמלים. זה פשוט תרבות אחרת.
עבודה בהיי-טק >>
לצפיה ב-'סיפור אמריקאי אחרון שימחיש את הרעיון'
סיפור אמריקאי אחרון שימחיש את הרעיון
20/05/2020 | 10:06
11
25
לפני כמה שנים טסתי בטיסת פנים אמריקאי כחלק מרודשואו להצגת המיזם שלי לעיתונאים. משהו שחברת הPR ארגנה.
המוצר היה סוג של רובוט ונסעתי עם אבטיפוס שהודפס בתלת מימד, כלל לוחות אלקטרוניים, חיישנים, חוטים מכל עבר וסוללת ליתיום גדולה של 20,000 מילי. חששתי לקראת הבידוק בעליה לטיסה ואסור לשלוח סוללה כזאת לבטן המטוס. המאבטח האמריקאי ביקש שאחלוץ נעליים. התחלתי להסביר לו שבשיקוף כרגע עובר רובוט, שלא ייבהל, אבל הוא רק שאג עליי "take off your shoos sr". אחרי עוד סבב כזה כשהיה נראה שהוא עומד לשלוף נשק, הורדתי את הפאקינג שוס שלי ועברתי. הוא בחן אותי בדקדקנות בשער בזמן שבשיקוף התעלמו מהמטען. אולי יכולתי להעביר רימון יד או נשק גרעיני, לא יודע אבל העיקר שהורדתי נעליים.
ברכבת ישראל לעומת זאת המאבטחים דרשו שאדליק ואפעיל את המוצר. אולי זה היה לשם השעשוע אבל הם עשו בדיקה "אמיתית" למרות שלא היה כיסוי מלא (לא הורדתי נעליים).
עבודה בהיי-טק >>
לצפיה ב-'מה זה קשור?'
מה זה קשור?
20/05/2020 | 10:17
9
22
מאבטחים של הTSA זה המיץ של הזבל, מה אתה משווה אותם למאבטחים של הרכבת... יותר בכיוון של "פותחת תיק בבקשה", וגם זה כנראה מחמאה עבורם.
 
אנחנו מדברים על הנדסה והבטחת איכות. היה פורום שלם לנושא פה בתפוז שבזמנו הייתי די פעיל בו אבל לצערי הוא כבר מזמן ננטש. זה תחום התמחות שלם, וכן - אני יודע שלהרבה מתכנתים זה נראה מוזר, קלייטון לא היחיד שחושב ש"מה פתאום שמישהו יגיד לי איך לעבוד", אבל יש מחקרים גם בתחום הזה, יש מדדים, יש השוואות, ויש שיטות מוכחות שאכן מביאות להקטנת הקצאת הזמן לתחזוקה כי הבעיות נתגלות בשלבים הרבה יותר מוקדמים.
 
וכן, אני לא מתווכח איתך לגבי המשמעות של מדד כיסוי שורות ושזה לחלוטין לא מספיק ואפשר להגיע ל100% כיסוי ועדיין להיות עם קוד מחורבן. אבל כשזה קורה, הקוד שלא היה מגיע ל100% יהיה בקנה מידה יותר גרוע!
עבודה בהיי-טק >>
לצפיה ב-'הקשר הוא שיכול להיות מתכנת "המיץ של הזבל" שמכסה 100% בדיקות'
הקשר הוא שיכול להיות מתכנת "המיץ של הזבל" שמכסה 100% בדיקות
20/05/2020 | 10:24
1
8
לצפיה ב-'בהחלט'
בהחלט
20/05/2020 | 10:35
22
ויכול להיות מתכנת שלא יזהה באג גם כשהוא עובר מולו במכונת שיקוף. גם יכול להיות. אז מה?
 
מה שכן הוא, המתכנת "מיץ של הזבל" שמכסה 100% בדיקות כן יתפוס את באג האחד במליון שהחביא סכין יפנית בנעל.
עבודה בהיי-טק >>
לצפיה ב-'אני חושב שמרוב הניסיון להיות נחמד, user מפרש את דבריו של'
אני חושב שמרוב הניסיון להיות נחמד, user מפרש את דבריו של
20/05/2020 | 10:52
6
27
קלייטון בצורה חיובית ושפויה, במקום ההטרלה שהם, ולכן הוויכוח בניכם, כפי שאני רואה אותו מהצד, הוא בין "מצוי לרצוי", ולא באמת בין "איכותי ולא איכותי".
 
מצד אחד, יש הרבה מוצרים שלא עושים שום דבר ממה ש-vinney כתב, ומצליחים לשמור על איכות מספקת ברמת התוצר הסופי.
 
יש מתכנתים שמצליחים לייצר קוד איכותי גם בלי שיש כלים שבודקים אותם.
 
בכל מוצר תמיד יש פשרות בנושא איכות, בדיקות, וכו'.
 
אבל, וזה אבל גדול, זה לא אומר שאנחנו צריכים להתעלם מכל מדד איכות של מתכנתים, קוד, ותוצר סופי לגמרי, ולומר שדין אפליקציה מ-"החצר האחורית" עליה דיבר user הוא כדין אפליקציה מאחד הצוותים המובילים של Google.
 
וזה מה שקלייטון בעצם טוען פה - הוא לא רוצה שימדדו את האיכות שלו ושל הקוד שלו, אז הוא מנסה לשכנע שלא צריך, ואולי בעצם אי אפשר, למדוד איכות בכלל.
 
פעם יצא לי להיות מעורב בתהליך פיתוח אפליקציית מובייל עבור חברת ביטוח בארה"ב.
בניגוד לחברות בארץ, הם התעקשו שהאפליקציה תהיה מאובטחת, ואשכרה הכריחו אותנו להגיש את כל הקוד לחברה חיצונית, שכל התפקיד שלה הוא לבצע רוויו אבטחה לא רק בצורה של black box אלא גם בצורה של white box.
 
היית סמטוחה לא קטנה להעביר את הפרויקט שיתקמפל בסביבת בדיקות שלהם כי הם לא היו ערוכים לפרויקטים של Android.
ואז גם הסתבר שהם לא כ"כ מכירים Java ולכן ניסו לבחון אותנו כאילו אנחנו #C.
 
מצד אחד אפשר לומר: מי אתם שתגידו לנו איך לפתח?
זה מה שקלייטון היה עושה, ולא היית עסקה עם חברה ענקית בארה"ב.
 
מצד שני, אפשר לוודא שאתה לא עושה שטויות כמו לשמור את ה-credentials ב-shared preferences אפה שכל אחד יכול לגנוב אותם, ואם וכאשר החברה הבודקת אומרת לך לא להחזיק מידע רגיש במשתנה מסוג מסוים כי אז הוא יישאר בזיכרון לעד, אתה מספק לה תיעוד שהחלופה המאובטחת שיש ב-#C לא קיימת ב-Java, ומכל המקבילות מה שבחרת זה הכי סביר.
 
אז כן, זה דורש מתכנת אמתי, מתכנת שאולי עומד בכמה מדדים, אבל בסוף המטרה של העסק זה להרוויח, לא?
 
אני עדין לא מבין איך אנשים וותיקים בתעשייה מסכימים עם יציאות הזויות של אדם שבעצם אומר:
 
אני מתכנת וותיק שלא יודע ולא מבין, וגם לא רוצה לדעת ולא להבין שום דבר מעבר למינימום הכי קטן שהיה נחוץ לפני 30 שנה כדי להעמיד איזשהו קוד עובד.
 
אני לא מוכן שמישהו יבחן אותי בשום דבר ואני לא מוכן לעבוד בשום שיטת עבודה חוץ מזו שלי, אבל סמוך עלי, לא משנה איזו עבודה תתן לי אני אעשה אותה במהירות ויהיה לך מוצר מצוין שתוכל למכור ולהרוויח.
 
אני כבר מעדיף את הוויכוחים הפוליטיים מול וויני, מאשר לדון ברצינות בהצהרות כאלה
עבודה בהיי-טק >>
לצפיה ב-'שטחים תמורת שלום עכשיו!'
שטחים תמורת שלום עכשיו!
20/05/2020 | 11:01
25
לצפיה ב-'עזוב רגע את קליטון. הדיון התגלגל לנושא די מהותי'
עזוב רגע את קליטון. הדיון התגלגל לנושא די מהותי
20/05/2020 | 11:26
4
31
הנושא הוא הגדרת ומדידת איכות קוד. זה נושא ראוי לדיון.
 
אני טוען שהמדדים האובייקטיביים וביניהם אחוז כיסוי טסטים, הם פחות חשובים מאשר מדדים סובייקטיביים כמו דברים שרואים ב code review ושמכונה לא יכולה לאתר.
 
יש להיט במחקרים בניהול וזה נושא ההתמכרות לדאשבורדים. הכי קל לברוח לאיזה דו"ח שאומר לנו כמה המתכנת כיסה את הקוד שלו, האם הוא עמד בתקן הLint והאם התוצר המקומפל גדל בנפח שלו. אני לא אומר שהדברים הללו מיותרים, רק שהם פחות חשובים ממדדי איכות אחרים שאי אפשר לבחון כמותית.
היה לי עובד שנשלח לעבוד באיזה מקום עם תהליך "גרמני" שבו מתכנתים נמדדים כל הזמן דרך הJIRA. מה פתוח, כמה זמן, על מה ענו, כמה שעות לקח, כמה משימות הסתיימו וכו'. התנצלתי בפניו שהוא ייאלץ להתרגל לזה והוא חייך ואמר: "אני גדלתי במדינה קומוניסטית. אנחנו אלופי העולם בשיפוץ דו"חות והצפת מדדים להנהלה". ואכן, לפי המדדים שלו הוא עובד מצטיין בטופ.
 
בראיון עבודה אני לא אבדוק אם המועמד מכסה 100% בדיקות. גם כי זה לא ניתן לאימות בראיון, וגם כי אם אני רוצה לאכוף את זה, אני יכול לקחת אפילו מתכנת עם פיגור שכלי והוא יכתוב עם 100% טסטים כי הבילד לא יתן לו להכניס קוד ללא כיסוי. אני לא צריך לראיין בשביל זה. את איכות העבודה שלו אני אנסה לבדוק בדרכים אחרות ואיכותיות האלה, מה לעשות הן סובייקטיביות למרות שעל חלק מהדברים יש קונצנזוס די רחב.
עבודה בהיי-טק >>
לצפיה ב-'אלה לא דברים סותרים'
אלה לא דברים סותרים
20/05/2020 | 11:37
2
22
אתה יכול להסתכל על הדברים בcode review ולסמוך על העין המאומנת שלך. ואתה יכול גם להסתכל על מדדים וdashboards. אפילו באותו כלי שבו אתה עושה code review (כמו שזה במקרה שלי, המדדים הבסיסיים כבר כלולים בכלי).
 
אבל, מה שמכונה לא יכולה לזהות - גם אנשים לא יכולים. לא כולם, לפחות. אז נוצר מצב שיש לך צוואר בקבוק של מי שעושה CRים. יש לך את המתכנת המנוסה והמומחה שיכול זהות בעיות רק מקריאת הקוד וכל הCRים נופלים עליו, אבל אז המומחיות שלו - מה איתה? בשביל מה גייסת אותו?
 
ולחלופין, אתה מתחיל לשלוח CRים לכל הצוות. יש לך תורן לזה כל שבוע, אתה עושה ראונד רובין, מישהו מתנדב, מישהו נענש, כל צוות מוצא לעצמו שיטות. ומה קורה? אם הCR נופל על מישהו חזק הוא מזהה בעיה, אבל אם אותו CR נופל על מישהו קצת פחות חזק - הוא מפספס את הבעיה.
 
אתה טוען שמדדים אובייקטיביים פחות חשובים מהסיכוי שהCR יפול על מישהו טוב כפול הסיכוי שהמישהו הזה ישים לב כפול הסיכוי שהמישהו הזה יהיה לו כוח להתווכח עם קלייטון ששלח לו את הCR?
 
ההערה האחרונה שלך כלל לא רלוונטית. מה שגילינו בראיון העבודה של קלייטון זה לא אם הוא מגיע ל100% כיסוי או לא אלא שהוא בכלל לא מאמין במושג "טסטים", או "מדדים" או "איכות". מבחינתו אלה לא דברים שקיימים. את זה כן אפשר לגלות, וכמו שראינו די בקלות, בראיון עבודה.
עבודה בהיי-טק >>
לצפיה ב-'לא מה שהתכוונתי לומר'
לא מה שהתכוונתי לומר
20/05/2020 | 11:58
1
21
אני טוען שהמדדים האובייקטיביים פחות חשובים מהגורם האנושי - כתיבת קוד איכותי באופן סובייקטיבי. זה יכול להיות עם או בלי CR, הרוויו הוא רק כלי עזר וגם הוא לא מתבצע תמיד.
הבסיס הוא מתכנת שיודע איכות מה היא. לזה אין תחליף, אין מדד אובייקטיבי שיכול לבדוק זאת אבל בראיון עבודה כן מנסים לבדוק את זה ברמת הצלחה כזו או אחרת ואני יודע שברוב האוניברסיטאות מתייחסים לזה ברצינות ומורידים על זה נקודות בתרגילים.
עבודה בהיי-טק >>
לצפיה ב-'זה עדיין לא סותר'
זה עדיין לא סותר
20/05/2020 | 12:11
19
וודאי שהגורם האנושי הרבה יותר חשוב, הרי מחוללי יישומים עדיין לא תופסים יותר מנישות קטנות בשוק.
 
זה לא סותר את העובדה שכן אפשר לכמת חלק מהאיכות הזאת באופן אובייקטיבי. לא רק כיסויי קוד בבדיקות - הנתונים שאתה מתאר שהגרמנים אוספים על העובדים שלהם הם בדיוק הנתונים עליהם דיברתי קודם שמאפשרים לך למדוד לאורך זמן את איכות התפוקה של הצוות.
 
אתה אומר שהעובד שלך לפי המדדים האלה היה מצטיין בנימה מזלזלת, לי זה נראה קצת מוזר הזילזול הזה. הרי אתה מתגאה ביכולת שלך לאתר עובדים טובים וביכולת שלך לספק להם עבודה ופרנסה ראויים, והנה - יש לך אסמכתא מדידה ומדוייקת לכמה שהעובד שלך באמת טוב ולא רק ראיה סובייקטיבית שלך - ואתה מזלזל בזה. למה?
עבודה בהיי-טק >>
לצפיה ב-'כשאתה מנסח את זה ככה, אין לי וויכוח איתך.'
כשאתה מנסח את זה ככה, אין לי וויכוח איתך.
20/05/2020 | 18:03
15
זה לא מה שהבנתי מיתר ההודעות פה, אבל אולי יש לי בעיה עם context switching.
 
יצא לי לראות, ולהלחם במידה קטנה בניסיון למדוד מתכנתים ע"י השוואת כמות משימות פיתוח חדשות מול כמות משימות תיקון באגים.
 
מדד שבמבט חטוף של אדם לא מיומן יכול להראות טוב, אך בפועל אין בו כל הגיון.
עבודה בהיי-טק >>
לצפיה ב-'יש כמה הנחות סמויות בסיפור שלך:'
יש כמה הנחות סמויות בסיפור שלך:
20/05/2020 | 17:55
13
האם ראית איך הרובוט שלך נראה על מסך השיקוף?
 
אף פעם לא הייתי בארה"ב, ואין לי הכרות אישית עם מאבטחי TSA או איכות האימון שלהם, אבל מכמה סדרות תעודה שראיתי, יש המון טכנולוגיה במכונות שיקוף מודרניות, והם לא מסתמכים רק על העין הבלתי מזוינת של זה שעומד מול המסך, אלא התוכנה בפנים מנסה לפענח את התמונה, לפחות בצורה חלקית.
 
כך למשל, חלק מהפריטים מוצגים על מסך בצבע מסוים.
כמובן, לקרני X אין צבע, אבל התוכנה עושה פרשנות כדי להקל על מי שמסתכל להפריד בין דברים שונים.
 
אין לי ידע טכני לקבוע בוודאות, אבל הייתי אומר שיש סבירות לא רעה שהרובוט שלך לא נראה מפחיד במסך השיקוף כפי שחשבת, ושלזה שעומד מול המסך יש מספיק ניסיון כדי להבדיל בינו לפצצה.
 
מהצד השני, התפקיד של זה שצעק עליך הוא להתרכז בך, ובכנות אני יכול להבין אותו:
הוא הרי לא לבד שם, ויש לו אלפי כמוך ביום.
 
זו בדיוק הבעיה:
אתה חושב שאתה מבין את התהליכים ושיטות העבודה שלהם, אבל האם עבדת אי פעם באבטחת שדות תעופה?
 
הבחור שתפקידו לדאוג שתוריד את הנעליים לא אמור להגיב להסחות דעת, לו יש את התפקיד שלו, ולזה שעומד בשיקוף יש את התפקיד שלו, ויש עוד 10 כמוהם בצד מוכנים לזנק עליך אם יתנו להם סימן הכי קטן.
 
אז סה"כ, אני חושב שזו מטפורה ממש לא מתאימה לדיון שלנו.
עבודה בהיי-טק >>
לצפיה ב-'אני אתן לך כמה דוגמאות לאכיפת תקן רשמי'
אני אתן לך כמה דוגמאות לאכיפת תקן רשמי
19/05/2020 | 21:08
23
כיסוי קוד בUT - מדד פשוט ואכיף שיכול לבדוק שהUT שלך מבצע כל שורת קוד. זה לא כיסוי מספיק, כמובן, אבל זה אחד המדדים הבסיסיים שהכי קל ליישם.
 
סיבוכיות הקוד - אחד המדדים הראשונים שהומצאו אי שם בשנות ה70 שנותן ציון לכמה קל לבדוק את הקוד שלך. ככל שסיבוכיות הקוד נמוכה יותר ככה יותר סביר שתוכל לבדוק את כל האפשרויות בתהליך הבדיקות. זה בדרך כלל מתקשר עם מדדי כיסוי של UT כי מעבר לבדיקות יחידה כיסויי בדיקות מלא כנראה לא יהיה סביר.
 
מדדי ביצועים - למשל benchmarking, או שינויים במדדים בעבקות שינויים בקוד (שינוי נפח קוד, שינוי זכרון נדרש, שינוי בlatency, וכד׳).
 
אלה דוגמאות למדדים אובייקטיביים. זה לא רק קוד מיושר או מספר שורות קוד בפונקציה. את כל המדדים האלה אפשר ליישם בקלות. יש עוד הרבה מדדים שונים שיהיה קצת יותר קשה ליישם אבל גם אפשרי (למשל - כמה זמן לוקח להכניס שינוי בקוד? כמה זמן לוקח לעשות roll-out לפרודקשן? כמה זמן לוקח לתיקון באג ממוצע? וכו׳ וכד׳).
 
אם תשאל אותי, זה נראה שקלייטון מעולם לא נתקל באף אחד מהמדדים האלה. מה איתך?
עבודה בהיי-טק >>
לצפיה ב-'למעשה, יש מדדים ידועים ואובייקטיביים לאיכות הקוד'
למעשה, יש מדדים ידועים ואובייקטיביים לאיכות הקוד
19/05/2020 | 17:21
2
33
זה משהו שמלמדים בתואר, וכנראה אפילו בחלק מהקורסים הלא אוניברסיטאיים...
עבודה בהיי-טק >>
לצפיה ב-'איך היית מדפיס hello'
איך היית מדפיס hello
19/05/2020 | 18:05
1
32
 # The easy way
print('hello')

# Some reviewers insist on
print("hello")

# The wrappers
def print_hello():
   print('hello')
print_hello()

# The generic wrappers
def print_str(str):
   print(str)
print_str()

# The ones who add comments no one reads
# This method will print a string to the console
def print_str(str):
   print(str)
print_str()

# Too bad Python doesn't have constatns
MSG = 'hello'
print(MSG)

# Config and property file lovers
str = env.get_property(HELLO)
print(str)

# What about languages support?
str = env.get_property(HELLO, LANG_EN)
print(str)

# You never know what can go wrong
try:
   print('hello')
except:
   print("Kind of stupid to print when print throws an exception")
כתבתי דוגמה להמחשה. תהנה
עבודה בהיי-טק >>
לצפיה ב-'זו בדיחה טובה אבל יש לך באג ב-2 דוגמאות'
זו בדיחה טובה אבל יש לך באג ב-2 דוגמאות
19/05/2020 | 20:04
28
שידפיסו מחרוזת ריקה.
 
ובכנות, אני יכול לספר לך על באגים ברמת show stopper שראיתי מכך שלא השתמשו בחלק מהמקרים היותר מורכבים שהדגמת ובחרו ביותר פשוטים.
 
למעשה, רק היום עבר אצלי ברוויו באג שנבע מכך שמישהו ניסה לבדוק אם המחרוזת ריקה בלי לחשוב לרגע שהמחרוזת עלולה להיות null.
 
ב-Python זה היה זורם, אבל פה מדובר בקוד Java.
בדיקה שהמחרוזת ריקה צריך לעשות עם מתודה של מחרוזת, אבל היות וכל המחרוזות ב-Java הן רפרנס, יש גם אפשרות שמשתנה מחרוזת יכיל null וכל ניסיון להריץ עליו מתודה יגרום לקריסה מיידית של אפליקציה.
 
ועכשיו ברצינות:
יצא לי לעבוד עם מפתחים שאין להם מושג מה זה "Big O", וראיתי חברות שהמפתחים האלה עבדו בהן נכנסות לצרות בדיוק בגלל חוסר ידע זה.
 
נכון - זה לא בא לידי ביטוי בכל פעם ובכל מקום, אבל אני לא רואה בן אדם עובד כמפתח 30 שנה בלי שזה ינגוס לו בתחת לפחות פעם אחת!
עבודה בהיי-טק >>
לצפיה ב-'פלקל.'
פלקל.
19/05/2020 | 21:02
14
30
ההנהלה העסקית לא מתעניינת באיכות הגג. ההנהלה העסקית רק רוצה לראות קומה נוספת באולם אירועים. מהנדס בניין יחיד לא יכול לדאוג להכל, אז למה לו להעסיק את עצמו בבדיקות עומסים ובחינת חומרים? עובד, לא? כש200 איש רוקדים נופלים למטה זאת בעיה שלהם, לא של המהנדס, לא?
 
למה אתה חושב שמה שלא עובד בכל תחום הנדסי אחר יעבוד לך בתור מהנדס תוכנה?
 
אם אתה לא יודע איך הרכיבים שאתה משתמש בהם עובדים - איך אתה יכול למנוע בעיות שונות - בעיות אבטחה, בעיות זכרון, ניצול משאבים לא יעיל, קוד מנופח, וכו׳ וכד׳?
 
לא יודע מה העסק שאתה עובד בו עושה, אבל יש מלא דוגמאות של תוכנה חובבנית שעובדת עד שהיא פתאום לא עובדת. למשל - zoom, תוכנת שיחות וועידה. עובדת לכולם. חוץ מאלה שעושים להם zoom-bombing. למה? כי מישהו שבנה את התוכנה הוא חובבן ולא חשב לא על פרטיות משתמשים ולא על אבטחת מידע. פועל יוצא - מי שהשתמש בתוכנה הזאת ניזוק, ומי שרצה לשלם על רשיונות עסקיים עכשיו מעדיף לשלם למייקרוסופט או גוגל להם יש מוצרים מתחרים הרבה יותר בטוחים ואמינים. וזאת ההשפעה של פיתוח חובבני על העסק. השפעה שאתה חושב שההנהלה העסקית לא מתעניינת בה.
עבודה בהיי-טק >>
לצפיה ב-'יש לי עד היום ספר Java שנותנים בקורס בפתוחה.'
יש לי עד היום ספר Java שנותנים בקורס בפתוחה.
19/05/2020 | 21:51
1
27
בסוף כל פרק שם יש איזו תוספת על "כישלונות תוכנה גדולים", שמדגימה באג כזה או אחר שהרס מוצרים או אפילו חברות.
 
היית שם אפילו דוגמה לבאג ב-UI שהרג אנשים - זה היה UI של מכונת טיפול בהקרנה (נגד סרטן), באג שלא סנכרן נכון את ה-UI, וחוסר בבדיקת בטיחות גרמו לכך שהמפעיל יכל בשוגג להורות למכונה להקרין כמות קטלנית, במקום כמות נכונה.
 
אם אני זוכר נכון נהרגו 3 אנשים לפני שהבאג תוקן סופית.
 
לא כתבו שם כלום על תביעות, אבל יש לי תחושה שהחברה שפיתחה את המכונה לא יצא בזול, אם קרובי משפחה של אותם מסכנים הצליחו להשיג עו"ד טובים.
 
קראתי אפשהו גם סיפור על מערכת מסחר של בורסת לונדון, שהיית כ"כ אטית שהסוחרים עצרו את המסחר יום אחד ויצאו החוצה בשביתת מחאה.
המערכת הוחלפה במלואה (במקור, משהו בנוי ב-#C על Windows, חלופה ++C על Linux).
 
אני בד"כ מביא את הסיפור הזה כדוגמה למה מוצרי MS לא הכי טובים, אבל השרשור הזה גרם לי לחשוב:
אם אתה חברה שמשווקת מערכת מסחר בורסאית - מוצר גדול ומורכב עם כמות לקוחות מוגבלת, ואתה מקבל מוניטין של עצירת מסחר ושביתת סוחרים, מה הסיכויים שלך לשרוד עסקית?
עבודה בהיי-טק >>
לצפיה ב-'יצא לי לעשות משהו דומה בעצמי'
יצא לי לעשות משהו דומה בעצמי
19/05/2020 | 22:01
29
בצעירותי שכתבתי מערכת שנכתבה במקור בVB ורצה על PC. שכתבתי אותה ב++C שרץ על שרת יוניקס וקטעים נרחבים בstored procedures של PL/SQL.
 
המוביל הטכני המקורי פוטר אחרי שהראתי שיפור ביצועים כשהתוכנה שפעם הייתה רצה כמה ימים על PC רצה פחות משעה עם השינויים שלי. המוצר שעד אז לא הצליחו למכור אותו התחיל להמכר. המוביל הטכני החדש (אני) עזב רגע אחרי שחרור הגרסה כי מי רוצה לעבוד בכזה מקום...
עבודה בהיי-טק >>
לצפיה ב-'דוגמה גרועה'
דוגמה גרועה
20/05/2020 | 00:36
11
35
כי באסון ורסאי היתה מעורבת רשלנות מובהקת. הבעיות במבנה היו גלויות לעין שבועות לפני האסון ולא טופלו אלא להפך הוסתרו.
אני לא יודע איך הרכיבים בהם אני משתמש עובדים ואני גם לא יכול לדעת, וגם אתה לא. אם אתה לא מבין את זה אז אתה חובבן ברמה מביכה. תעשה רשימה מסודרת של הרכיבים בהם אתה משתמש ותראה. אם אתה מסוגל לזה בכלל.
אם המדד שלך לתוכנה איכותית הוא שאין בה שום באגים ואין שום בעיות אבטחה אז אני מתקשה לחשוב על תוכנה איכותית. זה בטח לא יהיה מוצר של גוגל או מיקרוסופט או אפל. זה לא יהיה דואר אלקטרוני, לא מסמכי PDF, לא שרתי אינטרנט, לא SQL. לא יודע מה כן. כנראה גם לא המוצרים שאתה אחראי לפיתוחם, ותנופף בידיים כמה שתנופף.
 
עבודה בהיי-טק >>
לצפיה ב-'זה בדיוק המצב פה לא?'
זה בדיוק המצב פה לא?
20/05/2020 | 03:05
10
23
אתה באופן מובהק רשלן, אתה מתעלם מבעיות במבנה שגלויות לעין, אתה אפילו לא מוכן לדון בהן. אמרת ״בן אדם יחיד עומד על הרצפה והיא לא נופלת, מה אתה רוצה?״, אמרת ״הנה, שמתי קירות על הפלקל, זה טריויאלי, מה יש לשאול על הקמת קומה נוספת על גג?״
 
מה ההבדל? זה לא מה שאמרת?
עבודה בהיי-טק >>
לצפיה ב-'אין לי מושג על סמך מה קבעת את הדברים האלה'
אין לי מושג על סמך מה קבעת את הדברים האלה
20/05/2020 | 03:26
9
20
זה קשקוש גמור.
 
עבודה בהיי-טק >>
לצפיה ב-'אני אצטט'
אני אצטט
20/05/2020 | 05:41
8
23
״אני רואה בהדר של ה-C שההכרזות עטופות ב- extern C. זהו. המוצר הזה עובד יופי. עוד משהו?״
 
במה זה שונה מ״עליתי לקומה השניה והתקרה לא נפלה. הפלקל הזה עובד יופי. עוד משהו?״
עבודה בהיי-טק >>
לצפיה ב-'זה לא שונה אבל גם אתה עובד ככה'
זה לא שונה אבל גם אתה עובד ככה
20/05/2020 | 06:02
7
26
כולם עובדים ככה. כולם סומכים על הטכנולוגיות הנמצאות בבסיס העבודה שלהם.
ההבדל בין זה לבין מה שקרה בפועל באסון ורסאי הוא ששם הפלקל בבירור לא עבד:
"רצפת הקומה השלישית החלה לשקוע לאחר הסרת הקיר מתחתיה, דבר שהיה צריך לעורר את תשומת לבם של בעלי האולם. השקיעה החלה להיות ניכרת לעין שבועות אחדים לפני האס..., אלא להפך: במקום לטפל בגורם לשקיעת הרצפה, הוספו חול וריצוף נוסף מעליה על מנת ליישר בחזרה את הרצפה. לא רק שפתרון זה הסתיר את הבעיה המדאיגה, אלא שהוא אף החמיר אותה בכך שעקב פתרון זה נוספו על הרצפה עומסים קבועים נוספים מהריצוף החדש (המסתכמים במאות קילוגרמים)."
עבודה בהיי-טק >>
לצפיה ב-'אתה סותר את עצמך'
אתה סותר את עצמך
20/05/2020 | 06:13
6
22
שני דברים:
 
אתה טוען ש״רצפה שקעה״, אבל זה בבירור מדד אובייקטי. אתה טוען שלא צריך מדדים אובייקטיביים, ולא צריך בדיקות איכות. אתה טוען ש״הסרתי קיר והתקרה לא נפלה, מספיק - לא?״, אתה טוען שבדיקות, מספרים, מדדים - זה ביזבוז זמן. אז למה אתה פתאום מסתמך על איזשהו מדד אובייקטיבי של איכות מוצר אחרי שטענת שאין שום סיבה למדוד אותם?
 
אתה טוען שהפתרון לא מתאים. אבל קודם טענת שהפתרון שלך היה מתאים כי ״עובד״. אז למה שיטוח רצפה עם הוספת חול זה לא בסדר מבחינת? הרי הבעיה נפתרה - הרצפה חזרה להיות שטוחה?
 
למה בעינייך צריך להבין את הבעיה ולהבין את פתרון בנושא שילוב טכנולוגיות בבנייה, אבל לא בנושא שילוב טכנולוגיות בתוכנה?
עבודה בהיי-טק >>
לצפיה ב-'"הרצפה שקעה" = "התוכנה קורסת"'
"הרצפה שקעה" = "התוכנה קורסת"
20/05/2020 | 07:48
5
25
או "התוכנה מפיקה פלט שגוי" וכדומה. זה מדד אובייקטיבי. זו עובדה. המדדים שאתה מתכוון אליהם הם כלים נחמדים ואולי יכולים לעזור אבל אובייקטיבים הם לא.
"שיטוח רצפה עם חול" = "הפלט לא נכון אז אני אכניס קוד שבמצב המדויק הזה מוציא את הפלט שאמור היה לצאת". ברור שאם יש בעיה צריך לטפל בבעיה ולא לזייף תוצאות.
בכל אופן הדיון על הדוגמה שלך עם השילוב C הוא על טכנולוגיה חיצונית שמוכחת כעובדת. אין חשד שיש בה בעיה. אתה אומר שאני צריך להבין למה צריך את הטכנולוגיה הזו ואיך בדיוק היא עובדת. אני אומר שאני לא צריך להבין. הטכנולוגיה עובדת, לא ידוע על שום בעיה בה, היא לא מהווה שום נדבך בעבודה שלי. בזבוז משאבי הבנה עליה לא יקדם אותי. סתם עוד הגדרה מבין אלפי הגדרות נוספות שצריך להגדיר לקומפיילר. בין כה וכה גם אני וגם אתה נותנים אמון בקומפיילר. אחרת לא נוכל להתקדם.
עבודה בהיי-טק >>
לצפיה ב-'לא, זה לא נכון'
לא, זה לא נכון
20/05/2020 | 08:58
4
20
הרצפה קורסת = תוכנה קורסת.
 
אבל מה זה "פלט שגוי"? איך אתה מודד את תקינות הפלט? ה"טכנולוגיה שמוכחת כעובדת" - איך זה מוכח לך כעובד?
 
הידעת למשל שבהרבה מקומות לא משתמשים בSTL של ++C? שאלת את עצמך למה? אני אתן לך רמז - בהרבה מצבים מוכח שהטכנולוגיה לא עובדת. האם תוכל לענות על שאלה "מתי לא להשתמש בSTL" בשלוף בראיון בלי ללכת לגוגל עכשיו לפני שאתה כותב לי תגובה? ואם כן - מדוע את זה אתה צריך לדעת, ואיך עובד מיון אתה לא צריך לדעת?
עבודה בהיי-טק >>
לצפיה ב-'יש מחלקת בדיקות ושם יושבים אנשי מקצוע'
יש מחלקת בדיקות ושם יושבים אנשי מקצוע
20/05/2020 | 09:12
3
21
הם מחליטים מה תקין ומה לא ומה שלא תקין צריך לתקן לפי ההסברים שלהם. אותם אני צריך להבין ואת הלוגיקה שלהם אני צריך להכיר. זו העבודה. לא השטויות שאתה ודומיך ממציאים.
לא ידעתי שלא משתמשים ב STL. גם אני לא משתמש. לא ידעתי שיש בזה בעיות. אני מניח שאם הייתי משתמש הייתי מגלה שיש בעיות והייתי נוטש. לכן לשאלה מתי לא להשתמש כנראה הייתי עונה שמצידי - לעולם לא.
 
עבודה בהיי-טק >>
לצפיה ב-'שמת לב שבינתיים ענית כבר לכמה שאלות ב"ראיון" שלי?'
שמת לב שבינתיים ענית כבר לכמה שאלות ב"ראיון" שלי?
20/05/2020 | 09:21
2
23
ותראה מה גילינו, חוץ מהיהירות והבטחון העצמי המופרז שלך.
 
טענת שאתה מכיר ++C, אבל מסתבר שאתה לא. אתה לא משתמש בSTL בכלל (שזה חלק ניכר מהשפה), ללא שום סיבה שאתה יכול להסביר. אתה לא מכיר את המגבלות של השפה. אתה לא יודע איך להתאים את הקוד שלך בשפה הזאת אם אתה צריך לשלב אותו עם קוד בשפה אחרת (משהו שקורה למרבה הפתעתך די הרבה בעולם הטכנולוגי של ימינו, והביאו לך דוגמא של JNI שזאת דוגמא מאוד נפוצה נוספת לשילוב של C עם ++C, ובמקרה הזה של ++C/C עם JAVA). אתה באופן עקרוני לא מוכן להשתמש בכלים שנועדו לעזור לך לייצר קוד יותר טוב. אתה גם לא משקיע הבנה באיך הדברים עובדים מאחורי הקלעים ולכן כנראה לא תוכל למצוא פתרון אופטימלי לבעיה.
 
אבל אתה מציג את עצמך כמישהו עם נסיון של 30 שנים בתעשיה שכולם צריכים לקבל אותו בזרועות פתוחות בזמן שרמת הידע והיכולות המקצועיות שלך לא משתוות אפילו לאלו של בוגר טרי מודרני מכל מוסד להשכלה גבוהה שמכבד את עצמו ולו במעט.
 
לא פלא שאתה כלוא בכלוב הזהב שלך, לא היית יכול לצאת משם גם אם היית רוצה.
עבודה בהיי-טק >>
לצפיה ב-'תראה לי מקום אחד שטענתי שמישהו צריך לקבל אותי'
תראה לי מקום אחד שטענתי שמישהו צריך לקבל אותי
20/05/2020 | 09:54
1
32
באיזו צורה שהיא. איפה ראית את זה?
אתה מנסה כל הזמן לשכנע אותי שדרך העבודה שלי שגויה ושלך נכונה. ראיתי שכתבת שעבדת על פרויקט שכתוב, עם צוות, ולקח לכם שנתיים. אצלנו היית עף לכל הרוחות וגם חוטף תביעה על הנזק שגרמת לחברה (כנראה שלא אבל היה מגיע לך).
אני הרווחתי את כלוב הזהב שלי ביושר. אני לא צריך להוכיח את עצמי לא לך (אף שנראה שאתה ממש רוצה בזה) ולא לאף אחד. ה"קריירה" שלי בבירור מאחורי וברגע שיתאפשר לי לפרוש אני אעזוב את המקצוע. הקריירה שלך עוד לפניך, עם פרויקטי שכתוב של שנים שמסתבר שיש פראיירים שמוכנים לשלם לך עליהם. אני מאחל לך הצלחה בדרכך.
 
עבודה בהיי-טק >>
לצפיה ב-'תביעה על מה?'
תביעה על מה?
20/05/2020 | 09:57
23
זה שכתבתי שחסכתי שנות אדם באותו המשפט לא קראת? אם בחברה שלך היו מעיפים אותי אז למה שאני אעבוד בחברה כזאת מלכתחילה? אני טוב מה שאני עושה, אני לא צריך לייצר לעצמי job security בכתיבת מערכת שצוות שלם צריך לבזבז חודש כדי לכתוב. את המערכת ששיכתבתי לא אני כתבתי במקור, ומי שכתב אותה במקור אכן הועף מהצוות - למעשה החלפתי אותו. כי הוא אכן גרם נזק לחברה (טוב, הוא נשאר בחברה, אבל בתפקיד אחר ועם הרבה פחות אחריות).
עבודה בהיי-טק >>
לצפיה ב-'אני לא מסכים, לפחות לא עם הנוסח הנ"ל'
אני לא מסכים, לפחות לא עם הנוסח הנ"ל
19/05/2020 | 17:19
2
30
"חווית משתמש" זה אחד המקומות שאיכות הקוד הכי פוגעת בו.
 
אני מכיר מקרה שבו ממשק זחל על חומרה ייעודית, ובמשך תקופה האשימו את החומרה שהיא לא עומד בדרישות.
עד שבסוף יצא להחליף מפתח ולשכתב מ-0 את הממשק.
אותה פונקציונליות, עיצוב יותר יפה, והכי חשוב - מפתח עם יותר מומחיות בכלים שהשתמשו בהם ליצירת ממשק על אותה פלטפורמה ספציפית.
 
ופתאום הכל זרם, וחווית המשתמש השתפרה פלאים, למרות שלא החליפו דבר בחומרה.
הלקוחות התלהבו מהריספונסיביות.
 
אז יש גבול כמה גרוע מפתח יכול להיות.
 
ויש גבול כמה זריקת חומרה יותר יקרה יכולה לחפות על קוד דפוק.
(מזכיר לך שסקיילינג אנכי זה גם דבר שמוגבל חומרתית, לא רק כספית).
 
כן, לפעמים אפשר לחפות על יעילות עם חומרה חזקה יותר, אבל אני לא חושב שזה יותר מידי נפוץ.
 
אולי זה כי אני מהתחום שבו החלפת חומרה היא לא אופציה (מובייל + מערכות ייעודיות), ואין ברירה וחייבים לכתוב קוד שעובד טוב בהינתן מגבלות החומרה.
עבודה בהיי-טק >>
לצפיה ב-'מה שאתה אומר לא סותר את מה שכתבתי'
מה שאתה אומר לא סותר את מה שכתבתי
19/05/2020 | 17:36
1
32
השאלה היא כמה זה נפוץ. ממילא "הרבה" ו"קצת" הם מושגים סוביקטיביים אז נשאר להסכים שהמצבים האלה אפשריים.
החצר האחורית של ההיי-טק אולי פחות נוצצת ומוכרת אבל בהחלט קיימת.
עבודה בהיי-טק >>
לצפיה ב-'במקרה שתיארתי, ההבדל היה בין לקוחות שרצו להחזיר את'
במקרה שתיארתי, ההבדל היה בין לקוחות שרצו להחזיר את
19/05/2020 | 20:12
21
המוצר, ללקוחות שלא רצו להחזיר את המוצר, כך שהמדד היה די חד וברור...
 
אני חושב שראיתי נתח מסוים ממה שאתה מכנה "החצר האחורית" של ההייטק, ופיתחתי שנאה יוקדת כלפיו, שנובעת מהצורך להתמודד עם המוצרים שלו.
 
התחלתי את הקריירה שלי בחצר הזו, וכנראה אני עדיין חלק ממנה במידה מסוימת, כך שאולי זו יריקה לבאר שאני שותה ממנה, אבל כשמדי פעם יוצא לך לראות איך החצי השני חי, זה מפתח תאבון...
עבודה בהיי-טק >>
לצפיה ב-'אתה באמת לא מבין את ההבדל בין המקרים?'
אתה באמת לא מבין את ההבדל בין המקרים?
19/05/2020 | 09:11
3
39
כן, לפעמים יש באגים גם בתשתיות כמו שפות או frameworks, אבל כשהן מתגלות מי שאחראי על זה מתקן אותן... אתה אחראי על הקוד שלך ועל הבאגים שיש בו. מה לא ברור בזה?
עבודה בהיי-טק >>
לצפיה ב-'דיברנו על קוד שלא שלי, מצאתי באינטרנט, לא?'
דיברנו על קוד שלא שלי, מצאתי באינטרנט, לא?
19/05/2020 | 09:17
2
7
לצפיה ב-'קודם כל - אם מצאת באינטרנט..'
קודם כל - אם מצאת באינטרנט..
19/05/2020 | 09:23
1
38
יש לך אחריות בזה שאתה מצאת ובחרת דווקא בקוד הזה ולא בקוד אחר. ואתה גם אחראי על הקוד שמתממשק איתו שגם הוא יכול ליצור באגים...
עבודה בהיי-טק >>
לצפיה ב-'לי תמיד יש אחריות על הכל ותמיד אני אשם'
לי תמיד יש אחריות על הכל ותמיד אני אשם
19/05/2020 | 09:52
45
מבחינת העולם החיצוני כל הבאגים הם שלי. לא הלקוח ולא התמיכה ולא ההנהלה מבינים או מתעניינים בהבחנה בין המרכיבים הרבים של מערכת ממוחשבת. אם השרת נפל למי אכפת שזו בעיה של AWS? אם הדפדפן (כרום) מציג לא נכון טקסט ממש פשוט בדיב טריויאלי, למי אכפת שאפילו אדג' מציג נכון? "יש לך באג בפסקה השלישית. מתי אפשר לקבל עדכון? אני צריכה את זה בהול" 
אז אם אני אחיה בפחד מהאחריות ופחד מהאשמות אני לא אוכל לתפקד.
עובדים ומקווים לטוב, ובדרך כלל באמת טוב. וגם כשלא טוב אז זו העבודה.
 
עבודה בהיי-טק >>
לצפיה ב-'ודרך אגב...'
ודרך אגב...
19/05/2020 | 06:08
8
55
גם אני ידעתי לשלוף אז מהשרוול את התשובה לגבי extern C ולגבי ההשפעה שלו עו הקומפיילר (ולא הייתי צריכה אפילו לרענן את הזכרון לגבי זה) - אבל האם אתה מסוגל להסביר לעומק את ההבדל בין השפות שגורם לזה שהקוד מתקמפל בצורה שונה בין C ל C++, ולאיזה מנגנון של C++ (שאין ב C) זה קשור?
עבודה בהיי-טק >>
לצפיה ב-'למה אני צריך להתעסק בזה? אין לי מה לעשות?'
למה אני צריך להתעסק בזה? אין לי מה לעשות?
19/05/2020 | 08:22
7
41
מה התועלת שידע כזה אצלי יביא לארגון? אלא אם המשימה שלי היא פיתוח  קומפיילרים, שאז צריך להגיד את זה מראש, אני לא רואה שום תועלת בבזבוז משאבי חשיבה וידע יקרים על מידע מיותר. יש כמויות בלתי נדלות של פרטים וידע שמעליהם כל מתכנת עובד, או שמשיקים לעבודה שלו. המתכנת אמור להבין את כולם? את גם מעבירה נתונים בין שרת ולקוח מעל SSL. את יודעת להסביר את המתמטיקה של הצפנת RSA? הרי אין סוף לדרישות האלה.
 
עבודה בהיי-טק >>
לצפיה ב-'להבין איך השפה עובדת זה לא מידע מיותר...'
להבין איך השפה עובדת זה לא מידע מיותר...
19/05/2020 | 08:27
5
39
ספציפית לגבי הבדלי הקומפילציה האלו בין C ל C++ נובע בין השאר בגלל ש C++ מאפשרת function overloading ושפת C לא - וזו פונקציונליות מאוד בסיסית וחשובה ב C++. למה הידע הזה מיותר בעיניך? אולי יש איפשהו בקוד שלכם שימוש ב overloaded functions בצורה שתפריע לשימוש במודולה הזו בשפת C וזה יתגלה במקרי קצה מסוימים שחשוב לבדוק?
עבודה בהיי-טק >>
לצפיה ב-'הרבה דברים יכולים להיות'
הרבה דברים יכולים להיות
19/05/2020 | 08:35
4
33
באגים יש לכולם אחרת לא היו מוציאים "עדכוני אבטחה" כל שני וחמישי.
אם אתעסק בלי סוף בדאגות על מקרי קצה תיאורטים לא אוכל לספק מוצר, וזה לא טוב כי השיווק והמכירות וההנהלה, שלא מתעניינים בקוד מושלם, לוחצים כי הלקוח מעכב את התשלום.
 
 
 
עבודה בהיי-טק >>
לצפיה ב-'לספק מוצר זה לספק מוצר שעובד...'
לספק מוצר זה לספק מוצר שעובד...
19/05/2020 | 09:13
3
33
לפעמים עדיף לעבוד עם מוצר ישן יותר שעובד במקום עם מוצר חדש שיש בו באג שלמשל הורס נתונים במסד הנתונים או מתרסק בדיוק באמתע עדכון והורס מידע שנמצא באחסון כזה או אחר...
עבודה בהיי-טק >>
לצפיה ב-'בתכנות המושג "מוצר עובד" הוא מאד מעורפל'
בתכנות המושג "מוצר עובד" הוא מאד מעורפל
19/05/2020 | 09:20
2
35
יש הרבה מוצרים שעובדים למרות שהם מפוצצים בבאגים. אז מפעם לפעם המערכת קורסת, עושים אתחול וממשיכים. נדמה לי שיש אפילו בדיחה על זה.
 
עבודה בהיי-טק >>
לצפיה ב-'הלקוחות שאני מכירה מאוד התעצבנו על באגים...'
הלקוחות שאני מכירה מאוד התעצבנו על באגים...
19/05/2020 | 09:26
1
38
ורצו תיקון מיידי. אבל אולי לכם יש לקוחות מיוחדים שדווקא נהנים מהם.
עבודה בהיי-טק >>
לצפיה ב-'לנו? אני מתכוון למיקרוסופט ואפל ודומיהם'
לנו? אני מתכוון למיקרוסופט ואפל ודומיהם
19/05/2020 | 10:10
37
אפילו בלינוקס זה קורה. יש לי מחשב נייד עם לינוקס מינט. עובד יופי ולינוקס מאד נחמד, אבל פתאום אחרי צהרים אחד עשיתי משהו, העליתי איזו תמונה אולי, לא בטוח, ופתאום בום, הלינוקס קרס. עשיתי אתחול, עולה ומציג איזו הודעה. אני מאשר, חוזר ומציג אותה, וחוזר למסך הלוגין, וזהו, תקוע.
שעה לקח לי למצוא באינטרנט הדרכה איך להחלץ מזה (לזכותם ייאמר שאכן הלינוקס נחלץ).
 
עבודה בהיי-טק >>
לצפיה ב-'אני מבין שכשאתה צריך לדפוק מסמר, אתה בוחר באקראי'
אני מבין שכשאתה צריך לדפוק מסמר, אתה בוחר באקראי
19/05/2020 | 14:57
30
עם איזה צד של הפטיש להשתמש, בלי להקדיש טיפת מחשבה למה יש לפטיש בכלל צדדים שונים, אם במקרה הורדת לעצמך אצבע על הדרך, אתה אומר "נו טוב, זו העבודה".
 
אתה יודע מה, אתה אוהב דוגמאות עם משאיות, נכון?
אז הנה דוגמה:
מעסיק שואל את הנהג: "כשאתה בירידות סדום, איך אתה מאט את המשאית?"
הנהג עונה: "עם הברקס, מה השאלה?"
המעסיק שואל: "למה יש רטרדר במשאית?"
הנהג עונה: "מה אני מהנדס רכב? למה אני צריך לדעת למה הכניסו את זה! זה שם, ואני יודע שזה שם, יללה, בוא נדבר על המשכורת."
 
מפה יש 2 תסריטים:
1. המעסיק דלוק על הנהג כי הוא סקסי, לוקח אותו, ואחרי יומיים מוצא את שאריות המשאית השרופות אי שם בפיתולים של ירידות סדום.
2. המעסיק מבין עניין, ומעיף את הנהג בבעיטה, ומתקשר לכל החברים שלו בחברות הובלה אחרות לא להעסיק את המטומטם.
עבודה בהיי-טק >>
לצפיה ב-'מעבר למה שכתב vinney...'
מעבר למה שכתב vinney...
19/05/2020 | 05:57
2
57
מדובר על דברים קטנים ובסיסיים אפילו יותר.
 
למשל קח את הנושא של מערכים: בשפת C מדובר בעצם על עבודה עם פוינטרים: משתנה שמצביע על מערך הוא בעצם פוינטר להתחלה שלו, ואתה זה שצריך להתנהל בצורה זהירה מולו כדי לא לגלוש לזכרון מעבר לסיום שלו. 
 
מצד שני ב STL של C++ יש לך לא מעט built in types שכוללים vector ו string (שבשפת C הוא מערך), כך שנחסכת ממך כל העבודה מול הפוינטרים. הידע הזו ב STL הוא ידע בסיסי ב C++ - אבל במקביל זה גם גורם לזה שאתה לא עובד בצורה שוטפת עם מערכים בסגנון של שפת C ולא בהכרח זוכר מה המגבלות שלהם.
 
אז בראיון שבו ישאלו אותך מה המשמעות של להעביר לפונקציה פרמטר של char[] - תצטרך לחשוב טוב כדי להזכר שבעצם אתה לא מעביר מערך שלם אלא רק פוינטר להתחלה שלו, וגם לזכור שאתה צריך לבדוק טוב מקרי קצה שקשורים לעבודה עם פוינטרים. כשלמדתי לתואר וכתבנו בשפת C - הייתי יודעת את הדברים האלו מתוך שינה. כיום אחרי כתיבה של לא מעט שנים ב C++ - הייתי צריכה לרענן את הזכרון שלי ולתרגל את זה קצת כדי להחזיר לעצמי את היכולות האלו.
עבודה בהיי-טק >>
לצפיה ב-'והמעשה שהיה, כך היה:'
והמעשה שהיה, כך היה:
19/05/2020 | 15:10
1
37
פעם עבדתי עם מתכנת חביב שהתמחה ב-Java.
הוא היה טוב מאוד בתחומו, אבל לא התעניין בתחומים אחרים.
 
יום אחד הוא קיבל לעבוד על פרויקט שדרש ממנו לשלב ספריה ב-C, ולתקשר איתה דרך JNI.
הבחור הצליח, הרים את המוצר, ועל פניו העסק עבד סבבה.
 
אבל הוא לא ידע C (בכלל), ולא הלך ללמוד אותו לפרויקט הזה.
אז הוא לא בדק את הקוד ב-C שהוא התממשק מולו.
 
אחרי כמה זמן התחלנו לקבל תלונות מלקוחות על קריסה טוטלית של המוצר.
אחרי הרבה חקירות ופרופיילינג מצאנו שהתקלה היא בשכבת התממשקות בין ספריית C לקוד Java.
 
מה קרה?
מי שכתב את מעטפת ה-JNI שכח שצריך לנקות זיכרון כשמניידים מידע בין אובייקטים של Java למשתנים ב-C, והמתכנת ששילב את הספרייה, לא טרח ללמוד על JNI.
 
אז נוצרה זליגת זיכרון שהיית הורגת את היישום כולו, ואף פוגעת בביצועי יישומים אחרים במערכת.
 
מוסר השכל:
מי שמדבר על "אני לא צריך לדעת" כמו קלייטון דידינו, או שהוא לא קשור לתחום התכנות, או שהוא מהסוג הכי גרוע של אנשים שעוסקים בתחום התכנות.
 
מפתח אמתי צריך לשאוף להתעמק כמה שרק אפשר בכל דבר שהוא עובד איתו, בין אם זה ה-IDE שלו, בין אם זה נבחי השפה, ובין אם זה התנהגות חומרה.
 
כמובן, באמת שיש המון חומר, ואי אפשר להפוך למומחה בהכל, אבל אם יש דבר אחד שאני בטוח בו לחלוטין אחרי 15 שנה במקצוע - כל פיסת ידע עוזרת!
 
אין ומעולם לא היה "ידע מיותר" בתחום התכנות.
 
מצאתי אפילו שלימוד אסמבלי הופך אותי למפתח Java יותר טוב...
עבודה בהיי-טק >>
לצפיה ב-'בגלל זה כנראה מלמדים אסמבלי במהלך התואר...'
בגלל זה כנראה מלמדים אסמבלי במהלך התואר...
19/05/2020 | 15:25
33
אחד הקורסים היותר מעניינים, שנותן גם פרספקטיבה על איך המחשב באמת עובד ברמת "הברזלים".
עבודה בהיי-טק >>
לצפיה ב-'והנה פוסט מעניין בנושא...'
והנה פוסט מעניין בנושא...
19/05/2020 | 06:25
50
שמדבר על ההבדלים בין מראיינים שונים, עד כדי טענה ששני מראיינים באותה חברה יכולים לראיין בצורה כזו שונה שהם לא היו מקבלים אחד את השני לתפקיד (למרות ששניהם עובדים בצורה מספיק טובה כדי להיות אלו שמראיינים מועמדים לחברה). 
 
ברור שכל מראיין סביר, גם אם סגנון הראיון שלו הוא ייחודי לו, יצליח בסבירות גבוהה לעלות על מתכנת גרוע. ואני חושבת שאחת הסיבות לכך שיש כמה ראיונות מקצועיים על ידי אנשים שונים עם סגנון שונה אמור לתת תשובה למצב שהזכרת שאולי מתכנת גרוע יוכל לענות על שאלה ספציפית בצורה טובה, אבל ייכשל בשאלות אחרות.
 
אבל עולה השאלה עד כמה ההתאמה בתחומי הידע של המועמד לבין אלו שלמראיין חשוב להעלות חשובה להצלחה, גם אם הוא מתכנת טוב?
 
עבודה בהיי-טק >>
לצפיה ב-'כימיה חשובה מאד בעבודה'
כימיה חשובה מאד בעבודה
18/05/2020 | 10:16
2
98
לגבי ראיונות עבודה - יתכן שכן כדי לצלוח את הראיון, אבל היא לעולם לא חוזה את הכימיה שתהיה בעבודה עצמה.
עבודה בהיי-טק >>
לצפיה ב-'אני חושבת שבמצב חברתי...'
אני חושבת שבמצב חברתי...
18/05/2020 | 12:26
1
92
רובנו קובעים את דעתנו על מי שאנחנו פוגשים מהר מאוד, ולרוב לא משנים את דעתנו גם אחרי היכרות ארוכה יותר.
עבודה בהיי-טק >>
לצפיה ב-'בחלק מהמקרים'
בחלק מהמקרים
18/05/2020 | 16:21
81
המרצע נוטה לצאת מן השק בחצי שנה הראשונה (שהיא בדרך-כלל גם האחרונה).
עבודה בהיי-טק >>
לצפיה ב-'היא סוג של נכונה'
היא סוג של נכונה
18/05/2020 | 11:28
2
93
רושם ראשוני משפיע באופן חזק על רוב האנשים.
גם אם משהו אצלך יעורר תחושות שליליות או חיוביות במראיין, יש לזה סיכוי להשפיע.
 
מלבד הפן המקצועי, המראיין שואל את עצמו האם אני רוצה לעבוד עם הבן אדם הזה עכשיו במשך כל יום או לא?
מהמנהל הקודם שלי הייתי שומעת הרבה פעמים שהוא פסל אנשים כי משהו בראיון בלי קשר לפן המקצועי לא בא לו בטוב. זה יכל להיות מועמד מתנשא, או מועמד שאמר משפט שהרגיז אותו או פשוט מישהו שהראה חוסר מקצועיות במשהו שטען שהוא יודע. (ועדיין עושים להם את אותם מבחנים ולא אומרים להם לא בדקות הראשונות, כדי לתת להם הזדמנות שווה, אבל מלכתחילה היא כנראה לא היתה כזאת)
 
זאת סיטואציה לא נעימה, כי הצד הנבחן הרבה פעמים יכול להיות בלחץ ומהלחץ לא בטוח שיוצא ה"אני" האותנטי והמשוחרר.
 
פן נוסף זה שזה תלוי במראיין. יש מראיין שיקבע בשניה הראשונה שנכנסת לחדר אם את מתאימה לו או לא, ומכאן יהיה קשה לשנות את דעתו ויש מראיין אחר שיתן לך קודם לדבר במשך כמה דקות ורק אז יגבש את דעתו, זו גישה משתנה. (אני מאמינה שהסוג הראשון פחות נפוץ, אבל יש מראיינים מאוד מאוד יהירים).
 
בכל אופן, אם את מתכוננת לראיון ונותנת את ההכי טוב שלך, אין הרבה מה לאכול את עצמך על זה, זה יכול להיות מליון סיבות למה לא התאמת באותו רגע. יכול להיות שהראת יכולת חשיבה מעולה, אבל היה מישהו שקצת עקף אותך.
עבודה בהיי-טק >>
לצפיה ב-'האם ההבדל בין כמה שניות לכמה דקות בתחילת הראיון הוא משמעותי?'
האם ההבדל בין כמה שניות לכמה דקות בתחילת הראיון הוא משמעותי?
18/05/2020 | 12:34
1
76
הייתי רוצה להאמין שחלקים גדולים יותר מהראיון משמעותיים. כמו למשל מצב שבו בתחילת הראיון הייתי לחוצה, אבל התחלתי להשתחרר ברגע שראיתי שאני מצליחה להתמודד עם השאלות.
עבודה בהיי-טק >>
לצפיה ב-'זה תלוי מי מראיין אותך'
זה תלוי מי מראיין אותך
18/05/2020 | 12:57
74
יש אנשים שחורצים גורל מהר יותר מאחרים
יש כאלו שאין להם כוח בכלל לראיין
אני מאמינה שכן אפשר לשנות את הרושם שנוצר לחיוב או לשלילה.
 
מאחר ומדובר בבני אדם, יתכן שאם x היה מראיין במקום y הוא היה מקבל אותך, אבל y החליט שלא. יש כל כך הרבה משתנים ברקע שאי אפשר לדעת מה הושפע ממה.
עבודה בהיי-טק >>
לצפיה ב-'"פיזיקה" יותר חשובה...'
"פיזיקה" יותר חשובה...
19/05/2020 | 22:03
10

הודעות אחרונות

11:37 | 26.05.20 jellymean
18:27 | 25.05.20 Desslok of Gamilon
06:36 | 25.05.20 מחפשת עבודה17
00:31 | 25.05.20 Desslok of Gamilon
21:41 | 22.05.20 סימבה8881
05:51 | 21.05.20 מחפשת עבודה17
04:57 | 21.05.20 מחפשת עבודה17
13:01 | 18.05.20 men43
08:49 | 18.05.20 מחפשת עבודה17

חם בפורומים של תפוז

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

מקרא סימנים

בעלת תוכן
ללא תוכן
הודעה חדשה
הודעה נעוצה
אורח בפורום
הודעה ערוכה
מכיל תמונה
מכיל וידאו
מכיל קובץ