אורי לביא על בניית צוותים מצליחים

במסגרת ה-TechTalks ב-Outbrain הגיע היום אורי לביא מ-PicScout להסביר את עמדתו על אומנות פיתוח התוכנה, כיצד לטפח צוותים וכיצד לבנות צוותים מצליחים.

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

מה לדעתכם מחזור החיים של מהנדס תוכנה?

(עם או בלי פיצה...?)

טענה: התעשייה מתבגרת (לטובה) יש יותר מפתחים מבוגרים שאינם מנהלים בהכרח.

אנשים נוגעים בקוד בד"כ כ-10 שנים.

המחזור: למידה של שנה שנתיים, עבודה במה שלמדתי, עבודה חדשה בתחום דומה למקום הקודם, העמקה בנסיון, עבודה חדשה -- וחוזר חלילה. אורי טוען שיצא לו לראיין בין 200 ל-400 מתוך 500 ל-800 קורות חיים (הוא כבר לא סופר) ונדמה לו שהמחזור הזה תופס לפחות ב-75% מהמקרים. והוא טוען שזה מחזיק בערך 10 שנים. באלגוריתמים למשל הוא טוען שנשרפים באותו הנושא באותה החברה תוך שנה-שנתיים.

בתור חברה מצויינת יש לחברה צורך ליצור סביבה שמאפשרת למפתח להצליח.

software engineer vs. developer vs. coder

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

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

הטענה שיש 100% מאמץ ו-0% אפקטיביות. (הוצג סרטון bad code של uncle bob).

מה צריך לדעת? כלים כלים כלים -- לכל דבר צריך להכיר כלים שונים ופרדיגמות שונות:

IDE ולשלוט בו, טכנולוגיה של שפת התכנות, פרדיגמות שונות של שפות תכנות, אנליזה סטטית של קוד, ארכיטקטורה, בדיקות שונות למיניהן (יחידה, קופסה שחורה, קבלה, לקוח, וכו'...) על כל הכלים שלהן, להכיר HTTP וכלים לניתוח ולפיתוח, מה זה WEB, services, פלטפורמות שונות, מערכות הפעלה שונות, mobile, מסדי נתונים sql ו- nosql, להבין בניתוב ובקרה, אבטחה, continuous deployement, continuous integration ועוד ועוד... -- זה מה שמהנדס תוכנה צריך. זה לא מה שלומדים בלימודים בהכרח ובוודאי לא בהיקף הזה. מי שלא לומד לימודים אקדמיים חסר לו מספיק כלים להיות מהנדס תוכנה. ללמוד לתכנת בלבד זה לא מספיק. מהנדס נדרש ליותר יכולת בקבלת החלטות ובהכרות של כלים ותחומים רבים יותר.

מה לומדים?

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

צריך לצעוד בצעדים קטנים (baby steps) וצריך לחבק ולקבל שינויים. הכרחי להיות נלהבים.

הוצג קטע של Miyamoto Musashi שאומר שצריך ללמוד כל הזמן ולשקול יתרונות וחסרונות וכו'. הוזכר הספר The book of five rings.

מה עושה המפתח?

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

לקרוא ספרים!

להכיר שפות תכנות. להכיר פרדיגמות תכנות שונות. להיות פוליגליטים.

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

מה ה-layout?

ניהול גרסאות.

מדיניות לכל check in -- בדיקות קוד, בדיקות יחידה, אנליזה סטטית וכו', כתיבת הערות ב-commit, לחבר למשימות ולבאגים שקשורים -- קישור למערכות הניהול שלהם.

automatic build system

unit testing

Test Driven Development

Refactoring

code reviews: peer reviews, team reviews -- מעבר למה שעושים ב-commit.

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

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

טיפול בחורים בידע, technical debts, איך להשלים חוסרי ידע.

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

לקרוא ספרים!

לעשות book reviews.

להשתמש בכלים הטובים ביותר. להשקיע ולהכיר אותם.

אקוסיסטם: פירמידה הפוכה: לקוחות רבים למעלה, מפתחים אח"כ ולמטה מעט מנהלים. (הפוך מהפירמידה הרגילה)

visibility -- ההפך מ-"יהיה בסדר" ו-"עזוב" ו-"היתה בעיה ברשת..." ו-"זה לא עובד" ו-"ככה צריך לעשות את זה"... -- התבטאויות כאלה מסרסות אפשרות לשקול יתרונות וחסרונות.

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

A Day at Work --

כמה זמן אפקטיבי יש באמת ביום עבודה?

קפה: 15 דקות

שיחות חולין: 15 דקות

דוא"ל: 30 דקות

קפה: 15 דקות

שקט! עובדים: 45 דקות

דיון מה אוכלים: 30 דקות

ארוחת צהריים: שעה

קפה: 15 דקות

דוא"ל: 15 דקות

שיחות חולים ו-social media: 15 דקות

עבודה: שעתיים

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

צריך להיות מעורב ומשמעת!!

חוק הסחת הדעת: 15 דקות לשלווה. צריך זמן שנדרש לצאת מהסחת דעת ולהכנס לעשייה.

לתת הערכות זמנים, לנתח, להשתפר.

ישיבות קצרות ויעילות.

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

כמובן -- כל הטענות, המסקנות וכו' -- הכל לשיטתו של אורי לביא. ולא שלי. אולי אכתוב מתישהו את עמדתי בדברים הללו.

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

היה מעניין.

השיחה הוסרטה. אני מקווה שאזכור לקשר לסרטון לכשיהיה לי קישור.

Bill Slawski on Google patents for ratings and raters

I've been following Bill Slawski's SEO by the Sea for a few years. I enjoy the presentation of search related patents and trends and the exposition of technology used by the big names in the search industry: Google, Yahoo! and Microsoft. Due to my recent intereset in recommendation systems (I now work at Outbrain) I searched back for Bill's posts on recommendation systems, ratings and raters. I came up with quite a lot:

• Google Approach to Making Online Ratings Easier... (on October 2, 2009)
  
• Innovating Product Reviews at Google (on June 16, 2006)
  
• The Growing Power of Online Reviews (on September 6, 2006)
  
• Google Reviews: Reputation + Quality + Snippets + Clustering (on April 6, 2007)
  
• Google's New Review Search Option and Sentiment Analysis (on June 12, 2009)
  
• How Google May Rate Raters (on June 15, 2009)
  

I wrote two comments on that post:

Shlomo Yona 11/03/2010 at 3:20 am
I wonder why not just use the actualaccess to a page through Google as a way to measure popularity — in a way, a Click Through Rate measure — number of actual clicks on the proposed page (link) by google on screen divided by the number of times it was shown

Shlomo
Yona 11/03/2010 at 4:24 am
Apparently, if a user actually clicks the link of a search result, then it means that there’s some sort of agreement with it. In cases where google can “see” (cookie of a google domain or of an affiliate) the page view timing or other clue of user satisfaction from the actual “landing” on the page, then it is an additional indication of satisfaction. So, perhaps raters are not so good and they are biased and not representative?!

• Opinion Summaries in Google Maps Reviews (on August 4, 2009)
  

While Google is in the search business and advertisements, Outbrain attempts to make its living from promoting content. The readers that get the recommendations come first -- they are offered with the highest quality recommendations, the revenue comes next. It makes sense as in the long run, the more satisfied the readers are the more they click on the recommendations. So, as long as the recommendations are of high quality, the traffic will drive profit, instead of doing it backwards (by attempting to influence and to control traffic with short term revenues as motivation).

See more on A view of Outbrain's algorithms' focus and on Bruni PR about Outbrain. Is Content promotion a new and a profitable way to advertise on the web?