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

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

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

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

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

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