تو جامعه فنی اصطلاحی وجود داره تحت عنوان «مهندس ده‌برابر» یا 10x Engineer. ریشه این اصطلاح به یک مقاله در سال ۱۹۶۸ برمی‌گرده که با تحلیل داده‌ها به این نتیجه رسید که نسبت یک مهندس خوب به یک مهندس بد در سازمان عدد ۱۰ هست، به این معنی که این «مهندسین خوب» ده برابر ارزشمند‌تر و پربارتر هستن. این اصطلاح توی سال‌های ۲۰۱۶ و ۲۰۱۸ گسترده‌تر و به نوعی Meme (طنز اینترنتی) و دستمایه شوخی‌های مهندسین تبدیل شد.
در مقابل مهندس ۱۰ برابر، مهندس منفی ۱۰ برابر هست که باعث افزایش هزینه‌ها میشه. توی این بلاگ پست که ترجمه‌ای از مطلب How to become a -10x Engineer هست میخوایم ببینیم که چطور میشه یک مهندس منفی ده‌برابر شد.
مهندسین ده برابر ممکنه افسانه‌ای باشن، اما مهندسین منفی ده برابر قطعا وجود دارن.
برای اینکه یک مهندس منفی ده برابر بشید کافیه تا هر هفته ۴۰۰ ساعت وقت تیم مهندسی رو تلف کنین. برای این کار از ترکیبی از استراتژی‌های زیر استفاده کنین:
نیازمندی‌های پروژه رو هر چه که بیشتر توسعه پیدا میکنه عوض کنین. برای اینکه شما رو سرزنش نکنن از همون اول نیازمندی‌ها رو مبهم تعریف کنین.
از تیم‌تون بخواید تسک‌هایی رو انجام بدن که شبیه کار واقعیه. مثال‌های متنوعش شامل ارائه دادن، دیاگرام درست کردن، و مدیریت تیکت هاست. آداب و رسوم بی‌معنی درست کنین.
ناسپاس باشین. بقیه رو سرزنش کنین. باعث سردرگمی بشین. عصبانی بشین. دلیل اضافه‌کاری بقیه باشین.
اجازه بدین که مهندسین درباره ایده‌هاشون صحبت کنن. تشویق‌شون کنین که به جای عمل‌گرایی دنبال ظاهرسازی باشن. مطمئن بشین که هیچکس قدرت کافی برای تصمیم‌گیری نداره.
جلسات تقویم رو خراب میکنن. برای اینکه به شکل چراغ خاموش وقت بقیه رو هدر بدین، پیام‌ها و اسناد طولانی بنویسین و تا جایی که میشه به اشتراک بذاریدش. از همه نظرات استقبال کنین و با همشون تعامل داشته باشین.
نرم‌افزار‌های کند بنویسین. از ایندکس‌های دیتابیس اجتناب کنین. روی ماشین‌های که ۱۶ تا هسته دارن برنامه‌های تک-نخی (Single Threaded) بنویسین. سخت‌افزار عجیب و غریب با میزان RAM و GPU شیک انتخاب کنین. هر جور دلتون خواست داده‌ها رو روی رم/دیسک ذخیره کنین. هیچ چیزی رو فشرده‌سازی نکنین. هیچ اهمیتی به چیدمان داده‌ها ندین.
تصمیم بگیرین که راه‌حل‌هایی که همین الان وجود دارن مشکل شما رو دقیقا حل نمیکنن. اسکریپت‌هایی بنویسید که فقط یک نفر ازشون سر در میاره. اگه این اسکریپت کار مهمی انجام میده، مستندی براش ننویسین.
بیلدهای کند باعث هدر رفتن زمان و «سود روی سود اومدن» [به مرور زمان کندتر شدن] میشن. هرچی که زمان بیلد طولانی‌تر بشه، توسعه‌دهنده‌های بیشتری حواسشون رو با چیزای مختلف پرت میکنن. برای اینکه مطمئن بشید توسعه‌دهنده‌ها مدام بین کارهای مختلف سوییچ میکنن اطمینان حاصل کنین که بیلد شما حداقل ۲۰ ثانیه زمان میبره. میتونید برای گرفتن نتیجه مشابه تست‌های کند هم بنویسین.
به یک سری از متغیرهای خاص وابستگی ایجاد کنین بدون اینکه کاری که پشتش اتفاق میفته رو تست کنین. انقدر صدا زده شدن توابع رو Mock کنید که دیگه هیچ کد واقعی‌ای اجرا نشه. تست‌هاتون رو زیرزیرکی تصادفی کنین جوری که بعضی اوقات بی هیچ دلیل pass و بعضی اوقات دیگه fail بشن.
رشد سیستم‌تون در آینده رو حین طراحی سیستم در نظر نداشته باشین. و یا به جای اون کاری کنید که تیم شما روی تصمیمات معماری وسواس داشته باشن تا دیگه وقتی برای آزمایش نظریه‌هاشون باقی نمونه.
تا میتونید محیط‌های مختلف ایجاد کنین. محیط پروداکشن و Staging باید تا حد ممکن با هم فرق داشته باشن. کدهای شکننده روی بیلدسیستم‌های شکننده راه‌اندازی کنین. پشت سر هم دیتابیس‌هاتون رو مایگریت کنین.
متداوماً در تشخیص و حل خطاهای اضطراری مشتریان‌تون شکست بخورین. هیچ اهمیتی به مشکلات امنیتی ندین.
کدها روی توی پیام‌های خصوصی توضیح بدین. مستنداتی بنویسید که هیچ‌کسی قرار نیست ازشون استفاده کنه.
مهندسین خوش‌فکر رو جذب کنین و استعداد و توانایی‌هاشون رو هدر بدین. پیچیدگی پروژه رو کمتر از حد واقعی، و کاربردی بودنش رو بیشتر از حد واقعی به مدیریت نشون بدین. انقدر به مدیریت بگید که «تقریباً دیگه تمومه» تا بالاخره بیخیالش بشن.
مهندسین باید به طور جداگانه همه کتاب‌خونه‌ها رو یاد بگیرن.
هیچ‌وقت به شکست اقرار نکنین. تیم‌تون رو غرق هزینه‌ها کنین. توافقات ۸۰/۲۰ ای که می‌تونن وضعیت‌تون رو بهبود بدن رو نادیده بگیرین.
هزینه فرصت میتونه کشنده باشه. وزنه‌های مرده ممکنه متداوماً به تیم شما ضرر نرسونن، اما روی صندلی کسایی میشینن که میتونستن واقعا کمک کنن.
به وزنه‌مرده‌ها بسنده نکنین. به طور فعال مهندسینی رو استخدام کنین که فاجعه ایجاد میکنن و در برابر یادگرفتن مقاومت نشون میدن.
قایق‌هاتون رو تکون ندین. هیچ ردی از شکست باقی نذارین. ضامن مهندسین بد بشین.
برنامه‌های غیرقابل دیباگ بنویسین. روی همه‌چیز لایه‌های انتزاعی بکشین. کدهای اسپاگتی بنویسین. همه چیز رو حساس به شرایط اولیه کنین. از توابع Pure پرهیز کنین. هر جور دلتون خواست به پروژه وابستگی اضافه کنین. هر جا که ممکن بود بگید «رو ماشین من کار میکنه».
