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

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

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

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

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

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