קטגוריה: בלוגרול

הפילוסופיה של הקוד

ישנו פודקאסט מאוד מעניין שקיבל את השם "הפילוסופיה של הקוד".

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

הפודקאסט מדבר על טכנולוגיות בעולם התכנות. אבל בניגוד להרבה מאוד מאוד מקומות בהם מתמקדים רק בכותרת, כלומר, לא מתפזרים בדברים ומסבירים אותם לעומק, כאן יש כניסה ממש לעובי הקורה. למשל נגיד ומדברים על javascript (הפודקאסט השלישי בשם mocha), אז לא מדברים רק עליה, אלא גם על ההשפעות שממנה היא הגיעה, מה זה אומר, הרבה מונחים, התנהגויות מוזרות וכיוב' …

אנשים כמו ארתיום למשל, ממש ירגישו בבית, כי יש הרבה מאוד פודאסטים על C ו ++C.
כאילו לא סבלנו מספיק בעולם …

כל זה נעשה בשפה העברית.

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

שולחן העבודה הוא מקום מסוכן לצפות על העולם

קראתי היום את הבלוג הזה עם הכותרת הזהה (רק באנגלית כמובן), דבר שהזכיר לי בעיה שהיתה לי במקום העבודה האחרון, ולכן הוא זכה להתייחסות מצידי קריצה

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

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

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

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

ד"א בסופו של דבר, אחרי כמעט 7 חודשים, הפרוייקט התבטל והשאיר הרבה בעיות מאחוריו.

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

סתם עוד חומר למחשבה