دنبال کنیدمسعود شریفی پورخواندن ۱۴ دقیقه·۶ روز پیشآیا Engineering Manager باید هنوز کد بزند؟من هنوز کد زدن رو دوست دارم. خیلی زیاد.

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

IDE رو باز کنم، یه پروژه رو بالا بیارم، چند تا فایل رو تحلیل کنم، بفهمم مشکل کجاست، کد بزنم و یه Pull Request باز کنم.

برای کسی که سال‌ها مهندس نرم‌افزار بوده، این حس خیلی آشناست. (تعریف از خودم نباشه )

یه حس خوبیه که یادت میندازه از کجا اومدی و هنوز هم ازش لذت می‌بری.

اما هرچی بیشتر درگیر کارم به عنوان Engineering Manager شدم، بیشتر به این سؤال فکر کردم:

و هرچی بیشتر بهش فکر می‌کنم، به نظرم سؤال درست این نیست.

وقتی Software Engineer بودم، کدنویسی کار اصلی من بود.

کد زدم، Feature ساختم، Bug حل کردم، Code Review کردم، یه سیستم رو تغییر دادم.

آخر روز هم معمولاً یه چیزی داشتم که می‌تونستم نشونتون بدم.

اما وقتی مسیر Engineering Manager رو پیش می‌گیری، بازی عوض میشه.

دیگه قرار نیست ارزش تو با تعداد Featureهایی که خودت تحویل دادی سنجیده بشه.

قرارِ تیمی که باهاش کار می‌کنی بهتر کار کنه.

و تیم بتونه بدون اینکه برای هر تصمیمی بیاد سراغ تو، کارش رو جلو ببره.

این تغییر برای من یکی از سخت‌ترین بخش‌های Manager شدن بوده.

چون انجام دادن کار، خیلی وقت‌ها راحت‌تر از کمک کردن به دیگرانه که خودشون اون کار رو انجام بدن.

نه اینکه همیشه بد باشه، ولی خیلی راحت میتونه تبدیل بشه به یه عادت بد.

فرض کنیم یکی از مهندس‌های تیم مرخصی رفته و یه Feature نیمه‌کاره مونده.

منم می‌دونم این Feature چطوری باید پیاده بشه.

یا مثلاً یه مشکل فنی داریم که مدت‌هاست کسی وقت نکرده بره سراغش.

آیا این واقعاً بهترین استفاده از وقت من بوده؟

چون من EM هستم و هفته‌ام اصلاً قابل پیش‌بینی نیست.

ممکنه دو ساعت وقت برای یه کار کنار گذاشته باشم، ولی وسطش یه Incident اتفاق بیفته، یه مصاحبه داشته باشم، یه 1:1 جدی پیش بیاد، محصول یه مبحث فوری داشته باشه، مدیرم یه کار فوری بخواد یا یه Escalation از سمت مشتری برسه.

در خروجی چیزی که قرار بود کمک کنه، خودش تبدیل میشه به یه Dependency.

و این دقیقاً چیزیه که یه EM نباید درگیرش بشه.

البته اینجا هم مثل خیلی چیزهای دیگه، یه جواب قطعی وجود نداره.

بستگی داره به اینکه مسئله چیه، تیم چه شرایطی داره، بیزنس چه فشاری روشه، چه Stakeholderهایی درگیرن و کلی چیز دیگه.

اتفاقاً اینکه بتونی همین شرایط رو ببینی و تشخیص بدی الان باید خودم وارد بشم یا نه، خودش یکی از Skillهای مهم یه EMـه.

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

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

«خب خودت انجامش بده دیگه، چرا وقت تیم رو می‌گیری؟»

ولی شاید اون یه روز برای یکی از بچه‌های تیم خیلی ارزشمندتر از اون دو ساعت برای من باشه.

چون توی اون یه روز یه چیزی یاد می‌گیره که بعداً می‌تونه خودش انجامش بده.

این یکی از سخت‌ترین تحولات ذهنی برای Manager شدنه:

همیشه با سرعت‌ترین آدم برای انجام یه کار، بهترین آدم برای انجام اون کار نیست.

گاهی بهترین کاری که من می‌تونم انجام بدم اینه که کاری رو که خودم بلدم، به یکی دیگه یاد بدم تا خودش انجامش بده.

حتی اگر بدونم احتمالاً اولش خراب‌کاری هم می‌کنه.

بخشی از کار من دیگه فقط حل کردن مسئله نیست.

ساختن آدم‌هاییه که بتونن مسئله رو حل کنن.

یه خاطره از همین مبحث دارم که فکر می‌کنم خوبه اینجا تعریفش کنم.

یه Feature داشتیم که توی Plaing به یکی از بچه‌های تیم داده شد.

تازه وارد تیم شده بود و هنوز خیلی با سیستم آشنا نبود، ولی چیزی که ازش دوست داشتم، پشتکار و انگیزه‌اش بود.

خودم هم در جذبش نقش داشتم و از همون اول حس خوبی نسبت بهش داشتم.

وقتی Feature رو بهش دادیم، اوایل کار کنارش بودم.

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

به نظرم این یکی از جاهایی بود که اگر خودم وارد کار می‌شدم، شاید Feature با سرعت‌تر جلو می‌رفت، ولی اون آدم چیزی که باید یاد می‌گرفت رو یاد نمی‌گرفت.

QA هم تستش کرد و همه‌چیز ظاهراً درست بود.

ولی بعد از اینکه Feature رفت بالا، یه مشتری یه باگ جالب گزارش کرد.

سناریو این بود که مثلاً من به عنوان کارشناس ارائه، برای یه مشتری یه لینک پرداخت می‌فرستم.

مشتری لینک رو باز می‌کنه و پرداخت رو انجام میده.

ولی چیزی که اتفاق می‌افتاد این بود که اعتبار حساب کارشناس فروش‌رسانی که لینک رو ساخته و فرستاده بود، شارژ می‌شد!

یعنی به جای اینکه شناسه مشتری رو در نظر بگیریم، شناسه کسی که درخواست لینک رو ایجاد کرده بود وارد فرآیند شده بود.

اینجا هم می‌تونستم خیلی راحت وارد بشم و بگم:

ولی واقعاً هیچ‌کدوم اینا کمکی به رشد اون آدم نمی‌کرد.

پس دوباره سعی کردم کنارش باشم، ولی نه اینکه مسئله رو براش حل کنم.

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

حالا قرار نبود با اولین اشتباه، اون اعتماد رو پس بگیرم.

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

ولی تصمیم نگرفتم چون یه اشتباه اتفاق افتاده، از این به بعد خودم همه‌چیز رو کنترل کنم.

بعد از اون اتفاق، برای این آدم یه مسیر رشد جدی شروع کار شد.

کم‌کم مسئولیت‌های بیشتری گرفت، اعتمادبه‌نفسش بیشتر شد، سیستم رو بهتر شناخت و در نهایت تبدیل شد به یکی از بهترین Engineerهای تیم.

اگر اون روز من Feature رو ازش گرفته بودم، احتمالاً باگ هم با سرعت‌تر حل می‌شد.

ولی شاید یه چیز مهم‌تر رو از دست می‌دادیم:

این برای من یکی از مهم‌ترین تفاوت‌های Engineer بودن و Engineering Manager بود.

وقتی Engineer هستی، طبیعیه که تمرکزت روی حل کردن مسئله باشه.

ولی وقتی Manager میشی، باید کم‌کم یاد بگیری که همیشه قرار نیست خودت مسئله رو حل کنی.

گاهی وظیفه تو اینه که کنار آدم بایستی، کمکش کنی مسئله رو بفهمه، مسیر رو نشونش بدی و بعد اجازه بدی خودش بره و حلش کنه.

چون هدف فقط این نیست که این Feature در روز جاری درست بشه.

هدف اینه که آدمی بسازی که زمان آینده بتونه Feature بعدی رو خودش درست کنه.

به نظرم اینم یکی دیگه از اون جواب‌های صفر و یکیه که برای این مبحث زیاد می‌بینیم.

باید بتونم درباره Architecture، Performance، Reliability، Deployment و Technical Debt حرف بزنم.

اگر Deploymentها ۴۰ دقیقه طول میکشن و هر چند وقت یه بار هم Fail میشن، برای من مهمه بفهمم مشکل کجاست.

اگر یه تست مدام Flaky میشه، خوبه که بدونم چرا.

اگر تیم از یه Service خاص متنفره، باید بدونم چرا.

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

میتونم Pipeline مربوط به Deployment رو ارزیابی کنم.

میتونم یه Service رو که خوب نمی‌شناسم از روی کد بخونم.

میتونم برم ببینم چرا یه تست خاص مدام Fail میشه.

حتی میتونم یه تغییر کوچیک بدم که قرار نیست هیچ‌کس براش Sprint Plaing داشته باشه.

میخوام اونقدر نزدیک به سیستم بمونم که وقتی تیم درباره یه Technical Constraint، یه تخمین، یه Trade-off یا یه مشکل معماری صحبت میکنه، واقعاً بفهمم چی میگن.

این به نظرم یکی از خطرناک‌ترین حالت‌های EM شدنه.

مدیری که دیگه واقعاً Engineering رو نمی‌فهمه، ولی همچنان درباره Engineering تصمیم می‌گیره.

تا چند وقت پیش، یکی از مشکلات اصلی این بود که کدنویسی جدی Focus می‌خواست.

اگر قرار بود واقعاً یه چیزی بسازم، باید چند ساعت وقت خالی داشتم.

چون ممکنه ساعت ۹ صبح برنامه داشته باشم که روی یه مبحث فنی کار کنم و ساعت ۹:۱۵ اولین جلسه برنامه‌ریزی‌نشده‌ام شروع کار بشه!

الان میتونم یه Agent رو بفرستم دنبال یه مسئله.

«برو ارزیابی کن چرا Deployment ما اینقدر طول میکشه.»

بعد بذارم Implementation اولیه رو انجام بده.

این به نظرم یه استفاده خیلی خوب از AI برای EMـه.

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

مثلاً تحلیل Technical Debt، بهبود Observability، ارزیابی Pipeline، یه Flaky Test یا حتی فهمیدن اینکه یه Service قدیمی دقیقاً چه کاری انجام میده.

AI خیلی راحت‌تر از قبل بهم اجازه میده مفید باشم.

خیلی راحت‌تر هم میتونم فکر کنم مفیدم، در حالی که دارم مزاحم تیم میشم.

فرض کن تیم داره روی یه Feature کار میکنه.

منم با Claude چند ساعت کار میکنم و یه PR آماده میکنم.

ولی شاید اصلاً نباید من این کار رو انجام میدادم.

شاید یکی از Engineerهای تیم باید این کار رو انجام میداد.

شاید دارم یه تصمیم فنی رو از تیم می‌گیرم.

شاید زمان آینده تیم باید ساعت‌ها وقت بذاره تا بفهمه من چی ساختم.

برای همین به تازگیً اگر بخوام یه کار فنی رو خودم بردارم، سعی میکنم سه تا سؤال از خودم بپرسم.

اگر جواب بله باشه، احتمالاً بهتره خودم انجامش ندم.

چون اگر یکی از Engineerهای تیم بالاخره وقت پیدا میکنه و میره سراغش، چرا باید فرصت رو ازش بگیرم؟

«نه، احتمالاً هیچ‌وقت انجام نمیشه، چون همیشه چیزهای مهم‌تری داریم.»

مثلاً یه Technical Debt قدیمی که همه میدونن باید حل بشه، ولی هیچ‌وقت توی اولویت قرار نمی‌گیره.

این میتونه جای خوبی باشه که خودم برم سراغش.

من واقعاً نباید خودم رو بذارم روی Critical Path.

چون احتمال اینکه برنامه‌ام به هم بخوره خیلی زیاده.

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

اگر کاری که برداشتم بدون من متوقف میشه، احتمالاً انتخاب خوبی نبوده.

ولی باید حواسم باشه که یکی از مهم‌ترین مسئولیت‌های من، رشد دادن آدم‌های تیمه.

اگر هر کار جالبی رو خودم بردارم، عملاً دارم فرصت‌های یادگیری رو از بچه‌ها می‌گیرم.

ممکنه یه تیم داشته باشم که کلی کار تحویل داده، ولی آدم‌هاش رشد نکردن.

با همه این حرف‌ها، اینکه EM کلاً کدنویسی رو کنار بذاره هم به نظرم اشتباهه.

خودم دوست دارم چند ساعت در هفته رو عمداً برای کار فنی کنار بذارم.

حتی یه لیست از چیزهایی که درست نمی‌فهمم هم میتونه خیلی کمک کنه.

هر وقت وسط یه بحث فنی متوجه شدم دارم سر تکون میدم ولی واقعاً نمیفهمم طرف مقابل چی میگه، اون مبحث باید بره توی لیستم.

مثلاً در مدت اخیرً اگر بخوام عمیق‌تر روی محوراتی مثل ، Observability یا ابزارهایی مثل NER (Named-entity recognition) کار کنم، اتفاقاً AI کمک خیلی بزرگیه.

میتونم یه محور رو بردارم و از چند زاویه ارزیابیش کنم.

حتی روی یه نمونه واقعی از سیستم خودمون تحلیلش کنم.

من قرار نیست دوباره برگردم به همون Software Engineer چند سال پیش.

قرار نیست بهترین Technical Decisionها حتماً از من بیاد.

میخوام اونقدر فنی بمونم که وقتی تیم درباره یه مشکل حرف میزنه، بفهمم مشکل چیه.

وقتی یکی یه تخمین میده، بتونم سؤال درست بپرسم.

وقتی دو تا راه‌حل فنی داریم، بتونم Trade-offهاشون رو بفهمم.

و مهم‌تر از همه، وقتی تیم یه تصمیم فنی میگیره، بتونم تشخیص بدم که آیا واقعاً تصمیم خوبیه یا نه.

هر خط کدی که نمیفهمی، یه بدهیه که بالاخره باید با سودش پس بدی.

ولی اگر قسمت‌های مهم سیستم رو نفهمم، دیر یا زود این ناآگاهی خودش رو نشون میده.

یه روز تیم درباره یه مشکل حرف میزنه و من نمیفهمم.

یه روز یه تصمیم معماری گرفته میشه و من نمیتونم درست Challenge کنم.

یه روز یه تخمین اشتباه داده میشه و من نمی‌تونم تشخیص بدم.

اون موقع هزینه فاصله گرفتنم از Engineering رو پرداخت میکنم.

ولی نه برای اینکه ثابت کنه هنوز Engineerه.

Debug کن برای اینکه سیستم رو بهتر بشناسی.

روی Technical Debtهایی کار کن که هیچ‌کس وقت رسیدگی بهشون رو نداره.

ولی حواست باشه خودت رو تبدیل به Developer اصلی تیم نکنی.

چون از یه جایی به بعد، بیشتر کد زدن دیگه لزوماً نشونه Technical بودن نیست.

ممکنه فقط نشونه این باشه که هنوز نتونستی از نقش قبلیت دل بکنی.

من هنوز وقتی یه مسئله فنی جالب میبینم، دلم میخواد خودم برم سراغش.

احتمالاً این حس هیچ‌وقت جامع از بین نمیره.

ولی الان قبل از اینکه دست به کد بشم، سعی میکنم یه سؤال از خودم بپرسم:

«این کاری که الان میخوام انجام بدم، واقعاً به تیم کمک میکنه، یا فقط خودم رو خوشحال میکنه؟»

به نظرم برای یه Engineering Manager، جواب همین سؤال خیلی چیزها رو مشخص میکنه.

شاید وقتی Engineer بودم، موفقیت برای من این بود که خودم مسئله رو حل کنم.

ولی امروز، بخش مهم‌تری از موفقیت برای من اینه که آدم‌هایی داشته باشم که خودشون بتونن مسئله رو حل کنن.

و فکر میکنم این یکی از بزرگ‌ترین تفاوت‌های Engineer بودن و Engineering Manager بودنه.

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

بعضی قسمت‌های این مقاله رو سعی کردم فنی بنویسم، بعضی جاها عامیانه‌تر حرف زدم، بعضی جاها هم شاید یکم کتابی شده باشه. در واقع چیزی بوده که توی ذهنم بوده و سعی کردم همون رو تبدیل کنم به کلمه و با شما به اشتراک بذارم.

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

ولی اگر بخوام همه این مقاله رو توی یک چیز خلاصه کنم، برای من اینه:

به نظرم یکی از مهم‌ترین مهارت‌های یک EM اینه که بتونه ۳۶۰ درجه به ماجرا نگاه کنه.

بتونه تیمش رو ببینه، Stakeholderهاش رو ببینه، بیزینس رو ببینه، Customer رو ببینه و حتی جایی که داره سرویس می‌ده و تأثیری که تصمیم‌هاش اونجا می‌ذاره رو هم ببینه.

باید بتونی وقتی یک تصمیم جلوت قرار می‌گیره، خیلی شتابان بفهمی این تصمیم چه اثری روی تیمت داره، روی این Stakeholder چه اثری داره، روی اون یکی Stakeholder چی، روی Customer چه تأثیری می‌ذاره و اصلاً آیا داری یک مانع رو از سر راه تیم برمی‌داری یا خودت داری یک مانع تازه درست می‌کنی.

و برای اینکه بتونی همچین نگاهی داشته باشی، باید سیستم رو بشناسی.

نمی‌تونی از Engineering فاصله بگیری و انتظار داشته باشی همچنان بتونی درباره Engineering تصمیم‌های درست بگیری.

فقط باید حواسش باشه که برای چی داره کد می‌زنه.

قرار نیست با کدنویسی ثابت کنیم هنوز Engineer هستیم.

گاهی باید کد بزنیم تا سیستم رو بهتر بفهمیم، گاهی Debug کنیم، گاهی Pair بشیم، گاهی یک Technical Debt قدیمی رو جمع کنیم و گاهی هم با AI بریم سراغ چیزهایی که مدت‌هاست می‌دونیم باید بفهمیم یا درستشون کنیم.

این مقاله برای من خلاصه‌ای بود از کلی مقاله و نوشته‌ای که خوندم، چیزهایی که توی مسیر Engineering Manager شدن یاد گرفتم، تجربه‌هایی که داشتم و البته یک‌سری حس و فکر شخصی که مدت‌ها توی ذهنم بود.

دوست داشتم همه این‌ها رو یک‌جا با شما به اشتراک بذارم.

سوالات متداول

چرا آیا Engineering Manager باید هنوز کد بزند؟ - ویرگول اهمیت دارد؟

این موضوع به دلیل اطلاعات و کاربردهای مرتبط، مورد توجه کاربران قرار گرفته است.

آیا Engineering Manager باید هنوز کد بزند؟ - ویرگول چیست؟

در این مطلب اطلاعات، جزئیات و نکات مرتبط با آیا Engineering Manager باید هنوز کد بزند؟ - ویرگول بررسی شده است.

مهم‌ترین نکات درباره خودم چیست؟

جزئیات مهم و نکات قابل توجه درباره خودم در متن مقاله بررسی شده است.