اگر به شروع خودم نگاه کنم، وقت‌ها بیشتر از آنکه صرف نفهمیدن یک مفهوم شود، صرف انتخاب می‌شد. کدام زبان، کدام ویرایشگر، کدام مسیر شغلی، کدام آموزش. این انتخاب‌ها مهم به نظر می‌رسیدند چون علنی و مقایسه‌پذیر بودند. چیزی که واقعاً سرعت را تعیین کرد دیرتر معلوم شد: آیا یک مسئله کوچک را تا جایی بردم که خطا بدهد، خطا را بخوانم، و نتیجه را به کس دیگری نشان بدهم یا نه.
این حرف را به‌صورت ده نکته جدا نمی‌گویم چون شروع، چک‌لیست نیست. یک اشتباه تکراری است: بزرگ کردن چیزهای قابل خرید و کوچک کردن چیزهای قابل تمرین. ابزار را می‌شود همان هفته عوض کرد. عادت خواندن خطا و تمام کردن یک برش را اگر از اول نسازی، با هر ابزار تازه هم همراهت نمی‌آید.
خطا نشانه کار است نه نشانه ناتوانی
اوایل، پیام قرمز را شکست شخصی می‌دیدم و سعی می‌کردم کدی بنویسم که هیچ‌وقت خطا ندهد. این هدف، تمرین را منحرف می‌کند. کد مفید در تماس با ورودی واقعی خطا می‌دهد و برنامه‌نویس خوب کسی است که از روی پیام، محدوده را کوچک می‌کند نه کسی که پیام را نمی‌بیند. اگر از خطا فرار کنی، فقط مسیرهایی را می‌نویسی که از قبل مطمئنی و هیچ‌وقت دیباگ یاد نمی‌گیری.
عادت جایگزین ساده است. متن خطا را تا آخر بخوان. بگو کدام فرض تو با این متن نمی‌خواند. یک چیز را عوض کن و دوباره اجرا کن. اگر چند چیز را با هم عوض کنی، نمی‌فهمی کدام کار کرد. این ریتم از حفظ کردن نحو مهم‌تر است. نحو را با کار فراموش می‌کنی و برمی‌گردانی. ریتم دیباگ اگر نباشد، هر خطا تازه به نظر می‌رسد و خسته‌کننده می‌شود.
و خطا را پاک نکن فقط برای اینکه صفحه تمیز شود. هشداری که امروز بی‌معنی است اغلب فردا همان جایی است که رفتار را نفهمیده‌ای. حداقل یک بار بپرس این پیام دارد درباره چه نوع اشتباهی حرف می‌زند. لازم نیست همان روز همه‌اش را حل کنی. لازم است از آن نترسی.
یک زبان را تا یک نتیجه واقعی نگه دار
تنوع زبان در شروع حس پیشرفت می‌دهد و معمولاً پیشرفت نیست. هر بار که عوض می‌کنی، دوباره با نصب، نحو، و محیط درگیری. مفهوم مشترک، تابع و داده و خطا، همان‌جا که بود می‌ماند و تو کمتر به آن می‌رسی. یک زبان معمولی و یک محیط که اجرا می‌شود کافی است تا وقتی بتوانی یک برنامه کوچک را که ورودی می‌گیرد و خروجی قابل چک دارد تمام کنی.
معیار عوض کردن این نیست که جایی گفته باشند زبان دیگری آینده است. معیار این است که مسئله خودت در این زبان غیرعملی شده باشد. تا آن لحظه نرسیده، جا به‌جایی بیشتر از آنکه در یاد بماند وقت می‌گیرد. آینده شغلی هم معمولاً به کسی می‌رسد که یک چیز را تا آخر نشان دهد، نه به کسی که فهرست آشنا بودن بلندتری دارد.
همین برای چارچوب هم هست. اگر هنوز نمی‌توانی بدون چارچوب یک درخواست را بگیری و یک جواب ساده بدهی، چارچوب را زود اضافه کردن یعنی دو مجهول هم‌زمان. اول مجهول کوچک‌تر. بعد ابزار را وقتی اضافه کن که درد مشخص را کم کند، مثلاً تکرار زیاد در کاری که دیگر بلد هستی.
تاریخچه و سؤال، بخشی از کدنویسی‌اند
کد بدون تاریخچه، قابل فهم نیست حتی برای خودت دو هفته بعد. git را به‌خاطر حرفه ای به نظر رسیدن یاد نگیر. یاد بگیر چون هر commit یک نقطه برگشت و یک جمله نیت است. لازم نیست روز اول شاخه‌های پیچیده بسازی. لازم است کار کوچک را با توضیح انسانی ذخیره کنی تا جرئت آزمایش داشته باشی. اگر ذخیره‌ای در کار نباشد، از تغییر می‌ترسی و همان ترس یادگیری را کند می‌کند.
سؤال پرسیدن هم مهارت شروع است. سؤال خوب نتیجه را سریع‌تر از هوش خام جلو می‌برد. بگو چه می‌خواستی، چه کردی، چه دیدی، و چه فکر می‌کنی آن مشاهده یعنی. «کار نمی‌کند» سؤال نیست و چند رفت‌وبرگشت می‌سازد. اگر این قالب را از اول تمرین کنی، هم کمک بهتری می‌گیری هم خودت اغلب وسط نوشتن سؤال جواب را می‌بینی.
نشان دادن کار ناتمام به یک نفر، حتی یک صفحه، از پنهان کردن تا روز کمال مؤثرتر است. کمال در شروع معمولاً نمی‌رسد. بازخورد روی یک برش ناقص می‌رسد و مسیر را عوض می‌کند. منتظر ماندن برای اینکه شرمنده نباشی، همان شرمندگی را طولانی‌تر می‌کند.
چه چیزی را در شروع جمع نکن
دوره هم‌زمان زیاد، ابزار بهره‌وری، و نقشه کامل تبدیل شدن به متخصص را جمع نکن. این‌ها حس کنترل می‌دهند و تمرین را به تعویق می‌اندازند. یک منبع، یک مسئله، یک محیط اجرا. مسئله می‌تواند خیلی کوچک باشد: تبدیل یک فایل، یک صفحه که یک فرم را چک می‌کند، یک اسکریپت که کار دستی خودت را کم می‌کند. کوچک بودن عیب نیست. تمام شدن، ماده تمرین است.
بازنویسی را هم شکست حساب نکن. تقریباً هر چیز اول را بعداً جور دیگری می‌نویسی. اگر از اول منتظر طرح نهایی بمانی، هیچ نسخه‌ای به بازخورد نمی‌رسد. نسخه اول باید وجود داشته باشد تا نسخه دوم ممکن شود. این را زودتر قبول کردن، جلوی چند ماه معطل ماندن روی معماری خیالی را می‌گیرد.
و مقایسه مداوم با کسی که سال‌هاست کار می‌کند را کنار بگذار. فاصله واقعی اغلب تعداد زبان نیست. تعداد دفعاتی است که آن آدم خطا را تا یک علت مشخص دنبال کرده و یک کار را به دست کاربر رسانده. این دو تا را می‌شود از همین ماه شروع کرد، با ابزار متوسط و مسئله کوچک. بقیه فهرست‌ها اگر این دو نباشند تزئین‌اند.
پرسش‌های کوتاه
کدام زبان را بردارم؟ همان که برای مسئله این ماه منبع روشن و محیط اجرای ساده دارد. عوض کردنش را به بعد از یک نتیجه واقعی موکول کن.
اگر خطا را نفهمم؟ متن را کپی نکن در خلأ. بگو آخرین چیزی که مطمئنی درست بود کجاست و از آنجا یک قدم را جدا کن. اگر هنوز مانده، همان را در سؤال بیاور.
کی سراغ ابزار بیشتر بروم؟ وقتی یک درد تکراری را بتوانی نام ببری که ابزار دقیقاً همان را کم می‌کند. قبل از آن، ابزار تازه فقط مجهول اضافه است.