شما در آستانه انجام یک سرمایهگذاری بزرگ هستید. شاید مبلغ پولیِ آن زیاد نباشد، اما سرمایهتان «زمان» شماست؛ «زندگی» شماست. بسیاری از ما صرفاً در مسیر شغلی خود شناور میشویم و اجازه میدهیم جریان آب ما را به هر کجا که میخواهد ببرد. ما خیلی اتفاقی سر از جاوا یا ویژوال بیسیک درمیآوریم، و بعد کارفرمایانمان بالاخره هزینه یک کلاس آموزشی برای یکی از جدیدترین اصطلاحات دهانپرکنِ (Buzzwords) صنعت را متقبل میشوند. بنابراین، مدتی در آن مسیر شناور میمانیم تا زمانی که چیز دیگری به دستمان داده شود. شغل ما تبدیل میشود به یک سری اتفاقاتِ هدایتنشدۀ بزرگ.
در کتاب برنامهنویس عملگرا (The Pragmatic Programmer)، دیو توماس و اندی هانت درباره «برنامهنویسیِ تصادفی» (Programming by Coincidence) صحبت میکنند. بیشتر برنامهنویسان میتوانند با این ایده ارتباط برقرار کنند: شما شروع به کار روی چیزی میکنید، کمی کد اینجا اضافه میکنید و کمی بیشتر آنجا. شاید با یک برنامه نمونه شروع کنید که از یک وبسایت کپی-پیست کردهاید. به نظر میرسد کار میکند، پس کمی آن را تغییر میدهید تا بیشتر شبیه برنامهای شود که واقعاً نیاز دارید. شما واقعاً نمیفهمید چه کار میکنید، اما برنامه را آنقدر دستکاری میکنید تا تقریباً نیازهایتان را برآورده کند. مشکل اینجاست که شما درک نمیکنید آن برنامه چطور کار میکند، و مانند خانهای پوشالی، هر ویژگی جدیدی که اضافه میکنید، احتمال فروپاشی برنامهتان را افزایش میدهد.
به عنوان یک توسعهدهنده نرمافزار، کاملاً بدیهی است که برنامهنویسیِ تصادفی چیز بدی است. با این حال، بسیاری از ما اجازه میدهیم انتخابهای شغلی مهممان، در عمل، تصادفی باشند. روی کدام تکنولوژیها باید سرمایهگذاری کنیم؟ در کدام حوزه (Domain) باید تخصص پیدا کنیم؟ آیا باید دانش خود را گسترده کنیم یا عمیق؟ اینها سوالاتی هستند که واقعاً باید از خودمان بپرسیم.
تصور کنید شرکتی را راهاندازی کردهاید و در حال توسعه چیزی هستید که قرار است «محصول پرچمدار» شرکت باشد. بدون «موفقیت» این محصول، شرکت شما ورشکسته خواهد شد. چقدر به اینکه مشتریان هدف شما چه کسانی هستند توجه میکنید؟ قبل از تولید واقعی محصول، چقدر فکر میکنید که این محصول واقعاً چیست؟ هیچکدام از ما اجازه نمیدهیم تصمیماتی نظیر اینها به جای ما گرفته شوند. ما کاملاً حواسمان به تکتک جزئیات فرآیند تصمیمگیری خواهد بود.
پس چرا اکثر ما به انتخابهایی که در مسیر شغلی خود انجام میدهیم، چنین توجهی نداریم؟ اگر به شغل خود به عنوان یک کسبوکار نگاه کنید (که واقعاً هم همینطور است)، «محصول» شما از خدماتی تشکیل شده که برای ارائه دارید.
آن خدمات چه هستند؟ قرار است آنها را به چه کسی بفروشید؟ آیا تقاضا برای خدمات شما در سالهای آینده رشد خواهد کرد یا کاهش خواهد یافت؟ چقدر حاضرید روی این انتخابها قمار کنید؟
این بخش از کتاب به شما کمک میکند تا پاسخ این سوالات مهم را برای خودتان بیابید.
اگر بخواهید پولتان را سرمایهگذاری کنید، گزینههای زیادی پیش رو دارید. میتوانید آن را در یک حساب پسانداز بگذارید، اما سودی که به آن تعلق میگیرد احتمالاً با نرخ تورم برابری نمیکند. میتوانید اوراق قرضه دولتی بخرید. باز هم در نتیجه پول زیادی به دست نمیآورید، اما شرطبندیهای ایمنی هستند.
یا میتوانید پولتان را در یک شرکت نوپا (استارتآپ) سرمایهگذاری کنید. مثلاً ممکن است چندین هزار دلار در ازای سهم کوچکی از مالکیت شرکت بپردازید. اگر ایده شرکت خوب باشد و بتوانند آن ایده را به طور موثر اجرا کنند، پتانسیل این را دارید که پول زیادی به دست آورید. از سوی دیگر، هیچ تضمینی وجود ندارد که حتی سرمایه اولیه خود را پس بگیرید.
این مفهوم چیز جدیدی نیست. شما یادگیری آن را از کودکی و هنگام بازی کردن شروع میکنید. «اگر مستقیم از وسط بدوم، ممکن است همه را غافلگیر کنم و کسی نتواند مرا بگیرد (Tag me).» در زندگی روزمره نیز دائماً این موضوع به شما یادآوری میشود. وقتی برای جلسهای دیر کردهاید و سعی دارید بهترین مسیر را برای رفتن به محل کار انتخاب کنید، این موازنه بین «ریسک و پاداش» را انجام میدهید: «اگر ترافیک بد نباشد، اگر از خیابان سیودوم بروم ۱۵ دقیقه زودتر میرسم. اما اگر ترافیک سنگین باشد، کارم تمام است (I’m toast).»
موازنه ریسک و پاداش، بخش مهمی از انجام انتخابهای آگاهانه در مورد تکنولوژیها و حوزههایی است که میخواهید روی آنها سرمایهگذاری کنید. پانزده سال پیش، یک انتخاب بسیار کمریسک، یادگیری برنامهنویسی به زبان COBOL بود. البته، آن زمان برنامهنویسان COBOL آنقدر زیاد بودند که باید با آنها رقابت میکردید و میانگین حقوق یک برنامهنویس COBOL در آن زمان خارقالعاده نبود. به راحتی میتوانستید کار پیدا کنید، اما آن کار لزوماً نانودندانگیر نبود. ریسک کم، پاداش کم.
از سوی دیگر، اگر در همان زمان تصمیم میگرفتید زبان جدید Java از شرکت سان مایکروسیستمز (Sun Microsystems) را بررسی کنید، ممکن بود برای مدتی پیدا کردن کار در شرکتی که واقعاً با جاوا کاری انجام دهد، دشوار باشد. چه کسی میدانست که آیا بالاخره کسی با جاوا کاری انجام خواهد داد یا نه؟
اما اگر در آن زمان نگاهی به وضعیت صنعت میانداختید (همانطور که Sun نگاه میکرد)، ممکن بود چیز ویژهای در جاوا ببینید. ممکن بود حس قویای داشته باشید که این زبان قرار است بزرگ شود. سرمایهگذاری زودهنگام روی آن، شما را به یک رهبر و پیشرو در یک روند تکنولوژیِ بزرگ و آیندهدار تبدیل میکرد.
البته در آن مورد خاص، حق با شما بود. و اگر کارتهایتان را درست بازی میکردید، سرمایهگذاری شخصی شما روی جاوا میتوانست بسیار پرسود باشد. ریسک بالا، پاداش بالا.
حالا تصور کنید که باز هم ۱۵ سال پیش، دمویی از سیستم عامل جدید BeOS از شرکت Be را میدیدید. در آن زمان باورنکردنی بود. از پایه طوری ساخته شده بود که از پردازندههای چندگانه بهره ببرد. قابلیتهای چندرسانهای آن خیرهکننده بود. این پلتفرم سر و صدای زیادی به پا کرد و کارشناسان از انتظار برای ورود یک رقیب جدید و قدرتمند به دنیای سیستمعاملها سر از پا نمیشناختند. طبیعتاً با پلتفرم جدید، روشهای جدید برنامهنویسی، APIهای جدید و مفاهیم جدید رابط کاربری هم آمدند. چیزهای زیادی برای یادگیری بود، اما واقعاً ارزشش را داشت. شما میتوانستید تلاش زیادی کنید تا مثلاً اولین کسی باشید که یک کلاینت FTP یا یک مدیر اطلاعات شخصی (PIM) برای BeOS میسازد. در حالی که Be نسخه سازگار با اینتلِ سیستمعامل خود را منتشر کرد، شایعاتی پخش شد مبنی بر اینکه اپل قصد دارد این شرکت را بخرد تا از تکنولوژی آن به عنوان پایهای برای نسل بعدی سیستمعامل مکینتاش استفاده کند.
اپل شرکت Be را نخرید. و در نهایت، مشخص شد که Be حتی قرار نیست سهم کوچکی از بازار را تصاحب کند. محصول اصلاً جا نیفتاد. بسیاری از توسعهدهندگانی که بر برنامهنویسی در محیط BeOS مسلط شده بودند، به آرامی و با دردسر متوجه شدند که سرمایهگذاریشان در بلندمدت نتیجه نخواهد داد. در نهایت، Be توسط Palm خریداری شد و تولید سیستمعامل متوقف گردید. BeOS یک سرمایهگذاری تکنولوژیِ جذاب اما پرریسک بود که برای توسعهدهندگانی که آن را انتخاب کرده بودند، بازدهی ملموس بلندمدتی نداشت. ریسک بالا، بدون پاداش.
تا اینجا، آنچه در موردش صحبت کردم تفاوت بین انتخاب تکنولوژیهایی است که هنوز در «لبه تکنولوژی» (Bleeding edge) هستند و تکنولوژیهایی که کاملاً تثبیت شدهاند. انتخاب یک تکنولوژی پایدار که قبلاً جای خود را در سیستمهای تولیدیِ کسبوکارهای سراسر جهان محکم کرده، انتخابی امنتر اما با پاداشِ احتمالیِ کمتر نسبت به انتخاب یک تکنولوژی جدید و پرزرقوبرق است که هنوز کسی آن را پیادهسازی نکرده است. اما در مورد تکنولوژیهایی که دوره خود را طی کردهاند چطور؟ آنهایی که فقط منتظرند تا آخرین میخها بر تابوتشان کوبیده شود؟
چه کسی آن میخها را میکوبد؟ ممکن است مثلاً آخرین برنامهنویسانِ باقیماندهی RPG را افرادی مو سفید تصور کنید که لحظات را تا بازنشستگی میشمارند، در حالی که نسل جدید جوانترها حتی اسم RPG را هم نشنیدهاند؛ آنها همه در حال یادگیری جاوا و داتنت (.NET) هستند. تصور اینکه شغلِ آخرین بازماندگانِ وفادار به یک تکنولوژیِ پیر و در حال مرگ، در همان گردابِ مرگی قرار دارد که خود تکنولوژی در آن است، آسان است.
اما سیستمهای قدیمی فقط نمیمیرند؛ آنها جایگزین میشوند. علاوه بر این، در بیشتر موارد، سیستمهای بومی و داخلی (Homegrown) بهصورت مرحلهبهمرحله جایگزین میشوند. در این مراحل، سیستمهای قدیمی باید با سیستمهای جدید صحبت کنند. کسی باید بداند چگونه جدید را وادار به صحبت با قدیم کند و برعکس. معمولاً تازهکارها نمیدانند (یا نمیخواهند بدانند) که چطور سیستمهای قدیمی را وادار به شنیدن کنند. و قدیمیهای بدقلق و در آستانه بازنشستگی هم نمیدانند چطور سیستمهای جدید و عجیبوغریب را وادار کنند با مخلوقات محبوبشان صحبت کنند.
بنابراین، نقشی وجود دارد که باید توسط یک متخصصِ حسابگر پر شود: آسایشگاه تکنولوژی (Technology Hospice).
کمک به سیستمهای قدیمی برای مرگی راحت و باوقار، وظیفهای است که نباید دستکم گرفته شود. و البته، بیشتر مردم قبل از غرق شدن کشتی، یا از طریق بازنشستگی و یا با تغییر مسیر به سمت یک قلمروی تکنولوژی دیگر، از آن بیرون میپرند. با ماندن به عنوان آخرین نفر برای پشتیبانی از سیستمهایی که هنوز حیاتی هستند، شما تقریباً میتوانید تعیینکننده شرایط باشید. این کار ریسک دارد، از این جهت که وقتی تکنولوژی واقعاً از بین برود، شما متخصص چیزی خواهید بود که دیگر وجود ندارد. با این حال، اگر بتوانید به اندازه کافی سریع حرکت کنید، میتوانید به دنبال نسل بعدی سیستمهای میراثی (Legacy) که در حال مرگ هستند بگردید و دوباره شروع کنید.
هر دو انتهای نمودارِ پذیرشِ تکنولوژی (Technology adoption curve) ممکن است پرسود باشند.
نمودار پذیرش در هر دو طرف لبههایی دارد. شما میخواهید چقدر در این لبهها جلو بروید؟
۱. لیستی از تکنولوژیهایی با پذیرش زودهنگام، میانی و دیرهنگام بر اساس بازار امروز تهیه کنید. آنها را روی کاغذ از چپ به راست ترسیم کنید؛ سمت چپ «لبه تکنولوژی» (Bleeding edge) است و سمت راست پر از تکنولوژیهایی است که در غروب عمر خود به سر میبرند. به خودتان فشار بیاورید تا جایی که ممکن است تکنولوژیهای بیشتری را در هر بخش از این طیف پیدا کنید. در مورد اینکه آنها نسبت به یکدیگر کجای منحنی قرار میگیرند، تا حد امکان دقیق و جزئینگر باشید.
وقتی تا جایی که به ذهنتان میرسید تکنولوژیها را نقشهبرداری کردید، آنهایی را که فکر میکنید در آنها قوی هستید، علامت بزنید. سپس، شاید با رنگی متفاوت، آنهایی را که تجربه کمی در آنها دارید اما در آنها صاحبنظر (Authoritative) نیستید، مشخص کنید. بیشتر علامتهای شما کجای منحنی پذیرش قرار دارند؟ آیا توده شدهاند؟ آیا به طور یکنواخت پخش شدهاند؟ آیا تکنولوژیهایی در لبههای دورِ نمودار وجود دارد که علاقه خاصی به آنها داشته باشید؟
وقتی وب واقعاً شروع به اوج گرفتن کرد، میتوانستید با ساخت صفحات ساده HTML برای شرکتها پول زیادی به دست آورید. هر شرکتی یک وبسایت میخواست و افراد نسبتاً کمی بلد بودند چطور آنها را بسازند. شرکتها حاضر بودند برای طراحان وب «باتجربه» بالاترین مبالغ را بپردازند؛ که در آن زمان، منظور از تجربه دانستن مبانی HTML، لینکدهی (Hyperlinking) و ساختار سایت بود.
ساخت صفحات HTML بسیار ساده است. ساختن صفحاتی که واقعاً زیبا به نظر برسند سخت است، اما یادگیری اصول اولیه آسان است. وقتی مردم دیدند که این طراحان وب چه قیمتهایی درخواست میکنند، افراد بیشتر و بیشتری شروع به خرید کتابهای HTML و خودآموزی کردند. بازار داغ بود، حقوقها یا دستمزدهای ساعتی جذاب بودند، و در پاسخ به این وضعیت، عرضه متخصصان HTML شروع به افزایش کرد.
همانطور که بازار از طراحان وب اشباع شد، اهالی وب شروع به طبقهبندی شدن بین «نیروی واقعاً هنرمند» و «نیروی صرفاً کاربردی» کردند. علاوه بر این، رقابت باعث شد قیمتها کاهش یابد. در نتیجهی قیمتهای پایینتر، شرکتهای بیشتری مایل شدند اولین قدم خود را برای حضور در اینترنت بردارند. آنها شاید ۵۰۰۰ دلار برای اولین وبسایت خود نمیپرداختند، اما ۵۰۰ دلار را میپرداختند.
البته، برخی شرکتها هنوز حاضر بودند برای یک وبسایت خارقالعاده پولهای کلانی خرج کنند. و طراحان وبِ خاصی هنوز میتوانستند دستمزدهای شگفتانگیزی طلب کنند. در نهایت، سیلِ طراحان وب در سطوح هزینهی پایین تا متوسط فروکش کرد. طراحان وبِ کماستعداد جای خود را به کاربران نهایی و سایر کارکنان IT دادند که لزوماً متخصص طراحی HTML نبودند. در این نقطه، عرضه، تقاضا و قیمتِ تولیدِ HTML به یک تعادل رسید.
این تاریخچهی مختصر و غیررسمی از حرفهی طراحی وب، یک مدل اقتصادی را نشان میدهد که همه ما نامش را شنیدهایم: عرضه و تقاضا.
وقتی اکثر ما به عرضه و تقاضا فکر میکنیم، تصورمان این است که این موضوع عمدتاً به قیمتی مربوط میشود که چیزی میتواند و قرار است با آن فروخته شود. اگر تعداد کالاهای موجود برای فروش بیشتر از تعداد افرادی باشد که میخواهند آن کالا را بخرند،
قیمت آن کالا کاهش مییابد. اگر تعداد کسانی که خواهان کالا هستند بیشتر از کالاهای موجود برای خرید باشد، با رقابت خریداران بالقوه، قیمت کالا افزایش مییابد.
مدل عرضه و تقاضا علاوه بر پیشبینی قیمت کالاها و خدمات، میتواند پیشبینی کند که تغییرات قیمت چگونه بر تعداد افراد متمایل به فروش و خرید یک محصول یا خدمت تأثیر میگذارد. معمولاً برای هر چیزی، خریداران بیشتری در قیمت پایینتر وجود دارند تا در قیمت بالاتر.
شما نمیتوانید بر سر قیمت رقابت کنید. در واقع، توانش را ندارید (برایتان نمیصرفد) که بر سر قیمت رقابت کنید.
چرا این موضوع برای ما مهم است؟ روند برونسپاری نرمافزار به خارج از کشور (Offshore)، حجم بزرگی از نیروهای IT ارزانقیمت را به اقتصاد ما تزریق کرده است. اگرچه ما نگران از دست دادن مشاغل در داخل کشور هستیم، اما هزینه کمتر به ازای هر برنامهنویس در واقع تقاضای کلی را افزایش داده است. در عین حال، با افزایش تقاضا، قیمت کاهش مییابد. رقابت در محصولات و خدماتِ پرتقاضا، بر پاشنه قیمت میچرخد. در بازار اشتغال، این به معنای «حقوق» است. شما نمیتوانید بر سر قیمت رقابت کنید. توانش را ندارید. پس چه کار میکنید؟
بازار برونسپاری، برنامهنویسان ارزانقیمت خود را به مجموعه نسبتاً محدودی از تکنولوژیها تزریق کرده است. برنامهنویسان جاوا و داتنت (.NET) در هند مثل ریگ بیابان فراواناند. هند مدیران پایگاهداده (DBA) اوراکل زیادی هم دارد. تکنولوژیهای کمتر متداول، در شرکتهای توسعهدهنده خارجی (Offshore shops) حضور بسیار کمرنگی دارند.
هنگام انتخاب مجموعهای از تکنولوژیها برای تمرکزِ شغلی، باید تأثیراتِ افزایش عرضه و قیمتهای پایینتر را بر چشمانداز شغلی خود درک کنید. به عنوان یک برنامهنویس داتنت، ممکن است خود را در رقابت با دهها هزار نفر بیشتر در بازار کار ببینید، نسبت به زمانی که مثلاً یک برنامهنویس پایتون (Python) بودید. این امر منجر به کاهش قابل توجه میانگین هزینه یک برنامهنویس داتنت میشود و احتمالاً تقاضا را بالاتر میبرد (به عبارت دیگر، مشاغل داتنت بیشتری ایجاد میکند). بنابراین، احتمالاً کارهایی پیدا خواهید کرد، اما آن کارها دستمزد خیلی خوبی نخواهند داشت.
عرضه برنامهنویسان پایتون ممکن است بسیار کمتر از برنامهنویسان داتنت باشد، با تقاضایی که با آن همخوانی دارد. اگر بازار کار پایتون از قیمتهای بهطور محسوسی بالاتر به ازای هر برنامهنویس پشتیبانی کند، افراد بیشتری جذب میشوند تا خدمات خود را در این محدوده قیمتی بالاتر ارائه دهند، که منجر به رقابتی میشود که قیمت را دوباره پایین میآورد.
کل این ماجرا یک بندبازی برای ایجاد تعادل است. اما یک چیز (فعلاً) قطعی به نظر میرسد. هند بازارهای خدمات IT که از قبل به تعادل رسیدهاند را تأمین میکند. شما شرکتهای برونسپاری هندیِ جریان اصلی را نمیبینید که روی تکنولوژیهای غیرمتعارف بپرند. آنها «اولین حرکتکنندگان» (First-movers) نیستند. آنها معمولاً ریسک نمیکنند. آنها صبر میکنند تا بازارهای خدمات تکنولوژی به تعادل برسند، و سپس با هزینههای بسیار پایینتر به ازای هر برنامهنویس، آن بازارها را دگرگون میکنند.
بر اساس این مشاهده، ممکن است انتخاب کنید که در بخشهایی از بازار کار رقابت کنید که در واقع تقاضای کمتری وجود دارد. هرچند ممکن است خلاف شهود به نظر برسد، اما اگر نگران از دست دادن شغل به نفع برونسپاری هستید، یک استراتژی این است که از انواع کارهایی که شرکتهای خارجی انجام میدهند اجتناب کنید. شرکتهای خارجی کارهایی را انجام میدهند که تقاضای بالایی دارند. بنابراین، تمرکز روی تکنولوژیهای خاص (Niche)، استراتژیای است که اگرچه لزوماً رقابت را کمفشارتر نمیکند (چون کارهای کمتری برای تقسیم وجود دارد)، اما ممکن است تمرکز رقابت را از «قیمت» به «توانایی» تغییر دهد. این همان چیزی است که شما نیاز دارید. شما نمیتوانید بر سر قیمت رقابت کنید، اما میتوانید بر سر توانایی رقابت کنید.
همچنین، با کاهش میانگین قیمتِ این برنامهنویسانِ جریان اصلی، تقاضا افزایش خواهد یافت. افزایش کلی تقاضا برای برنامهنویسان جاوا، مثلاً، ممکن است در واقع منجر به مشاغل بیشتری (از نوع خاصی) در خانه (داخل کشور) شود، نه کمتر. افزایش در بازارِ ارزانقیمتِ خارجی میتواند تقاضای کلی را، شامل ردههای بالاترِ توسعهدهندگان، افزایش دهد. این در عمل اتفاق میافتد.
برای اینکه برونسپاری به خوبی کار کند، بسیاری از شرکتها نیاز به ذخیرهای از توسعهدهندگان ردهبالای داخلی (Onshore) را درک میکنند که بتوانند استانداردها را تعیین کنند، کیفیت را تضمین کنند و رهبری فنی را بر عهده بگیرند. افزایش در تقاضای کلی برنامهنویسی جاوا به طور طبیعی منجر به افزایش در این دسته از کارهای جاوا میشود. کارهای ردهپایین ممکن است به خارج بروند، اما کارهای نخبگان (Elite jobs) بیشتری نسبت به دوران پیش از برونسپاری برای تقسیم شدن وجود دارد. همانطور که در بازارهای شغلی خاص (Niche) دیدیم، در این سطح از توسعه جاوا، رقابت از قیمت به توانایی تغییر میکند.
مهمترین درسی که میتوانیم از مدل عرضه و تقاضا بگیریم این است که با افزایش تقاضا، رقابت قیمتی افزایش مییابد. استراتژیِ آزمودهشدهی «دنبالِ کار رفتن»، شما را مستقیماً در رقابت قیمتی قرار میدهد.
از عدم تعادلهای بازار بهرهبرداری کنید.
با توسعهدهندگان خارجی رقابت کنید، زیرا مهارتهای شما در بازارهای متعادلی که مناسب برونسپاری هستند جای میگیرد. برای رقابت در بازار تکنولوژیِ جریان اصلی، باید در سطحی بالاتر رقابت کنید. در غیر این صورت، میتوانید از عدم تعادلهای بازار بهرهبرداری کنید—به جاهایی بروید که شرکتهای خارجی نمیروند. در هر دو حالت، درک نیروهای موجود و داشتن مهارت و چابکی کافی برای واکنش به آنها، سودمند است.
۱. تقاضای فعلی برای مهارتهای فنی را تحقیق کنید. از آگهیهای استخدام و وبسایتهای کاریابی استفاده کنید تا بفهمید کدام مهارتها تقاضای بالا و کدام تقاضای پایین دارند. وبسایتهای برخی شرکتهای برونسپاری (Outsourcing) خارجی را پیدا کنید (یا اگر با آنها کار میکنید، با کارکنان آن شرکتها صحبت کنید). مهارتهای موجود از طریق این شرکتها را با لیست «تقاضای بالا» که تهیه کردهاید مقایسه کنید. یادداشت کنید که کدام مهارتها در داخل کشور تقاضای بالایی دارند اما نفوذ کمی در خارج دارند. یک مقایسه مشابه بین تکنولوژیهای «لبه تکنولوژی» و مهارتهای موجود از طریق شرکتهای برونسپاری انجام دهید. چشمتان را روی هر دو دسته از مهارتهای فنی که توسط شرکتهای خارجی کمتر پوشش داده شدهاند نگه دارید. چقدر طول میکشد تا آنها این حفرهها را پر کنند (اگر اصلاً پر کنند)؟ این شکاف زمانی، پنجرهای است که در آن عدم تعادلِ بازار وجود دارد.
فکر کردن به اینکه روی چه تکنولوژیهایی سرمایهگذاری کنید کافی نیست. هرچه باشد، بخشِ تکنولوژی یک «کالای عمومی» (Commodity) است، مگر نه؟ شما نمیتوانید لم بدهید و صرفاً بر یک زبان برنامهنویسی یا سیستمعامل مسلط شوید و اجازه دهید اهالی کسبوکار (Businesspeople) به کارهای تجاری برسند. اگر تمام چیزی که آنها نیاز داشتند یک «ربات کدنویس» بود، خیلی راحت میتوانستند کسی را در کشوری دیگر استخدام کنند تا آن نوع کار را انجام دهد.
اگر میخواهید مرتبط و بهروز بمانید، باید در «دامنه کسبوکاری» (Business Domain) که در آن هستید غرق شوید. در واقع، یک نیروی نرمافزاری باید دامنه کسبوکار را نهتنها آنقدر خوب بشناسد که بتواند برایش نرمافزار توسعه دهد، بلکه باید به یکی از صاحبنظران آن حوزه تبدیل شود.
در شرکت قبلی، نمونهای عالی از این موضوع را دیدم. تیم مدیریت پایگاهداده متشکل از افرادی بود که واقعاً علاقهای به تکنولوژی دیتابیس نداشتند. وقتی اولین بار با آنها روبرو شدم، کمی شوکه شدم. با خودم فکر کردم: «چرا این آدمها در بخش فناوری اطلاعات هستند؟» از نظر مهارت فنی، آنها خیلی قوی نبودند.
اما این تیم چیز ویژهای داشت. آنها به عنوان حافظان و نگهبانانِ دادههای سازمانی ما، دامنه کسبوکار را بهتر از تقریباً هر تحلیلگر کسبوکاری که داشتیم، میشناختند. دانش و درک آنها از بیزنس، آنها را به مهرههایی ارزشمند و کمیاب در بازارِ فرصتهای شغلیِ داخلی تبدیل کرده بود. در حالی که ما «خوره»های کامپیوتر (Geeks) با تحقیر به آنها نگاه میکردیم، کسبوکاری که برایش کار میکردند ارزش فوقالعادهای در آنها میدید.
شما باید به تجربه خود در دامنه کسبوکار به عنوان بخش مهمی از «رپرتوار» (مجموعه مهارتهای) خود نگاه کنید. اگر نوازنده باشید، وقتی قطعهای را به رپرتوار خود اضافه میکنید، معنیش فقط این نیست که آن آهنگ را یک بار نواختهاید. به این معنی است که شما آن آهنگ را واقعاً و عمیقاً میشناسید. باید همین تئوری را در مورد تجربه خود در دامنه کسبوکار نیز به کار ببرید.
برای مثال، کار کردن روی پروژهای در صنعت بیمه سلامت تضمین نمیکند که تفاوت بین تراکنش EDI HIPAA 835 و HIPAA 837 را درک کرده باشید. این دقیقاً همان نوع دانشی است که در موقعیت مناسب، تفاوت بین دو توسعهدهنده نرمافزار را که از نظر فنی برابر هستند، رقم میزند.
شما ممکن است «فقط یک برنامهنویس» باشید، اما توانایی صحبت کردن با مشتریان تجاری به زبانِ دامنه کسبوکارِ خودشان، یک مهارت حیاتی است. تصور کنید زندگی چقدر آسانتر میشد اگر تمام کسانی که باید با آنها کار میکردید، واقعاً میفهمیدند توسعه نرمافزار چگونه کار میکند. دیگر لازم نبود برایشان توضیح دهید چرا بازگرداندن ۳۰,۰۰۰ رکورد در یک صفحه از وباپلیکیشن ایده بدی است، یا چرا نباید لینکهای سرور توسعه (Development server) را پخش کنند.
این دقیقاً همان حسی است که مشتریان تجاری شما نسبت به شما دارند: «تصور کن کار کردن با این برنامهنویسها چقدر راحتتر میشد اگر فقط میفهمیدند من چه درخواستی دارم، بدون اینکه مجبور باشم همه چیز را احمقانه سادهسازی کنم و به طرز مسخرهای وارد جزئیات شوم!»
و حدس بزنید چه؟ این «کسبوکار» است که حقوق شما را میدهد.
درست مانند تکنولوژیهایی که داغ میشوند، دامنههای کسبوکار را نیز میتوان به همان روش انتخاب کرد. جاوا و داتنت در حال حاضر چیزهای بزرگ (Big Things) در توسعه نرمافزار هستند. اگر آنها را یاد بگیرید، میتوانید برای شغلی در یکی از شرکتهای بسیاری که این تکنولوژیها را به کار میگیرند رقابت کنید. همین موضوع در مورد دامنههای کسبوکار نیز صدق میکند. شما باید همان سطح از دقتی را که در انتخاب تکنولوژی برای تسلط به کار میبرید، در انتخاب صنعتی که میخواهید به آن خدمت کنید نیز به خرج دهید.
الان زمان آن است که به دامنههای کسبوکاری که وقتتان را روی آنها سرمایهگذاری میکنید فکر کنید. با توجه به اهمیتی که باید برای انتخاب یک دامنه کسبوکار جهت تکمیل پورتفولیوی خود قائل شوید، شرکت و صنعتی که برای کار انتخاب میکنید به سرمایهگذاری قابلتوجهی از جانب شما تبدیل میشود.
اگر هنوز تفکر واقعی و عامدانهای در مورد اینکه روی کدام دامنههای تجاری باید سرمایهگذاری کنید نداشتهاید، الان وقتش است. هر روزی که میگذرد یک فرصت از دست رفته است. مانند رها کردن پساندازتان در یک حساب کمسود وقتی که نرخ بهرههای بالاتری وجود دارد، رها کردنِ توسعهی فردی در جبههی بیزنس به حالت سکون، یک انتخاب سرمایهگذاریِ بد است.
۱. ناهار را با یک فرد بیزنسی (غیرفنی) برنامه ریزی کنید. با آنها در مورد اینکه چگونه کارشان را انجام میدهند صحبت کنید. همانطور که با آنها حرف میزنید، از خود بپرسید اگر آرزوی داشتن شغل آنها را داشتید، چه چیزی را باید تغییر میدادید یا یاد میگرفتید. در مورد جزئیات کار روزانهشان بپرسید. با آنها صحبت کنید که چگونه تکنولوژی به آنها در کار کمک میکند (یا سرعتشان را میگیرد). به کار خودتان از زاویه دید آنها فکر کنید. این کار را بهطور منظم انجام دهید.
این ممکن است ایدهای عجیب یا معذبکننده به نظر برسد. اشکالی ندارد. من چند سال پیش شروع به انجام این کار کردم و تفاوت بزرگی در نحوه درک و ارتباط من با کسبوکاری که پشتیبانی میکردم ایجاد کرد. همچنین باعث شد در صحبت با مشتریانم راحتتر باشم، که یک عارضه جانبی مثبت است.
۲. یک مجله تخصصی (Trade magazine) مربوط به صنعت شرکتتان را بردارید. احتمالاً حتی لازم نیست یکی بخرید. اکثر شرکتها شمارههای قدیمی مجلات صنفی را جایی تلنبار کردهاند. شروع کنید و سعی کنید یک مجله را بخوانید. ممکن است همه چیزهایی را که میخوانید متوجه نشوید، اما سماجت به خرج دهید. لیستی از سوالاتی تهیه کنید که میتوانید از مدیریت یا مشتریان تجاری خود بپرسید. حتی اگر سوالاتتان به نظر خودتان احمقانه باشد، مشتریان تجاریتان از اینکه تلاش میکنید یاد بگیرید قدردانی خواهند کرد. به دنبال وبسایتهای صنعتی بگردید که بتوانید بهطور منظم رصدشان کنید. هم در وبسایتها و هم در مجلات، توجه ویژهای داشته باشید که اخبار بزرگ و مقالات ویژه (Feature articles) در مورد چیست. صنعت شما با چه چیزی دست و پنجه نرم میکند؟ موضوع داغ جدید در حال حاضر چیست؟ هر چه که هست، آن را با مشتریان تجاری خود مطرح کنید. از آنها بخواهید توضیح دهند و نظرشان را بگویند. فکر کنید که این روندهای فعلی چگونه بر شرکت شما، بخش شما، تیم شما و در نهایت کار شما تأثیر میگذارد.
پت متنی (Pat Metheny)، گیتاریست افسانهای جاز، یک نصیحت همیشگی برای نوازندگان جوان دارد: «همیشه بدترین نوازنده در هر گروهی باش که در آن هستی.»
همیشه بدترین نوازنده در هر گروهی باش که در آن هستی. قبل از شروع کارم در فناوری اطلاعات، من نوازنده حرفهای ساکسیفون در سبک جاز و بلوز بودم. به عنوان یک نوازنده، این شانس را داشتم که این درس را خیلی زود یاد بگیرم و به آن پایبند بمانم. بدترین فرد گروه بودن یعنی همیشه با افرادی ساز بزنید که از شما بهتر هستند.
حالا، چرا باید همیشه انتخاب کنید که بدترین فرد گروه باشید؟ میپرسید: «آیا این اعصابخردکن نیست؟» بله، در ابتدا فوقالعاده دلهرهآور است. به عنوان یک نوازنده جوان، خودم را در موقعیتهایی مییافتم که آشکارا بدترین فرد گروه بودم و مطمئن بودم که مثل وصله ناجور توی ذوق خواهم زد. سر اجرا حاضر میشدم و حتی دلم نمیخواست ساکسیفونم را از جعبه درآورم چون میترسیدم با زور از روی سن (Bandstand) بیرونم کنند. خودم را کنار کسانی میدیدم که الگویم بودند، و انتظار میرفت در سطح آنها اجرا کنم—گاهی حتی به عنوان ساز اصلی!
بدون استثنا (خوشبختانه!)، در این موقعیتها اتفاقی جادویی میافتاد: من «جا میافتادم». من در میان سایر نوازندگان به عنوان یک ستاره نمیدرخشیدم، اما از طرف دیگر، بهطور فاحشی هم سطح پایینتر نبودم. این اتفاق به دو دلیل رخ میداد. دلیل اول این است که من واقعاً آنقدرها که فکر میکردم بد نبودم. بعداً به این موضوع برمیگردیم.
دلیل جالبتر اینکه من با این نوازندگان برتر—و در برخی موارد قهرمانانم—هماهنگ میشدم این بود که نوازندگی من تغییر میکرد تا بیشتر شبیه آنها شود. دوست دارم فکر کنم که نوعی توانایی ابرانسانی داشتم تا صرفاً با ایستادن کنار یک نابغه به نابغه تبدیل شوم، اما با نگاهی به گذشته فکر میکنم قضیه خیلی کمتر از این حرفها پرزرقوبرق است. بیشتر شبیه نوعی رفتار غریزیِ گلهای بود که در من برنامهریزی شده بود. این همان پدیدهای است که باعث میشود وقتی در کنار افرادی هستم که متفاوت از من صحبت میکنند، کلمات یا عادات دستوری جدیدی را اتخاذ کنم. وقتی بعد از یک سال و نیم زندگی در هند برگشتیم، همسرم گاهی به حرف زدنم گوش میداد و میزد زیر خنده: «شنیدی الان چی گفتی؟» من داشتم انگلیسی را با لهجه هندی صحبت میکردم.
بدترین فرد گروه بودن، همان رفتار را در من به عنوان ساکسیفونیست برانگیخت. من بهطور طبیعی مثل بقیه مینواختم.
چیزی که این پدیده را واقعاً غیرجذاب (و واقعی) میکند این است که وقتی در کازینوها و بارهای معمولی با گروههای «نه چندان خوب» مینواختم، من هم مثل همانها مینواختم. همچنین، مثل فرد الکلیای که حتی وقتی مست نیست کلمات را میکشد، متوجه میشدم که عادات بدِ گروههای موسیقیِ سطح پایین به شبهای اجرایِ سطح بالای من هم سرایت کرده است.
بنابراین، من از این موضوع یاد گرفتم که افراد میتوانند صرفاً بر اساس کسانی که با آنها کار میکنند، به طرز چشمگیری در مهارت پیشرفت کنند یا پسرفت نمایند. و تجربه طولانیمدت با یک گروه میتواند تأثیری ماندگار بر توانایی عملکرد فرد داشته باشد.
بعدها، وقتی وارد صنعت کامپیوتر شدم، دریافتم که این عادت آموختهشده برای جستجوی بهترین نوازندگان، بهطور طبیعی به عنوان یک برنامهنویس در من وجود دارد. شاید بهطور ناخودآگاه، به دنبال بهترین افرادِ IT برای کار کردن میگشتم. و جای تعجب نیست که این درس در اینجا هم صادق است. بدترین پسر (یا دختر، البته) بودن در تیم، همان تأثیری را دارد که بدترین فرد بودن در گروه موسیقی. متوجه میشوید که بهطور غیرقابل توضیحی باهوشتر شدهاید. حتی هوشمندانهتر صحبت میکنید و مینویسید. کدها و طراحیهایتان ظریفتر میشوند و درمییابید که قادر به حل مشکلات سخت با راهحلهای خلاقانهتر هستید. افرادی که اطرافتان هستند بر عملکرد خودِ شما تأثیر میگذارند. جمع خود را هوشمندانه انتخاب کنید.
بیایید برگردیم به دلیل اولی که توانستم بهتر از انتظارم در آن گروهها حل شوم: من واقعاً آنقدرها که فکر میکردم بد نبودم. در موسیقی، خیلی راحت میتوان فهمید که آیا نوازندگان دیگر فکر میکنند شما خوب هستید یا نه. اگر خوب باشید، دوباره دعوتتان میکنند تا با آنها ساز بزنید. اگر نباشید، از شما دوری میکنند. این معیاری بسیار مطمئنتر از این است که فقط از آنها نظرشان را بپرسید، چون نوازندگان خوب دوست ندارند با نوازندگان بد ساز بزنند.
با کمال تعجب، دریافتم که در بسیاری از این موارد، یک یا چند نفر از این نوازندگان برتر با من تماس میگرفتند تا کارهای بیشتری انجام دهم یا حتی با آنها گروه تشکیل دهم. تلاش برای «بدترین بودن» در واقع مانع از این میشود که خودتان را دستکم بگیرید. ممکن است جای شما در گروه A باشد اما همیشه خودتان را در گروه B قرار دهید، چون میترسید. اذعانِ صریح به اینکه شما بهترین نیستید، ترس از اینکه لو بروید که بهترین نیستید را از بین میبرد. در واقعیت، حتی وقتی سعی میکنید بدترین باشید، عملاً نخواهید بود.
۱. یک موقعیت «بدترین بودن» برای خود پیدا کنید. ممکن است این تجمل را نداشته باشید که فوراً تیم یا شرکت خود را عوض کنید فقط به این دلیل که میخواهید با افراد بهتری کار کنید. در عوض، یک پروژه داوطلبانه پیدا کنید که در آن بتوانید با توسعهدهندگان دیگری کار کنید که از طریق «همنشینی و تأثیرپذیری» (Osmosis) شما را بهتر کنند. دنبال جلسات گروههای توسعهدهنده (Developer groups) در شهر خود بگردید و در آنها شرکت کنید. توسعهدهندگان اغلب به دنبال پروژههای وقتِ آزاد هستند تا تکنیکهای جدید را تمرین کنند و مهارتهایشان را تیز کنند.
اگر جامعه توسعهدهندگان فعالی در نزدیکی خود ندارید، از اینترنت استفاده کنید. یک پروژه متنباز (Open Source) را انتخاب کنید که تحسینش میکنید و توسعهدهندگانش به نظر میرسد در آن «سطح بعدی» که به دنبالش هستید قرار دارند. لیست کارهای (To-do list) پروژه یا آرشیو لیست پستی را بررسی کنید، یک ویژگی (Feature) یا یک اصلاح باگ مهم را انتخاب کنید و شروع به کدنویسی کنید!
از سبک کدهای موجود در پروژه تقلید کنید. این کار را به یک بازی تبدیل کنید. طراحی و کد خود را آنقدر غیرقابل تشخیص از بقیه پروژه بسازید که حتی توسعهدهندگان اصلی هم در نهایت یادشان نیاید چه کسی آن را نوشته است. سپس، وقتی از کارتان راضی شدید، آن را به عنوان یک «پچ» (Patch) ارسال کنید. اگر خوب باشد، در پروژه پذیرفته میشود.
از نو شروع کنید و دوباره این کار را انجام دهید. اگر تصمیماتی گرفتهاید که توسعهدهندگان پروژه با آن مخالفاند، یا بازخورد آنها را اعمال کنید و دوباره بفرستید یا به تغییراتی که میدهند دقت کنید. در پچ بعدی خود، سعی کنید با دوبارهکاریِ کمتری پذیرفته شوید. در نهایت، خود را عضوی مورد اعتماد از تیم پروژه خواهید یافت. شگفتزده خواهید شد که چه چیزهایی میتوانید از مجموعهای از توسعهدهندگان ارشدِ دورکار یاد بگیرید، حتی اگر هرگز فرصت شنیدن صدایشان را پیدا نکنید.
وقتی در حال انتخاب هستید که روی چه چیزی تمرکز کنید، وسوسهکننده است که صرفاً به تکنولوژیهایی نگاه کنید که بیشترین شغل را تولید میکنند و روی آنها تمرکز کنید. جاوا بزرگ است. داتنت (.NET) بزرگ است. یادگیری جاوا یک اثر مستقیم و ساده دارد: اگر من جاوا بلد باشم، میتوانم برای شغلی که کدنویسی جاوا میخواهد درخواست بدهم و احتمالاً آن را به دست بیاورم.
با استفاده از این منطق، احمقانه به نظر میرسد که روی یک تکنولوژی خاص و محدود (Niche) سرمایهگذاری کنید، بهویژه اگر برنامهای برای بهرهبرداری از آن بازار خاص نداشته باشید.
شرکت نرمافزاری TIOBE از موتورهای جستجوی اینترنتی استفاده میکند تا محبوبیت نسبی زبانهای برنامهنویسی را بر اساس صحبتهای مردم در اینترنت درباره آن زبانها نشان دهد. طبق وبسایت TIOBE، «رتبهبندیها بر اساس در دسترس بودن مهندسان ماهر، دورههای آموزشی و فروشندگان شخص ثالث (Third-party) در سراسر جهان است.» این قطعاً یک معیار علمی قابل اثبات برای محبوبیت نیست، اما شاخص بسیار خوبی است.
در زمان نگارش این متن، محبوبترین زبان جاوا است و پس از آن C قرار دارد. سیشارپ (#C) در جایگاه قابلاحترام ششم قرار دارد اما با شیب ملایمی رو به بالا. زبان ABAP شرکت SAP در جایگاه هفدهم است و به آرامی رو به پایین حرکت میکند. روبی (Ruby) که زبان برنامهنویسی مورد علاقه شخصی من است—زبانی که تقریباً تمام کارهای جدیام را با آن انجام میدهم و هر سال کنفرانسی بینالمللی برایش برگزار میکنم—در جایگاه یازدهم است. اما زمانی که ویرایش اول این کتاب منتشر شد، روبی حتی در بین بیست تای اول هم نبود. پایینتر از ABAP بود! آیا من دیوانه بودم که از روبی استفاده میکردم یا فقط احمق بودم؟ حتماً یکی از این دو هستم، نه؟
در مقاله «هکرهای بزرگ» (Great Hackers)، پل گراهام (Paul Graham) با این ادعا که برنامهنویسان جاوا به باهوشیِ برنامهنویسان پایتون نیستند، صنعت را آزردهخاطر کرد. او بسیاری از برنامهنویسان احمقِ جاوا را عصبانی کرد (یعنی من این را گفتم؟)، و باعث شد بسیاری از آنها در وبسایتهایشان جوابیه بنویسند. این واکنش خشن نشان میدهد که او بدجوری به تریج قبایشان برخورده بود (Touched a nerve). من زمانی که این مقاله برای اولین بار به صورت سخنرانی ارائه شد، در میان حضار بودم. برای من، این سخنرانی باعث شد خاطرهای برایم زنده شود.
من در یک سفر استخدامی در هند بودم و داشتم از میان صدها کاندیدا برای تنها دهها شغل غربالگری میکردم، و تیم مصاحبه به خاطر نرخ پایینِ «موفقیتِ مصاحبه-به-استخدام» در حال از پا در آمدن بود و وقتمان هم داشت تمام میشد.
با سرهایی دردناک و چشمانی قرمز، جلسهای دیروقت برگزار کردیم تا درباره یک تغییر استراتژیک در نحوه بررسی کاندیداها بحث کنیم. ما باید یا فرآیند را بهینه میکردیم تا بتوانیم با افراد بیشتری مصاحبه کنیم، یا به طریقی با افراد بهتری مصاحبه کنیم (یا هر دو).
با ته صدایی که بعد از دوازده ساعتِ مداوم تلاش برای بیرون کشیدنِ به زورِ جواب از دهان برنامهنویسانِ بهتزده برایم مانده بود، استدلال کردم که کلمه کلیدی «Smalltalk» را به لیست کلماتی که هدهانترهای ما (مسئولین کاریابی) برای جستجو در بانک رزومهشان استفاده میکردند، اضافه کنیم.
مدیر منابع انسانی فریاد زد: «اما در هند هیچکس اسمالتاک بلد نیست.»
نکته من هم دقیقاً همین بود. هیچکس آن را بلد نبود، و برنامهنویسی در Smalltalk تجربهای اساساً متفاوت از برنامهنویسی در Java بود. این تجربه متفاوت به کاندیداها سطح متفاوتی از انتظارات میداد، و ماهیت پویای محیط Smalltalk، روشی را که یک برنامهنویس جاوا با آن به یک مسئله نزدیک میشد، تغییر میداد. امید من این بود که این عوامل، سطحی از بلوغ فنی را تشویق کند که من تا آن لحظه در کاندیداهایی که ملاقات کرده بودم، ندیده بودم.
اضافه کردن Smalltalk به لیست نیازمندیها، مجموعهای از کاندیداها را حاصل کرد که در مقایسه با لیست قبلی ما بسیار کوچک بود. این افراد، الماسهای تراشنخورده بودند. آنها واقعاً برنامهنویسی شیگرا (Object-Oriented) را درک میکردند. آنها آگاه بودند که جاوا آن نوشداروی آرمانگرایانهای که گاهی از آن ساخته میشود، نیست. بسیاری از آنها عاشق برنامهنویسی بودند! با خودمان فکر کردیم: «شماها در این دو هفته گذشته کجا بودید؟»
متأسفانه، توانایی ما برای جذب این توسعهدهندگان با حقوقهایی که قادر به پرداختش بودیم، محدود بود. آنها بودند که شرایط را تعیین میکردند، و اکثرشان انتخاب کردند که یا جای فعلیشان بمانند یا به دنبال شغل جدید دیگری بگردند. اگرچه ما نتوانستیم تعداد زیادی از آنها را استخدام کنیم، اما یک درس استخدامی ارزشمند گرفتیم: احتمال اینکه ما به کاندیداهایی با تجربه متنوع (و حتی نامتعارف) پیشنهاد کار بدهیم، بیشتر از کسانی بود که تجربیاتشان همگن و یکدست بود.
توضیح من این است که یا آدمهای خوب به دنبال تنوع هستند چون عاشق یادگیری چیزهای جدیدند، یا اینکه مجبور شدن به کار در تجربیات و محیطهای غریب، توسعهدهندگان نرمافزارِ بالغتر و همهجانبهتری میسازد. من گمان میکنم کمی از هر دو باشد، اما صرفنظر از دلیلش، ما یاد گرفتیم که این روش جواب میدهد. من هنوز هم هنگام جستجو برای توسعهدهندگان از این تکنیک استفاده میکنم.
خب، به جز اینکه بخواهید وقتی من دنبال استخدام کسی هستم در رادار من دیده شوید، چرا باید بخواهید روی تکنولوژیهای حاشیهای سرمایهگذاری کنید که ممکن است به ندرت یا هرگز فرصتی برای پول درآوردن از آنها پیدا کنید؟
برای من، به عنوان یک مدیر استخدام، دلیل اول این است که این کار نشان میدهد شما «علاقهمند» هستید. اگر بدانم شما چیزی را صرفاً برای توسعه فردی و (بهتر از آن) برای تفریح محض یاد گرفتهاید، میفهمم که شما نسبت به حرفه خود هیجانزده و باانگیزه هستید. دیوانهام میکند وقتی از افراد میپرسم آیا فلان تکنولوژیِ نه-چندان-جریان-اصلی را دیدهاند یا استفاده کردهاند و در جواب میشنوم: «فرصت کار کردن روی آن به من داده نشده است.»
فرصت داده نشده؟ به من هم داده نشد! من فرصت را برای یادگیری قاپیدم.
مهمتر از به تصویر کشیدن این ذهنیت که شما بهاندازه کافی باانگیزه و درگیرِ رشته خود هستید، این است که مواجهه با این تکنولوژیها و متدولوژیهای حاشیهای در واقع شما را عمیقتر، بهتر، باهوشتر و خلاقتر میکند.
«فرصت به من داده نشده است...؟» فرصت را دریابید!
اگر این دلیل به اندازه کافی خوب نیست، پس احتمالاً در حرفه اشتباهی هستید.
۱. یک زبان برنامهنویسی جدید یاد بگیرید. اما، از جاوا به #C یا از C به ++C نروید. زبانی را یاد بگیرید که شما را وادار کند به روشی جدید فکر کنید. اگر برنامهنویس جاوا یا #C هستید، سعی کنید زبانی مثل Smalltalk یا Ruby را یاد بگیرید که از «تایپ ایستایی» (Static typing) قوی استفاده نمیکند. یا اگر مدت زیادی است که برنامهنویسی شیگرا انجام میدهید، یک زبان تابعی (Functional) مثل Haskell یا Scheme را امتحان کنید.
لازم نیست متخصص شوید. آنقدر کد بزنید که واقعاً تفاوت را در محیط برنامهنویسی جدید احساس کنید. اگر به اندازه کافی حسِ عجیب و غریبی نداشت، یا زبان اشتباهی را انتخاب کردهاید یا دارید روش تفکر قدیمی خود را روی زبان جدید اعمال میکنید.
از مسیر خود خارج شوید تا اصطلاحات و قواعد خاص (Idioms) زبان جدید را یاد بگیرید. از قدیمیهای آن زبان بخواهید کد شما را بررسی کنند و پیشنهاداتی بدهند که آن را از نظر اصطلاحی صحیحتر کند.
در فرهنگ ما، پیروی از توصیههای والدین چیزی مقدس محسوب میشود. این کار به عنوان وظیفه فرزند تلقی میشود و در کنار انجام وظایف مذهبی، به عنوان «کار درست» رتبهبندی میگردد. طرح داستان کتابها، فیلمها و سریالهای تلویزیونی بر محور خرد و حکمتِ والدین به عنوان یک پند اخلاقی میچرخد.
اما برای مشاغل در صنعت ما، این پند اخلاقی اشتباه است. والدین شما ترجیح میدهند شما «حال و روزتان خوب و امن» باشد تا اینکه یک شغل فوقالعاده و چشمگیر به قیمت ریسکهای شخصی بزرگ داشته باشید. بیشتر از هر شخص ثالث دیگری که ممکن است به او نگاه کنید، والدین شما مشاورههایی مبتنی بر ترس به شما میدهند.
مشاوره مبتنی بر ترس، روی «نبختن» متمرکز است. فکر کردن به نباختن، راه برنده شدن نیست! برندگان ریسک میکنند. آنها به این فکر میکنند که «کجا میخواهند بروند»، نه اینکه بقیه گله کجا هستند. برنامهریزی شغلی مبتنی بر ترس، به احتمال زیاد شما را برای بقیه عمرتان در یک مزرعه از اتاقکهای اداری (Cubicle farm) مینشاند تا در مسیر عظمت و بزرگی. مطمئناً، این مسیر امن است، اما هیچ لذتی ندارد.
یک نسل قبل، وقتی درباره انتخابهای شغلی صحبت میکردیم، «لذت» فاکتور تعیینکنندهای نبود. قرار نبود مشاغل لذتبخش باشند. قرار بود نانآور باشند. لذت چیزی است که در روزهای تعطیل انجام میدهید. لذت در عصرها و آخر هفتهها اتفاق میافتد.
اما همانطور که متوجه شدهایم، اگر شغل شما لذتبخش نباشد، کار خارقالعادهای در آن انجام نخواهید داد. مسئله این نیست که اکنون اوضاع خیلی متفاوت است، بلکه درک فرهنگی ما از معنای کار کردن به سمت بهتر شدن تغییر کرده است. تعداد بیشتری از ما میفهمیم که «اشتیاق» منجر به «تعالی» میشود. و بدون لذت، بعید است که هیچ اشتیاقی در یک شغل نرمافزاری وجود داشته باشد.
یکی دیگر از عوامل تصمیمگیری شغلی که احتمالاً با دیدگاه والدین شما از دنیای کار همسو نیست، این است که تغییر شغل اشکالی ندارد (و اغلب ترجیح داده میشود). یک متخصص نرمافزار همهفنحریف زوایای بسیاری از صنعت را دیده است: توسعه محصول، پشتیبانی IT، توسعه سیستمهای تجاری داخلی و کارهای دولتی. هرچه دامنههای بیشتری دیده باشید و معماریهای فنی بیشتری را شخم زده باشید، آمادگی بیشتری برای گرفتن تصمیمات درست در پروژههای سختتر دارید. ماندن در یک شرکت واحد و بالا رفتن از پلههای ترقی در آن، محیطی محدودکننده برای رشد به عنوان یک توسعهدهنده است. روزهای کارمندان «مادامالعمر» که به یک شرکت بزرگ میپیوستند و برای یک دوره کاری کامل در آنجا مستقر میشدند، گذشته است. این نوع رفتار قبلاً نشانهای از تعهد بود. اکنون یک نقطه ضعف (Liability) است. اگر فقط در یک جا کار کرده باشید و تنها یک مجموعه از سیستمها را دیده باشید، بسیاری از مدیران (باهوش) هنگام تصمیمگیری برای استخدام،
این را به عنوان یک امتیاز منفی علیه شما میبینند. من شخصاً ترجیح میدهم کسی را استخدام کنم که تنوعی از موفقیتها و شکستها را در محیطهای مختلف دیده باشد تا کسی که فقط یک روش برای انجام کارها را میشناسد.
چند سال پیش، متوجه شدم که مسیر شغلی خودم بیش از حد تحت تأثیر ارزشهای حرفهای والدینم و نسل آنها شکل گرفته است. من برای یکی از بزرگترین و باثباتترین شرکتهای جهان کار میکردم و با سرعتی آهسته و پیوسته در حال پیشرفت بودم. اما داشتم راکد میشدم (درجا میزدم). خودم را مطمئن کرده بودم که خودم را محدود نمیکنم (Pigeon-holing)، بر این اساس که شرکت آنقدر بزرگ است که میتوانم کارهای مختلفی را در لیستی به ظاهر بیپایان از مکانها انجام دهم. اما در نهایت، من در همان مکان ماندم و همان نوع کار را انجام دادم.
یادم میآید که با دوستی در مورد احتمال بیرون آمدن از این شرکت صحبت میکردم و او گفت: «آیا سرنوشت تو این است که بقیه عمرت را در شرکتِ فلان کار کنی؟»
معلوم است که نبود! پس، سریعاً شغل دیگری پیدا کردم و آنجا را ترک کردم. این جابجایی نشاندهنده شروعِ واضحِ یک جهش غیرخطی در موفقیت من در صنعت نرمافزار بود. دامنههای جدیدی دیدم، روی مشکلات سختتری کار کردم و پاداش بسیار سنگینتری نسبت به قبل دریافت کردم. گاهی اوقات ترسناک بود، اما وقتی تصمیم گرفتم در انتخاب شغلیام کمتر محافظهکار و ترسمحور باشم، شکل و آهنگِ شغلم—و زندگیام—به سمت بهتر شدن تغییر کرد.
با شغل خود ریسکهای حسابشده بکنید. نگذارید ترس شما را ببلعد. و اگر لذت نمیبرید، عالی نخواهید بود.
۱. بزرگترین ترسهای شغلی شما چیست؟ به چند انتخاب شغلیِ آخر خود فکر کنید. لازم نیست تصمیمات بزرگی باشند (در واقع، اگر انتخابهای ترسمحور میکنید، تصمیمات شما احتمالاً بزرگ نیستند). آنها میتوانند این باشند که آیا مسئولیتهای خاصی را قبول کردهاید یا اینکه آیا برای تغییر شغل یا ترفیع درخواست دادهاید. لیستی از این انتخابها تهیه کنید و برای هر کدام، خودتان را مجبور کنید که یک ارزیابی صادقانه انجام دهید: تصمیم شما چقدر ناشی از ترس بوده است؟ اگر ترس فاکتوری نبود، چه میکردید؟ اگر تصمیم واقعاً ناشی از ترس بوده، چگونه میتوانید آن را برگردانید یا فرصتی مشابه پیدا کنید تا انتخابی با ترس کمتر انجام دهید؟
نوشته تام پرستون-ورنر (Tom Preston-Werner)
سال ۲۰۰۸ یک سال کبیسه است. این یعنی ۳۶۶ روز پیش، تقریباً سرِ دقیقه، من تنها در یک غرفه (Booth) در بار و گریل ورزشیِ Zeke در خیابان سوم سانفرانسیسکو نشسته بودم. من معمولاً در یک بار ورزشی وقت نمیگذراندم، چه برسد به یک بار ورزشی در محله SOMA، اما آن زمان پنجشنبهها شبِ «من روبی میخوام» (I Can Has Ruby) بود. حدس میزنم آن موقع «من ... میخوام» (I can has _) لقب معقولی بود که میشد تقریباً به هر چیزی چسباند. ICHR یک گردهمایی نیمهخصوصی از هکرهای روبیِ همفکر بود که عموماً و با میل خود به جلسات نوشیدنی آخرِ شب ختم میشد. معمولاً این شبها مثل خماریِ صبحِ بعدش محو میشدند، اما این شب متفاوت بود. این شبی بود که GitHub متولد شد.
فکر میکنم دلیل اینکه تنها در غرفه نشسته بودم این بود که تازه یک نوشیدنی Fat Tire سفارش داده بودم و نیاز به استراحتی کوتاه از معاشرتهایی داشتم که سر میزهای دراز در قسمت کمنورِ انتهای بار جریان داشت. در جرعه پنجم یا ششم، کریس وانستراث (Chris Wanstrath) وارد شد. الان سخت میتوانم به یاد بیاورم که آیا در آن زمان حتی کریس و خودم را به عنوان «دوست» طبقهبندی میکردم یا نه. ما همدیگر را از طریق گردهماییها و کنفرانسهای روبی میشناختیم اما فقط در حد معمولی. مثل یک حس متقابلِ «هی، فکر میکنم کُدِت عالیه». مطمئن نیستم چه چیزی باعث شد این کار را بکنم، اما به او اشاره کردم که بیاید سر میز و گفتم: «رفیق، این رو ببین.»
حدود یک هفته قبل، کار روی پروژهای به نام Grit را شروع کرده بودم که به من اجازه میداد از طریق کد روبی و به روشی شیگرا به مخازن Git دسترسی پیدا کنم. کریس در آن زمان یکی از معدود روبیکارهایی بود که داشت در مورد Git جدی میشد. او نشست و من شروع کردم به نشان دادن چیزهایی که داشتم. چیز زیادی نبود، اما کافی بود تا ببینم جرقهای در کریس ایجاد کرده است. با حس کردن این موضوع، ایده خام و نیمپختهام را برای نوعی وبسایت که به عنوان مرکزی برای کدنویسها جهت به اشتراکگذاری مخازن Git عمل کند، مطرح کردم. حتی اسمی هم داشتم: GitHub.
ممکن است نقل به مضمون کنم، اما پاسخ او چیزی در مایههای یک «من هستم. بیا انجامش بدیم!» بسیار قاطعانه بود.
شب بعد—جمعه، ۱۹ اکتبر ۲۰۰۷، ساعت ۱۰:۲۴ شب—کریس اولین کامیت (Commit) را روی مخزن GitHub انجام داد و آغاز سرمایهگذاری مشترک ما را در سنگ دیجیتال حک کرد.
تا اینجا، هیچ توافقی از هیچ نوعی در مورد چگونگی پیشرفت کارها وجود نداشت. ما فقط دو نفر بودیم که تصمیم گرفته بودیم با هم روی چیزی هک کنیم (کد بزنیم) که جالب به نظر میرسید. آن چند دقیقه شگفتانگیز در فیلم بچه کاراتهباز را یادتان هست که دنیل تمرین میکند تا متخصص هنرهای رزمی شود؟ موسیقیاش یادتان هست؟ خب، احتمالاً باید بروید و آهنگ You’re the Best از جو اسپوزیتو را در آیتونز بخرید و گوش دهید چون میخواهم با یک مونتاژ به شما ضربه بزنم.
برای سه ماه آینده، من و کریس ساعات مضحکی را صرف برنامهریزی و کدنویسی گیتهاب کردیم. من با Grit ادامه دادم و رابط کاربری (UI) را طراحی کردم. کریس اپلیکیشن Rails را ساخت. ما هر شنبه حضوری همدیگر را میدیدیم تا تصمیمات طراحی بگیریم و سعی کنیم بفهمیم طرح قیمتگذاری لعنتیمان چه شکلی خواهد بود. یادم میآید یک روزِ خیلی بارانی، دو ساعتِ تمام درباره استراتژیهای مختلف قیمتگذاری روی تعدادی از بهترین اسپرینگرولهای ویتنامیِ شهر صحبت کردیم.
همه این کارها را در حالی انجام دادیم که تعهدات دیگری هم داشتیم. من، به نوبه خودم، بهصورت تماموقت در شرکت Powerset به عنوان توسعهدهنده ابزار برای تیم رتبهبندی و ارتباط (Ranking and Relevance) مشغول به کار بودم.
در اواسط ژانویه، پس از سه ماه شبکاری و آخر هفتهها، ما نسخه بتای خصوصی را راهاندازی کردیم و دعوتنامهها را برای دوستانمان فرستادیم. در اواسط فوریه، پی.جی. هایت (P.J. Hyett) به ما پیوست و ما را سه نفره کرد. ما سایت را در ۱۰ آوریل بهصورت عمومی راهاندازی کردیم. تککرانچ (TechCrunch) دعوت نشده بود. در این نقطه، ما هنوز فقط سه تا بیستوچند ساله بودیم بدون حتی یک پنی سرمایهگذاری خارجی.
من هنوز در ۱ ژوئیه ۲۰۰۸ تماموقت در Powerset کار میکردم که فهمیدیم Powerset توسط مایکروسافت به مبلغی حدود ۱۰۰ میلیون دلار خریداری شده است. زمانبندی جالبی بود. با این خرید، من زودتر از آنچه پیشبینی کرده بودم با یک انتخاب روبرو میشدم. میتوانستم یا به عنوان کارمند مایکروسافت قرارداد امضا کنم یا استعفا دهم و تماموقت روی گیتهاب کار کنم. در ۲۹ سالگی، من مسنترینِ آن سه گیتهابی بودم و به نسبت بدهی و هزینه ماهانه بیشتری جمع کرده بودم. من به سبک زندگی ششرقمیام عادت کرده بودم. چیزی که مسئله را پیچیدهتر میکرد، بازگشت قریبالوقوع همسرم، ترزا، از کار میدانیِ دکترایش در کاستاریکا بود. من به زودی از یک مجردِ الکی دوباره به مرد متأهل تبدیل میشدم.
برای اینکه آبِ تصمیمگیری را گلآلودتر کند، پیشنهاد شغلی مایکروسافت آبدار بود. حقوق به اضافه ۳۰۰,۰۰۰ دلار در طول سه سال؛ آبدار. این پول کافی است تا هر کسی را وادار کند در مورد هر چیزی دو بار فکر کند.
بنابراین، من با این روبرو بودم: یک شغل امن با مقدار زیادی پولِ تضمینشده به عنوان مرد مایکروسافت، یا یک شغل پرریسک با مقادیر نامعلومی پول به عنوان یک کارآفرین.
میدانستم اگر مدت طولانیتری در Powerset بمانم، اوضاع با بچههای دیگرِ گیتهاب بهشدت متشنج خواهد شد. آنها که مقداری پول پسانداز کرده بودند و مدتی قبل فریلنسر شده بودند، هر دو شروع کرده بودند به اختصاص تلاش تماموقت به گیتهاب. زمانِ «مرگ یا زندگی» بود. یا گیتهاب را انتخاب کن و برو سراغش، یا انتخاب امن را بکن و گیتهاب را رها کن تا فرغونفرغون پول نقد در مایکروسافت پارو کنی.
اگر دستورالعملی برای خواب ناآرام میخواهید، میتوانم یکی به شما بدهم. یک پیمانه «همسرم چه فکری خواهد کرد؟» را با ۳۰۰۰ پیمانه بنجامین فرانکلین (دلار) مخلوط کنید، یک «هر وقت دلت خواست آبجو بخور» تویش هم بزنید و رویش را با یک شانس برای استقلال مالی تزئین کنید.
من در دادن این خبر بد به کارفرمایانم که دارم شرکت را ترک میکنم تا کار باحالتری انجام دهم، حسابی خبره شدهام. روزی که مهلت پیشنهاد شغلی تمام میشد، خبر را به رئیسم در Powerset دادم. به او گفتم که دارم استعفا میدهم تا تماموقت روی گیتهاب کار کنم. مثل هر رئیس عالیای، او ناراحت شد اما درک کرد. سعی نکرد مرا با پاداش بزرگتر یا چیزی شبیه آن وسوسه کند. فکر میکنم در اعماق وجودش میدانست که من قرار است بروم. من حتی ممکن بود به دلیل اینکه «ریسک پریدن» (Flight risk) محسوب میشدم، مشوق بزرگتری برای ماندن دریافت کرده باشم نسبت به دیگران. به شما میگویم، آن مدیران مایکروسافت حیلهگرند. آنها پاداشهای نگهداشت (Retention bonuses) را به یک علم تبدیل کردهاند—خب، البته به جز زمانی که شما یک کارآفرین، این تکینگیِ دنیای کسبوکار، را قاطی ماجرا کنید. وقتی یکی از آنها دور و بر باشد، همه چیز قاطی پاتی میشود.
در نهایت، همانطور که ایندیانا جونز هرگز نمیتوانست فرصت جستجو برای جام مقدس را رد کند، من هم نمیتوانستم شانس کار کردن برای خودم روی چیزی که واقعاً عاشقش بودم را رد کنم، مهم نبود جایگزین چقدر امن باشد. وقتی پیر و در حال مرگ هستم، برنامه دارم که به زندگیام نگاه کنم و بگویم: «واو، عجب ماجراجوییای بود»، نه اینکه بگویم «واو، من واقعاً احساس امنیت کردم.»
تام پرستون-ورنر همبنیانگذار GitHub است.
برای حداقل دو دهه، مدیران و صاحبان کسبوکارهایِ درمانده وانمود کردهاند که توسعه نرمافزار در باطن یک فرآیند تولیدی (Manufacturing process) است. مشخصاتِ نیازمندیها (Requirements specifications) ایجاد میشود و معماران (Architects) این مشخصات را به یک چشمانداز فنیِ سطح بالا تبدیل میکنند. طراحان، معماری را با مستنداتِ طراحی دقیق پر میکنند، که به کدنویسانِ رباتگونهای تحویل داده میشود که در یک دست رمانهای بازاری دارند و با دست دیگر، با خوابآلودگی، پیادهسازیِ طرح را تایپ میکنند. در نهایت، بازرس شماره ۱۲ کدِ تکمیلشده را دریافت میکند، که مهر تأیید او را نمیگیرد مگر اینکه با مشخصات اولیه مطابقت داشته باشد.
جای تعجب نیست که مدیران میخواهند توسعه نرمافزار شبیه تولید باشد. مدیران میفهمند چگونه تولید را عملی کنند. ما دههها تجربه در مورد نحوه ساخت اشیاء فیزیکی بهصورت کارآمد و دقیق داریم. بنابراین، با به کارگیری آنچه از تولید آموختهایم، باید بتوانیم فرآیند توسعه نرمافزار را به موتورِ خوشتنظیمی تبدیل کنیم که کارخانههای تولیدی ما به آن تبدیل شدهاند.
در به اصطلاح «کارخانه نرمافزار»، کارمندان متخصص هستند. آنها در جایگاه خود در خط مونتاژ مینشینند، اجزای جاوا را به هم وصل میکنند یا لبههای ناهموار یک برنامه ویژوال بیسیک را روی ماشینتراشهای نرمافزاری خود صیقل میدهند. بازرس شماره ۱۲ شغلش تست کردن است. اجزای نرمافزاری در خط حرکت میکنند و او هر روز به همان روش آنها را تست و مهر میکند. طراحان J2EE برنامههای J2EE طراحی میکنند. کدنویسان ++C با ++C کد میزنند. دنیا بسیار تمیز و بخشبندی شده است.
متأسفانه، تشبیه تولید کار نمیکند. نرمافزار حداقل به اندازه نیازمندیهای نرمافزار شکلپذیر (Malleable) است. چیزها در کسبوکار تغییر میکنند، و اهالی کسبوکار میدانند که نرمافزار «نرم» است و میتواند تغییر کند تا آن نیازمندیها را برآورده سازد. این بدان معناست که معماری، طراحی، کد و تستها همه باید به روشی «چابکتر» (Agile) از آنچه نابترین (Leanest) فرآیندهای تولید میتوانند ارائه دهند، ایجاد و بازبینی شوند.
در این نوع محیط که بهسرعت در حال تغییر است، افراد منعطف برتری خواهند داشت. وقتی فشار زیاد است، یک فرد باهوشِ بیزنس به سراغ یک متخصص نرمافزار میرود که بتواند مشکل موجود را حل کند. پس، چگونه شما
به آن شخصی تبدیل میشوید که وقتی به دنبال یک ابرقهرمان برای نجات روز میگردند، نامش مطرح میشود؟
کلید ماجرا این است که قادر باشید مشکلاتی را که ممکن است پیش بیاید حل کنید. آن مشکلات چیستند؟ درست است: شما نمیدانید. من هم نمیدانم.
آنچه میدانم این است که آن مشکلات به اندازه مسائل استقرار (Deployment)، نقصهای بحرانی طراحی که نیاز به حل و پیادهسازی مجددِ سریع دارند، یکپارچهسازی سیستمهای ناهمگون و تولید گزارشهای موردی (Ad hoc)، متنوع هستند. در مواجهه با مجموعهای از مشکلات به این تنوع، بازرس شماره ۱۲ بیچاره خیلی زود نادیده گرفته میشود.
برچسب «همهکاره و هیچکاره» (Jack-of-all-trades but master of none) معمولاً به معنای تحقیرآمیز به کار میرود، با این مضمون که فردِ برچسبخورده فاقد تمرکز لازم برای شیرجه عمیق در یک موضوع و تسلط بر آن است. اما، وقتی برنامه خرید آنلاین شما از کار افتاده (On the fritz) و شما با گذشت هر ساعت صدها سفارش را از دست میدهید، این همان «همهکاره» است که نهتنها میداند کدِ برنامه چگونه کار میکند، بلکه میتواند دیباگ سطح پایینِ یونیکس (UNIX debugging) روی فرآیندهای وبسرور شما انجام دهد، تنظیمات RDBMS شما را برای گلوگاههای عملکردیِ بالقوه تحلیل کند و پیکربندی روتر شبکه شما را برای مشکلاتِ سختیاب بررسی نماید.
و مهمتر از همه، پس از پیدا کردن مشکل، این همهکاره میتواند بهسرعت تصمیمات معماری و طراحی بگیرد، اصلاحات کد را پیادهسازی کند و یک سیستمِ اصلاحشدهی جدید را در محیط عملیاتی (Production) مستقر نماید. در این سناریو، سناریوی تولید (Manufacturing scenario) در بهترین حالت قدیمی و بامزه، و در بدترین حالت دارای نقص بحرانی به نظر میرسد.
راه دیگری که کارخانه نرمافزار در آن در هم میشکند این است که برخلاف خط مونتاژ که در آن کار بهصورت جریانی مداوم وارد میشود، پروژههای نرمافزاری معمولاً بسیار چرخهای (Cyclical) هستند. نهتنها جریان واقعی پروژهها چرخهای است، بلکه کار در داخل یک پروژه نیز چرخهای است. یک کدنویس روی نیمکت ذخیره مینشیند در حالی که نیازمندیها مشخص، معماری و طراحی میشوند، یا اینکه کدنویس بین پروژههای زیادی چندوظیفگی (Multitasking) میکند. مشکلِ کدنویسانِ چندوظیفه این است که علیرغم نیات کارخانه نرمافزار، وقتی پای عمل به میان میآید، کدنویسان برای انجام کارشان تا حد زیادی به زمینه (Context) و تجربه تکیه میکنند. مستندات نیازمندیها، معماری و طراحی میتوانند یک شروع عالی باشند، اما در نهایت اگر برنامهنویسان نفهمند سیستم قرار است چه کار کند، نخواهند توانست پیادهسازی خوبی از سیستم ایجاد کنند.
البته من اینجا فقط به کدنویسان گیر نمیدهم. همین موضوع تقریباً در هر نقطهای از خط مونتاژ نرمافزار صادق است. «زمینه» مهم است و چندوظیفگی (Multitasking) خیلی خوب کار نمیکند. در نتیجه، ما یک سیستمِ
تولیدیِ ناکارآمد داریم. تلاشهای مختلفی برای حل این مشکلِ ناکارآمدی بدون فاصله گرفتن از سیستمِ الهامگرفته از تولید صورت گرفته است، اما ما هنوز نفهمیدهایم چگونه کارخانههای نرمافزار خود را تا سطحی قابل قبول بهینه کنیم.
اگر شما «فقط» یک کدنویس یا یک تستر یا یک طراح یا یک معمار باشید، خود را در حال بیکاری یا انجام کارهای بیهوده (Busywork) در طول دورانِ فروکشِ جریان پروژههای شرکتتان خواهید یافت. اگر شما فقط یک برنامهنویس J2EE یا یک برنامهنویس .NET یا یک برنامهنویس سیستمهای یونیکس باشید، وقتی تمرکز یک پروژه یا یک شرکت، حتی بهطور موقت، از حوزه تمرکز شما خارج شود، چیز زیادی برای مشارکت نخواهید داشت.
مسئله این نیست که شما کجای زنجیره ارزشِ فرضیِ کارِ پروژه نشستهاید (جایی که معمار بالاترین جایگاه سلطنتی را دارد). مسئله این است که چقدر خودتان را بهطور کلی مفید (Generally useful) میکنید. اگر هدفتان این است که آخرین فردِ ایستاده در میانِ دورهای اخراج و فرستادنِ شغلها به آن سوی آبها باشید، بهتر است خودتان را بهطور کلی مفید کنید.
اگر میترسید که دفتر توسعهِ زمانی شلوغِ شما تبدیل به خانه یک «تیم اسکلتی» (تیم کوچک و ضروری) داخلی شود، به نفعتان است درک کنید که وقتی تیم فقط چند جای خالی دارد، یک نفر که «فقط تستر» یا «فقط کدنویس» است، خواهان نخواهد داشت. بهتر از آن، اگر فقط میخواهید متمایز و برجسته باشید، درک کردنِ «تصویر بزرگ» (The Big Picture) راهش است. همهفنحریفها کمیاباند... و بنابراین، ارزشمند. راه تبدیل شدن به یک همهفنحریف این است که به خود برچسبِ یک نقش یا تکنولوژی خاص نزنید. ما میتوانیم در مسیر شغلی خود به روشهای زیادی کلیشهای (Typecast) شویم.
برای تجسم اینکه همهفنحریف بودن چه معنایی دارد، میتواند کمککننده باشد که چشمانداز شغلی IT را به جنبههای مستقل مختلفش تشریح کنیم. من میتوانم به پنج مورد فکر کنم، اما تعداد بینهایتی وجود دارد (همه چیز به این بستگی دارد که شما شخصاً موضوعات را چطور تقسیم میکنید):
- پله نردبان شغلی
- پلتفرم/سیستمعامل
- کد در مقابل داده
- سیستمها در مقابل اپلیکیشنها
- کسبوکار (Business) در مقابل IT
اینها ابعاد مختلفی هستند که میتوانید از طریق آنها به مسئله تبدیل شدن به یک همهفنحریف نزدیک شوید. این فقط راهی برای فکر کردن در مورد تصویر کلیِ شغل شماست و شما احتمالاً میتوانید لیست بهتری برای خودتان پیدا کنید. فعلاً، ما در مورد اینها بحث خواهیم کرد.
اول، شما میتوانید انتخاب کنید که یا نوعی رهبر یا مدیر باشید یا یک فرد فنی. یا ممکن است خود را در معماری محدود کنید (Pigeonhole) در مقابلِ برنامهنویس یا تستر بودن. تواناییِ انعطافپذیر بودن در نقشهایی که میتوانید و میخواهید پر کنید، ویژگیای است که بسیاری از مردم ارزش آن را درک نمیکنند.
برای مثال، در حالی که یک رهبرِ قوی باید تا حد امکان از انجام کارهای جایگزین (Pinch-hitting) اجتناب کند، دنیای جدیدِ تیمهای اسکلتیِ داخلی میتواند از شخصی بهره ببرد که میداند چگونه افراد و پروژهها را رهبری کند اما همچنین میتواند آستینها را بالا بزند و برخی باگهای بحرانی لحظه آخری را در حالی که تیمِ آنسویِ آبها (Offshore team) خواب هستند، برطرف کند. همین موضوع در مورد یک معمار نرمافزار صادق است که شاید بتواند پیشرفت پروژه را بهطور چشمگیری سرعت بخشد، اگر فقط کمی کد بنویسد تا کارها را راه بیندازد.
وقتی صحبت از عبور از مرزهای سلسلهمراتبی میشود، اغلب اوقات این بیمیلی نیست که افراد را از انجام آن باز میدارد. توانایی است. خورههای برنامهنویسی (Programmer geeks) نمیتوانند رهبری کنند و رهبران نمیتوانند هک (کدنویسی) کنند. پیدا کردن کسی که حتی در هر دو «نسبتاً خوب» باشد، نادر است.
خط مصنوعی (و غیرقابل توجیه) دیگری دور پلتفرمها یا سیستمعاملها کشیده میشود. بودن یک «آدم یونیکسی» که از انجام ویندوز سر باز میزند، بهطور فزایندهای غیرعملیتر میشود. همین امر برای .NET در مقابل J2EE یا هر پلتفرم زیرساختی دیگری صدق میکند.
ماندگاری (Longevity) در محیط کار مستلزم این است که شما از نظر پلتفرم خنثی باشید. همه ما ترجیحات خود را داریم، اما باید ایدهآلهای خود را در خانه بگذارید. بر یکی مسلط شوید و در دیگری خوب شوید. مهارتهای شما باید فراتر از پلتفرم تکنولوژی باشد. آن فقط یک ابزار است. اگر ما یک «آدم ویندوزی» بخواهیم، میتوانیم او را در فیلیپین استخدام کنیم. اگر کسی را بخواهیم که واقعاً توسعه ویندوز و یونیکس را بفهمد و بتواند به ما در یکپارچهسازی آنها با هم کمک کند، احتمالاً در داخل کشور (Onshore) به دنبالش خواهیم گشت.
مهارتهای شما باید فراتر از پلتفرمهای تکنولوژی باشد. نگذارید به خاطر چیزی که در اصل «تعصب تیمی» است، نادیده گرفته شوید.
خط جداکننده بین مدیر پایگاهداده (نقشی که در دهه گذشته از هیچ شکل گرفته و سفت شده است) و توسعهدهنده نرمافزار نیز باید تار باشد. مدیر پایگاهداده یا DBA بودن، در بسیاری از سازمانها به این معنا شده است که شما بلد هستید از ابزار مدیریت گرافیکی (GUI admin tool) استفاده کنید و میدانید چگونه یک محصول پایگاهداده خاص را راهاندازی کنید. شما لزوماً چیز زیادی درباره نحوه استفاده از دیتابیس نمیدانید. در طرف مقابل، توسعهدهندگان نرمافزار دارند بهطور فزایندهای تنبل و بیاطلاع نسبت به نحوه کار با پایگاهدادهها میشوند. هر طرف به دیگری خوراک میدهد (این وضعیت را تشدید میکند).
چیزی که اول از همه وقتی وارد حوزه فناوری اطلاعات شدم مرا شگفتزده کرد، این بود که بسیاری از برنامهنویسان تحصیلکرده (شاید اکثرشان) الفبای راهاندازی سیستمهایی را که برای توسعه و استقرار استفاده میکردند، نمیدانستند.
من با توسعهدهندگانی کار کردم که حتی اگر از آنها میخواستید، نمیتوانستند یک سیستمعامل روی یک کامپیوتر شخصی نصب کنند، چه برسد به راهاندازی یک اپلیکیشن سرور (Application server) برای استقرار برنامههایشان روی آن. پیدا کردن توسعهدهندهای که واقعاً پلتفرمی را که روی آن کار میکند بفهمد، نادر و فرحبخش است. در نتیجه، برنامهها بهتر میشوند و کار سریعتر انجام میشود.
در نهایت، همانطور که در بخش «کدنویسی دیگر کافی نیست» (صفحه ۳۱) بحث کردیم، دیوار بین «کسبوکار» و «IT» باید همین الان خراب شود. یادگیریِ نحوه عملکردِ کسبوکار خود را شروع کنید.
۱. روی یک تکه کاغذ یا یک تخته وایتبرد، ابعادی را که ممکن است در آنها دانش و تواناییهای خود را تعمیم دهید (یا ندهید) لیست کنید. برای هر بُعد، تخصص خود را بنویسید. برای مثال، اگر پلتفرم و سیستمعامل یکی از ابعاد شماست، ممکن است Windows/.NET را کنار آن بنویسید.
حالا، در سمت راستِ تخصص خود، یک یا چند موضوع بنویسید که باید در لیست «برای یادگیری» خود قرار دهید. با ادامه دادن همان مثال، ممکن است Linux و Java (یا حتی Ruby یا Perl) را بنویسید.
در اسرع وقت (حداکثر زمانی در همین هفته!)، سی دقیقه وقت پیدا کنید تا شروع به رسیدگی به حداقل یکی از موارد «برای یادگیری» در لیست خود کنید. فقط در موردش نخوانید. اگر امکان دارد، تجربه عملی کسب کنید. اگر تکنولوژی وب است، یک بسته وب سرور دانلود کنید و خودتان راهاندازیاش کنید. اگر یک موضوع بیزنس است، یکی از مشتریان خود در محل کار را پیدا کنید و از آنها بخواهید برای ناهار و گپ و گفت بیرون بروید.
«چطور برنامهای مینویسید، در جاوای خالص (Pure Java)، که باعث کرش کردنِ (Crash) ماشین مجازی جاوا (JVM) شود؟»
سکوت مرگبار.
«الو؟»
«ببخشید. متوجه منظورتان نمیشوم. میشود لطفاً سوال را تکرار کنید؟» صدا مستأصل به نظر میرسید. از تجربه میدانستم که تکرار سوال کمکی نخواهد کرد. بنابراین، سوال را تکرار کردم، شمردهتر و بلندتر.
«چطور برنامهای مینویسید، در جاوای خالص، که باعث شود ماشین مجازی جاوا کرش کند؟»
«امم... متأسفم. تا حالا همچین کاری نکردم.»
«مطمئنم که نکردید. نظرتان درباره این سوال چیست: چطور برنامهای مینویسید که باعث شود JVM کرش نکند؟»
من به دنبال برنامهنویسانِ جاوای واقعاً خوب بودم. برای شروع مصاحبه، از این شخص (و تمام کسان دیگری که آن هفته مصاحبه کرده بودم) خواستم تا به خودشان از یک تا ده نمره بدهند. او گفت نُه. من اینجا انتظار یک ستاره را دارم. اگر این آقا چنین نمره بالایی به خودش میدهد، چرا نمیتواند حتی به یک ترفند برنامهنویسیِ مخرب (Abusive) فکر کند که باعث کرش کردن JVM شود؟
فقدان عمق فنی. این کسی بود که ادعا میکرد در جاوا «تخصص» دارد. اگر او را در مهمانی میدیدید و میپرسیدید چه کاره است، میگفت: «من یک توسعهدهنده جاوا هستم.» با این حال، او نتوانست به این سوال ساده پاسخ دهد. حتی نتوانست یک پاسخ غلط سرهم کند.
در طول دو و نیم هفته مصاحبههای فشرده در یک سفر استخدامی به سراسر کشور، این «قاعده» بود—نه استثنا. هزاران متخصص جاوا برای موقعیتهای باز درخواست داده بودند، که تقریباً هیچکدامشان نمیتوانستند توضیح دهند که یک Java Class Loader چگونه کار میکند یا یک نمای کلی سطح بالا از اینکه مدیریت حافظه معمولاً توسط ماشین مجازی جاوا چگونه انجام میشود، ارائه دهند.
به نظر میرسد بسیاری از ما معتقدیم که تخصص داشتن در چیزی صرفاً به معنای ندانستن درباره چیزهای دیگر است. قبول، لازم نیست این چیزها را بدانید تا کدهای ابتدایی را زیر نظر دیگران سرهمبندی (Hack out) کنید. اما قرار بود اینها متخصص (Expert) باشند.
به نظر میرسد بسیاری از ما معتقدیم که تخصص داشتن در چیزی صرفاً به معنای این است که شما درباره چیزهای دیگر نمیدانید. مثلاً من میتوانم مادرم را متخصص ویندوز بنامم، چون او هرگز از لینوکس یا OS X استفاده نکرده است. یا میتوانم بگویم اقوامم در مناطق روستایی آرکانزاس متخصصان موسیقی کانتری هستند، چون هرگز به چیز دیگری گوش ندادهاند.
تصور کنید به پزشک خانوادگی خود مراجعه میکنید و از وجود توده عجیبی زیر پوست بازوی راستتان شکایت دارید. پزشکتان شما را به یک متخصص ارجاع میدهد تا نمونهبرداری (Biopsy) انجام دهید. چه میشود اگر آن متخصص کسی باشد که تنها مدرکش به عنوان متخصص این باشد که در هیچ کلاسی در دانشکده پزشکی شرکت نکرده و هیچ تجربهای در دورههای رزیدنتی نداشته که مستقیماً به انجامِ عملِ خاصی که قرار است امروز روی شما انجام دهد مربوط نباشد؟
منظورم این نیست که آنها در موضوعات مرتبط با عمل امروز عمیقتر شدهاند. چه میشود اگر آنها فقط سطح این موضوعات را خراشیده باشند (اطلاعات سطحی داشته باشند)، اما هیچ چیز دیگری هم ندانند؟
ممکن است بپرسید: «اگر آن دستگاهِ آنجا در حین عمل شروع به بوق زدن کرد چه؟»
«اوه، تا حالا پیش نیامده. این بار هم اتفاق نمیافتد. من نمیدانم آن دستگاه چه کار میکند، ولی هیچوقت بوق نمیزند.»
خوشبختانه، بیشتر توسعهدهندگان نرمافزار مسئول موقعیتهای مرگ و زندگی نیستند. اگر خرابکاری کنند، معمولاً منجر به طولانی شدن پروژهها یا باگهای محیط عملیاتی میشود که صرفاً برای کارفرمایانشان هزینه مالی دارد، نه جانی. متأسفانه، صنعت نرمافزار تعداد زیادی از این متخصصان کمعمق را بیرون داده است، کسانی که از واژه «متخصص» به عنوان بهانهای برای دانستنِ تنها یک چیز استفاده میکنند.
در صنعت پزشکی، متخصص کسی است که درک عمیقی از یک حوزه خاص از رشته دارد. پزشکان بیمارانشان را به متخصصان ارجاع میدهند، زیرا در شرایط خاصِ معین، متخصص میتواند مراقبت بهتری نسبت به پزشک عمومی به آنها ارائه دهد.
پس، یک متخصص در حوزه نرمافزار باید چه ویژگیهایی داشته باشد؟
من میتوانم به شما بگویم در آن سفر استخدامی، در هر سوراخسنبهای به دنبال چه بودم. من به دنبال افرادی بودم که عمیقاً برنامهنویسی جاوا و محیط استقرار (Deployment environment) را درک میکردند. من کسانی را میخواستم که بتوانند در ۸۰ درصد موقعیتهایی که ممکن است با آنها روبرو شویم بگویند «این راه را رفتهام، این کار را کردهام» و عمق دانششان بتواند ۲۰ درصد باقیمانده را قابلتحملتر کند. من کسی را میخواستم که هنگام کار با انتزاعات سطح بالا (High-level abstractions)، جزئیات سطح پایینی را که در پیادهسازی آن انتزاعات به کار رفته، درک کند. من کسی را میخواستم که بتواند هر مشکل استقراری را که ممکن است با آن روبرو شویم حل کند، یا حداقل بداند اگر خودش نتوانست، برای کمک به چه کسی زنگ بزند.
این همان نوع متخصصی است که در صنعتِ در حالِ تغییرِ کامپیوتر دوام خواهد آورد. اگر شما متخصص داتنت هستید، این فقط بهانهای برای ندانستنِ هیچ چیز جز داتنت نیست. این بدان معناست که اگر موضوعی به داتنت مربوط باشد، شما در آن صاحبنظرید (Authority). سرورهای IIS هنگ کردهاند و نیاز به ریبوت دارند؟ «مشکلی نیست.» یکپارچهسازی سورس کنترل با ویژوال استودیو داتنت؟ «نشانتان میدهم چطور.» مشتریان به خاطر مشکلات عملکردیِ مبهم تهدید به قطع همکاری میکنند؟ «سی دقیقه به من وقت بدهید.»
اگر معنی متخصص برای شما این نیست، پس امیدوارم ادعا نکنید که متخصص هستید.
۱. آیا از زبان برنامهنویسیای استفاده میکنید که کامپایل میشود و روی یک ماشین مجازی اجرا میگردد؟ اگر چنین است، زمانی بگذارید تا درباره عملکرد درونی ماشین مجازی (VM) خود یاد بگیرید. برای جاوا، داتنت و اسمالتاک، کتابها و وبسایتهای زیادی به این موضوع اختصاص یافتهاند. یادگیری آن آسانتر از چیزی است که فکر میکنید.
چه زبان شما متکی به ماشین مجازی باشد و چه نباشد، زمانی بگذارید تا مطالعه کنید که دقیقاً وقتی یک فایل منبع (Source file) را کامپایل میکنید چه اتفاقی میافتد. کدی که تایپ میکنید چطور از متنی که میتوانید بخوانید به دستورالعملهایی تبدیل میشود که کامپیوتر میتواند اجرا کند؟ نوشتن کامپایلرِ خودتان چه معنایی خواهد داشت؟
وقتی کتابخانههای خارجی (External libraries) را ایمپورت یا استفاده میکنید، آنها از کجا میآیند؟ ایمپورت کردن یک کتابخانه خارجی واقعاً چه معنایی دارد؟ کامپایلر، سیستمعامل یا ماشین مجازی شما چگونه چندین قطعه کد را به هم پیوند میدهد (Link) تا یک سیستم منسجم را تشکیل دهد؟
یادگیری این حقایق شما را چندین گام به متخصص (Expert specialist) بودن در تکنولوژی انتخابیتان نزدیکتر میکند.
۲. فرصتی پیدا کنید—در محل کار یا بیرون—تا کلاسی در مورد جنبهای از یک تکنولوژی برگزار کنید که دوست دارید در آن عمق پیدا کنید. همانطور که در بخش «مربی باشید» (Be a Mentor) خواهید دید، تدریس یکی از بهترین راهها برای یادگیری است.
زمانی که مدیر یک گروه توسعه اپلیکیشن بودم، یک بار از یکی از کارمندانم پرسیدم: «میخواهی با مسیر شغلیات چه کار کنی؟ میخواهی چه کاره شوی؟»
من از پاسخ او به شدت ناامید شدم: «میخواهم معمار J2EE شوم.»
پرسیدم چرا یک «طراح مایکروسافت ورد» یا یک «نصاب RealPlayer» نه؟
این آدم میخواست مسیر شغلیاش را حول یک تکنولوژیِ خاص بسازد که توسط یک شرکتِ خاص ایجاد شده بود که او کارمندش نبود. اگر آن شرکت ورشکست میشد چه؟ اگر اجازه میداد تکنولوژیِ فعلاً جذابش منسوخ شود چه؟ چرا باید با مسیر شغلی خود به یک شرکت تکنولوژی اعتماد کنید؟
به نحوی، به عنوان یک صنعت، ما خودمان را گول میزنیم و فکر میکنیم «رهبر بازار» بودن همان «استاندارد» بودن است. بنابراین، برای برخی افراد منطقی به نظر میرسد که محصول شرکت دیگری را بخشی از هویت خود کنند. بدتر از آن، برخی افراد مسیر شغلی خود را بر پایه محصولاتی بنا میکنند که حتی رهبر بازار هم نیستند—حداقل تا زمانی که شغلشان آنقدر مفتضحانه شکست بخورد که چارهای جز بازنگری در این استراتژیِ بازنده نداشته باشند.
بیایید دوباره لحظهای وقت بگذاریم و به یاد بیاوریم که باید به شغل خود به عنوان یک کسبوکار نگاه کنیم. اگرچه ممکن است کسبوکاری ساخت که به صورت انگلِ کسبوکار دیگری وجود داشته باشد (مانند شرکتهایی که محصولات حذف جاسوسافزار (Spyware) میسازند تا کاستیهای مدل امنیتی مرورگر مایکروسافت را جبران کنند)، اما به عنوان یک فرد، انجام این کار فوقالعاده پرریسک است.
یک شرکت، مانند مثال جاسوسافزاری که همین الان زدم، معمولاً میتواند به نیروهای در حال تغییر در بازار واکنش نشان دهد، مثل بهبود غیرمنتظره در امنیت مرورگر مایکروسافت (یا تصمیم مایکروسافت برای ورود به بازار حذف جاسوسافزار). در حالی که یک فرد، پهنای باند (ظرفیت) یا پول اضافی برای تغییر ناگهانیِ جهت یا تمرکز شغلی را ندارد.
دیدگاههای فروشندهمحور (Vendor-centric) معمولاً کوتهبینانه هستند. چیز غمانگیز در مورد دیدگاه فروشندهمحور به دنیا این است که معمولاً جزئیات پیادهسازی نرمافزارِ یک فروشنده، یک راز است. شما واقعاً فقط تا حد مشخصی میتوانید در مورد یک نرمافزار انحصاری (Proprietary) یاد بگیرید تا زمانی که به سد «خدمات حرفهای» برخورد کنید.
سدِ خدمات حرفهای، مانعی مصنوعی است که یک شرکت بین شما و راهحلِ مشکلی که ممکن است داشته باشید ایجاد میکند تا بتواند از فروش خدمات پشتیبانی به شما سود ببرد. گاهی اوقات این سد عمداً ایجاد میشود، و گاهی اوقات به عنوان عارضه جانبیِ تلاشی است که شرکت برای محافظت از مالکیت معنوی خود (با به اشتراک نگذاشتن کد منبع) انجام میدهد.
بنابراین، اگرچه سرمایهگذاری تکبعدی روی یک تکنولوژی خاص تقریباً همیشه ایده بدی است، اگر مجبورید این کار را بکنید، تمرکز روی یک گزینه متنباز (Open Source) را در نظر بگیرید، نه یک گزینه تجاری. حتی اگر نمیتوانید یا نمیخواهید برای استفاده از راهحل متنباز در محل کارتان استدلال بیاورید، از گزینه متنباز به عنوان پلتفرمی استفاده کنید که از طریق آن میتوانید شیرجهای عمیق به درون تکنولوژی بزنید.
برای مثال، ممکن است بخواهید در نحوه کار اپلیکیشن سرورهای J2EE متخصص شوید. بهجای اینکه تلاشتان را روی جزئیات نحوه پیکربندی و استقرار یک اپلیکیشن سرور تجاری متمرکز کنید (هر چه باشد، هر کسی میتواند بفهمد چطور تنظیمات را در یک فایل کانفیگ دستکاری کند، نه؟)، سرورهای متنباز JBoss یا Geronimo را دانلود کنید و زمانی را برای خود کنار بگذارید تا نهتنها یاد بگیرید چگونه با سرورها کار کنید، بلکه اجزای داخلی (Internals) آنها را مطالعه نمایید.
خیلی زود متوجه خواهید شد که بهطور طبیعی دیدگاهتان در حال تغییر است. این قضیه J2EE (یا هر چیزی که انتخاب کردید واردش شوید) واقعاً آنقدرها هم خاص نیست. حالا که جزئیات پیادهسازی را میبینید، میبینید که الگوهای مفهومی سطح بالایی در کار هستند. و شروع به درک این موضوع میکنید که، چه با جاوا و چه با زبان یا پلتفرم دیگری، معماری سازمانی توزیعشده (Distributed enterprise architecture)، همان معماری سازمانی توزیعشده است.
دیدگاه شما از باریک به وسیع تغییر میکند و ذهنتان شروع به باز شدن میکند. شروع به درک این میکنید که این مفاهیم و الگوهایی که مغزتان در حال دستهبندی و معنا کردن آنهاست، بسیار مقیاسپذیرتر و جهانیتر از تکنولوژیِ هر فروشنده خاصی هستند.
«بگذار فروشندهها بیایند و بروند—من میدانم چطور یک سیستم طراحی کنم!»
۱. یک پروژه کوچک را دو بار امتحان کنید. یک بار آن را در تکنولوژی اصلی خود انجام دهید و سپس یک بار، تا حد امکان اصولی و با رعایت قواعد خاص (Idiomatically)، در یک تکنولوژی رقیب.
ممکن است این حرف شبیه نوعی مزخرفاتِ تشویقیِ پرشور و حرارت به نظر برسد که هدفش شلاق زدن شما به سمت یک جنون آرمانگرایانه است، اما مهمتر از آن است که گفته نشود. اگر میخواهید در کارتان عالی باشید، باید نسبت به کارتان اشتیاق (Passion) داشته باشید. اگر اهمیت ندهید، خودش را نشان خواهد داد.
وقتی من و همسرم به بنگلور نقل مکان کردیم، من واقعاً هیجانزده بودم. برای اولین بار در مسیر شغلیام، مشتاقانه منتظر یافتن تکنولوژیستهای همفکر در نزدیکی بودم که اشتیاقی برای یادگیری داشته باشند. انتظار یک زندگیِ پرجنبوجوشِ پس از کار را داشتم، با جلسات گروههای کاربری و بحثهای عمیق و فلسفی درباره متدولوژیها و تکنیکهای توسعه نرمافزار. انتظار داشتم «سیلیکون ولیِ هند» را در حال انفجار از سرریزِ صنعتگران (Artisans) مشتاق در تعقیبِ هنرِ والای توسعه نرمافزار بیابم.
چیزی که پیدا کردم، انبوهی از آدمها بودند که فقط میآمدند تا حقوق بگیرند، و تعداد انگشتشماری صنعتگرِ فوقالعاده پرشور. درست مثلِ خانه (آمریکا).
البته، در آن زمان متوجه نشدم که آنجا درست مثل خانه است. من چند نقطه داده (Data point) از ایالات متحده داشتم، اما همیشه فرض میکردم که فقط در شهرهای بد یا محیطهای شرکتی بد کار کردهام. موقعیتهایی مثل اولین تجربیاتم با اشتغال در IT را به عنوان دادههای پرت (Outliers) میشمردم. با خودم فکر میکردم: «بیشتر توسعهدهندگان نرمافزار حتماً قضیه را میگیرند. من فقط هنوز محیط مناسب را پیدا نکردهام.»
من کار در دپارتمان IT دانشگاهم را با یک توصیه کورکورانه از طرف دوستم والتر شروع کردم. او کار کردن من با کامپیوترها را به اندازه کافی دیده بود که بداند احتمالاً میتوانم بهتر از اکثر کسانی که در دانشگاه نیاز به کمک داشتند، آنها را وادار به انجام کارها کنم. من که هیچ آموزش رسمی نداشتم، باور نمیکردم بتوانم. من فقط یک نوازنده ساکسیفون بودم که دوست داشت بازیهای ویدیویی بازی کند. اما، والتر واقعاً یک فرم درخواست برایم پر کرد و یک مصاحبه ترتیب داد. من بدون اینکه حتی یک سوال فنی پرسیده شود استخدام شدم و قرار بود فوراً شروع کنم.
وقتی سرِ کار حاضر شدم، پارانویا داشتم که به عنوان شیادی که واقعاً بودم لو بروم. این نوازنده ساکسیفون اینجا با ما حرفهایهای آموزشدیده چه میکند؟ هر چه باشد، من داشتم با کسانی کار میکردم که مدارک پیشرفته علوم کامپیوتر داشتند. و من اینجا بودم، تنها با بخشی از یک مدرک موسیقی، و سعی میکردم طوری جا بیفتم که انگار چیزی سرم میشود.
در عرض چند روز کار کردن، حقیقت شروع به نفوذ کرد. این آدمها هیچ ایدهای ندارند که دارند چه غلطی میکنند! در واقع، برخی افراد داشتند کار کردن مرا تماشا میکردند و یادداشت برمیداشتند! افرادی با مدرک کارشناسی ارشد علوم کامپیوتر!
اولین واکنش من این بود که فرض کنم توسط احمقها محاصره شدهام. هر چه باشد، من هیچ آموزش رسمی نداشتم. شبهایم را به نوازندگی در گروههای موسیقیِ بارها میگذراندم و روزهایم را به انجام بازیهای کامپیوتری. من فقط به این دلیل کار با کامپیوتر را یاد گرفته بودم که به آنها علاقه داشتم. در واقع، من واقعاً برنامهنویسی را یاد گرفتم چون میخواستم بازیهای کامپیوتری خودم را بسازم.
من دیروقت بعد از یک شب کرکننده در یک بار به خانه میآمدم و در سایتهای Gopher (سیستمی برای اشتراک اسناد شبیه وب که با ظهور وب منسوخ شد) آموزشهای برنامهنویسی را تا طلوع خورشید مرور میکردم. سپس میخوابیدم، بیدار میشدم و یادگیریام را ادامه میدادم تا زمانی که مجبور میشدم بیرون بروم و دوباره اجرا کنم. مطالعه را با بازیهای کامپیوتریِ محبوبم قطع میکردم، غذا میخوردم و سپس دوباره برمیگشتم به ور رفتن با گوفر و هر کامپایلری که میتوانستم راهش بیندازم.
وقتی به گذشته نگاه میکنم، میبینم معتاد بودم، اما به روشی خوب. میل من به خلق کردن، دقیقاً به همان روشی شعلهور شده بود که وقتی نوشتن موسیقی کلاسیک یا نواختن جاز بداهه را شروع کردم. من وسواسِ یادگیریِ هر چیزی و همه چیزی را داشتم که میتوانستم. من برای یک شغل جدید در این کار نبودم. در واقع، بسیاری از دوستان موزیسینم آن را به عنوان یک حواسپرتیِ غیرمسئولانه از شغل واقعیام میدانستند. من در این کار بودم چون نمیتوانستم نباشم.
کار کنید چون نمیتوانید کار نکنید.
این تفاوتِ بین من و همکارانِ بیشازحد-تحصیلکرده و کمبازدهام در محل کار بود. اشتیاق. این افراد هیچ ایدهای نداشتند که چرا در رشته IT هستند. آنها تصادفی وارد مشاغلشان شده بودند، چون فکر میکردند برنامهنویسی کامپیوتر ممکن است درآمد خوبی داشته باشد، چون والدینشان تشویقشان کرده بودند، یا چون نتوانسته بودند به رشته بهتری در کالج فکر کنند. متأسفانه، عملکردشان در کار این را منعکس میکرد.
اگر به زندگینامههایی که میخوانید یا مستندهایی که درباره بزرگان در رشتههای مختلف تماشا میکنید فکر کنید، همین الگویِ رفتارِ اعتیادگونه و پرشور ظاهر میشود. جان کولترین (John Coltrane)، بزرگِ ساکسیفون جاز، طبق گزارشها آنقدر تمرین میکرد که لبهایش خونریزی میکرد.
البته، استعداد ذاتی نقش بزرگی در توانایی ایفا میکند. همه ما نمیتوانیم موتزارت یا کولترین باشیم. اما، همه ما میتوانیم با پیدا کردن کاری که نسبت به آن اشتیاق داریم، گامی بزرگ برای دور شدن از میانمایگی (Mediocrity) برداریم.
ممکن است یک تکنولوژی یا دامنه کسبوکار باشد که شما را هیجانزده میکند. یا از طرف دیگر، ممکن است یک تکنولوژی یا دامنه کسبوکار خاص باشد که شما را پایین میکشد. یا نوعی سازمان. شاید شما برای تیمهای کوچک ساخته شدهاید یا تیمهای بزرگ. یا فرآیندهای خشک. یا فرآیندهای چابک (Agile). ترکیبش هر چه که هست، زمانی بگذارید تا مال خودتان را پیدا کنید. میتوانید مدتی تظاهر کنید (Fake it)، اما فقدان اشتیاق، یقه شما و کارتان را خواهد گرفت.
۱. بروید شغلی پیدا کنید که واقعاً نسبت به آن اشتیاق دارید.
۲. از دوشنبه آینده، برای دو هفته یک گزارش (Log) ساده نگه دارید. هر روز کاری وقتی بیدار میشوید، سطح هیجان خود را در مقیاس ۱ تا ۱۰ رتبهبندی کنید—۱ یعنی ترجیح میدهید واقعاً مریض شوید تا اینکه سر کار بروید، و ۱۰ یعنی به سختی میتوانید در رختخواب بمانید چون فکرِ انجام دادنِ کارِ بعدی شما را بلعیده است.
بعد از دو هفته ثبت این گزارش، نتایج را بررسی کنید. آیا نقاط اوجی (Spikes) وجود داشت؟ آیا روندهایی (Trends) وجود داشت؟ آیا همه پایین بود یا همه بالا؟ اگر این یک امتحان مدرسه بود، نمره میانگین شما چند میشد؟
برای دو هفته بعد، هر صبح برنامهریزی کنید که چگونه میخواهید فردا را به یک ۱۰ تبدیل کنید. برنامهریزی کنید که امروز چه کاری انجام میدهید تا فردا یکی از آن روزهای کاری باشد که برای شروعش نمیتوانید صبر کنید. هر روز، سطح هیجان دیروز را ثبت کنید. اگر بعد از دو هفته اوضاع غمانگیز به نظر میرسد، ممکن است زمان آن رسیده باشد که یک تغییر بزرگ را در نظر بگیرید.
نوشته جیمز دانکن دیویدسون (James Duncan Davidson)
از همان ابتدا، من چیزی که خیلیها یک مسیر شغلی سنتی در نظر میگیرند، نداشتم. در عوض، بیشتر مسیری بوده از دنبال کردن فرصتها به شکلی که خودشان را نشان میدهند.
اولینِ این فرصتها زمانی ظاهر شد که در دانشگاه مشغول تحصیل برای دریافت مدرک معماری بودم. من در ۱۵ یا ۱۶ سالگی تصمیم گرفته بودم که میخواهم معمار شوم، و زمان زیادی را صرف سرمایهگذاری روی آن آینده کردم. اما بذرهای آنچه که واقعاً شغل من پس از دانشگاه را شکل میداد، در شیفتگیِ اولیه من به سیستمهای آنلاین BBS کاشته شد.
من یکی از آن بچههایی بودم که عاشق مودم ۳۰۰-baud در کامپیوترِ خانوادگی بودند. این در نهایت مرا به اینترنت کشاند، که مرا به Gopher و سپس به World Wide Web رساند. وب بلافاصله مرا قلاب کرد (Hooked me). من چندین وبسایت شخصی را به سرعت ساختم و از هر تکنولوژیِ موجودی که در اختیارم بود استفاده کردم و هر جا نیاز بود همه چیز را خودم به خودم یاد دادم.
در آن زمان، من به این کار به عنوان آزمایشهایی در «معماری سایبری» (Cyberarchitecture) نگاه میکردم. الان خیلی پرطمطراق و حتی کاملاً احمقانه (Dorky) به نظر میرسد، اما این دنیایی بود که ما در روزهای اولیه وب در آن زندگی میکردیم. ما سعی میکردیم تصور کنیم آینده چه چیزی ممکن است بیاورد.
البته، کار واقعیِ ساختنِ آینده اینترنت در آزمایشگاههای معماری اتفاق نمیافتاد. بلکه در دنیای کسبوکار در جریان بود. خیلی زود، و بر اساس آنچه با وبسایت عمومی خود انجام داده بودم، یک استارتآپ که برای امثال هیلتون (Hilton) و Better Business Bureau وبسایت میساخت با من تماس گرفت. آنها وبسایتهایی را که ساخته بودم دیده بودند، و ظاهراً من دقیقاً همان مهارتهایی را داشتم که آنها نیاز داشتند.
به من شغلی پیشنهاد شد با حقوقی که در آن زمان به طرز مضحکی عالی به نظر میرسید. من آن را قبول کردم، با این تصور که میتوانم مدتی روی این موج سوار شوم، مقداری پول پسانداز کنم و چند سال بعد به دانشگاه برگردم. سال ۱۹۹۵ بود.
روحم هم خبر نداشت که اوضاع تا کجا پیش خواهد رفت و کمی اشتیاق برای کندوکاو در چیزهای جدید، مرا به کجا خواهد برد.
در حین کمک به ساخت اولین نسخه وبسایت هیلتون که قابلیت رزرو آنلاین (Real-time reservation placement) داشت، یاد گرفتم چگونه با استفاده از انواع تکنولوژیهای سمت سرور (Server-side) وبسایت بسازم. در عرض چند ماه، من از یک کارآموز به کسی تبدیل شدم که فریمورکهای سمت سرورِ خودش را میساخت. وقتی به گذشته نگاه میکنم، مسخره به نظر میرسد، اما در آن زمان، این چیزی بود که ضرورت داشت. من روزنهای دیدم، آن را گرفتم و تا جایی که ارزش داشت از آن بهرهبرداری کردم، و در صورت نیاز خودم را از نو ساختم (Reinventing myself).
یک چیز منجر به چیز دیگری شد. در سال ۱۹۹۷، من به JavaSoft رفتم تا روی نرمافزار سمت سرور کار کنم، و پس از چند سال، مسئولیت مشخصات Servlet (Servlet specification) را بر عهده گرفتم. متأسفانه، این تلاشی با بودجه ناکافی بود، و من تیمی نداشتم که کمکم کند تمام کارهایی که باید انجام میشد را انجام دهم، از جمله ساخت یک پیادهسازی مرجعِ (Reference implementation) جدید.
با این حال، اجازه ندادم این موضوع متوقفم کند و شروع کردم به ساخت یک پیادهسازی کاملاً جدید از پایه که در نهایت با نام «کیت توسعه وب جاواسرور» (JavaServer Web Development Kit) منتشر شد. افراد زیادی آن نرمافزار را به یاد نمیآورند. اما اکثر کسانی که با جاوا در سمت سرور کار میکنند، نسخه بعدی آن کد را میشناسند. اسمش Tomcat است. و از طریق بنیاد نرمافزاری آپاچی (Apache Software Foundation) به همراه دستیارش به نام Ant به دنیا عرضه شد.
داستان پشت آن انتشار خودش یک کتاب را پر میکند. همینقدر کافی است بگویم که همه اینها از طریق مجموعهای عالی از فرصتها اتفاق افتاد که توانستم از آنها بهرهبرداری کنم.
پس از چهار سال کار در شرکت Sun و مواجهه با سوالی از نوع «بعدش چه کار کنم؟»، تصمیم گرفتم مستقل شوم. برای O’Reilly کتاب نوشتم. برای Mac نرمافزار توسعه دادم. مقدار زیادی نرمافزار برای خودم توسعه دادم که در نهایت آنها را منتشر نکردم. و در نهایت کمی هم توسعه Ruby on Rails انجام دادم.
توسعهدهنده نرمافزارِ مستقل بودن با من مهربان بود، و من در آن نسبتاً خوب هستم. اما در طول مسیر، سرگرمیای که دنبال میکردم شروع کرد به رشد کردن و تبدیل شدن به مسیر شغلی خودش. علاوه بر اینکه دانشجوی معماری بودم که تبدیل به تکنولوژیست شده بود، مدتها عکاس هم بودم. مادربزرگم اصول اولیه را به من یاد داد. والدینم تشویقم کردند. در نتیجه، تا آنجا که یادم میآید، همیشه یک دوربین دور و برم داشتم. این بخش بزرگی از زندگی من بوده است. در واقع، نرمافزار منتشرنشدهای که پس از ترک Sun برای خودم نوشتم، برای کار با عکسها بود.
در سال ۲۰۰۵، ده سال پس از اینکه شانسی آوردم و دنده را از دانشجوی معماری به توسعهدهنده نرمافزار تغییر دادم، تماسی از دوستانم در گروه کنفرانسهای O’Reilly دریافت کردم. آنها به کسی نیاز داشتند تا رویدادهایشان را مستند کند و پرسیدند آیا علاقهمندم بیایم و چند تا عکس (Snap) بگیرم.
من قبول کردم، اما به جای گرفتنِ تنها چند عکس، کمی فراتر از دستورالعملم (Brief) عمل کردم. دیوانهوار کار کردم و تمام جلسات مهم را پوشش دادم و تصاویر را در Flickr آپلود کردم تا تحویلِ کار (Turnaround) فوقالعاده سریعی داشته باشم. دوباره دعوت شدم و در طول چهار سال گذشته، کسبوکاری حول این موضوع با طیف وسیعی از مشتریان ساختهام.
در حالی که این را مینویسم، هنوز گهگاهی کد میزنم (Hack code)، و حتی کمی کار نرمافزاری برای چند مشتری انجام میدهم. اما، این روزها تقریباً یک عکاس تماموقت هستم. با این حال، ممکن است تغییر کند. آدم هیچوقت نمیداند. سخت است گفت که آینده چه چیزی خواهد آورد.
آنچه میدانم این است که من یک «فرصتطلبِ سریالی» (Serial Opportunist) هستم. وقتی چیزی را میبینم که برایم جالب و هیجانانگیز است، میپرم وسط و هر کاری لازم باشد برای موفقیت انجام میدهم. معمولاً این به معنای یادگیری مهارتهای جدید و کسب توانمندیهای تازه است. برخی ممکن است ایجاد مهارتهای جدید را کسالتبار بدانند، اما به دلایلی من عاشق یادگیریِ نحوه انجام کارهای جدید هستم. هر چه باشد، مهارتهای جدید به شما اجازه میدهند کارهای جدید انجام دهید.
و من هرگز خودم را با مهارتهایم تعریف نکردهام. در عوض، همیشه خودم را با کارهایی که انجام دادهام و کارهایی که میخواهم بعداً انجام دهم تعریف کردهام. مهارتها فقط راهی برای رسیدن به آنجا هستند.
جیمز دانکن دیویدسون یک برنامهنویس و عکاس است.