آیا ستاره پاپ دهه ۱۹۸۰ به نام تیفانی (بدون نام خانوادگی) را به یاد دارید؟ او در آن زمان در صدر جدول «چهل آهنگ برتر» بود و صدایش مدام از رادیو شنیده میشد. او از موفقیت عظیمی لذت برد و برای مدت کوتاهی نامش سر زبانها بود. آخرین باری که چیزی درباره او شنیدید (اگر اصلاً شنیده باشید) کی بود؟ حدس میزنم که نمیتوانید به یاد بیاورید. من هم نمیتوانم.
تیفانی چیزی را داشت که برای موفقیت (هیت شدن) در دهه ۸۰ لازم بود — حداقل برای مدتی کوتاه. بعد دهه ۹۰ از راه رسید و تیفانی کاملاً از مد افتاد. ظاهراً، اگر تلاشی هم کرده بود، آنقدر سریع حرکت نکرد که بتواند علاقه — یا حتی توجه — طرفدارانش را حفظ کند. وقتی سلیقه ملت از موسیقی «پاپِ آدامسبادکنکی» (Bubble gum pop) به «گرانج» (Grunge) تغییر کرد، تیفانی ناگهان منسوخ شد.
همین اتفاق میتواند در حرفه شما هم بیفتد. فرآیندی که در این کتاب آمده یک حلقه است که تا زمان بازنشستگی شما تکرار میشود: تحقیق کنید، سرمایهگذاری کنید، اجرا کنید، بازاریابی کنید، تکرار کنید. صرف کردن زمان بیش از حد در هر تکرار از این حلقه، شما را در معرض خطر منسوخ شدنِ ناگهانی قرار میدهد. اگر صراحتاً مراقبش نباشید، میتواند یواشکی سراغتان بیاید. و وقتی غافلگیرتان کرد، دیگر خیلی دیر شده است.
تیفانی احتمالاً هیچ ایدهای نداشت که جریان «گرانج» قرار است بترکاند. او تمام تلاشش را میکرد تا یک ستاره پاپ نوجوانِ آدامسبادکنکی باشد، و تا زمانی که موسیقی گرانج جدولِ چهلتاییها را تسخیر کرد، او به شکلی برگشتناپذیر از مد افتاده بود.
این بخش به شما نشان خواهد داد که چطور از تبدیل شدن به یک «معجزهی تکآهنگ» (One-hit wonder) اجتناب کنید.
بسیاری از ما جذب صنعت آیتی شدیم چون همه چیز همیشه در حال تغییر است. این یک محیط کاری هیجانانگیز و تازه است. همیشه چیز جدیدی برای یادگیری وجود دارد. اما روی دیگر سکه، این واقعیتِ دلسردکننده است که دانشِ مرتبط با تکنولوژیِ ما که به سختی به دست آمده، سریعتر از یک ماشین شِورلتِ نو مستهلک میشود. کالای داغ و جدیدِ امروز، آشغالِ منسوخِ فردا با تاریخ انقضای محدود است.
مهارتهای جدید و براق شما از همین الان منسوخ شدهاند.
در کتاب رهبری انقلاب (Leading the Revolution)، گری همل (Gary Hamel) درباره این صحبت میکند که چطور رهبرانِ فعلیِ هر صنعتی دچار خودشیفتگی و تنبلی میشوند و از طریق این تنبلی، نقاط کور پیدا میکنند. هرچه کسبوکار شما موفقتر باشد، احتمال اینکه با مدل کسبوکار خود راحت و آسوده شوید بیشتر است، که این شما را به شدت در برابر کسانی که پشت سر شما با یک ایده رادیکال میآیند آسیبپذیر میکند — حتی یک ایده احمقانه — که ممکن است مدل کسبوکارِ فوقالعاده و برندهی شما را شبیه یک ژاکت کهنه و نخنما در یک دیسکو نشان دهد.
همین را میتوان درباره انتخابهای تکنولوژی گفت. اگر شما بر «بزرگِ» هر دوره زمانی مسلط شده باشید، مثل J2EE یا NET. در زمانی که این کتاب منتشر شد، ممکن است احساس راحتی فوقالعادهای بکنید. جای پر سودی است، مگر نه؟ هر وبسایت کاریابی و بخش نیازمندیهای روزنامه، تأییدی بر تصمیم شماست.
مراقب باشید. موفقیت غرور میآورد، و غرور تنبلی میآورد. موجی مثل J2EE ممکن است طوری حس شود که انگار هرگز تمام نخواهد شد. اما، همه امواج در نهایت یا پراکنده میشوند یا به ساحل میخورند. راحتیِ بیش از حد برای مدت طولانی ممکن است شما را بیدفاع بگذارد و در حالی رها کند که متعجبید در یک دنیای بدون J2EE چه کار باید بکنید.
با وجود این حرفها، مردم دهههاست که دارند مرگ کوبول (COBOL) را اعلام میکنند. هر مدعیِ جدیدی «کوبولِ قرن بیست و یکم» یا چیزی شبیه به آن نامیده میشود. این روزها، این برچسب به جاوا زده میشود. هرچقدر هم که من از دست زدن، دیدن یا نزدیک بودن به کدِ کوبول متنفر باشم، اینکه جاوا را کوبولِ قرن بیست و یکم بنامیم، تعریف بزرگی است. هرچقدر هم که برخی از ما دوست داشته باشیم رفتنش را ببینیم، کوبول اینجاست، و برای مدت طولانی کار کرده است. برنامهنویسان کوبول برای یک عمرِ کاریِ کامل با کوبول کار کردهاند. در این ترنِ هواییِ صنعتی که ما داریم، این واقعاً حرفی برای گفتن دارد. سخت است بگوییم که آیا همان نوع سرمایهگذاری در اقتصاد امروز جواب میدهد یا نه.
داستان کوبول استثناست — نه قاعده. تکنولوژیهای کمی چنین پلتفرمِ پایداری برای اشتغال فراهم میکنند. پیام اینجا این نیست که بدوید و خودتان را از دانشِ جریانِ اصلی (Mainstream) خالی کنید. این کار غیرمسئولانه خواهد بود. من میگویم هرچه دانش شما بیشتر در جریان اصلی باشد، ریسک اینکه در عصر حجرِ تکنولوژی جا بمانید بیشتر است.
ما همه برونیابیهای قانون مور (Moore's law) را شنیدهایم که میگوید قدرت محاسباتی هر هجده ماه دو برابر میشود. چه اعداد دقیقاً درست باشند چه نه، آسان است ببینیم که تکنولوژی هنوز تقریباً با همان نرخی پیشرفت میکند که در سال ۱۹۶۵ وقتی گوردون مور از اینتل این ادعا را کرد، پیشرفت میکرد. و با این پیشرفتها در اسب بخارِ سختافزار، پیشرفتهایی در آنچه انجامش با نرمافزار ممکن است، پدید میآید.
قدرت محاسباتی دو برابر میشود.
با پیشرفتِ سریع تکنولوژی، اتفاقاتِ بیش از حدی در جریان است که هر فرد خاصی بتواند با همه آنها همگام شود. حتی اگر مهارتهای شما کاملاً بهروز باشد، اگر تقریباً در پایانِ فرآیند یادگیریِ «چیز بزرگ بعدی» (Next Big Thing) نباشید، تقریباً خیلی دیر شده است. شما میتوانید جلوتر از منحنیِ موجِ فعلی باشید و عقبتر از موج بعدی. زمانبندی در محیطی مثل این بسیار مهم میشود.
باید با درک این موضوع شروع کنید که حتی اگر روی لبه تیغِ تکنولوژیِ موجِ امروز باشید، احتمالاً از همین الان نسبت به موج بعدی عقب هستید. حالا که زمانبندی همهچیز است، شروع کنید به آیندهنگری در مطالعهتان. چه چیزی دو سال دیگر ممکن خواهد بود که الان ممکن نیست؟ اگر فضای دیسک آنقدر ارزان بود که عملاً رایگان میشد چه؟ اگر پردازندهها دو برابر سریعتر بودند چه؟ در آن صورت دیگر لازم نبود نگران بهینهسازی چه چیزی باشیم؟ این پیشرفتها چطور ممکن است چیزی را که قرار است مُد شود (hit)، تغییر دهند؟
بله، این کمی قمار است. اما، این بازیای است که اگر انجامش ندهید قطعاً میبازید. بدترین حالت این است که چیزی غنیکننده یاد گرفتهاید که دو سال دیگر مستقیماً در شغلتان کاربرد ندارد. پس، باز هم با نگاه به جلو و انجام چنین قماری، وضعیت بهتری دارید. بهترین حالت این است که جلوتر از منحنی باقی میمانید و میتوانید همچنان متخصصِ تکنولوژیهای لبهی تکنولوژی باشید. نگاه به جلو و صراحت داشتن در توسعه مهارتهایتان میتواند تفاوت بین کور بودن یا بینا (Visionary) بودن باشد.
اقدام کنید!
۱. زمان هفتگی برای تحقیق درباره لبه تیغِ تکنولوژی (Bleeding edge) کنار بگذارید. حداقل دو ساعت در هر هفته جا باز کنید تا درباره تکنولوژیهای جدید تحقیق کنید و شروع به توسعه مهارت در آنها نمایید. با این تکنولوژیهای جدید کارِ عملی انجام دهید. برنامههای ساده بسازید. نسخههایی با تکنولوژیِ جدید از بخشهای سختِ پروژههای با تکنولوژیِ فعلیتان بسازید (پروتوتایپ کنید) تا بفهمید تفاوتها چیست و تکنولوژیهای جدید چه چیزی را امکانپذیر میکنند. این زمان را در برنامهتان بگذارید. نگذارید از دست برود.
شغلی که برای انجامش استخدام شده بودید دیگر وجود ندارد. ممکن است هنوز حقوق بگیرید. ممکن است ارزش اضافه کنید. ممکن است حتی کارفرمایتان را از خوشحالی ذوقمرگ کنید. اما، شما همین الان شغلتان را از دست دادهاید.
تنها چیزِ قطعی این است که همه چیز در حال تغییر است. اقتصاد در حال جابجایی است. مشاغل به خارج (Offshore) میروند و برمیگردند. کسبوکارها سعی میکنند بفهمند چطور سازگار شوند. اوضاع در صنعت ما به نقطه ثبات نرسیده است. صنعت ما مثل نوجوانِ دستپاچلفتیای است که دارد بلوغ را میگذراند. دستپاچلفتی، زشت و متفاوت؛ سال به سال — روز به روز.
بنابراین، اگر استخدام شدهاید که برنامهنویس باشید، به خودتان به عنوان یک برنامهنویس فکر نکنید. به خودتان فکر کنید به عنوانِ کسی که شاید دیگر برنامهنویس نیست. به انجام کارتان ادامه دهید، اما زیادی راحت نباشید. سعی نکنید در هویتِ یک برنامهنویس ساکن شوید. یا یک طراح. یا یک تستر.
در واقع، دیگر امن نیست (انگار که قبلاً بوده) که خودتان را بیش از حد نزدیک به شغلی که برایش استخدام شدهاید شناسایی کنید. اگر محیط اطراف شما در حال تغییر است و بافتِ (Context) کار شما دائماً در حال حرکت است، چسبیدن به شغلتان ناهماهنگیِ ناسالمی ایجاد میکند که کارتان را آلوده میکند. ممکن است خودتان را به عنوان «کسی که میخواهد برنامهنویس باشد» در حال انجام کارِ «کسی که باید مدیر پروژه باشد» بیابید. و آن کار را ضعیف انجام دهید.
شما شغلِتان نیستید.
قبلاً، قبل از اینکه شغلتان را از دست بدهید، ممکن است نقشههایی داشتید. ممکن است پیشرفت خودتان را در رتبههای شرکت تصور کرده بودید. شما دورانِ طراح بودنتان را میگذراندید و وقتی پاداشِ حقتان میرسید، نقش معمار (Architect) را میگرفتید. میتوانستید کلِ مسیرِ پیشرفت از معمار به تحلیلگر به رهبر تیم و بالا رفتن از زنجیره مدیریت را ببینید.
اما، شما همین الان شغلتان را از دست دادهاید، و نقشههایتان تغییر کردهاند. آنها قرار است به تغییر کردن ادامه دهند. هر روز.
داشتنِ جاهطلبی خوب است، اما زیادی روی یک آیندهی طولانی و خیالی حساب باز نکنید. نمیتوانید از پسِ هزینهِ داشتنِ دید تونلی (Tunnel vision) نسبت به چیزی که خیلی در آینده دور است، بربیایید. اگر میخواهید به یک هدفِ متحرک شلیک کنید، خودِ هدف را نشانه نمیگیرید. جایی را نشانه میگیرید که هدف احتمالاً به آنجا خواهد رفت. مسیر از اینجا به آنجا دیگر یک خط مستقیم نیست. در بهترین حالت یک قوس (Arc) است، اما به احتمال زیاد یک خطِ کجومعوج (Squiggle) است.
اقدام کنید!
۱. اگر برنامهنویس هستید، یکی دو روز سعی کنید کارتان را طوری انجام دهید که انگار تستر یا مدیر پروژه هستید. نقشهای زیادی که ممکن است روزانه بازی کنید و هرگز صراحتاً در نظر نگرفتهاید، چه هستند؟ لیستی تهیه کنید، و آنها را امتحان کنید (پرو کنید). یک روز را روی هر کدام وقت بگذارید. ممکن است حتی خروجیِ واقعیِ کارتان را تغییر ندهید، اما کارتان را متفاوت خواهید دید.
یکی از بزرگترین مشکلات آمریکا این است که جامعهای هدفگرا (Goal-oriented) است. ما ملتی از مردمی هستیم که همیشه روی نتیجهی یک فرآیند تمرکز کردهایم، چه فرآیندِ یادگیری باشد، چه حرفهی شغلی، یا حتی رانندگی در ماشین. ما آنقدر روی نتیجه متمرکزیم که فراموش میکنیم به مناظر نگاه کنیم.
اگر به آن فکر کنید، تمرکز روی نتایج، منطقاً برعکسِ چیزی است که باید وقتمان را رویش صرف کنیم. شما معمولاً تمام وقتتان را صرفِ انجام دادنِ کارها میکنید و زمان کمی از وقتتان را صرفِ رسیدن به اهداف.
برای مثال، وقتی دارید نرمافزار توسعه میدهید، فرآیند توسعه جایی است که تمام وقتتان را میگذرانید، نه روی رویدادِ واقعیِ بیرون پریدنِ نرمافزارِ تمامشده از انتهای فرآیند. این درباره حرفهی شما هم صادق است. گوشتِ واقعیِ حرفهی شما، ترفیعها و افزایش حقوقها نیست. زمانی است که صرفِ کار کردن به سمت آن پیشرفتها میکنید. یا مهمتر از آن، زمانی است که صرفِ کار کردن میکنید، فارغ از پیشرفتها.
اگر این هستهی زندگی کاری شماست — یعنی کارِ واقعی — پس شما همین الان به مقصدتان رسیدهاید. تفکرِ هدفگرا و متمرکز بر مقصد که معمولاً انجام میدهید، فقط از یک هدف به هدف بعدی میرود. هیچ پایان منطقیای ندارد. چیزی که بیشترِ ما در درکش شکست میخوریم این است که مسیر، همان پایان است.
با بازگشت به مثال توسعه نرمافزار، آسان است که غرق در تحویلِ کدی شوید که دارید خلق میکنید. مشتری شما نیاز دارد یک وباپلیکیشن بالا بیاید، و شما روی تمام کردنِ آن اپلیکیشن تمرکز میکنید. اما، یک اپلیکیشنِ زنده هرگز «تمام» نمیشود. یک نسخه (Release) به نسخه بعدی منجر میشود. تمرکز بیش از حد روی محصول نهایی، ما را از تحویلدادنیِ (Deliverable) واقعی منحرف میکند: توسعهی پایدارِ یک موجودیتِ جدید.
روی انجام دادن تمرکز کنید، نه روی تمام شدن.
تمرکز بر پایان باعث میشود فراموش کنید فرآیند را خوب بسازید. و فرآیندهای بد، محصولات بد میسازند. محصول ممکن است حداقلِ نیازمندیهایش را برآورده کند، اما درونش زشت خواهد بود. شما برای هدفِ نهاییِ کوتاهمدت بهینهسازی کردهاید — نه برای آیندهی اجتنابناپذیر و جاریِ توسعهی محصول.
نهتنها فرآیندهای بد محصولات بد میسازند، بلکه محصولات بد هم فرآیندهای بد میسازند. وقتی یکی از این محصولات را دارید که درونش شلوغوپلوغ است، فرآیندهای شما دورِ آن شکل میگیرند (تطبیق مییابند). پنجرههای شکسته (Broken windows) در محصول شما منجر به پنجرههای شکسته در فرآیند شما میشود. این یک چرخه معیوب است.
بنابراین، به جای اینکه مدام بپرسید «هنوز نرسیدیم؟ هنوز نرسیدیم؟» درک کنید که تنها پاسخِ سالم «بله» است. این که چطور مسیر را طی میکنید مهم است — نه مقصد.
اقدام کنید!
۱. تیچ نات هان (Thich Naht Hanh) در کتابش معجزه ذهنآگاهی (The Miracle of Mindfulness) پیشنهادی ارائه میدهد: دفعه بعد که مجبورید ظرف بشویید، آنها را برای این نشویید که تمام شوند. سعی کنید از تجربه ظرف شستن لذت ببرید. روی تمام کردن آنها تمرکز نکنید. روی خودِ عملِ شستنِ آنها تمرکز کنید. ظرف شستن یک کارِ پیشپاافتاده (Mundane) است که تقریباً هیچکس از آن لذت نمیبرد (مزه نمیکند). توسعهدهندگان نرمافزار هم کارهای سخت و خستهکنندهی (Drudgery) مشابهِ زیادی دارند که باید در یک روز معمولی انجام دهند، مثل ردیابی زمان (Time tracking) و گزارش هزینه. دفعه بعد که مجبورید کاری مثل این انجام دهید، ببینید آیا میتوانید راهی پیدا کنید که حین انجام کار روی خودِ کار تمرکز کنید به جای اینکه با اضطراب عجله کنید تا تمامش کنید.
وقتی در "حالت نگهداری" (Maintenance Mode) هستی، خیلی راحت میتونی توی یه روتین تکراری بیفتی و همونجوری که هستی بمونی. به عنوان یه توسعهدهنده نرمافزار، از تجربهای که با سیستمها داری میدونی که این حرف درسته.
اگه مسئول نگهداریِ یه اپلیکیشن یا کتابخونه باشی که بقیه توسعهدهندهها ازش استفاده میکنن، اون نرمافزار توی حالت "رفع باگ" (یا بدتر از اون) راکد میمونه، مگر اینکه یه نقشه راه (Roadmap) مشخص و قوی برای ویژگیهای جدیدش داشته باشی. شاید هر از گاهی به خاطر درخواست کاربرها یا نیازهای خودت یه تغییر کوچیک توش بدی، اما کدها معمولاً به یه حالت سکون میرسن و چون فکر میکنی "کارش تمومه"، تغییراتش به شدت کند میشه.
اما یه نرمافزار زنده، هیچوقت "تموم" نمیشه؛ مگر اینکه تو جادهی بازنشستگی و مرگ باشه.
دقیقاً همین ماجرا دربارهی تو و مسیر شغلیت هم صدق میکنه. مگر اینکه بخوای از این صنعت خداحافظی کنی، وگرنه نیاز به یک "نقشه راه" داری.
- اگه مایکروسافت ویندوز ۳.۱ رو "تموم شده" فرض میکرد، الان همهمون داشتیم با مکینتاش کار میکردیم.
- اگه توسعهدهندگان آپاچی (Apache) وقتی به نسخه ۱.۰ رسیدن کار رو تموم شده میدونستن، الان رهبر بلامنازع بازار نبودن.
نقشه راه محصول شخصی تو، چیزیه که باهاش میفهمی آیا حرکت کردی یا نه. وقتی هر روز به همون دفتر کار همیشگی میری و روی همون چیزهای تکراری کار میکنی، منظرهی اطرافت تغییر نمیکنه. باید یه سری نشانه در دوردستها برای خودت بذاری تا وقتی بهشون رسیدی، بفهمی که واقعاً جلو رفتی. "ویژگیها" (Features) یا مهارتهای جدید تو، همون نشانهها هستن. تا وقتی که برنامهریزی نکنی، نمیتونی دورتر از نوک دماغت رو ببینی.
تو فصلهای قبل یاد گرفتی که چطور در انتخاب مسیر شغلی هوشمندانه عمل کنی. فکر کردن به هر مجموعه جدید از دانش یا توانایی به عنوان یک "ویژگی" (Feature) در یک نرمافزار، دید خیلی خوبی بهت میده. نرمافزاری که فقط یه ویژگی داشته باشه، خیلی به درد بخور نیست. از اون بدتر، نرمافزاری که یه مشت ویژگی بیربط و غیرمنسجم داشته باشه، کاربرهاش رو گیج میکنه. (مثلاً این الان دفترچه تلفنه یا اپلیکیشن چت؟ بازیه یا مرورگر وب؟).
یک نقشه راه شخصی نهتنها کمکت میکنه تو مسیر بمونی و مدام پیشرفت کنی، بلکه تصویر بزرگتری از چیزی که برای ارائه داری رو بهت نشون میده. بهت نشون میده که هیچ مهارتی به تنهایی کافی نیست. هر سرمایهگذاری جدید، بخشی از یک کلِ بزرگتره. شاید یادگیری مهارتهای متنوع خوب باشه و ذهنت رو باز کنه، اما باید به داستانی که مهارتهات تعریف میکنن هم فکر کنی. بدون نقشه راه، داستان شغلی تو ممکنه بیشتر شبیه یه رمان گیجکننده باشه تا یک مجموعه منسجم از تواناییهای مرتبط. بدون نقشه، ممکنه واقعاً گم بشی.
قبل از اینکه نقشه بکشی که کجا میخوای بری، خیلی مفیده که ببینی کجا بودی. ۱. یکم وقت بذار و خط زمانی (Timeline) شغلیت رو روی کاغذ بیار. ۲. نشون بده از کجا شروع کردی و در هر مرحله چه مهارتها و شغلهایی داشتی. ۳. ببین کجاها پیشرفتهای کوچیک داشتی و کجاها پرشهای بزرگ کردی. ۴. ببین به طور میانگین چقدر طول کشیده تا یه پیشرفت اساسی بکنی.
از این نقشه تاریخی استفاده کن تا آیندهت رو بسازی. وقتی تصویر شفافی از گذشتهت داشته باشی، هدفهای واقعیتری برای خودت میچینی.
آدم باید احمق باشه که پولش رو توی یه سهام پرنوسان سرمایهگذاری کنه و بعد کلاً بیخیالش بشه. حتی اگه کلی تحقیق کرده باشی، بازار همیشه غیرقابلپیشبینیه. توی سرمایهگذاری نمیتونی از استراتژی "بزن و در رو" (Fire-and-forget) استفاده کنی. حتی اگه ارزش یه سهام الان داره میره بالا، معنیش این نیست که فردا سقوط نمیکنه.
شاید هم داری یه فرصت رو از دست میدی. ممکنه الان یه جای امن با سود ۱۰ درصد پیدا کرده باشی. تا وقتی بقیه بازار سودش بیشتر از ۱۰ درصد نشه، این معاملهی خوبیه. اما اگه حواست نباشه و شرایط بازار عوض بشه، ممکنه سودی که میتونستی ببری رو از دست بدی.
همین موضوع دقیقاً برای سرمایهگذاری روی دانش هم صدق میکنه. مثلاً جاوا (Java) امروز انتخاب محافظهکارانه و امنیه. اما چه چیزی ممکنه تغییر کنه که این حرف دیگه درست نباشه؟ از کجا میفهمی؟ مثلاً اگه شرکت "سان مایکروسیستمز" (سازنده اصلی جاوا در زمان نوشتن کتاب) ورشکست بشه چی؟ اگه تغییرات ناسازگار بدن چی؟
اگه سرت فقط توی مانیتور و کد زدن باشه، ممکنه وقتی خبردار بشی که دیگه خیلی دیر شده. یهو خودت رو توی بازار کار با یه مهارت کمارزش پیدا میکنی.
شاید این سناریو بعید باشه، اما محتملتر اینه که: چون توی شغل فعلیت و با مهارتهای فعلیت راحتی، از "اتفاق بزرگ بعدی" (Next Big Thing) که داره میاد کاملاً بیخبر بمونی. ۱۰ سال پیش، کسی فکرش رو نمیکرد زبانهای شیءگرا اینقدر غول بشن. اما اگه حواست جمع بود، نشانههاش رو میدیدی. ۱۰ سال دیگه چی مده؟ کی میدونه؟
باید چشم و گوشت رو باز نگه داری. اخبار تکنولوژی (هم بخش تجاری و هم فنی) رو دنبال کن. به قول "تیم اورایلی" (Tim O’Reilly): "حواست به آلفا گیکها (Alpha Geeks) باشه." آلفا گیکها اون خوره های کامپیوتری هستن که همیشه (حداقل توی پروژههای تفریحیشون) روی لبهی تکنولوژی راه میرن و دست و پاشون خونیه! اگر ببینی این آدمها دارن با چی ور میرن، میتونی بفهمی یکی دو سال دیگه قراره چی توی دنیا مد بشه. این روش به طرز عجیبی خوب جواب میده.
یادت باشه توی تکنولوژی، سرمایهگذاریِ خوبِ امروز، لزوماً فردا خوب نیست. غافلگیر نشو.
۱. سال آینده رو صرف این کن که سعی کنی یکی از اون "آلفا گیکها" بشی. ۲. یا حداقل با یکیشون بگرد و رفیق شو!
من متأسفانه اضافه وزن دارم. خیلی وقته. وقتی هند زندگی میکردم، خیلی وزن کم کردم (بخشی بخاطر رژیم، بخشی ورزش، ولی عمدتاً بخاطر مریضی!). وقتی برگشتم آمریکا، آروم آروم دوباره چاق شدم. نکته جالبش اینه که من واقعاً نمیفهمم کِی دارم چاق میشم یا لاغر. تنها راهی که میفهمم اینه که یکی بهم بگه یا لباسهام دیگه اندازم نشه. خانمم هم چون هر روز منو میبینه متوجه تغییرات ریز نمیشه.
چون من خودم رو "هر روز" میبینم، تغییر رو حس نمیکنم. اگه بشینی پای گلی که داره باز میشه، باز شدنش رو نمیبینی. اما اگه بری و دو روز دیگه برگردی، تغییرش واضحه.
همین اتفاق برای شغل و حرفهت میفته. در واقع، متوجهش نمیشی؛ مشکل دقیقاً همینه. شاید هر روز تو آینهی استعاریِ شغلیت نگاه کنی و هیچ تغییری نبینی. فکر میکنی همونقدر بهروزی، همونقدر رقابتی هستی. اما یهو یه روز میبینی شغلت (یا صنعتت) دیگه اندازهت نیست. اولش فقط یکم ناراحته، اما وقتی به نقطه بحرانی برسی، مجبوری سریع عمل کنی یا بری یه شلوار (استعاری) جدید بخری!
برای وزن، ترازو داریم. اما متأسفانه ترازویی برای سنجش "بازارپسندی" یا مهارتت به عنوان توسعهدهنده وجود نداره. پس باید ترازوی خودت رو بسازی.
توسعهدهنده، خودت رو ارزیابی کن. یه راه آسون، استفاده از یه شخص سومِ قابل اعتماده. یه منتور (Mentor) یا همکار نزدیک که توی سرِ تو زندگی نمیکنه و میتونه یه نگاه بیطرفانه بهت بندازه. توی شرکت جنرال الکتریک (GE) یه پروسهای هست به اسم "ارزیابی ۳۶۰ درجه". با اینکه اسمش خیلی اداریه، اما روش فوقالعادهیه: بازخورد گرفتن از همردهها، مدیران و حتی مشتریها.
مهمترین چیزی که باید کشف کنی "نقاط کور" (Blind Spots) تو هستن. لازم نیست همشون رو درست کنی، فقط باید بدونی کجان. بدون ارزیابی، نسبت به نقاط کورت، کور هستی! و اونجاست که اتفاقات بد غافلگیرت میکنن.
حتی اگه ترازوی جادویی هم داشتی، تا وقتی روش نری فایده نداره.
- ارزیابیها رو زمانبندی کن.
- توی تقویمت "وقتِ خود-ارزیابی" بذار.
- نتایج رو بنویس.
- نذار منسوخ شدن مثل یه شلوار تنگ یواش یواش خفتت کنه!
۱. یه ارزیابی ۳۶۰ درجه انجام بده:
- لیستی از آدمهای قابل اعتماد (همکار، مدیر، مشتری) تهیه کن.
- لیستی از ۱۰ تا ویژگی که برات مهمه (مهارت فنی، ارتباطات و...) بنویس.
- تبدیلش کن به پرسشنامه و بفرست براشون. بگو که "نقد سازنده" میخوای نه "تعارف".
- جوابها رو بخون و برنامه بریز. ۲. شروع کن به نوشتن (Journaling):
- وبلاگ یا دفترچه خاطرات. درباره چیزایی که یاد میگیری و نظراتت بنویس.
- بعد از مدتی نوشتههای قدیمیت رو بخون. چقدر تغییر کردی؟ چقدر اون موقع خام بودی؟
در کتاب Zen and the Art of Motorcycle Maintenance، رابرت پیرسیگ داستان روشنگرانهای تعریف میکند دربارهی اینکه مردم جنوب هند چطور میمونها را شکار میکردند. نمیدانم این داستان واقعاً درست است یا نه، اما درس مفیدی میدهد، پس آن را بهاختصار نقل میکنم.
مردم جنوب هند، که سالها از دست میمونها کلافه شده بودند، روش هوشمندانهای برای به دام انداختن آنها ابداع کردند. آنها یک سوراخ بلند و باریک در زمین میکندند و بعد با یک ابزار باریک و بلند، انتهای سوراخ را کمی گشادتر میکردند. سپس مقداری برنج داخل بخشِ گشادِ پایین سوراخ میریختند.
میمونها عاشق غذا هستند. در واقع، بخش بزرگی از آفتبودنشان دقیقاً به همین دلیل است. روی ماشینها میپرند یا حاضرند از وسط جمعیت عبور کنند تا غذا را از دستت بقاپند. مردم جنوب هند این را خوب میدانند. (باور کن ایستادن آرام در یک پارک و دیدنِ یک ماکاک که ناگهان هجوم میآورد تا چیزی از تو بدزدد، تجربهی عجیبی است.)
طبق روایت پیرسیگ، میمونها میآمدند، برنج را پیدا میکردند و دستشان را تا ته سوراخ پایین میبردند. دستشان به انتهای سوراخ میرسید. بعد حریصانه هرچه میتوانستند برنج در مشتشان جمع میکردند و دستشان را مشت میکردند. مشت آنها در بخش گشاد جا میشد، اما دهانهی باریک سوراخ آنقدر تنگ بود که نمیتوانستند مشت بستهشان را بیرون بکشند. گیر میافتادند.
البته میتوانستند خیلی ساده غذا را رها کنند و آزاد شوند. اما میمونها برای غذا ارزش بسیار بالایی قائلاند. آنقدر بالا که نمیتوانند خودشان را مجبور کنند آن را رها کنند. آنها آن برنج را نگه میدارند تا یا از زمین بیرون بیاید یا خودشان در تلاش برای بیرون کشیدنش بمیرند. معمولاً دومی زودتر اتفاق میافتاد.
پیرسیگ این داستان را برای توضیح مفهومی به نام «خشکی ارزش» (Value Rigidity) تعریف میکند. خشکی ارزش زمانی رخ میدهد که به ارزشِ چیزی آنقدر شدید باور داری که دیگر نمیتوانی آن را بهطور عینی زیر سؤال ببری. میمونها آنقدر برای برنج ارزش قائل بودند که وقتی مجبور میشدند بین برنج و اسارت یا مرگ یکی را انتخاب کنند، نمیتوانستند ببینند که در آن لحظه از دست دادن برنج انتخاب درست است.
این داستان میمونها را خیلی احمق نشان میدهد، اما بیشتر ما معادلهای شخصیِ خودمان را برای آن برنج داریم.
اگر از تو بپرسند آیا کمک به تغذیهی کودکان گرسنه در کشورهای در حال توسعه کار خوبی است یا نه، احتمالاً بدون لحظهای فکر کردن میگویی «بله». اگر کسی سعی کند خلافش را استدلال کند، شاید فکر کنی دیوانه است. این هم یک نمونه از خشکی ارزش است. به چیزی آنقدر محکم باور داری که حتی تصورِ باور نداشتنش برایت ممکن نیست. واضح است که همهی ارزشهایی که ما بهطور سختگیرانه به آنها پایبندیم بد نیستند. برای بیشتر آدمها، مذهب (یا نبودنش) هم مجموعهای از باورها و ارزشهای شخصیِ تغییرناپذیر است.
ارزشهای سختگیرانه، تو را شکننده میکنند.
اما همهی ارزشهایی که سفت و سخت به آنها چسبیدهایم خوب نیستند. و خیلی وقتها چیزی که در یک شرایط خوب است، در شرایط دیگر خوب نیست. مثلاً بهراحتی میشود در انتخاب فناوری گیر افتاد. این مسئله بهخصوص وقتی شدیدتر میشود که فناوری مورد علاقهات نقش «کمتر دیدهشده» را داشته باشد. آنقدر عاشقش میشویم و آنقدر برای دفاع از آن بهعنوان یک انتخاب ارزش قائل میشویم که هر فرصت را یک نبرد میبینیم—حتی وقتی داریم آشکارا از انتخاب اشتباه دفاع میکنیم.
نمونهای که زیاد با آن برخورد کردهام (و احتمالاً خودم هم مقصر بودهام) تعصب افراطی طرفداران لینوکس است. خیلی از کاربران لینوکس حاضرند لینوکس را روی دسکتاپ هر منشی، دستیار اداری یا مدیر ارشد شرکتی نصب کنند، بدون توجه به این واقعیت که از نظر کاربردپذیری، ابزارهایش قابل مقایسه با بسیاری از نرمافزارهای تجاریِ سیستمعاملهای تجاری نیست. وقتی نرمافزار درست را به آدم اشتباه بدهی، هم خودت مضحک به نظر میرسی و هم مشتریهایت را ناراضی میکنی.
همانطور که سخت است بفهمی وزن کم کردهای چون هر روز خودت را میبینی، خشکی ارزش هم همینطور عمل میکند. چون هر روز در مسیر شغلیمان زندگی میکنیم، بهراحتی دچار خشکی ارزش در انتخابهای شغلی میشویم. میدانیم چه چیزهایی قبلاً جواب دادهاند و همانها را ادامه میدهیم. یا شاید همیشه آرزو داشتهای وارد مدیریت شوی، و بدون توجه به اینکه واقعاً برنامهنویسی را دوست داری یا نه، همچنان بهسمت آن هدف فشار میآوری.
حتی ممکن است فناوریِ مورد علاقهات منسوخ شود و ناگهان بدون هیچ تکیهگاهی بمانی. مثل قورباغهای در قابلمهای که آرامآرام گرم میشود، ممکن است یکدفعه بفهمی در وضعیت بدی گیر افتادهای. خیلی از ما در اواسط دههی ۱۹۹۰ به پلتفرم NetWare شرکت Novell قسم میخوردیم. Novell با سرویسهای دایرکتوریاش از زمان جلوتر بود و ما «آگاهان» با نوعی غرور، فناوریهای رقیب را مسخره میکردیم. سهم بازارش عالی بود و تصور تغییر جریان سخت بود.
هیچ اتفاق واحدی وجود نداشت که ناگهان روشن کند Novell دارد به مایکروسافت میبازد. مایکروسافت هرگز آن نسخهی جادویی Active Directory را نداد که همه بگوییم: «واو! NetWare را ول کن!» اما NetWare کمکم از یک نوآورِ لبهی فناوری، به یک فناوریِ قدیمی تبدیل شد. برای بسیاری از مدیران NetWare، آب زمانی به جوش آمد که هنوز نفهمیده بودند قابلمه گرم شده است.
چه در مسیر شغلیات و چه در فناوریهایی که از آنها دفاع و رویشان سرمایهگذاری میکنی، مراقب تلههای میمون باش. انتخابهایی که زمانی آگاهانه بودهاند، ممکن است همان مشتِ آخرِ برنجی باشند که درست قبل از کوبیدهشدنِ مسیر شغلیات، محکم به آن چسبیدهای.
- تلههای میمونت را پیدا کن. فرضهای سختگیرانهات چیست؟ کدام ارزشها بدون اینکه آگاهانه بدانی، رفتارهای روزمرهات را هدایت میکنند؟
یک جدول با دو ستون درست کن: «شغل» و «فناوری». زیر هرکدام، ارزشهایی را بنویس که بدون تردید به آنها باور داری. در بخش شغل: نقاط قوت و ضعفی که همیشه به آنها باور داشتهای چیست؟ هدفت چیست («میخواهم مدیرعامل شوم!»)؟ راههای درست رسیدن به آن کداماند؟ در بخش فناوری: چه چیزهایی را در فناوریها بیش از همه ارزشمند میدانی؟ مهمترین معیارهای انتخاب فناوری چیست؟ سیستم مقیاسپذیر چطور ساخته میشود؟ محیط بهرهور توسعه کدام است؟ بهترین و بدترین پلتفرمها کداماند؟
وقتی لیستت کامل شد، تکتک گزارهها را در ذهنت معکوس کن. اگر عکسِ هرکدام درست باشد چه؟ صادقانه هر ادعا را به چالش بکش. این فهرست، فهرست آسیبپذیریهای توست.
- دشمنت را بشناس. فناوریای را که از همه بیشتر از آن بدت میآید انتخاب کن و با آن یک پروژه انجام بده. توسعهدهندهها معمولاً به اردوگاههای رقیب تقسیم میشوند: .NET در برابر J2EE، یونیکس در برابر ویندوز.
یک پروژهی ساده انتخاب کن و سعی کن با فناوریای که از آن بدت میآید، یک نرمافزار عالی بسازی. اگر جاواکاری، به آن .NETیها نشان بده یک توسعهدهندهی واقعی چطور از پلتفرمشان استفاده میکند! بهترین حالت: میفهمی آن فناوری آنقدرها هم بد نیست و واقعاً میشود با آن کد خوب نوشت. ضمن اینکه یک مهارت جدید (هرچند خام) هم یاد میگیری که شاید آینده به کارت بیاید. بدترین حالت: یک تمرین خوب کردهای و مهمات بهتری برای بحثهایت داری.
اوایل این هزاره، یک شورش کوچک در صنعت نرمافزار شکل گرفت. گروهی از متخصصان توسعهی نرمافزار متوجه شدند الگوهای مشترکی در شکست و موفقیت پروژهها وجود دارد. در صنعتی که پروژههای ناموفقش بیشتر از موفقها بود، آنها فکر میکردند راه بهتری پیدا کردهاند. اسم خودشان را گذاشتند «اتحاد چابک» (Agile Alliance).
در آن زمان، صنعت به این باور رسیده بود که تنها راه توسعهی نرمافزار، پیروی از یک فرایند بالابهپایین، سنگین و بهشدت برنامهریزیشده است. تحلیلگرها نیازمندیها را در اسناد عظیم تعریف میکردند. معمارها معماری را طراحی میکردند و به طراحها تحویل میدادند. طراحها طرحهای جزئی میساختند و آنها را به توسعهدهندهها میدادند تا در قالب کد پیادهسازی کنند. در نهایت، بعد از ماهها—گاهی سالها—کد یکپارچه میشد و به تیم تست میرسید تا برای استقرار تأیید شود.
گاهی این مدل جواب میداد؛ وقتی همه از ابتدا دقیقاً میدانستند چه میخواهند. اما اغلب مردم جزئیات یک پروژهی بزرگ را از اول نمیدانند. هرچه پروژه بزرگتر و پیچیدهتر باشد، تصور همهی ویژگیها از ابتدا سختتر میشود. این همان فرایند آبشاری است—و امروز تقریباً همه آن را معادل فرایند بد میدانند.
اتحاد چابک فهمید که این فرایندهای سنگین، نرمافزاری تحویل میدهند که خوب تست شده و خوب مستند شده، اما آن چیزی نیست که کاربران میخواهند. پس خانوادهای از متدولوژیهای چابک شکل گرفت؛ فرایندهایی که برای تغییر آسان طراحی شده بودند. زمان کمتری صرف برنامهریزی و طراحی اولیه میشد. نرمافزار انعطافپذیر است و تغییرش میتواند ارزان باشد. چابکها تغییر را جزء ثابت توسعه فرض کردند و خودشان را طوری تنظیم کردند که تغییر کمهزینه و ساده باشد.
امروز بدیهی به نظر میرسد، اما آن زمان بحثبرانگیز بود. در تئوری، برنامهریزی دقیق منطقی به نظر میرسد؛ در عمل، کار نمیکند.
اوایل گرایش من به متدولوژیهای چابک (بهویژه Extreme Programming)، شروع کردم همهچیز را از دریچهی چابک دیدن. کمکم فهمیدم این نیروها فقط مخصوص نرمافزار نیستند. هر مسئلهی پیچیدهای را که با رویکرد تکرارشونده و سازگار با تغییر حل میکردم، هم کماسترستر بود و هم مؤثرتر.
با این حال، مدتها طول کشید تا بفهمم پیچیدهترین پروژهای که تا به حال مدیریت کردهام—پراسترسترین و حیاتیترین—مسیر شغلی خودم بوده است. من شغلم را از قبل مثل یک پروژهی آبشاری طراحی کرده بودم، و همان مشکلاتی که در پروژههای نرمافزاری پیش میآمد، داشت در زندگی شغلیام تکرار میشد.
در مسیر تبدیلشدن به یک معاون ارشد یا مدیر ارشد فناوری موفق بودم. سریع از برنامهنویس تازهکار به معمار، مدیر و بعد مدیرکل رسیدم. اما هرچه موفقتر میشدم، کمتر کاری انجام میدادم که دوستش داشتم. در واقع، داشتم با موفقیت کامل، شغلی را به خودم تحویل میدادم که نمیخواستم.
راهحلش در ابتدا غیرشهودی بود: مسیر شغلیات را تغییر بده. برای من یعنی برگشتن به عمق فناوری؛ همان چیزی که اول کار عاشقش شده بودم. برای دیگران یعنی جابهجایی بین مدیریت و برنامهنویسی، یا حتی ترک کامل این حرفه.
همانطور که در توسعهی نرمافزار، هزینهی تغییر لزوماً بالا نیست، در شغل هم همینطور است. تغییر مسیر از مدیریت به برنامهنویسی یا برعکس سخت نیست. عوضکردن شرکت یا حتی شهر هم آنقدرها دشوار نیست. و برخلاف ساختن آسمانخراش، تغییر مسیر شغلی به معنی دور ریختن همهی گذشته نیست. تجربههای قبلیات همچنان ارزشمندند.
نکتهی مهم این است: تغییر در مسیر شغلی نهتنها ممکن است، بلکه ضروری است. همانطور که هرگز نمیخواهی نرمافزاری بسازی که مشتریات نمیخواهد، نباید شغلی بسازی که خودت نمیخواهی. هدفهای بزرگ تعیین کن، اما مدام در مسیر اصلاحشان کن. در نهایت، چیزی که میخواهیم یک «مشتری راضی» است—حتی وقتی آن مشتری، خودمان هستیم.
رفع کردن یک باگ (معمولاً) آسان است. یک چیزی خراب است. میدانی خراب است چون کسی گزارشش کرده. اگر بتوانی باگ را بازتولید کنی، پس رفع کردنش یعنی اصلاح همان اختلالی که باعثش شده و بعد هم مطمئن شدن از اینکه دیگر بازتولید نمیشود. کاش همهی مشکلات همینقدر ساده بودند!
اما همهی مشکلات و چالشها اینقدر جدا و مشخص نیستند. بیشتر چالشهای مهم زندگی، خودشان را به شکل تودههای بزرگ، غیرقابلمهار و بیشکل از «شکستِ بالقوه» نشان میدهند. این در توسعهی نرمافزار صدق میکند، در مدیریت مسیر شغلی هم صدق میکند، حتی در سبک زندگی و سلامتی.
یک سیستم پیچیده و پر از باگ نیاز به بازسازی اساسی دارد. شغلت هر دقیقه بیشتر از حرکت میایستد. سبک زندگیِ پشتمیزنشینیِ برنامهنویسی دارد کمکم بدنت را به ژله تبدیل میکند. همهی اینها خیلی بزرگتر و سختتر از آناند که مثل یک باگ «فیکس» شوند. همهشان پیچیدهاند، اندازهگیریشان سخت است، و از تعداد زیادی راهحل کوچک تشکیل شدهاند—که بعضیهایشان هم قرار است جواب ندهند!
به خاطر همین پیچیدگی، خیلی راحت با مسائل بزرگ دلسرد میشویم و حواسمان میرود سمت چیزهایی که اندازهگیریشان راحتتر است و سریعتر هم میشود درستشان کرد. این همان دلیل اهمالکاری است. و اهمالکاری هم احساس گناه تولید میکند، گناه باعث میشود بدحال شویم، و بدحالی دوباره اهمالکاری را بیشتر میکند.
همانطور که در «آن مرد چاق در آینه» (صفحهی ۱۹۲) گفتم، من از وقتی یادم میآید با «فرم گرفتن و فرم ماندن» مشکل داشتهام. واقعاً هم وقتی افتضاح از فرم خارج باشی، «فقط برو فرم بگیر» اصلاً مفهومی نیست که بتوانی بفهمی، چه برسد به اینکه کاری مشخص دربارهاش انجام بدهی. و بدتر اینکه اگر هم کاری برای بهتر شدنش انجام بدهی، فوراً یا حتی بعد از یک هفته نمیتوانی بگویی چیزی تغییر کرده. در واقع ممکن است یک روز کامل روی فرم گرفتن کار کنی و یک هفته بعد هیچ چیزی برای نشان دادن نداشته باشی.
این مدل دلسردکننده میتواند قبل از اینکه حتی شروع کنی، بپرد بالا و لهت کند.
اخیراً دارم واقعاً جدی روی همین مسئله کار میکنم: تقریباً هر روز باشگاه، غذای بهتر—همهچیز. اما حتی وقتی واقعاً برنامه را جدی میگیرم، دیدن نتیجهها سخت است.
یک شب که داشتم در دلسردی خودم غلت میزدم، دوست من «اریک کستنر» یک پیام در سایت اجتماعی توییتر گذاشت با این متن:
(…)
وقتی این را خواندم فهمیدم دقیقاً همان چیزی است که برای فرم گرفتن لازم دارم. این را از همان «مسائل بزرگ»ی شناختم که در زندگیام با موفقیت حل کرده بودم. راز کار این است: تمرکز کن روی اینکه هر چیزی را که میخواهی بهترش کنی، امروز بهتر از دیروز انجام بده. همین. ساده است. و همانطور که اریک نوشته بود، میشود با اشتیاق هم قدمهای واقعی و قابل لمس به سمت یک هدف دور برداشت.
اخیراً همچنین مشغول یکی از پیچیدهترین و زشتترین برنامههای Ruby on Railsی هستم که تا حالا دیدهام. شرکت ما این پروژه را بهعنوان کار مشاوره از یک توسعهدهندهی دیگر تحویل گرفت. چند ویژگی کلیدی باید پیاده میشد و یک عالمه باگ و مشکل کارایی هم داشت که باید درست میشد. وقتی کاپوت را بالا زدیم تا تغییرها را شروع کنیم، با یک آشفتگی عظیم روبهرو شدیم. شرکتی هم که ما را استخدام کرده بود هم از نظر زمان محدود بود هم از نظر پول؛ پس این تجمل را نداشتیم که از صفر شروع کنیم—با اینکه از آن کدهایی بود که آدم دوست دارد دور بریزد.
پس شروع کردیم به جلو رفتن، فیکسِ کوچک بعد از فیکسِ کوچک—و هرکدام هم خیلی بیشتر از چیزی که فکر میکردیم زمان میبرد تا تمام شود. اوایلش اینطور به نظر میرسید که این هیولای کدبیس هیچوقت تمام نمیشود. کار کردن روی آن برنامه خستهکننده و بیلذت بود. اما با گذشت زمان، اصلاحها سریعتر شدند و کاراییِ زمانی غیرقابلقبولِ برنامه بهتر شد. چرا؟ چون تصمیم گرفتیم هر روز کدبیس را بهتر از روز قبل کنیم.
گاهی این یعنی بازآرایی (Refactor) یک متد طولانی به چند متد کوتاهتر با اسمهای درست و حسابی. گاهی یعنی حذف سلسلهمراتبهای ارثبریای که اصلاً هیچوقت نباید وارد مدل شیء میشدند. گاهی هم فقط یعنی درست کردن یک تست واحد (Unit Test) که مدتها بود خراب مانده بود.
اما چون این تغییرها را تدریجی انجام دادیم، عملاً «رایگان» به دست آمدند. بازآرایی یک متد کاری است که میتوانی در همان زمانی انجام بدهی که معمولاً برای گرفتن یک فنجان قهوهی دیگر یا گپ زدن با همکارت دربارهی خبرهای روز هدر میدهی. و انجام دادن یک بهبود کوچک، انگیزهبخش است. تفاوتِ همان یک چیزی را که درست کردهای، دقیقاً همان لحظه میبینی.
البته ممکن است با هر تغییر کوچک، در «کلِ تصویر» تفاوت چشمگیری نبینی. وقتی میخواهی در محل کارت محترمتر شوی یا سالمتر زندگی کنی، بهبودهای روزانهات خیلی وقتها مستقیماً به نتیجهی ملموس نمیرسند. و همین—همانطور که دیدیم—دلیل دلسردکننده شدن هدفهای بزرگ است. پس برای بیشتر هدفهای بزرگ و سختی که دنبالشانی، مهم است نه اینکه هر روز «نزدیکتر شدن به هدف» را بسنجی، بلکه اینکه تلاش امروزت نسبت به دیروز بهتر باشد.
من نمیتوانم تضمین کنم امروز از دیروز لاغرترم، اما میتوانم کنترل کنم که امروز برای لاغر شدن بیشتر از دیروز کار کردهام یا نه. و اگر این کار را کرده باشم، حق دارم بابتش حس خوبی داشته باشم. این بهبودِ پیوسته و قابل اندازهگیری در «عملکرد من» باعث میشود از چرخهی گناه و اهمالکاری آزاد شوم—چرخهای که بیشتر ما را وقتی میخواهیم «کارهای بزرگ و مهم» انجام بدهیم شکست میدهد.
همچنین باید از «بهترِ کوچک» راضی باشی. نوشتنِ فقط یک تست بیشتر از دیروز، برای نزدیک شدن به هدف «بهتر شدن در تست واحد» کافی است. اگر از صفر شروع میکنی، روزی یک تست بیشتر نرخ پایداری است؛ و وقتی دیگر نتوانی از دیروز بهتر شوی، میفهمی حالا واقعاً «در تست واحد بهتر شدهای» و دیگر لازم نیست همان بهبودها را ادامه بدهی. اگر در عوض تصمیم بگیری روز اول از صفر برسی به پنجاه تست، روز اول سخت میشود و روز دوم احتمالاً اصلاً اتفاق نمیافتد.
پس بهبودهایت را کوچک و تدریجی، اما روزانه نگه دار. بهبودهای کوچک هزینهی شکست را هم کم میکنند. اگر یک روز از دستت رفت، فردا یک خط پایهی جدید داری.
یکی از چیزهای خوبِ این اصل ساده این است که هم برای هدفهای کاملاً تاکتیکی به درد میخورد—مثل تمام کردن یک پروژه یا تمیز کردن یک تکه نرمافزار—و هم برای بزرگترین هدفهایی که ممکن است داشته باشی.
امروز برای بهتر کردن مسیر شغلیات چه کاری کردهای که از دیروز بهتر باشد؟ یک ارتباط جدید بساز، یک پچ به یک پروژهی متنباز بده، یک نوشتهی فکرشده بنویس و در وبلاگت منتشر کن. یک نفر دیگر را در یک انجمن فنی، در حوزهای که در آن تخصص داری، کمک کن—بیشتر از دیروز. اگر هر روز کمی بهتر از دیروز برای بهتر کردن خودت عمل کنی، آن پیشنهادِ به اندازهی اقیانوس—ساختن یک مسیر شغلی درخشان—قابلمدیریتتر میشود.
۱) فهرستی از بهبودهای سخت یا پیچیدهای که میخواهی ایجاد کنی بنویس؛ میتوانند شخصی یا حرفهای باشند. اشکالی ندارد اگر لیستت بلند است. حالا برای هر مورد، فکر کن امروز چه کاری میتوانی انجام بدهی تا خودت یا آن مورد، بهتر از دیروز شود. فردا دوباره به لیست نگاه کن. آیا دیروز از روز قبل بهتر بود؟ امروز چطور میتوانی بهتر باشی؟ این کار را روز بعد هم تکرار کن. در تقویمت ثبتش کن. هر صبح دو دقیقه وقت بگذار و به این فکر کن.
در زمانهای پراسترس، گاهی با حسرت به روزهایی نگاه میکنم که در یک شرکت بزرگ کار میکردم. در یک دفتر یا کابین خودم لانه کرده بودم و دورم هم یک سلسلهمراتب مدیریتی ضخیم، نرم و چندلایه بود. آن روزها به شوخی میگفتیم، اما در یک شرکت بزرگ، آدم باهوش میتواند بدون اینکه تقریباً هیچ کاری انجام بدهد هم دوام بیاورد. در بیشتر موارد، اگر پروژهای جلو نمیرفت، آدمهای کافی در لایههای کافی بودند که تقصیر پخش شود و معلوم نشود دقیقاً کجا خراب شده. این برای شکستهاست. حتی وقتی کارها طول میکشید، پیچیدگی سازمان آنقدر دلیلها را مبهم میکرد که کسی واقعاً نمیفهمید یک پروژه «اصلاً باید» چقدر طول بکشد.
پس روزهایی که حال نداری پایت را بگذاری روی گاز، کار در شرکت بزرگ این فرصت را میدهد که عقب بنشینی و مثلاً یک مدت وبگردی کنی. یا زودتر بروی خانه. یا یک «مرخصی استعلاجی» بگیری. با همهی غرهایی که به زندگی شرکتی میزدم، واقعاً مزایای خودش را داشت.
مشکل اینجاست که آن پتوی امنِ سلسلهمراتب شرکتی تو را کند میکند. اگر بتوانی پشت سپرِ متوسطبودنی که اکثر بخشهای شرکتی دارند قایم شوی، انگیزهی زیادی برای عالی بودن نمیماند. حتی آنهایی از ما که ذاتاً بدخواه نیستیم، وسوسه میشویم در واحهی آرام یوتیوب یا مجموعهی کمیکهای وبِ محبوبمان لم بدهیم.
از این نظر، شرکت بزرگ جای خوبی است برای اینکه اگر فرسودهای، مدتی بروی و نیمهبازنشسته شوی. اما اگر میخواهی «خاص» باشی (که هستی!)، شرکت بزرگ جای سختی است برای پیدا کردن ریتم درست؛ همانطور که یک نانوایی جای بدی است برای رفتن و کم کردن چربیهای دور شکم. راهحل؟ مستقل شو!
تو یک مجموعه مهارت داری. صیقلشان دادهای. میدانی چقدر میارزی. مستقل شدن به عنوان پیمانکار، یکی از آزمونهای نهایی است. دیگر بروکراسیای نیست که پشتش پنهان شوی. مستقیم در برابر کسانی پاسخگویی که دارند پول میدهند. اینکه «داری خدمت ارائه میدهی» در همهی کارهایت کاملاً واضح میشود. تیمی نیست که وقتی خرابکاری کردی تقصیر را با آن تقسیم کنی. فقط تویی، تخصصت، و تواناییات برای اجرا.
مستقل شدن همچنین مجبورَت میکند یاد بگیری چطور خودت را بازاریابی کنی و همزمان انتخابهایت را—در حوزهی کاری و فناوری—به آزمون میگذارد. وقتی مستقل میشوی، نمیتوانی مثل شرکت بزرگ منتظر بمانی کار خودش بیاید سراغت. باید بروی دنبال مشتری. و وقتی پیدایش کردی، باید قانعش کنی که ارزش پول دادن داری.
همچنین باید تصمیم بگیری واقعاً چقدر میارزی. کاری که میکنی ساعتی ۵۰ دلار میارزد؟ یا ۲۵۰؟ چطور قبضهایت را میدهی؟ چطور پولی را که فکر میکنی میارزی توجیه میکنی؟ اصلاً واقعاً به اندازهای که فکر میکنی میارزی؟
مستقل شدن سخت است. همهی مهارتهایت را به عنوان یک حرفهای به چالش میکشد. شاید هنوز آمادهاش نباشی. خبر خوب این است که لازم نیست یکهو همهچیز را رها کنی. میتوانی مثل یک پروژهی رشد فردی به آن نگاه کنی و در وقت آزاد خودت را وارد بازار کنی. یک هدف بگذار: یک قرارداد با نرخ مشخص بگیری و آن را با یک مشتری راضی تمام کنی. شبها یا آخر هفتهها روش کار کن (اما لطفاً در کابینِ محل کارتِ شغل روزانهات این کار را نکن!). بدون از دست دادن تورِ ایمنیات، کلی یاد میگیری. بدترین حالت: چند هفته زیادی کار میکنی، در یک پروژه شکست میخوری، و با یک حس تازه از قدرشناسی نسبت به کارت، برمیگردی به کابین راحتت. بهترین حالت: فوقالعاده موفق میشوی، کار را دوست داری، و وارد مسیر جدیدی از رضایت شغلی و پاداش مالی میشوی.
بازبینِ کتاب، «سمی لَربی»، گزینهی دیگری هم پیشنهاد میکند: اگر الآن در یک شرکت بزرگ کار میکنی، به یک شرکت کوچکتر فکر کن. اگر در یک شرکت جاافتاده هستی، یک استارتاپ را امتحان کن. در یک استارتاپ کوچک میتوانی بهترینِ هر دو دنیا را داشته باشی: یک شغل تماموقت با حقوق ثابت، و در عین حال چالشِ روبهرو شدن مستقیم با مشکلات واقعیِ کسبوکار—بدون فیلتر و حائل.
مایک کلارک
پدر و مادرم بهت میگویند من بچهی کنجکاوی بودم. کلی سؤال میپرسیدم، هر چیزی که دستم میرسید میخواندم، و با باز کردن و از هم جدا کردنِ چیزها یاد میگرفتم چطور کار میکنند. که بعداً معلوم شد این فقط یک «دوره» نبود—من هیچوقت از آن کنجکاوی سیریناپذیر عبور نکردم. شاید ساده باشد از کنارش رد شوی، اما من باور دارم کنجکاوی میتواند یک نقطهقوت باشد. گاهی فقط کمی تمرین لازم دارد تا رشد کند.
وقتی به عقب نگاه میکنم، میتوانم چند اتفاقِ مسیر-عوضکنِ شغلی را پیدا کنم که بیشترشان صرفاً به این خاطر افتادند که دنبالِ یک کنجکاوی رفتم. چند مثال زیر را میگویم به امید اینکه وقتی کنجکاوی صدایت زد، تو هم گوش بدهی:
من هیچوقت فکر نمیکردم برنامهنویس بشوم. همیشه مجذوب هواپیماها و فضاپیماها بودم، پس ثبتنام در رشتهی مهندسی هوافضای دانشگاه Embry-Riddle منطقی به نظر میرسید. اما بعد از یکی دو سال جان کندن، فهمیدم آنطرف، در دانشکدهی علوم کامپیوتر، آدمها خیلی بیشتر خوش میگذرانند. بهعنوان بخشی از یک برنامهی جدید، آنها داشتند علوم کامپیوتر را روی مسائل مربوط به هوانوردی اعمال میکردند.
در دبیرستان نسبت به کامپیوتر کنجکاو شده بودم، اما هیچوقت واقعاً برنامهنویسی را بهعنوان مسیر شغلی در نظر نگرفته بودم. پس شروع کردم پاتوق زدن با نِردهای کامپیوتری تا ببینم مشغول چه کاریاند. خیلی زود رشتهام را عوض کردم. همان یک تغییر، شد یکی از بهترین تصمیمهای زندگیام. درسها هنوز هم چالشبرانگیز بودند، اما من هر دقیقهاش را دوست داشتم. آن کنجکاوی اولیهام نسبت به برنامهنویسی سریع تبدیل شد به یک علاقهی جدی که باعث شد برای کارآموزی در ناسا اقدام کنم و مسیر کاری نرمافزاریام را شتاب بدهم. و تا امروز هیچوقت پاداشِ احتمالیِ این را دستکم نمیگیرم که بفهمم بقیهی گیکها برای تفریح روی چه چیزهایی کار میکنند.
هر وقت احساس میکنم خیلی راحت شدهام، میفهمم وقتش است سراغ چیزی تازه بروم. بعد از سالها نوشتن نرمافزارهای نهفته در صنعت هوافضا، با C و C++ راحت شده بودم—که برای من معمولاً یعنی «حوصلهسربر». همان حوالی، برنامهنویسی وب کنجکاویام را قلقلک داد، بیشتر هم به این دلیل که بهطور رادیکالی با برنامهنویسی سیستمهای نهفته فرق داشت. بدشانسی اینجا بود که پروژهی محل کارم دسترسی وب نداشت (از آن پروژههای فوقمحرمانه)، پس شبها و آخر هفتهها را گذاشتم برای یاد گرفتنِ نوشتن نرمافزار برای وب.
این دستکاریها و هککاریهای جانبی، کمکم تبدیل شد به فرصتی برای کار روی یک پروژهی جدید با جاوا. آخرش هم شد اینکه برای پروژههای بیشتری—و برای کارفرماهای بیشتری—برنامههای وبمحور جاوا ساختم. کنجکاویِ من نسبت به توسعهی وب، جرقهی متنوع کردن مهارتهایم شد—و در نهایت یک حرکت شغلی خوب از آب درآمد.
یکبار هم از روی هوس رفتم سراغ Ruby و Rails. روبی زبان بامزهای بود که باعث میشد دربارهی برنامهنویسی جور دیگری فکر کنم. ریلز هم همین کار را برای برنامههای وب کرد. آن موقع هیچ مشتریای نداشتم که بابت کار با روبی یا ریلز پول بدهد، اما این واقعاً مهم نبود. من کنجکاو بودم و نمیتوانستم جلوی خودم را بگیرم. چند ساعتِ قابلفاکتور کمتر کار کردم و آن زمان را گذاشتم برای عمیق شدن در روبی و ریلز.
نمیدانستم اوایل ۲۰۰۵ یک فرصت نصیبم میشود برای ساختن یکی از اولین برنامههای تجاریِ ریلز، و بعد هم دیو توماس از من دعوت میکند که در کتاب ریلزش کمک کنم. کنجکاویام نسبت به یک فناوریِ جدیدِ دیگر، یک قوس موفق دیگر در مسیر شغلیام ساخت.
کنجکاویِ من فقط محدود به فناوری نیست؛ جنبههای کسبوکار هم به همان اندازه برایم جذاباند. همین باعث شد مستقل شوم، بهعنوان مشاور کار کنم و یک شرکت آموزشی راه بیندازم (The Pragmatic Studio). کنجکاویام دربارهی اداره کردن یک کسبوکار کوچک، فرصت داد یک عالمه مهارت تازه یاد بگیرم: فروش، بازاریابی، پشتیبانی مشتری، و غیره. دیدنِ تصویر بزرگتر کمک کرده برنامهنویس بهتری بشوم.
پس تو واقعاً دربارهی چه چیزی کنجکاوی؟ یک مدت دنبال علاقههایت برو و ببین چه میشود. شاید از جایی که در نهایت به آن میرسی شگفتزده شوی!
مایک کلارک مشاور/برنامهنویس مستقل است.
اما به شما میگویم: وقتی کار میکنید، بخشی از دورترین رؤیای زمین را به انجام میرسانید؛ رؤیایی که وقتی زاده شد، انجامش به شما سپرده شد. و وقتی خود را با کار همراه میکنید، در حقیقت زندگی را دوست میدارید؛ و دوست داشتنِ زندگی از راهِ کار، یعنی آشنا شدن با درونیترین رازِ زندگی. جبران خلیل جبران، پیامبر
اگر به جایی رسیدهای که بهعنوان یک توسعهدهندهی نرمافزار آنقدر «فراغت» داری که واقعاً بتوانی به این فکر کنی مسیر شغلیات باید به کدام سمت برود، تبریک! میتوانی خودت را خیلی خوششانس بدانی. فرهنگهای زیادی هستند که در آنها «انتخاب کردن اینکه برای گذران زندگی چه کار کنی» یک امتیاز بزرگ است—چیزی که تعداد بسیار کمی از آدمها از آن بهرهمندند. تو بهعنوان توسعهدهندهی نرمافزار، احتمالاً خیلی نگران این نیستی که چطور پول اجاره خانه را بدهی یا غذا بخری.
میتوانستی هر مسیر شغلیِ دیگری را هم انتخاب کنی، اما این یکی هیجانانگیز است. خلاقانه است. نیاز به فکر عمیق دارد و در عوض به تو این حس را میدهد که میتوانی کاری انجام بدهی که بیشتر آدمهایی که هر روز میبینی حتی تصورش را هم نمیکنند. ممکن است نگران ارتقا به مرحلهی بعد، اثرگذاری، یا بهدست آوردن احترام همکارها و همصنفیهایت باشی؛ اما اگر واقعاً بایستی و فکر کنی، میبینی اوضاعمان خیلی هم خوب است.
توسعهی نرمافزار هم چالشبرانگیز است و هم پاداشدهنده. مثل یک هنر خلاقانه است، اما (برخلاف هنر) ارزشِ مشخص و قابلاندازهگیری تولید میکند. توسعهی نرمافزار مفرّح است!
در نهایت، مهمترین چیزی که در این سفر یاد گرفتهام—سفری که اسمش مسیر شغلی من در توسعهی نرمافزار بوده—این است که مهم نیست «برای امرار معاش چه کار میکنی» یا «چه چیزهایی داری». مهم این است که چطور انتخاب میکنی آنها را بپذیری. این یک موضوع درونی است. رضایت—مثل انتخابهای شغلیمان—چیزی است که باید آگاهانه دنبالش رفت و با قصد و نیت دربارهاش تصمیم گرفت.