בכל פעם שתנסו לשלוח Pull Request לפרויקט קוד פתוח, ובהרבה חברות תוכנה בכל פעם שתסיימו עבודה על פיצ'ר, יהיה מי שיבוא עם בקשות לתיקונים:

"תוסיף בבקשה הערות"

"הבדיקה לא מספיק טובה"

"מה קורה במצב ש... ?"

"תמעך את הקומיטים בבקשה שיהיה רק קומיט אחד ב PR"

"תהפוך את הטאבים לרווחים"

"יש לנו API חדש שבדיוק מתאים למה שכתבת, עדיף שתעבור להשתמש בו"

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

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

תשתית של שינויים מורכבת מידע, מכלים ומעיצוב הקוד:

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

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

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

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