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

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

دانشگاه و محل کار

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

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

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

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

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

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

درس ۱: رابطه شما با همکاران شما و قدرت‌های فنی شما (مهارت‌های درون فردی / رهبری)، به طور یکسان مهم هستند.

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

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

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

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

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

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

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

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

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

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

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

نگاه کردن به گذشته

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

به نگاه کردن به گذشته، در اینجا برخی از پیشمانی‌های بزرگ من را مشاهده می‌نمایید:

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

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

همینطور که به من سمت جلو حرکت می‌کنم، این چیزی است که در اولویت ذهن من قرار دارد:

• هدف: بهترین مهندس نرم‌افزار ممکن شوم. این یک مسیر چند هزار کیلومتری است و قدم به قدم اتفاق می‌افتد.
• هدف: بهترین هم‌تیمی ممکن شوم. اگر من یک نیروی رابطه‌ای مثبت نباشم، بهترین مهندس بودن هیچ ارزشی ندارد. پیوستگی تیمی از استعداد فردی برتر است.
• هدف: نگهداری اولویت‌ها. نرم‌افزار مهم‌تر از رابطه من با خدا، ازدواج من، دوستی من، یا سلامت من نیست. به این که بالاترین اولولیت‌هایتان چه هستند، فکر کنید. من به فدا کردن هیچ یک از این موارد برای «بارورتر» بودن فکر نمی‌کنم.

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

منبع