مبینا پاک از چالش‌هایش به عنوان یک برنامه نویس می‌گوید!

مبینا پاک از چالش‌هایش به عنوان یک برنامه نویس می‌گوید!

چالش‌های من به عنوان یک برنامه نویس!

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

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

برای هر کسی که رویایم را شرح می‌دادم یا می‌گفتم که می‌خواهم مدیر ناسا شوم مرا به سخره می‌گرفت. نباید هرگز رویای‌تان را با کسی در میان بگذارید چون بقیه چشم‌انداز (VISION) شما را ندارند و انرژی مثبت شما را می‌گیرند؛ البته بعد‌تر به اصل مشکل رویایم پی بردم و اسم جدیدی برای شرکت انتخاب کردم (چون می‌ترسم کسی از اسم جدید استفاده کند، در این مطلب از همان اسم ناسا استفاده می‌کنم).

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

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

 

ددلاین (deadline)، خط پایان برنامه‌نویسان

ضرب‌العجل، موعد یا بهتر بگویم ددلاین (deadline) یکی از دشمنان همیشگی برنامه‌نویسان است. شاید بگویید که یک برنامه‌نویس خوب و حرفه‌ای باید کارها و وظایف‌ خود را مدیریت کند تا بتواند قبل از موعد مقرر آن‌ها را به اتمام رسانده و تحویل دهد. درست می‌گویید! من هم با شما کاملا موافق هستم. بهترین راه‌حل مدیریت ددلاین‌ها، برنامه‌ریزی است.

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

اما اصل کلام من این است: «اگر نرسیدن به ددلاین برای برنامه‌نویس، هم‌تیمی‌ها، سرپرست تیم، مدیر پروژه، مدیرعامل یا سهام‌داران می‌تواند خط پایان باشد، تنها به خاطر کم‌کاری یا نقص فنی من به عنوان یک برنامه‌نویس نیست» ممکن است باشد؛ اما تنها دلیل نیست! از بررسی نیازمندی گرفته تا برنامه‌ریزی‌، عملکرد (operation) یا حتی دیزاین و معماری اشتباه سیستم ممکن است علت نرسیدن به موقع یک تسک به ددلاین باشد. نیازمندی دیده نشده، وابستگی‌های پیش‌بینی نشده و اشکالات چشم‌پوشی شده ممکن است علت این باشد که چرا برنامه‌نویس‌های ما به ددلاین‌های مقرر نمی‌رسند.

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

در ادامه چند پند و اندرز برای شما همکاران تازه وارد عزیز ذکر می‌کنم که بتوانید برای عملکرد بهتر به کار ببندید:

  • قبل از اینکه نیازمندی‌های یک تسک به طور دقیق برای خودتان و بقیه اعضای تیم (علی‌الخصوص سرپرست تیم) مشخص و آنالیز نشده باشد، برای آن تخمین زمانی ندهید. (البته خواهش می‌کنم این مورد را در موارد بحران و باگ‌های مهم (critical) فراموش کنید. در آن موارد کسی از شما زمان‌بندی نمی‌خواهد!)
  • در مورد پیش‌نیازها و تداخل‌هایی که در کار پیش می‌آید با مدیریت پروژه و سرپرست تیم، هماهنگی لازم را انجام دهید تا آن‌ها را در زمان‌بندی در نظر بگیرند.
  • هر چقدر هم که به موعد تسک نزدیک بودید و محدودیت زمانی شما را درگیر کرد، اصول کدنویسی و دیزاین درست را کنار نگذارید. شاید بتوانید با کنار گذاشتن این موارد در این خط پایان برنده محسوب شوید، اما اسپرینت‌های (Sprint) دیگری نیز پیش روی شماست. این کدهای کثیف و دیزاین نادرست در پیچ خط پایان‌های پیش روی شما، مشکل‌ساز خواهند بود.
  • هر زمان که احساس کردید که در انجام کار تحت فشار هستید یا محدودیت زمانی دارید، با سرپرست تیم مشورت کنید و از او کمک و راهنمایی بخواهید.

 

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

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

شواهد نشان می‌دهد ما برنامه‌نویس‌ها به رغم خواسته یا اختیار خودمان، برای کار گروهی پرورش نیافته‌ایم. می‌گویید چرا؟ به الگوهای ذهنی‌تان توجه کنید. همه ما وقتی به کلمه برنامه‌نویس فکر می‌کنیم تصویر یک موجود تنها مقابل یک مانیتور (یا شاید چند مانیتور) در ذهن‌مان شکل می‌بندد. شخصی که دیوانه‌وار مشغول تایپ است. وقتی که دکمه enter را بی‌رحمانه فشار می‌دهد، کلمات سبز رنگ در ترمینال مشکی به حرکت در می‌آیند؛ برنامه‌نویس به افق محو شده و قهوه‌اش را نوش‌جان می‌کند. (شاید در شماره‌های بعد به اینکه چرا برنامه‌نویس نام‌برده را مرد تصور کردید و نه زن! پرداختم). دقت می‌کنید! خود تصویر با شما صحبت می‌کند.

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

پاندمی کرونا و دورکاری متاسفانه در این مدت بیش از همه به چالش‌های کار تیمی افزوده است. دورکاری این امکان را به ما داد که بدون توجه به موقعیت جغرافیایی‌مان در شرکتی که دوست داریم کار کنیم. مخصوصا برای برنامه‌نویسان با استعدادی که ساکن شهرستان‌ها بودند و یا دوست داشتند ساکن شهرستان باشند اما به علت متمرکز بودن شرکت‌های فناوری در پایتخت، مجبور به مهاجرت و اقامت در تهران بودند (خود این مسئله یک چالش اساسی و بزرگ بوده که خود یک مطلب اختصاصی نیاز دارد).

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

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

 

منابع فارسی زبان برای برنامه‌نویسان

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

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

در آن روزها من جوان بودم و دایره لغات و دانسته‌هایم در زبان تخصصی، به کلمات کلیدی جاوا و عبارات SQL محدود می‌شد. آن روز بعد از اینکه مطالب سایت‌های خارجی را در بخش ترجمه گوگل وارد کردم و ساعت‌ها به ترجمه ماشینی آن‌ها خیره شدم، سرافکنده به مدیرم مراجعه کردم. برای او سیر تا پیاز داستان را توضیح دادم و از او خواهش کردم تا در مورد آن موضوع و جزییات تسک توضیحات بیشتری به من ارائه دهد.

از آن روز برای من زمان زیادی گذشته است. اما همچنان در مواجهه با هر موضوع یا ابهام جدید در کارم، آن را در وب‌سایت‌های فارسی جست‌وجو می‌کنم و هنوز هم با گذشت این همه سال منابع فارسی را محدود می‌بینم. نسخه ترجمه شده کتب فنی (غیر از کتب دانشگاهی) کم است. کتابخانه (library) و فریم‌ورک‌های (framework) فارسی زبان محدود است.

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

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

 

به‌روز بودن در دانش برنامه‌نویسی

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

من هر زمان که در حین کار به یک اصطلاح، موضوع یا تکنولوژی جدید می‌رسیدم آن را روی تکه کاغذی یادداشت می‌کردم و آن را در کاسه‌ای روی میزم می‌انداختم. هر زمان که وقت آزاد داشتم یکی از آنان را انتخاب می‌کردم و یاد می‌گرفتم. نسبت ورودی به خروجی کاغذها، بیست به یک بود. آنقدر این کاغذها زیاد و بدون نظم بود که سرانجام یک روز مادرم در حالی که میز کارم را مرتب می‌کرد، آن‌ها را با سایر کاغذهای باطله روی میزم روانه سطل زباله کرد و کاسه‌اش را پس گرفت! (البته با پیش‌فرض ذهنی مادرم در مورد شلخته بودن من، به او حق می‌دهم که این کار را کرده باشد)

دانش برنامه‌نویس باید به‌روز باشد؛ باید! این واقعیت بر هیچ کدام از خوانندگان محترم این مطلب پوشیده نیست که هر کسی که بخواهد در مسیر شغلی خود پیشرفت کند، باید مطالعه مرتبط و غیرمرتبط به رشته را در برنامه روزانه‌اش قرار دهد و با این روش، دانش خود را به‌روز نگه دارد. از طرفی برنامه‌نویسی و IT روزبه‌روز در حال پیشرفت است. حتی اگر اکنون به این دانسته‌ها نیاز نداشته باشیم، طولی نخواهد کشید که این موارد به نیازمندی شرکت‌ها در آگهی‌های استخدام تبدیل می‌شوند. اینجاست که ما مجبوریم آن‌ها را به رزومه‌مان اضافه کنیم؛ تا شاید روزی بیاید که بتوانیم مطالعه آن‌ها را به برنامه شلوغ کاری‌مان اضافه کنیم!

در ماهیت چالش به‌روز بودن و راه‌حل انکار ناپذیر آن شکی نداریم. اما برگردیم به آن کاسه پر از کاغذ! اشکال سیستم سنتی من چه بود ؟

  • امکان اولویت‌بندی موضوعات وجود ندارد
  • دسته‌بندی موضوعات سخت است
  • لزوم مطالعه هر کدام از موضوعات قطعی نیست
  • من همواره سردرگم بودم که هر مطلب را تا چه حد نیاز است یاد بگیرم؟
  • حجم زیاد موارد هم که باعث می‌شد تا زانوی غم بغل بگیرم.

من چند نکته برای‌تان لیست می‌کنم و نتیجه‌گیری را به خودتان می‌سپارم:

  • حجم مطالب زیاد است و زیادتر خواهد شد.
  • هر چقدر هم که متخصص باشیم یا در لینکدین خودمان را کارشناس ارشد (senior) خطاب کنیم، این مطالب کمتر که هیچ، بیشتر هم خواهد شد.
  • سنگ بزرگ نشانه نزدن است.
  • نابرده رنج گنج میسر نمی‌شود.
  • عالم بی‌عمل به چه ماند، به زنبور بی‌عسل!

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

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

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

نظرات

دیدگاه خود را اضافه کنید :

نام و ایمیل اختیاری است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.