הבלוג של ינון פרק

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

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

ולהטיה הזאת יש גם אפקט מאוד מוחשי ושלילי על החיים שלנו כמתכנתים.

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

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

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

פוסט אורח מאת ערן גולדמן-מלכא

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

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

כל אחד בוחר את המטרות שלו ואת ההקרבה שהוא מוכן כדי להגיע עליהן.

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

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

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

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

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

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

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

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

1. לדבר עם אנשים אחרים שהתמודדו עם בעיות דומות ולשמוע מה הם עשו.

2. ללמוד יותר על עולם התוכן הרלוונטי (קורס מקוון, ספר, קריאת תיעוד).

3. להמשיך לפתור בעיות אחרות ולחזור לזה עוד חודשיים-שלושה כשאהיה יותר משופשף.

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

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

חבר סיפר לי השבוע שהם מתלבטים בין Vue ל React לפרויקט הבא. בשיחה אחרת חברה שאלה באיזה כלי CI כדאי להשתמש וחבר שלישי לא הצליח להחליט אם לפתח את האפליקציית מובייל שלהם ב React Native או ב Flutter.

ובתכל'ס כולם מודאגים מאותם הדברים-

1. מה אם אבחר את הכלי הלא נכון?
2. מה אם בעוד חצי שנה לא אצליח לבנות איזה פיצ'ר בגלל הכלי שבחרתי?
3. מה אם הכלי שבחרתי יעלם מהשוק בעוד שנה?
4. מה אם לא אצליח להגיע לביצועים שאני רוצה?

או במילים אחרות: "מה כדאי לבחור כדי שלא אתחרט על זה בהמשך?"

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

אני רוצה להציע רעיון אחר - במקום לשבור את הראש כדי לנסות למצוא את הכלי הכי טוב עבורכם, נסו לסנן החוצה את כל הכלים שלגמרי לא באים בחשבון ולבחור באקראי את אחד מהנשארים. בינינו, יש סיכוי טוב שגם ב React וגם ב Vue תצליחו לבנות יופי של אפליקציה; שגם ב Jenkins, גם ב Travis וגם ב Circle CI תוכלו לבנות יופי של אינטגרציה ואפליקציית המובייל שלכם תרוץ גם אם תכתבו אותה ב RN, גם ב Flutter ואפילו אם תלכו על Xamarin. עדיף לכתוב קוד מאשר לבזבז את הזמן בהתלבטויות.

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

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

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

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

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

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

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

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

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

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

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

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

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

הדרך הרגילה לכתוב git alias היא פשוט לכתוב בקובץ הקונפיגורציה את הפקודה המקוצרת, אחריה סימן שווה ואז הפקודה המלאה. למשל השורות הבאות בגיט קונפיג יגדירו את הקיצור st שיפעיל אוטומטית את status:

[alias]
  st = status

אפשר גם להוסיף פרמטרי ברירת מחדל לפקודות לכן האליאס הבא יפעיל את reset hard בלי בעיה:

[alias]
    trashall = git reset --hard

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

[alias]
  stst = !git status && git status

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

$ git stst -s

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

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

[alias]
  acm = "!f() { git add \"$@\"; git commit; }; f"

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

$ git acm demo.txt hello.py

וזה יגרום להפעלה של:

$ git add demo.txt hello.py && git commit

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

https://www.atlassian.com/blog/git/advanced-git-aliases

יש את השיטה של הבית ספר ואת השיטה של החדר כושר.

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

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

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

לפני כמה ימים הראיתי פה שלד לפרויקט Node.JS שבכל קומיט מריץ את בדיקות היחידה עם מנגנון Bitbucket Pipelines. כמה חברים הציעו לקחת את זה עוד צעד קדימה ולשלב גם את Selenium כדי להריץ בדיקות End To End לפרויקט. מאחר ומערכות גדולות יותר אני מעדיף לכתוב ב Rails החלפתי גם את טכנולוגיית צד השרת וכך קיבלנו את השלד בפוסט של היום.

הפרויקט כולל:

1. פרויקט Rails שמציג אתר עם דף אחד ובו הודעת שלום. ההודעה והדף נשמרים בקובץ app/views/home/index.html.erb.

2. בדיקת End-To-End לפרויקט שמפעילה Selenium, מתחברת לעמוד ומוודאת שהדף עלה והציג את ההודעה. הבדיקה נמצאת בקובץ test/system/home_test.rb.

3. בסיס נתונים PostgreSQL עבור הבדיקות שמאופס בכל פעם שעושים Push.

4. קובץ bitbucket-pipelines.yml שמתקין את כל הכלים שצריך ומריץ את הבדיקות.

מוזמנים למצוא את הפרויקט לייב בריפו הזה:

https://bitbucket.org/ynonp/rails-selenium-pipeline/src

החלק שהכי יעניין אותנו היום הוא הקובץ bitbucket-pipelines.yml אז בואו נתחיל ממנו:

image: ruby:2.4.4

pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
        - export DATABASE_URL=postgresql://test_user:test_user_password@localhost/pipelines
        - curl -sL https://deb.nodesource.com/setup_8.x | bash -
        - apt-get update && apt-get install -y unzip libnss3-dev nodejs libgconf-2-4 wget && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -  && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && apt-get update && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont --no-install-recommends
        - bundle install
        - rake db:setup
        - rake db:test:prepare
        - rails test:system
        services:
        - postgres

definitions:
  services:
    postgres:
      image: postgres
      environment:
        POSTGRES_DB: pipelines
        POSTGRES_USER: test_user
        POSTGRES_PASSWORD: test_user_password

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

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

הקובץ שכולל את הגדרות הסלניום נקרא test/application_system_test_case והוא כולל את התוכן הבא:

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_chrome, screen_size: [1400, 1400], options: {
    args: %w[--headless --no-sandbox --disable-gpu --disable-dev-shm-usage]
  }
end

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

המקום האחרון שדרש התערבות בשביל שכל העסק הזה ירוץ הוא הקובץ test/test_helper.rb. לשם הוספתי את שתי השורות הבאות כדי שתוצאות הבדיקות יישמרו בקובץ XML בפורמט jUnit כך שביטבאקט יצליח לקרוא אותן:

require "minitest/reporters"

Minitest::Reporters.use! Minitest::Reporters::JUnitReporter.new("test-reports")

הג'ם שמפעיל את זה נקרא minitest-reporters והוא נמצא ב Gemfile.

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

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

"It's funny, people have been asking me since I got here, 'When is Yahoo going to have 20% time?'" she said on stage during an all-employee meeting at Yahoo. "I've got to tell you the dirty little secret of Google's 20% time. It's really 120% time."

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

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

כששאלו בראיון את קן ת'ומפסון (הממציא של מערכת יוניקס) אם העבודה על יוניקס אותה הוא עשה במהלך העבודה שלו ב AT&T היתה חלק מהמשימות הרשמיות שלו שם הוא ענה:

No, I was sort of incorrigible, to be honest. I suspected that I would eventually get fired, but it didn’t bother me. We were supposed to be doing basic research but there was some basic research we should be doing and some basic research we shouldn’t be doing. And just coming out of the ashes of MULTICS, operating systems was one of those basic research things we shouldn’t be doing

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

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