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

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

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

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

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