6 دقیقه مطالعه

وقت برنامه‌نویس را با قرارداد تمرکز نگه دار، نه با تقویم شلوغ

Mehdi Rezaei
Mehdi
نویسنده

برنامه‌نویس کم نمی‌آورد چون تقویم خالی ندارد. کم می‌آورد چون کار عمیق مدام نصف می‌شود و هر نصف‌شدن، مسئله را از نو باید در ذهن چید. توصیه عمومی مدیریت وقت این را جدی نمی‌گیرد. می‌گوید اولویت‌بندی کن، اعلان را ببند، و صبح زود بیدار شو. این‌ها گاهی کمک می‌کنند. مسئله اصلی جای دیگری است: کدنویسی یک حالت شناختی است که با جلسه، پیام، و پریدن بین PR ارزان جابه‌جا نمی‌شود.

برای همین به‌جای یک برنامه روزانه آرمانی که از پنج صبح شروع شود، به یک قرارداد ساده فکر کن. در چه ساعتی تیم حق ندارد مسئله‌ات را ببرد. کدام کارها اجازه دارند آن قرارداد را بشکنند. بقیه روز می‌تواند شلوغ باشد. اگر آن تکه محافظت نشود، شلوغی بقیه روز حس کار می‌دهد و کد جلو نمی‌رود.

چه چیزی واقعاً وقت را می‌خورد

بزرگ‌ترین هزینه، خود جلسه نیست. فاصله بین بیرون آمدن از مسئله و برگشتن به همان نقطه است. یک سؤال کوتاه در میانه طراحی، فقط همان یک دقیقه نیست. زمینه‌ای را که هنوز جایی ننوشته‌ای پایین می‌آورد. اگر آن زمینه فقط در سر تو بود، برگشت طول می‌کشد و معمولاً با یک مسیر ساده‌تر و ضعیف‌تر ادامه می‌دهی چون حوصله ساختن دوباره تصویر قبلی را نداری.

دومین هزینه، کار نیمه‌باز زیاد است. چند باگ، یک مهاجرت، یک بازبینی، و یک یادگیری هم‌زمان. هر کدام زمینه خودش را می‌خواهد. جابه‌جایی بینشان حس مشغول بودن می‌دهد. در عمل هر کدام آن‌قدر کم پیش می‌رود که هیچ‌کدام به نقطه بازخورد نمی‌رسد. خستگی آخر روز از حجم تایپ نیست. از این است که هیچ حلقه‌ای بسته نشده.

سومین هزینه، در دسترس بودن دائمی است. اگر هر پیام را همان لحظه جواب دهی، تو زمان‌بند بقیه شده‌ای. بعضی تیم‌ها این را فرهنگ پاسخ‌گویی می‌نامند. برای کار مهندسی، این فرهنگ یعنی عمیق‌ترین کار را به بعد از ساعت اداری موکول می‌کنی، یعنی به وقتی که انرژی قضاوت کمتر است. کد حساس را در ته روز نوشتن، صرفه‌جویی نیست.

قرارداد را کوچک و قابل اجرا کن

یک بلوک تمرکز در روز کافی است اگر واقعاً مال یک مسئله باشد. طولش را با تجربه خودت تنظیم کن، نه با عدد رایجی که در مقاله‌ها تکرار می‌شود. علامت درست این است که بتوانی بدون نگاه به پیام، یک فرض را جلو ببری: یک تست را قرمز کنی، یک مسیر را بشکنی، یا یک طراحی را تا حدی بنویسی که نفر دیگر بفهمد. اگر بلوک تمام شد و فقط صندوق را مرتب کردی، آن بلوک تمرکز نبود.

قبل از شروع بلوک، مسئله را در یک جمله بنویس و بگو چه چیزی امروز «تمام» حساب می‌شود. تمام شدن لازم نیست انتشار باشد. می‌تواند این باشد که علت یک شکست را به یک شرط مشخص برسانی. جمله را در همان PR یا تیکت بگذار. اگر وسط بلوک خواستی کار دیگری برداری، آن جمله جلوی چشم است و می‌پرسد آیا این پرش از همان مسئله است یا فرار.

بازبینی، پاسخ به هم‌تیمی، و کار اداری را در پنجره جدا بگذار. نه به‌خاطر اینکه کم‌ارزش‌اند. به‌خاطر اینکه ریتم دیگری دارند. بازبینی خوب خودش تمرکز می‌خواهد، ولی تمرکز روی کد کس دیگر است. قاطی کردنش با طراحی خودت هر دو را سطحی می‌کند. دو نوبت کوتاه بازبینی در روز معمولاً از پاسخ قطره‌ای در تمام ساعات بهتر است، چون نویسنده معطل یک نظر پراکنده نمی‌ماند و تو هم هر پنج دقیقه زمینه را عوض نمی‌کنی.

جلسه را با همین قرارداد بسنج. جلسه‌ای که تصمیم یا رفع مانع مشخص ندارد، نامزد حذف یا تبدیل به یک یادداشت ناهم‌زمان است. جلسه‌ای که باید باشد را به لبه بلوک تمرکز بچسبان، نه به وسطش. اگر تقویم تو را مجبور می‌کند مسئله را در دقیقه‌ای که تازه جا افتاده رها کنی، مشکل ابزار نیست. مشکل این است که بلوک در تقویم به‌عنوان مشغول دیده نمی‌شود. خودت آن را مشغول ثبت کن. اگر ثبت کردنی نیست، حداقل تیم بداند آن ساعت برای حادثه است نه برای گفتگوی قابل‌تعویق.

چه چیزی را بهینه نکن

روتین شخصی بقیه را کپی نکن. کسی که مسئله‌اش را عصر حل می‌کند و کسی که صبح زود بهتر کار می‌کند هر دو می‌توانند قرارداد داشته باشند. بهینه‌سازی ساعت بیداری، میز، و اپ مسدودکننده اگر بلوک و حد کار نیمه‌باز نداشته باشی فقط تزئین است. اپ را وقتی اضافه کن که قرارداد را قبول داری و انگشتت هنوز پیام را باز می‌کند.

همه‌چیز را هم در یک سیستم وظیفه نریز. فهرست بلند، خودش منبع اضطراب می‌شود و تو را به مرتب کردن فهرست معتاد می‌کند. برای کار مهندسی، صف کوتاه کافی است: چیزی که امروز در بلوک است، چیزی که در نوبت بازبینی است، و چیزی که عمداً این هفته شروع نمی‌شود. مورد سوم را بنویس. «شروع نکردن» اگر نانوشته بماند، در اولین پیام برمی‌گردد به «چرا این را برنداشتی».

یادگیری را هم داخل همان بلوکی نگذار که باید تحویل بدهی، مگر اینکه یادگیری خود تحویل باشد. خواندن یک ابزار تازه وسط باگ پروداکشن، هم باگ را طولانی می‌کند هم یادگیری را تکه‌تکه می‌کند. اگر لازم است چیزی را یاد بگیری تا مسئله حل شود، محدوده را ببند: فقط همان صفحه از مستند که به این خطا مربوط است، نه گشت در اکوسیستم.

و مراقب روزهایی باش که حادثه قرارداد را می‌شکند. شکستن برای حادثه واقعی درست است. شکستن برای هر چیزی که کسی «فوری» نامیده غلط است. اگر هر روز حادثه داری، مسئله زمان‌بندی تو نیست. مسئله صف کار یا کیفیت انتشار است. قرارداد تمرکز آن مسئله را حل نمی‌کند، فقط نشانش می‌دهد. همان نشان دادن مفید است. تیمی که هر روز عمیق‌ترین کارش قطع می‌شود و فکر می‌کند با تکنیک شخصی باید جبران کند، دارد علامت سیستم را نادیده می‌گیرد.

آخر روز را جمع کن

آخر بلوک، دو خط بنویس: چه چیزی معلوم شد و قدم بعدی چیست. این کار خاطره فردا را ارزان می‌کند. بدون این دو خط، فردا صبح بخشی از وقت تمرکز صرف یادآوری دیروز می‌شود و تو فکر می‌کنی تمرکز خراب شده. خراب نشده. سپرده نشده.

اگر روز جلسه بود و بلوک نمانده، همان را صادقانه بنویس و فردا بلوک را اول روز بگذار، قبل از اینکه صندوق دستور روز را عوض کند. مدیریت وقت برای برنامه‌نویس یعنی دفاع از یک تکه پیوسته برای یک مسئله، به‌علاوه جایی مشخص برای بقیه کارها. بقیه تکنیک‌ها اگر این دو را نداشته باشند سرگرمی‌اند.

پرسش‌های کوتاه

چند ساعت تمرکز لازم است؟ آن‌قدر که یک فرض در یک مسئله جلو برود. اگر تقویم اجازه یک بلوک واقعی نمی‌دهد، اضافه کردن تکنیک روی روز تکه‌تکه فایده کمی دارد.

پیام هم‌تیمی را معطل کنم؟ نه برای همیشه. پنجره پاسخ را اعلام کن. معطل کردن نامحدود بی‌احترامی است. پاسخ لحظه‌ای هم برای کار عمیق بی‌احترامی به نتیجه است.

کار نیمه‌باز را چند تا نگه دارم؟ آن‌قدر کم که بتوانی بدون نگاه به ابزار بگویی هر کدام منتظر چیست. اگر نمی‌توانی، یکی را متوقف کن و توقف را بنویس.

Share this article