ویرگول
ورودثبت نام
آرین ابراهیم‌پور
آرین ابراهیم‌پور
خواندن ۵ دقیقه·۱ سال پیش

چطوری یک مهندس منفی ده‌برابر بشیم؟

تو جامعه فنی اصطلاحی وجود داره تحت عنوان «مهندس ده‌برابر» یا 10x Engineer. ریشه این اصطلاح به یک مقاله در سال ۱۹۶۸ برمی‌گرده که با تحلیل داده‌ها به این نتیجه رسید که نسبت یک مهندس خوب به یک مهندس بد در سازمان عدد ۱۰ هست، به این معنی که این «مهندسین خوب» ده برابر ارزشمند‌تر و پربارتر هستن. این اصطلاح توی سال‌های ۲۰۱۶ و ۲۰۱۸ گسترده‌تر و به نوعی Meme (طنز اینترنتی) و دستمایه شوخی‌های مهندسین تبدیل شد.

در مقابل مهندس ۱۰ برابر، مهندس منفی ۱۰ برابر هست که باعث افزایش هزینه‌ها میشه. توی این بلاگ پست که ترجمه‌ای از مطلب How to become a -10x Engineer هست میخوایم ببینیم که چطور میشه یک مهندس منفی ده‌برابر شد.


مهندسین ده برابر ممکنه افسانه‌ای باشن، اما مهندسین منفی ده برابر قطعا وجود دارن.

برای اینکه یک مهندس منفی ده برابر بشید کافیه تا هر هفته ۴۰۰ ساعت وقت تیم مهندسی رو تلف کنین. برای این کار از ترکیبی از استراتژی‌های زیر استفاده کنین:


کار ده مهندس دیگه رو باطل کنین.

نیازمندی‌های پروژه رو هر چه که بیشتر توسعه پیدا میکنه عوض کنین. برای اینکه شما رو سرزنش نکنن از همون اول نیازمندی‌ها رو مبهم تعریف کنین.

۴۰۰ ساعت کار بیخود بسازین.

از تیم‌تون بخواید تسک‌هایی رو انجام بدن که شبیه کار واقعیه. مثال‌های متنوعش شامل ارائه دادن، دیاگرام درست کردن، و مدیریت تیکت هاست. آداب و رسوم بی‌معنی درست کنین.

۴۰۰ ساعت فرسودگی/عقب‌رفت بسازین.

ناسپاس باشین. بقیه رو سرزنش کنین. باعث سردرگمی بشین. عصبانی بشین. دلیل اضافه‌کاری بقیه باشین.

۱۰ مهندس رو توی یک مکالمه فنی گروگان بگیرین.

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

۴۰۰ ساعت سربار ارتباطی بسازین.

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

۱۰ هفته از حقوق کارمندان رو روی هزینه‌های ابری هدر بدید.

نرم‌افزار‌های کند بنویسین. از ایندکس‌های دیتابیس اجتناب کنین. روی ماشین‌های که ۱۶ تا هسته دارن برنامه‌های تک-نخی (Single Threaded) بنویسین. سخت‌افزار عجیب و غریب با میزان RAM و GPU شیک انتخاب کنین. هر جور دلتون خواست داده‌ها رو روی رم/دیسک ذخیره کنین. هیچ چیزی رو فشرده‌سازی نکنین. هیچ اهمیتی به چیدمان داده‌ها ندین.

ابزارهای بیخود بسازین.

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

۴۰۰ ساعت زمان بیلد/کامپایل به پروژه اضافه کنین.

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

تست‌های بی‌معنی بنویسین.

به یک سری از متغیرهای خاص وابستگی ایجاد کنین بدون اینکه کاری که پشتش اتفاق میفته رو تست کنین. انقدر صدا زده شدن توابع رو Mock کنید که دیگه هیچ کد واقعی‌ای اجرا نشه. تست‌هاتون رو زیرزیرکی تصادفی کنین جوری که بعضی اوقات بی هیچ دلیل pass و بعضی اوقات دیگه fail بشن.

۴۰۰ ساعت از وقت مهندسی رو روی یک معماری بد تلف کنین.

رشد سیستم‌تون در آینده رو حین طراحی سیستم در نظر نداشته باشین. و یا به جای اون کاری کنید که تیم شما روی تصمیمات معماری وسواس داشته باشن تا دیگه وقتی برای آزمایش نظریه‌هاشون باقی نمونه.

۴۰۰ ساعت وقت روی دیپلوی‌کردن تلف کنین.

تا میتونید محیط‌های مختلف ایجاد کنین. محیط پروداکشن و Staging باید تا حد ممکن با هم فرق داشته باشن. کدهای شکننده روی بیلدسیستم‌های شکننده راه‌اندازی کنین. پشت سر هم دیتابیس‌هاتون رو مایگریت کنین.

۱۰ هفته حقوق رو به مشتریان ناراضی ببازین.

متداوماً در تشخیص و حل خطاهای اضطراری مشتریان‌تون شکست بخورین. هیچ اهمیتی به مشکلات امنیتی ندین.

مستندات بیخود بنویسین.

کدها روی توی پیام‌های خصوصی توضیح بدین. مستنداتی بنویسید که هیچ‌کسی قرار نیست ازشون استفاده کنه.

۱۰ مهندس رو در یک پروژه بیهوده آزمایشی زندانی کنین.

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

وابستگی‌هایی به پروژه اضافه کنین که ۴۰۰ ساعت نگهداری نیاز دارن.

مهندسین باید به طور جداگانه همه کتاب‌خونه‌ها رو یاد بگیرن.

در تغییر استراتژی تاخیر داشته باشین.

هیچ‌وقت به شکست اقرار نکنین. تیم‌تون رو غرق هزینه‌ها کنین. توافقات ۸۰/۲۰ ای که می‌تونن وضعیت‌تون رو بهبود بدن رو نادیده بگیرین.

۱۰ مهندس صفر برابر استخدام کنین.

هزینه فرصت میتونه کشنده باشه. وزنه‌های مرده ممکنه متداوماً به تیم شما ضرر نرسونن، اما روی صندلی کسایی میشینن که میتونستن واقعا کمک کنن.

۵ مهندس منفی‌یک برابر استخدام کنین.

به وزنه‌مرده‌ها بسنده نکنین. به طور فعال مهندسینی رو استخدام کنین که فاجعه ایجاد میکنن و در برابر یادگرفتن مقاومت نشون میدن.

مانع اخراج شدن ۱۰ مهندس منفی‌یک برابر بشین.

قایق‌هاتون رو تکون ندین. هیچ ردی از شکست باقی نذارین. ضامن مهندسین بد بشین.

دلیل ۴۰۰ ساعت تریاژ باگ بشین.

برنامه‌های غیرقابل دیباگ بنویسین. روی همه‌چیز لایه‌های انتزاعی بکشین. کدهای اسپاگتی بنویسین. همه چیز رو حساس به شرایط اولیه کنین. از توابع Pure پرهیز کنین. هر جور دلتون خواست به پروژه وابستگی اضافه کنین. هر جا که ممکن بود بگید «رو ماشین من کار میکنه».

مهندس منفیمنفی ده‌برابربرنامه نویسیمهندسی نرم افزارمدیریت پروژه
وب سایت شخصی: https://avestura.dev
شاید از این پست‌ها خوشتان بیاید