چرا مهندسها باید بعضی وقتا هیچ کاری نکنن
خلاصهٔ کاملتر
نویسنده با یه ادعای جالب شروع میکنه: خیلی از مهندسها باید کمتر کار کنن — نه لزوماً کد کمتر بزنن، بلکه واقعاً ساعت کمتری کار کنن و با سرعت آرومتر. خودش هدفش اینه که بهطور پیشفرض با ۸۰٪ ظرفیت کار کنه و مگر وقتی یه پروژهٔ پرفشار داره، ۲۰٪ روزش رو دور از کامپیوتر بگذرونه.
دلیل اصلیش اینه که عملکرد تو شرکتهای فناوری رو رویدادهای نادر و پراثر تعیین میکنه. به گفتهٔ نویسنده تو سازمانهای بزرگ معمولاً کارهای مهندسی بهظاهر بیاهمیتی هست که میتونن دهها یا صدها میلیون دلار برای شرکت بسازن: یه فیچر یا رفع باگ که یه قرارداد بزرگ سازمانی رو میبنده، جلوگیری زودهنگام از یه اینسیدنت (حتی فقط با دونستن اینکه کدوم فیچر فلگ رو خاموش کنی)، یا یه تغییر کوچیک ولی مبهم که موفقیت یه فیچر پرسروصدا بهش بنده.
نکتهٔ مشترک این مثالها اینه که همهشون وابسته به زمانن. نمیتونی صبح لاگین کنی و تصمیم بگیری یه قرارداد بزرگ رو باز کنی. به گفتهٔ نویسنده شرط لازم اینه که از قبل مشغول نباشی. اگه همیشه ۱۰۰٪ روی یه جریان دائمی از کارهای کماهمیت مشغول باشی، دو جوری فرصتهای پراثر رو از دست میدی: اول اینکه اونقدر سرت شلوغه که اصلاً متوجهشون نمیشی، و دوم اینکه اگه همیشه مشغول به نظر برسی، مدیرت برای کارهای مهم سراغت نمیاد.
نویسنده میگه پس دقیقهبهدقیقه باید چی کار کنی؟ جوابش اینه: هیچی، و هیچکاری کردن واقعاً خوبه. مهندسی نرمافزار شغل پرتنشیه ولی معمولاً بهطور مداوم پرتنش نیست؛ تنش از اینسیدنتهای گاهبهگاه یا کارهای فوری میاد. اگه بخشهای کمفشار رو هم با شدت و فوریت انجام بدی، موقع بخشهای پرفشار خسته و فرسودهای. حتی موقع اینسیدنت هم توصیه میکنه عجله نکنی، چند تا نفس بکشی و «آروم فکر کنی»، چون بیشتر اینسیدنتها خودشون حل میشن و بیشتر تغییرات شتابزده اوضاع رو بدتر میکنن.
نویسنده میگه برای خالی نگه داشتن وقت، گاهی باید عمداً یه کارایی رو انجام ندی. مثلاً معتقده مهندسها بهتره از کارهای چسبی (glue work) مثل مطمئن شدن از اینکه آدمها با هم حرف میزنن یا داوطلب شدن برای بدهی فنی دوری کنن؛ چون این کارها نشوندهندهٔ اینه که سازمان عمداً اونها رو اولویت نداده، و انجامشون یا وقت تلف کردنه یا شرکت رو از پیامد اشتباهات خودش عایق میکنه به قیمت شغل و سلامت روان خودت.
یه هشدار دیگهش اینه که زیادی کمکرسان بودن آدم رو در برابر «شکارچیها» آسیبپذیر میکنه — کسایی که میخوان کار جبراننشده ازت بکشن، مثل یه پیاِم از یه تیم دیگه که ازت میخواد آمار براش بکشی، یا مهندسی که ازت میخواد «پِیر» کنی ولی آخرش همهٔ کد رو تو مینویسی و اون به اسم خودش ثبتش میکنه. نویسنده میگه یهکم از این کارا اشکالی نداره، ولی باید بتونی فشار معکوس بذاری، یا با نه گفتن یا با چند ساعت تأخیر تو جواب.
نویسنده هم اشاره میکنه که نباید زیادی روی کاری که احتمالاً نابود میشه سرمایهگذاری کنی؛ مثلاً وقتی یه طراح هر ساعت نظرش عوض میشه، به جای بازنویسی صفحه هر ساعت، یهبار بعدازظهر بر اساس آخرین طرح انجامش بده. جمعبندیش اینه که موفقیت تو مهندسی نرمافزار با توانایی انجام کار درست در زمان درست تعیین میشه، و این مستلزم اینه که بخشی از تلاشت رو عمداً تو کار عادی نگه داری.
نکات کلیدی:
- نویسنده هدفش کار با ۸۰٪ ظرفیت بهطور پیشفرضه
- عملکرد رو رویدادهای نادر و پراثر تعیین میکنه، نه حجم کار روزمره
- اگه همیشه ۱۰۰٪ مشغول باشی، نه فرصتها رو میبینی نه مدیرت سراغت میاد
- توصیه: از کار چسبی و کمکرسانی بیش از حد به «شکارچیها» دوری کن
- موقع اینسیدنت عجله نکن؛ بیشترشون خودشون حل میشن و عجله اوضاع رو بدتر میکنه
