ذاكرتك تخونك أكثر مما تظن. بعد ستة أشهر من كتابة دالة معقّدة، لن تتذكر لماذا اخترت هذا الحل تحديداً بدل غيره — وستقف أمام كودك الخاص كغريب يحاول تفسير قرارات شخص آخر. هذا بالضبط سبب أهمية التوثيق: ليس لأن أحداً غيرك سيقرأه بالضرورة، بل لأنك أنت من ستحتاجه أولاً. قرار تقني بلا سبب مكتوب يتحول بعد وقت لغموض: هل بُني هكذا عمداً، أم كان حلاً مؤقتاً نسيت أن تراجعه؟ بدون توثيق، لا فرق بين الاثنين. جرّب هذه العادة: كل مرة تحل مشكلة حقيقية، اكتب ثلاثة أسطر فقط — ما هو السبب الجذري (لا الأعراض)، ما الحل الذي اخترته ولماذا، وكيف تحققت أنه يعمل فعلاً. لا تكتب "ماذا فعلت" فقط — هذا موجود بالكود أصلاً. اكتب "لماذا فعلته"، لأن هذا الجزء يختفي أول ما تُغلق المحرر. بسديم نطبّق هذا بانضباط صارم: كل تعديل حقيقي يُوثَّق فور حدوثه، بنفس النمط — السبب، الحل، طريقة الاختبار، وقسم صريح لما لم يُمَسّ من الكود. النتيجة ليست ملفاً جميلاً على الرف؛ هي أننا نقدر نرجع لأي قرار بعد أشهر ونعرف بالضبط لماذا اتُخذ، بدل أن نعيد اختراعه من الصفر أو نخاف من لمسه لأننا لا نتذكر سببه. التوثيق ليس عبئاً إضافياً فوق البرمجة. هو الجزء من البرمجة الذي يحميك من نفسك، بعد أن تنسى.