اپیوئید

در تلاش برای رهایی از این گرداب

کار یا ریسرچ؟ بالاخره کدومش؟

۱۹ دی ۹۷

تو حوزه‌ای که ما هستیم (کامپیوتر)، آدما معمولا یکی از این دو مسیر رو میرن. یا ته ش میرن تو کار ریسرچ (استاد دانشگاه یا ریسچر شدن تو یه شرکتی) یا میرن مهندس میشن و بیشتر درگیر توسعه و پیاده‌سازی. میشن software engineer به عبارتی. یه مشکلی که کلا تو طول زندگی‌م داشتم این بوده که یه سری آدما از اول مسیر درس و research و researcher یا استاد دانشگاه شدن رو رفتن و یه سری آدم هم مسیر کار رو رفتن و مشکلی که وجود داشته این بوده که هیچ کدوم ایده‌ی مناسبی از اون حالت دیگه‌ه نداشتن. مثلا کسی که سر کار میرفته نمیدونسته که ریسرچ چطوریه (چه بسا اینکه ممکن بود اگه researcher میشد آدم خوشحال‌تری می‌شد) یا برعکس. همیشه دلم می‌خواست برای دو طرف براساس تجربیات خودم یه سری شفاف‌سازی‌ها بکنم و یه سری دید بهشون بدم راجع به مسائلی که وجود داره و الان تصمیم گرفتم این کار رو بکنم.
دقت کنید که آخر این مطلب قرار نیست به این نتیجه برسیم که ته ش بالاخره بریم تو کار ریسرچ یا بریم تو کار صنعتی. اینجا میخوام راجع به ابعادی که وجود داره صحبت کنم که تو تصمیم‌گیری‌هاتون بهش دقت کنید. کلا من همیشه سعی میکنم از یه نسخه پیچیدن برای همه اجتناب کنم و اگر کسی براتون نسخه پیچید کلا حرفش رو سعی کنید ignore کنید و صرفا از ابعادی که مطرح کرده یاد بگیرید. مثلا اگه یکی گفت آقا اپلای کن حتما ایران نمون خارج مثلا هواش خنک ه، شما کاری که باید بکنید اینه که در درجه‌ی اول اون قسمت اپلای کن ش رو ignore کنید و صرفا بگید آها، یه پارامتر دمای هوا هم هست که از این نظر خارج فلان جا خنک تره و ممکنه لازم باشه تو تصمیم‌گیری‌های آینده م لحاظ کنم. لذا من اسمش رو میذارم bullshit test. اگر کسی نسخه پیچید به این شکل، کلا ignoreش کنید.
حالا بریم سر قسمت بعدی. اولین نکته اینه که الان که دارم این پست رو مینویسم، حدود ۳ ۴ سال تجربه‌ی کار حرفه‌ای دارم (تسکولو، دیوار، رسید) و همچین تجربه‌ی ۲ سال و نیم ریسرچ (۲ سال ریسرچ تو ایران تو لیسانس، ۶ ماه اینجا تو کانادا تو ارشد) لذا حس میکنم مینیمم تجربه‌ی لازم رو دارم برای اینکه بتونم چند تا نکته بگم. **قطعا اگر میتونید با کسایی که تجربه‌ی بیشتری دارن هم صحبت کنید و من صرفا دارم براساس تجربه‌ی نه چندان زیاد خودم میگم. **
نکته‌ی دوم اینکه تمام نکاتی که دارم میگم قطعا یه سری biasها داره و اینکه به خیلی شرایط محیطی هم بستگی داره. نکاتی که دارم میگم برامده از مغزمه و مغز هم یه neural networkه که بسته به اینکه تو چه environmentی train شده، میتونه کانسپت‌های مختلفی generate کنه. خلاصه اینکه اینا همه نظر شخصی‌ه من براساس محیطی که من تجربه‌ش کردم و بهترین کاری که میتونم بکنم اینه که تا جاییکه میتونم از biasها جدا کنم حرفام رو ولی صد در صد شدنی نیست. سعی میکنم که تا جاییکه میشه صرفا ابعاد و طرز نگاه‌هایی که وجود داره رو مطرح کنم و نه اینکه یه جوری نشون بدم که انگار قضاوت من مطلقا درسته. صد البته که نظر شخصی خودم و preference خودم رو براساس شخصیت خودم میگم ولی لزوما قرار نیست برای بقیه هم برقرار باشه.

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

یه ذره راجع به ریسرچ بگیم. دقت کنید که در ادامه دارم خیلی شکمی و کلی صحبت میکنم برای اینکه برای مخاطب عام باشه. اینم بگم که تجربه‌ی ریسرچ من تو حوزه‌ی هوش مصنوعی (به طور خاص NLP تو ارشد و IR و recommender system تو دوره‌ی کارشناسی) بوده و راجع به حوزه‌های دیگه ممکنه detailها فرق بکنه. تو ریسرچ هوش مصنوعی general structureی که وجود داره اینه که ته ش میخوان همه‌ی کارا رو بدن به یه ماشین انجام بده. مثلا به ماشین بگی فعلا چیز رو برای من سرچ کن. یا مثلا بهش بگی فلان متن رو واسه من ترجمه کن. از این چیزا. بعد براساس این اهداف، شکسته میشه به یه سری field. مثلا یه فیلد داریم به نام Information Retrieval که خیلی خیلی کلی بخوام بگم روی الگوریتم‌های search کار میکنه. چیزی که گوگل رو گوگل کرده. یه فیلد داریم مثلا به اسم NLP یا Natural Language Processing. تایپ کارایی که میکنند مثلا اینه که میخوام فلان متن رو به صورت اتوماتیک از انگلیسی تبدیل کنیم به فرانسه. یا میخوایم فلان کامنت تو آمازون رو اتوماتیک ببینیم که نظر یارو مثبت بوده یا منفی بوده. از این تیریپ کارا. پس هر field هم شکسته میشه به یه سری مساله‌ی مختلف. مثلا همون طور که گفتم machine translation یه تایپ مساله تو حوزه‌ی nlp هستش. بعد حالا ریسرچرها چیکار میکنند؟ برای این مسائل میان الگوریتم و مدل ارائه میدن. مثلا فرض کن اولین نفر میاد یه راه حل x برای مساله‌ی machine translation ارائه میده. بعد حالا چه اتفاقی میفته؟‌ researcherهایی بعدی میان سعی میکنند که این مدل ارائه شده‌ی فعلی رو براساس پارامترهای مختلف بهبود بدن. مثلا یکی میاد سعی میکنه دقت ش رو بیشتر کنه. یکی میاد سرعتش رو بیشتر کنه. یکی سعی میکنه memory requirementش رو کم کنه که رو گوشی‌های موبایل قابل اجرا باشه. این مدل‌ها رو هم چطور بهتر میکنند؟ معمولا اینطوریه که یا میان کلا یه مدل/الگوریتم دیگه ارائه میدن. یا میان مثلا اون مدل و الگوریتم فعلی رو می‌شکنند به componentهای مختلف و سعی میکنند مثلا فلان component خاص رو بهبود بدن. تاریخ علم نشون داده که بهبودها آروم و کوچیک کوچیک هستند و به عبارتی پیشرفت علم یه فرایند incremental هستش. کلی ریسرچر از سراسر دنیا رو کارهای هم کار میکنند و کارهای هم رو کوچولوکوچولو پیشرفت میدن تا مثلا اون الگوریتم به یه جای معقول میرسه.

ریسرچ یه فرایند incremental هستش.

پس خیلی شکمی بخوایم بگیم، ریسرچرها سعی میکنند با خوندن paperهای خوب همیشه خودشون رو update نگه دارن و همش در جستجوی ایده‌ و بهبود باشن و بعد که چیزی پیدا کردن میرن سراغ اینکه پیاده‌سازی ش کنند و ببینن جواب میده یا نه. اگه جواب نداد باید ببینن چرا جواب نداده و آیا میتونند مشکلش رو حل کنند یا نه. وقتی هم که جواب داد، سعی میکنند محتوای کافی دست و پا کنند و داخل یه کنفرانس خوب سابمیت کنند به صورت مقاله. دقت کنید که کنفرانس‌های زیادی وجود داره ولی تو هر فیلد معمولا فقط دو سه تا کنفرانس تاپ وجود داره که ارزش سابمیت کردن دارن و بقیه‌ی جاها واقعا پوینتی ندارن. بعد حالا شما پیپر میدی و یه جای خفن اکسپت میشی و خیلی خوشحال میشی. بعد میری کشوری که کنفرانس توش برگزار میشه کارت رو ارائه میدی و یه دو سه روز تو اون کشور میچرخی و برمیگردی دانشگاه. حالا سعی میکنی یا همین کار رو ادامه بدی و ایشالا برای کنفرانس بعدی یا میری سراغ یه کار دیگه. تابستون هم اگه شد میری یه شرکتی internship. بعد هم که دوران ریسرچ ت تموم شد (مثلا پی اچ دی) اپلای میکنی برای research scientist شدن یا استاد دانشگاه شدن و تقریبا همین فرایند رو ادامه میدی که البته من راجع به عالم استاد دانشگاهی خیلی ایده‌ای ندارم.
باز تاکید کنم که این مدل خیلی کلی بود و واقعا زندگی دقیق یک ریسرچر نیستش ولی به نظرم تخمین خوبی زدم برای اینکه برای همه قابل درک باشه.

حالا یه ذره تحلیل و بررسی که اکثرش رو از اینجا دارم ترجمه میکنم با تصرف و تلخیص (نویسنده‌ش خودش google brain بوده):

۱. مسائل ریسرچی مسائلی هستند که خیلی خوش دست نیستند و قالب مشخصی ندارن. نه سوالاتشون. نه جواباشون. و هر روز هم مسائل جدیدی از دل مسائل قبلی در میاد. اینکه چهارچوب مشخصی ندارن هم مزیت حساب میشه هم عیب. مزیت ش اینه که کلا قضیه خلاقانه میشه. ینی به نظرم خلاقانه تر و challengingتر(یه خواننده‌ی خوب باید سوال بپرسه که از چه نظر challengingتر چون این واژه خوش تعریف نیست ولی حالا اگه یادم موند بعدا میگم) از مثلا software development هست به نظرم. برای اینکه یه مساله‌ی ریسرچی رو حل کنید باید خلاقیت به خرج بدید و ایده بزنید. عیب ش اینه که خب این کار زحمت داره دیگه. برای اینکه آدم ایده زنی بشید باید همش مشغول پیپر خوندن باشید و تئوری‌تون رو قوی کنید و کار تئوری خوب کار زیاد میطلبه. این نویسنده‌ی google brainه حرف جالبی میزنه، میگه به مساله‌ی ریسرچی به چشم exam question نگاه کنید کلا fail میشه قضیه.

۲. نتایج researchتون معمولا مساله‌ی خاصی رو حل نمیکنند و صرفا یه بهبود کوچیک ن اکثرا. غالبا این اتفاق میفته که شما میای مثلا یه مدلی رو ۵ درصد بهتر میکنی. نکته‌ای که وجود داره اینه که ماهیت research اینه که آدم‌ها قدم‌هاشون روی هم برمیدارن و با هم فیلد رو پیشرفت میدن. این هم خوبه هم بد. بدی ش اینه که خب output کارتون به تنهایی خیلی گنده نیست معمولا. خوبی‌ش اینه که برداشتن قدم‌های کوچیک خیلی خیلی راحت از یه نتیجه‌ی خیلی بزرگ گرفتن ه (که معمولا این نتیجه‌ی خیلی بزرگ گرفتن خیلی کم رخ میده)

۳. کار شما به مدت خیلی کمی “جدید” و “غالب” میمونه. حالا بستگی داره چقدر براتون مطرح باشه. تو software development شما میای یه software مینویسی مثلا تا مدت‌ها ملت ازش استفاده میکنند و جایگزینی نداره. تو ریسرچ شما یه پیپر میدی تو خفن ترین کنفرانس، سال دیگه رو پیپر شما پیپر دادن یا ریزالت‌های بهتر از شما گرفتن و دیگه پیپر شما بهترین ریزالت رو در بین کارها نداره. ظرف یک سال کار پارسال شما عقب میمونه از بقیه. خلاصه اینطوری بگم، معمولا اینطوری نیست که کار شما در صدر جدول راه‌حل‌‌های اون مساله باشه. سال بعد اومدن کار بهتر از شما کردن. فراموش نکنیم که این مساله شاید مطرح نباشه و اینکه شما یه کار خفن بکنید و بقیه بیان کار شما رو ادامه بدن اتفاقا خیلی هم خوبه حالا هر چند که کار شما دیگه در صدر جدول کارها نباشه. مثلا کارهای انجام شده تو ۲۰۰۰ روی شبکه‌های عصبی هم سهم گنده‌ای تو پیشرفت امروز شبکه‌های عصبی دارن! متریک citation یکی از متریک‌هایی هست که نشون میده کار شما چقدر تو کار بقیه تاثیر داشته.

۴. تقریبا تنهایی کار رو میبرید جلو. ببین تو ریسرچ غالبا شما به تنهایی روی یه مساله کار میکنید و حالا ممکنه بعضی اوقات از بقیه هم کمک بگیرید ولی theme غالب اینطوری‌ه که معمولا first author مقاله کسی هست که بیشترین کار رو کرده. حالا این هم مزیت هم عیب ه. مزیت ش اینه که نظارت خاصی روتون وجود نداره و آزادی عمل کامل دارید. عیب ش اینه که خودتونید و خودتون دیگه. مثلا تو مسیر اشتباه باشید و متوجه نباشید. اگه کار شکست بخوره تو اون غم شکست خوردن کار ه تنهایید و از این چیزا. البته باید حتما از استادتون هم کمک بگیرید تا ریسک کار کم بشه. برای آدم‌هایی که خیلی فاز کار گروهی ندارن این میتونه مزیت خیلی خوب باشه.

۵. ریسرچ ریسک‌های خودش رو داره. گفتیم که مسائل ریسرچی غالبا خیلی structure مشخصی ندارن و وقتی شما یه راه حلی میدی از اون اول نمیشه گفت که کار میکنه یا نه. حالا شما مثلا فرض کن که ۳ ماه زمان گذاشتی کلی مقاله خوندی که بتونی یه ایده بزنی. بعد مثلا میای سه هفته هم ایده ت رو پیاده میکنی. بعد مثلا میبینی ایده‌ه نگرفت. حالا تکلیف چیه؟ استرس میگیری که مثلا ددلاین فلان کنفرانس رو miss نکنم. استادم ازم انتظار داره بالاخره مقاله بدم و گرنه ممکنه fundم قطع بشه و از اینجور چیزا. (کار صنعتی هم ریسک‌های خودش رو داره که در بخش بعدی میگم)

۶. کل سابقه‌ی ریسرچ شما تو یه عدد خلاصه میشه. عددی به نام h-index. وقتی شما h-indexتون مثلا ۲۰ باشه معنی‌ش اینه که ۲۰ تا مقاله دارید که هر کدوم ۲۰ تا مقاله بهشون ارجاع دادن. و بدی ش هم اینه که این عدد پابلیک هست و تو اینترنت توسط همه قابل مشاهده هستش تو google scholar. این نشون میده که هر چقدرم شما آدم توانمندی باشید، اینکه رو چه قضیه‌ای کار میکنید تو عدد h-index شما و قضاوت بقیه راجع به شما تاثیر داره در حالیکه شما ممکنه واقعا آدم توانایی باشی ولی به هزار دلیل h-indexت بالا نباشه. من الان هر paperی میخونم، اولین کاری که میکنم اینه که میرم google scholar نویسنده‌ی اول و نویسنده‌ی آخر رو چک میکنم. وقتی میبینم h-index نویسنده‌ی آخر که معمولا استاد هستش، عدد بالایی هستش، روی قضاوتم از اون پیپر تاثیر مثبت میذاره. یه چیزی که راجع به ریسرچ شخص من رو اذیت میکنه اینه که حس میکنم دغدغه‌ی ریسرچا بیشتر act پیپر دادن و گرفتن citation هستش تا حل خود مساله. خیلی روی پیپر دادن obsession دارن (نظر و حس کاملا شخصی)

۷. یه چیز باحال راجع به ریسرچ اینه که اینقدر مساله زیاده که شما راحت میتونید اون چیزی که علاقه دارید رو انتخاب کنید. هر تابستون هم ممکنه برید internship و روی یه سری مسائل صنعتی که با ریسرچ حل میشن کار کنید و یه محیط مختلف رو تجربه کنید. خلاصه تنوع قضیه خیلی زیاده و جای مانور برای خلاقیت بالا. کلا برای شخص من، جذاب‌ترین چیز راجع به ریسرچ جای خلاقیت بالا و تنوع مسائلش و challenging بودنش از منظر تئوری و فکری هستش. یه جمله‌ی معروفی تو صنعت مهندسی نرم‌افزار وجود داره که میگه: همه‌ی مسائل قبلا حل شدن.

حالا که ریسرچ رو بررسی کردیم، بریم یه ذره سراغ کار و ببینیم general structure زندگی یه software engineer چه شکلی هستش. زندگی یه software engineer به خصوص اونایی که تو حوزه‌ی software as a service کار میکنند به این شکله که یه محصول نرم‌افزاری ی وجود داره که مخاطب‌هاش یا خاص ن یا عام هستند. حالا شما قراره اون محصول رو طراحی کنید از اول یا اینکه اون محصول وجود داره میخواین براساس نیازهای جدید بهش قابلیت اضافه کنید و همچنین ازش نگه‌داری و پشتیبانی کنید. خلاصه خروجی شما یه نرم‌افزار برای یه سری آدم هستش. به عنوان مثال، من بعد از کار کردن تو دیوار، به پروژه‌ی رسید که پروژه‌ی جدید شرکت بود ملحق شدم. موقعی که من به رسید ملحق شدم، یه نرم افزار working وجود داشت و یکی از تارگت‌هاش این بود که پرداخت کرایه تاکسی با رسید صورت بگیره. موقعی که من اضافه شدم بیشتر کارها از جنس maintenance و نگه‌داری بود. چیزی که همیشه جزو ثابت پروژه‌های نرم‌افزاری هستش ولی خب خلاقیت و جای مانور توش کمتره. بعد از مدتی به این نتیجه رسیدیم که میخوایم مدل قضیه رو عوض کنیم و بشیم کیف پول و مثلا شما بتونی به یه contact تو گوشی‌ت بدون اینکه شماره کارتش رو بدونی پول واریز کنی. وقتی نیازها و صورت مساله و مخاطب کلا عوض شد، نتیجتا معماری نرم‌افزار هم باید عوض میشد. معماری جدید باید جوری چیده میشد که اولا تا جاییکه میتونه ساده باشه (برای افزایش تغییرپذیری و نگه‌داری)، تا جاییکه میتونه سریع باشه و با افزایش استفاده‌ی کاربران کند نشه و اینکه نسبت به نیازهای آینده flexible باشه. ینی اینطوری نباشه که بعدا اگه یه تیکه‌ی کوچیک از صورت مساله عوض شد، لازم باشه هزینه‌ی زیادی برای تغییر به سیستم تحمل بشه. به صورت خلاصه طراحی یه معماری مناسب نیاز به تجربه و دید خوب مهندسی نرم افزار داره و قسمتی هستش که خیلی challenging هستند و یه سری آدم اصن تایتل شغلی‌شون معمار نرم‌افزار یا software architect هستش. بعد که معماری جدید رو چیدیم و سیستم رو مهاجرت دادیم، آروم آروم براساس نیازهامون بهش فیچرهای جدید اضافه کردیم که اضافه کردن فیچرهای جدید باید طوری باشه که اولا تا جاییکه میشه با کمترین تغییر تو سیستم صورت بگیره، خوانا و تمیز باشه، قابل تغییر و نگه‌داری باشه و از این چیزا. و در نهایت هم این اواخر بیشتر درگیر نگه‌داری و باگ فیکس و اینجور چیزا بود. خب این مثال تقریبا همه نوع کاری داشت. از کارهای challenging و نیاز به خلاقیت (معماری نرم‌افزار) و از کارهای کمتر challenging و شاید خسته کننده ولی مهم (نگه‌داری). حالا درجه‌ی هر کدوم از اینا بسته به محصول و اینا فرق میکنه. محصولی که قراره ۱۰ میلیون آدم رو هندل کنه یه سری challengeهای اضافه‌ای داره نسبت به محصولی که قراره کلا ۱۰۰ تا آدم رو هندل کنه.

حالا یه روزی کاری تو شرکت برای من چطوری بود؟ بچه‌ها معمولا ۱۰ ۱۱ میومدن. منم از همه دیرتر میومدم حدود ساعت ۲ ظهر. اولین کار این بود که میرفتم تو بالکن شرکت با باقر یه سیگار میزدیم. بعد با باقر راجع به کارهایی که مهمه انجام بشن صحبت میکردیم و نظر خودم رو میگفتم و نظر اون رو میشنیدم و خلاصه صحبت میکردیم. بعد میرفتم پای ماشین م و میرفتم تو sentry ارورهای دیروز رو چک میکردم ببینم کاربرا اروری چیزی خوردن یا نه و اگر ارور خوردن ببینم مشکل چی بوده آیا باگی بوده یا نبوده. بعد اگر مهناز (ساپورت) نیاز داشت چیزی رو چک کنم براش چک میکردم. بعد نگاه میکردم چه تسک ی دارم. بعد شروع میکردم روی اون تسک کار کردن. اگر تسک ه توش معماری اینا داشت، بعضی اوقات براساس اینکه چیزی که حس میکردم خوب ه میرفتم جلو و بعضی اوقات هم با بچه‌های فنی تیم دورهمی یه صحبت کوتاه میکردیم که کدوم approach رو بریم جلو. بعد تسک هم یا merge request میزدم به بچه‌های فنی که reviewش کنند و اگر اوکی بود مرج ش کنند یا اینکه فیدبک شون رو بذارن. و همچین یه سری اوقات هم من کد بقیه رو review و مرج میکردم. فرایند cooperative بود. بعضی اوقات هم ایمان و حامد و آرمان اگه میخواستند راجع به sideهای بیزنسی و مارکتینگی و نیازهای محصولی صحبت کنند یه صحبت دورهمی با بچه‌ها میکردیم. روزانه هم جلسات daily برگزار میکردیم که هر کسی به صورت خلاصه میگفت رو چی کار کرده و فردا احتمالا میخواد بره سر چی. بعضی روزا هم میرفتم مصاحبه‌ی مرحله‌ی اول مهندسین نرم‌افزار و مصاحبه‌شون میکردم و بعد میومدم و گزارشم رو مینوشتم. و اینجوری روز تموم میشد. بعضی اوقات هم درگیر کارای دیگه میشدم. مثلا یه بار با سینا و ملیکا مسئولیت برگزاری هکاتون داخلی کافه بازار رو به عهده گرفتیم. با وحید و پوریا صحبت میکردم راجع به دغدغه‌های راجع به شرکت و اینکه چه چیزایی شرکت بهتره حواسش باشه که من الان حس میکنم حواسش نیست. بعضی اوقات به آدما فیدبک میدادم. که فلان مثلا فلان کارت خیلی خوب بود ایول. بعضی اوقات هم میگفتم که فلانجا بهتر بود فلان مساله رو فلان طور مطرح نمیکردی. و طبعا بقیه هم بهم فیدبک میدادن. خلاصه اینجور چیزا.

حالا یه ذره تحلیل و بررسی :

۱. توی کار شما روی محصولی کار می‌کنید که حاصل کار شما مستقیم به دست کاربر نهایی میرسه. مثلا یه چیزی که راجع به کار کردن تو دیوار خیلی دوست داشتم این بود که خب سایت مشهوری بود و میلیون‌ها آدم تو ایران ازش استفاده میکردن و وقتی من به عنوان اولین taskم تو دیوار روی query prediction کار کردم و وقتی دیپلوی شد و آدما تو دیوار میخواستن سرچ کنند prediction میدیدن عمیقا حس خیلی خیلی خوبی بهم دست میداد. تفاوت ش با ریسرچ اینه که تو ریسرچ نتیجه‌ی کار شما خیلی غیرمستقیم و با واسطه به دست آدما میرسه ولی تو کار عملا هر کاری میکنید مستقیم به دست کاربر میرسه. حالا باید ببینید این موضوع چقدر ارضاتون میکنه. بعضی اوقات هم شما اصن care نمیکنید کیا از نتیجه‌ی کار شما استفاده میکنند.

۲. بحث سرعت delivery. معمولا شما تو کار، هر فیچری که میدید اگه اوکی باشه ریلیز میشه و به دست مردم میرسه. تو ریسرچ شما ریلیزت چه زمانی ه؟‌ زمان کنفرانس ه. ینی شما باید هی واسه ددلاین کنفرانس‌ها برسه و اونجا پابلیش کنی کارت رو. تعداد کنفرانس‌های خوب بعید میدونم بیشتر از ۲ ۳ باشه. تو NLP که ۳ تا کنفرانس خوب بیشتر نداریم و بقیه چرت ن تقریبا. این هم باز میتونه مزیت یا عیب باشه. تو ریسرچ شما ددلاین‌های طولانی تری دارید ولی عوضش کار سخت تری دارید. تو کار شما ددلاین‌های کوتاه تری دارید (مثلا فلان کار باید تو ۳ روز انجام شه) ولی عوضش کاره هم راحت تره. بستگی داره با کدوم setting شما بیشتر حال میکنید. ولی تو محیط کار زیاد پیش میاد که تخمین اشتباه زده میشه و یه کاری که تخمین زدیم ۱ هفته طول میکشه واقعا ۳ هفته طول کشیده و خب اون موقع شما ممکنه همش استراحت زیادی بکشید در حالیکه تو ریسرچ شما زمان زیادی دارید تا ددلاین کنفرانس و معمولا این اتفاق خیلی رخ نمیده شاید.

۳. تو کار خیلی روی کیفیت پیاده‌سازی مانور داده میشه. ببین یه اشتباهی که خیلی همه میکنند اینه که فکر میکنند کار صرفا پیاده‌سازی ه، صرفا برنامه‌نویسی ه، صرفا کد زدن ه، و حتی میگن ریسرچ خوبی ش اینه که پیاده‌سازی هم داره. خب این استدلال کامل غلط ه دوست من. به خاطر اینکه اون کیفیتی که تو کار مورد منتظر انتظار هست by far با اون کیفیتی که تو ریسرچ استفاده میشه فرق داره. تو کار شما باید کدی بزنی که خوانا باشه، پیاده‌سازی ت باید جوری باشه که هزینه‌ی زمانی کدت زیاد نباشه که تو تعداد کاربر بالا به مشکل بخوری، کدت باید تغییرپذیر باشه، ینی بعدا اگه یه سری نیازهای مساله تغییر کرد، لازم نباشه کلا از اول پیاده سازی صورت بگیره، کدت باید تا جای ممکن ساده باشه (یه tradeoff بین سادگی و گسترش پذیری وجود داره). حالا باید ببینی این موضوع چقدر برات جذابیت داره. تو نگاه من، اینجور کد زدن، یه هنر ه. کد خوب یه جورایی مثل نقاشی میمونه. و من واقعا از جنبه‌ی هنری قضیه لذت میبرم. وقتی یه کد خوب خوشگل تروتمیز و گسترش پذیر و general purpose بدون قربانی کردن سادگی مینویسم، اصن دوپامین ترشح میشه تو خونم (همین الان که بیانش کردم هم حس خوبی دارم). ولی تو ریسرچ قسمت تئوری قضیه مهمه. تو فیلدهای هوش مصنوعی، اکثر کارها هدفشون اینه که یه مساله‌ای حل کنند نه اینکه یه ابزار بدن که بقیه استفاده کنند. نتیجتا همه کدها رو سعی میکنند سریع بزنند بره که به ددلاینشون برسن و نتیجتا کدها کثیف ن. الان یه نمونه از کدی هستش که سال ۲۰۱۷ زده شده و من دارم سعی میکنم یه تغییری روش بدم. خدا نصیب گرگ بیابون نکنه که بخواد روی یه کدبیس theano کار کنه اونم وقتی که به این شکل نوشته شده:

اون m_ چیه. X_ چیه. Xx__ چیه. اخه چرا واقعا؟ خب درست اسم بذارید دیگه. ینی الان من کلا کارم این شده که بیام این کد رو مهندسی معکوس کنم هی print بذارم ببینم فلان متغیر چیه درحالیکه اگه اسمش رو درست انتخاب میکردن من این همه لازم نبود بدبختی بکشم. داک ماک هم که کلا هیچی. تو کدهای هوش مصنوعی این چیزا خیلی مهمه به خاطر اینکه کدهاشون پیچیده س و اگه این نکات رعایت نشه خواننده اصن نمیفهمه چی به چیه. بعد مثلا یه سری بدبختی دیگه هم وجود داره. فرض کن یه ماتریسی وجود داره که روش محسابه داره صورت میگیره. بعد کد طرف رو میخونی میبینی کلی کار عجیب غریب کرده با x که اصن تو پیپرش نیست. بعدا کاشف به عمل میاد که این یه سری optimization بوده برای convergence و اصن ربطی به پیپر نداره. خب یه کامنتی چیزی بالای اون لامصب بذار بفهمیم چیه و داره چیکار میکنه. بعد اینا میان لینک github پیاده‌سازی‌شون رو میذارن تو paper که contribution حساب بشه و احتمال اکسپت تو کنفرانس بره بالا درحالیکه در عمل اون کدی که میذارن اصن کیفیت کافی برای اینکه بقیه بیان ازش استفاده کنند رو نداره.

۴. تو کار بعضی اوقات کارها خسته کننده میشن بعضی اوقات هم خیلی جذاب. من موقعی که اکثر کارهامون maintenance بود خیلی خوشحال نبودم چون زیاد challenging نبود هر چند که لازم و مهم بود. برعکس موقعی که مثلا یه نیازی مطرح میشد یه طراحی و معماری‌ی باید صورت میگرفت خیلی حال میداد که با بچه‌ها بحث میکردیم. نقاط قوت و ضعف راه‌حل ها رو بررسی میکردیم و به معنای واقعی critical thinkning بود که خیلی حال میداد. تو کار این خلاقیت و تنوع خیلی بالا پایین داره ولی تو ریسرچ همیشه این خلاقیت ه هستش و حوصله ت سر نمیره. تو کار بسته به اینکه کارت چیه، ممکنه زیاد حوصله ت سر بره یا نره.

۵. یه تفاوت خیلی خیلی مهم بین کار و ریسرچ محیط دورتون هستش. به صورت کلی محیط کاری محیطی صمیمی هستش، کارهای گروهی و تیمی هستش ولی ریسرچ رو من کار گروهی به هیچ وجه حساب نمیکنم. در بهترین حالت second author یه کار گروهی با first author داره ولی باز به این یه کار تیمی نمیگم که چندین نفر با نقش‌های مختلف با دغدغه‌های مختلف با طرز نگاه‌های مختلف توش درگیر باشن. خب این مزایا و معایب داره. مزیت ش اینه که محیط کار خیلی خیلی محیط پویاتر و جذاب‌تر و صمیمی‌تری هستش به نظر من. تو شرکت مثلا سر تصمیمات معماری با هم صحبت میکردیم. جلسات محصولی بیزنسی داشتیم با تیم. با هم constantly در تعامل بودیم و این تعامل ه خودش خیلی جذاب بود. چون که هر کسی یه نگاهی داشت و آدما شبیه هم نبودن و این قضیه رو جذاب میکرد. یکی دید بیزنسی داشت. یکی دید فنی. یکی دید محصولی. و وقتی ادما با نقطه نظرها و دغدغه‌های مختلف یه مساله رو بررسی میکنند، خیلی جذاب میشه اون بحث که بالاخره چطوری باید تصمیم بگیریم که همه‌ی دغدغه ها رعایت شه. و این پویایی محیط چیزی هستش که خیلی خیلی خیلی خیلی دلم براش تنگ شده. محیط آزمایشگاه واقعا boringه و اصلا پویایی محیط شرکت رو نداره. یکی قضیه‌ی پویایی هست. یک قضیه‌ی دیگه که خیلی خیلی مهم هست بحث رشد شخصیتی هستش. تو محیط کار چون محیط کاملا گروهی و براساس تعاملات گروهی هستش و آدم‌ها حساسیت‌های مختلف و objective functionهای مختلف و دغدغه‌های مختلف دارن، در اثر این تعاملات، شما یه سری فیدبک از بقیه میگیرید و این باعث رشد شخصیتی تون میشه. به عنوان مثال، من موقعی که وارد شرکت شدم آدمی بودم که خیلی team player نبودم ولی موقعی که از شرکت خارج شدم به نظرم خیلی آدم team playerتری شده بودم. یا یه مثال دیگه اینکه من موقعی که وارد شرکت شدم آدم بسیار قضاوت‌کننده‌ای بودم ولی موقعی که از شرکت خارج شدم خیلی خیلی کمتر قضاوت‌کننده بودم. اینا همه تاثیرات محیط کاری بود و به خاطر فیدبک‌هایی بود که از آدما گرفتم. تو محیط کاری و گروهی، شما رشد شخصیتی پیدا میکنید. نمیدونم موافق هستید یا نه ولی به نظر میرسه که خیلی از استادهای دانشگاه، آدم‌های از لحاظ شخصیتی جالبی نیستند برخلاف قطب علمی‌شون. این حالا ممکنه نظر من باشه و باهاش موفق نباشید ولی اگر موافق باشید، دلیل این موضوع که استادهای دانشگاه زیادی رو میبینیم که از لحاظ شخصیتی مشکلات عجیبی دارن، به نظر من دلیلش این بوده که طرف همیشه مشغول ریسرچ بوده که یه کار تقریبا فردی ه و تعامل تیمی نداره. وقتی شما تعامل تیمی ندارید، از بقیه فیدبک نمیگیرید و این باعث میشه که ایراداتتون برطرف نشه و نتونید آدم شخصیتا بهتری بشید. لذا به نظر من، وقتی شما وارد شرکت میشی و بعد چند سال خارج میشی، خیلی شخصیت پخته‌تر و بهتری پیدا کردی. عیب این قضیه‌ی تیمی و گروهی و تعاملی بودن چیه؟ اگه شما آدمی باشی که حوصله‌ی مسائل انسانی و هندل کردن حساسیت‌های مربوطه رو نداشته باشید اذیت میشید. اگه شما دوست داری تنها بشینی کارت رو بکنی و تو کارت فقط challenge محتوایی بخوای نه challenge انسانی، خب محیط کار یه مقدار اذیتت میکنه احتمالا. به خاطر conflict با آدم‌ها.

۶. یه نکته هم اینه که تو کار رقابت سر گرفتن market و پول دراوردن هستش. تو ریسرچ خیلی رقابت مستقیمی وجود نداره. اصن به کی میگی رقیب؟ به کسی که با تو روی یه مساله کار میکنه؟ خب پیپر جفتتون چاپ میشه. خیلی اینطوری نیست که یکی زنده بمونه اون یکی حذف شه. باید ببینی کدوم رقابت برات جذاب‌تره. البته به عنوان software engineer شاید برای تو صرفا مهم باشه که حقوقت رو بگیری بری ولی من خیلی دوست داشتم مثلا تو رقابت با رقبامون برنده بشیم :)

۷. تا حدی این موضوع رو تو بخش‌های قبلی گفتم و خیلی شبیه به اون رشد شخصیتی هست ولی یه ذره تفاوت داره. تو کار soft skillهاتون خیلی پیشرفت میکنه. مثلا قابلیت leadership. اینا مهارت‌هایی هستند که همه‌ی جای زندگی به درد آدم میخورن.

فعلا اینا چیزایی بود که به ذهنم رسید. الان ۴ صبحه اینجا و خستم. اگر بعدا چیزی به ذهنم رسید اضافه میکنم. ولی امیدوارم تونسته بشه یه سری تفاوت‌ها رو بین کار و ریسرچ براتون مشخص کرده باشه. نظر شخصی خودم رو بخوام براساس علایق و شخصیت خودم بگم، واسه من ریسرچ از نظر challenging بودن جذاب‌تره، محیط کار برام از نظر پویا بودن و هنرمندانه بودن کار software development. من فعلا در لحظه پلن م اینه که بعد از ارشد وارد مسیر machine learning engineer شدن بشم و اون رو هم امتحان کنم چون تا حالا امتحانش نکردم به اون شکل. مسیری که ترکیب دو تا مسیر قبلی هستش. هم software engineer هستی و هم کار علمی میکنی. البته خلاقیت research رو نداره اصلا به اون شکل چون تو صرفا مدل‌های state of the art (مدل‌های قابل قبول ارائه شده توسط researcherها) رو پیاده‌سازی میکنی معمولا و خودت ایده‌ی خاصی نمیزنی به اون شکل. ولی خب باز همینکه یه ذره کار علمی قاطی شه جذاب تر میکنه قضیه رو. این براساس علایق و شخصیت خودم بود و به عنوان پیشنهاد نمیگمش! صرفا خواستم بگم خودم دارم چیکار میکنم و علایقم چیه.

comments powered by Disqus