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

כמתכנתי Full Stack, חודש עבודה על באג נשמע לנו נצח. התרבות וכלי העבודה מעודדים את קצב הפיתוח הכי מהיר שאפשר ולפעמים יותר מהיר. הפיתרון הנפוץ לבעיות הוא חיפוש הודעת השגיאה ב Stack Overflow. הפיתרון הנפוץ לבניית רכיב ממשק חדש הוא חיפוש אחר החבילה החופשית שכבר מספקת את הרכיב הזה, ואפילו כשכבר כן יושבים לכתוב לבד קוד כלי הפיתוח שלנו הופכים את החוויה למיידית: שנו CSS ותראו את התוצאה מיד בדפדפן; עדכנו קוד JS ותראו את התוצאה ב HMR אפילו בלי לטעון מחדש את העמוד.

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

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

2. חיפוש מהיר של תשובה והעתקה מ Stack Overflow עלול להביא אותנו להדבקת קוד שאינו הכי יעיל למקרה שלנו, רק בגלל שזה הדבר הראשון שעבד.

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

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

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