מיקרופוסט: אוסף סטריפים בנושאים די קרובים שעשוי לשעשע את מי שלשמחתו או לרוע מזלו הזדמן לו לעבוד עם מתכנתים ומנהלי IT במידה כזו או אחרת

הספר הזה, שהוא אוסף של סטריפים מהקומיקס הזה (או שאולי זה חומר חדש לחלוטין? אני לא יודעת) – נורא מצחיק!

וגם – מאיפה הקרצתי את שם הפוסט?

ואמא שלי DBA, הא!

ואנחנו מדברות על מתמטיקה ומדעי המחשב וטכנולוגיה^[1] בארוחות שבת.
ודודה שלי היא דוקטור לפסיכולוגיה, ואמא של חברה שלי היא פרופסור לביולוגיה חישובית (או משהו, זה לא התחום שלי), וחברה שלי מתחילה את הקריירה האקדמית שלה כמו פגז על ספידים.
ולכל מי שאי פעם אמר לי שנשים מסוגלות פחות או שנשים הן פשוט "לא טכניות" (ויש הרבה כאלה), אתם יכולים לתחוב את הדעות שלכם למקום הבודד אליו יש סיכוי שהן יביאו אור.

עדכוןובדיוק כשחשבתי שסיימתי להתעצבן…

^[1] ועל איך להקים RAC על לינוקס על VMWare שמותקן על הלפטופ שלה, you pricks!

כנגד 4 תכניתנים

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

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

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

כשירות לצרכן, אני פורשת לפניכם את קטלוג התכנתים הגרועים הלוקה-בחסר* שלי, חינם אין כסף, ללא אותיות קטנות וללא תוספות**.

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

האדיש
האדיש בחר בקריירה בתחום המחשוב כי זו עבודה לגיטימית כמו כל עבודה, והשמועה אומרת ש"יש בזה כסף טוב", אז עד היום הוא מקווה למעוד במקרה על סטארט אפ ש"יעשה את המכה" ויגאול אותו מהגורל שהוא בחר לעצמו. הוא מבלה 9 שעות ביום בעיסוק שהוא לא ממש אוהב ולא ממש טוב בו, והוא יודע את זה, וכל שאיפתו היא לסיים את העבודה מהר ולעשות את הדבר היחיד שהוא באמת משתוקק אליו – לשבת מול הטלויזיה ולחלום על חיים של אנשים אחרים שקמים בבוקר בשביל משהו שהם באמת שמים עליו קצוץ.
האנשים האלה בדרך כלל ישייטו בשקט מתחת לרדאר של ההנהלה בתקווה למשוך עוד יום בו אף אחד לא ישים לב לבינוניות שלהם. אפשר לזהות אותם לפי ה check inים ל source control system שבהם נוספים גידולי קוד חיזריים שמטפלים בקוד שרת מה JavaScript של ה UI בלי שום קשר לכל דבר שמזכיר עיצוב הגיוני של מערכת, מתודות שפותחות חיבורים ל DB בלולאה ושולפות שורה את כל פעם ואבסטרקציות לבדיקת הערך של משתנה בולאני . והם בין הגורמים שאחראים לריקבון האיטי והבלתי נמנע של כל מערכת שהם עובדים עליה.

הנלהב
הנלהב סיים זה עתה בהצטיינות תואר ראשון במדעי המחשב והוא ניגש במרץ לשנות את פני עולם התכנה למרות שהוא לא עבד על מערכת אמיתית מימיו. הוא מגיע לעבודה מלא כרימון ברעיונות חדשים ומבריקים שהוא שהוא שמע עליהם בשיעורי design patterns ומבני נתונים , וכעת הוא נחוש לממש linked list תחת כל מחלקה רעננה. בעיניו הבורקות כל מחלקת utilities קיקיונית לובשת צורה של היררכייה מורכבת עם שני ממשקים לפחות ו factory עשוי ניירוסטה, כרום וניקל נוצץ שמייצר את המופע הבודד שלה במערכת שהוא, כמובן, singleton. האנשים האלה אחראיים ל"סינדרום המערכת הראשונה": עיצוב יתר ברמת פירוט מיקרוסקופית של קטעי קוד שמוטב היה לו היו פשוטים וקוהרנטיים, תוך התעלמות מוחלטת מסוגיות עיצוביות רחבות במערכת והתעקשות קשת עורף לממש כלים קיימים וקטעי קוד שנכתבו בעבר שוב ושוב במו ידיהם.
הבנים הללו הם למעשה לא תכניתנים גרועים באופן חסר תקווה, ותחת יד מרסנת שתכווין את המרץ הבלתי נגמר שלהם לאפיקים מועילים, הם יכולים לפרוח.

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

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

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

** ללא דמי מנוי בכפוף לשימוש יומי בסכום של 99.99 שקלים לפחות ועד לתקרה של 100 שקלים ליום, ובעלות של 10 שקל לדקה עבור כל דקה נוספת לא כולל שימוש ביכולות חיפוש, ציטוט או קריאה בלילות ירח מלא.

פעלולי קוד

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

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

// Maximum of objects that it's REALLY RALLY IMPORTANT not to create too many of!!!1
private static final int HEAVY_OBJECTS_MAX = 100;

// Counter for my objects
private int reallyHeavyObjectsCount = 0;

...

// Make sure we are not creating too many objects
if (++reallyHeavyObjectsCount < HEAVY_OBJECT_MAX) {
	new ReallyHeavyObject();
}

לכאורה הדבר הזה אמור לעבוד.
אמור, אלא אם האפליקציה שלנו רצה מספיק זמן.
בכל פעם שהתנאי הזה רץ, הערך של המשתנה מתקדם. אחרי מספיק ריצות כאלה, הערך שלו יזלוג (נו, איך מתרגמים overflow?) והוא יתאתחל למספר קטן מאד, שכמובן יגרום לכך שבריצות הבאות ניצור כמות לא מבוטלת של האובייקטים הממש כבדים שממש, אבל ממש, בשום פנים ואופן אסור לנו ליצור יותר מידי מהם.
והבעיה עם תכנות כזה היא שמאד קשה להבין מה לא בסדר בקוד הזה ממבט ראשון. אלה באגים מגעילים, חמקמקים, באגים מהסוג שלא משתחזר ושלך תמצא מאיפה הם מגיעים במערכת.
אז ככה מפילים מערכת production שלמישהו נורא חשוב לשמור למעלה, עם 30K+ אובייקטים שלא אמורים להיות יותר ממספר זעום של מופעים שלהם במערכת. למעשה, ככה מפילים מערכת production שכל כך חשוב לשמור למעלה, עד שיש לה שרת גיבוי, אבל זה בסדר, ככה מפילים גם את שרת הגיבוי.

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

מה אתה עושה כשאתה קם בבוקר?

על רצפת הייצור של מפעל ההי-טק, כולנו, איך נאמר, טכנאים ופועלי מכונות. את ימי כפועלת על פס הייצור אני מעבירה בחיזוק תנאים, החלפת לולאות ושימון Design Patterns כדי להבטיח את פעולתן החלקה של מכונות ייצור ה Buzz Words הנצחיות.

כל אחד צריך משהו לקום בשבילו בבוקר.

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

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

אלה הם חלומותיו הצנועים של האיש הטכני.

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

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

אבל לפעמים אני חושבת – אולי זה התפקיד של המנהל להפוך את העבודה של האנשים שלו לקצת יותר מרק עבודה?

בלשנות מחשובית

נתקלתי בפסקה הבאה בעמוד של LISP בוויקיפדיה (ההדגשה שלי):

Lisp (or LISP) is a family of computer programming languages with a long history and a distinctive, fully parenthesized syntax. Originally specified in 1958, Lisp is the second-oldest high-level programming language in widespread use today; only Fortran is older. Like Fortran, Lisp has changed a great deal since its early days, and a number of dialects have existed over its history. Today, the most widely known general-purpose Lisp dialects are Common Lisp and Scheme.

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

וסתם משהו קטן שמצאתי כשחיפשתי פוסט שרציתי לקשר אליו, אשר ככל הנראה אבד לנצח בתהומות קורא הRSS שלי:

You can't get a leopard to change his spots. In fact, now that I come to think of it, you can't really get a leopard to appreciate the notion that it has spots. You can explain it carefully to the leopard, but it will just sit there looking at you, knowing that you are made of meat.

משפט נהדר שמצאתי בפוסט המשעשע הזה.

* Here be post

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

לגו!

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

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

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

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

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

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

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

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

ארכיטקטורה ארגונית – אלה תולדות

מתוך הרצאה של פיליפ סטארק.

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

We must remember, and we can see that in any book of my son of 10 years old, that life appears four billion years ago, around — four billion point two?

Voice offstage: Four point five.

Yes, point five, OK, OK, OK! I'm a designer, that's all, of Christmas gifts. And before, there was this soup, called "soupe primordiale," this first soup — bloop bloop bloop — sort of dirty mud, no life, nothing. So then — pshoo-shoo — lightning — pshoo — arrive — pshoo-shoo — makes life — bloop bloop — and that dies. Some million years after — pshoo-shoo, bloop-bloop — ah, wake up! At the end, finally, that succeeds, and life appears. We was so, so stupid. The most stupid bacteria. Even, I think, we copy our way to reproduce, you know what I mean, and something of — oh no, forget it.

After, we become a fish; after, we become a frog; after, we become a monkey; after, we become what we are today: a super-monkey, and the fun is, the super-monkey we are today, is at half of the story. Can you imagine? From that stupid bacteria to us, with a microphone, with a computer, with an iPod — four billion years. And we know, and especially Carolyn, that when the sun will implode, the earth will burn, explode, I don't know what, and this is scheduled for four, four billion years? Yes, she said, something like that. OK, that means we are at half of the story. Fantastic! It's a beauty! Can you imagine? It's very symbolic. Because the bacteria we was had no idea of what we are today. And today, we have no idea of what we shall be in four billion years. And this territory is fantastic.

That is our poetry. That is our beautiful story. It's our romanticism. Mu-ta-tion. We are mutants. And if we don't deeply understand, if we don't integrate that we are mutants, we completely miss the story. Because every generation thinks we are the final one. We have a way to look at Earth like that, you know, "I am the man. The final man. You know, we mutate during four billion years before, but now, because it's me, we stop. Fin. For the end, for the eternity, it is one with a red jacket."

ולמה אנחנו צריכים ארכיטקטורה ארגונית? כי זו המוטציה הבאה של הנדסת תכנה. כי אנחנו אפילו לא בחצי הדרך. כי מאחורינו יש ערימות של ספרות שמדברת על בנייה של מערכת, אבל אנחנו לא באמת יודעים לבנות ארגון שעובד. כי ארכיטקטורת IT של ארגון שלם זה הדבר הבא שאנחנו צריכים ללמוד, ואנחנו עדיין מנסים – עם שיטות לקשר בין מערכות שונות (EAI, SOA וחברים), עם מחשבות להפוך את הארגון למערכת אחת (ERP) או בבורות ועיוורון מוחלטים – מפתחים מערכות מערכות כמו שעשינו עד עכשיו ומקווים שאיכשהו, אם לא תכנון חשיבה והפקת לקחים יובילו אותנו לפתרון, אולי המזל, הקארמה, הקב"ה ושתי שיני שום מתחת למקלדת יגרמו ל IT שלנו להתאים לצרכי הארגון ולהיות יעיל, גמיש ואתלטי כמו שאנחנו חולמים אותו.

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

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

בקטנה: Google Wave

היום פתחתי בהתרגשות את העטיפה המנצנצת של חשבון ה Google Wave Sandbox החדש שלי אחרי המתנה לא קצרה.

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

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

Peopleware: Productive Projects and Teams

לאחרונה סיימתי לקרוא את הספר "Peopleware: Productive Projects and Teams", אחרי שנתקלתי בשם באחד משיטוטי בבלוג שאני אוהבת. מדובר בספר ניהול שיצא בשנת 1987, ובשנת 1999 יצאה מהדורה שנייה שלו בתוספת פרקים חדשים עם תובנות של הכותבים מהשנים שעברו מאז המהדורה הראשונה. שם הספר הוא משחק מילים שבא להצביע על כך שעולם המחשוב עומד על שלושה דברים: Hardware, Software ו- Peopleware, ושהמנהלים בעולם הזה צריכים לדעת לנהל את המשאב האנושי בנוסף ליכולת לנהל את משאבי החומרה והתוכנה.

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

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

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

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

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