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

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

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

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

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

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

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

تغییر عقیدۀ من
من مدّتها این اعتقاد را داشتم. ساعت‌های طولانی بحث می‌کردم که چرا ویندوز خیلی بهتر از مَک است. بارها درباره این که چرا #C و سایر زبانهای نوع ایستا خیلی بهتر از زبا نهای پویا مانند پِرل و روبی هستند داد و فریاد راه می‌انداختم. حتی با شرمندگی باید بگویم که گاهی دیگر تولیدکنندگان نرم‌افزار را که عقیدة دیگری داشتند سرزنش می‌کردم .چطور جرئت می‌کردند به فناوری دیگری غیر از آنچه من اعتقاد داشتم، اعتقاد داشته باشند؟

تجربه‌ای که چشم مرا باز کرد هنگامی بود که برای نخستین بار از من خواسته شد تا سرپرست تیمی برای انجام یک پروژه جاوا بشوم. تا آن زمان، من اساسا یک برنامه‌نویس NET. و متمرکز بر روی #C بودم. (راستش را بخواهم بگویم، پیش از آمدن NET. تعصّب زیادی روی ++C داشتم.) من نمی‌توانستم ایده کارکردن با جاوا را هضم کنم. از نظرمن، جاوا در مقایسه با زیبایی #C، زبان کثیفی بود. وقتی بلد نبودم از عبارت‌های لاندا استفاده کنم، چطور می‌توانستم از نوشتن کد جاوا لذّت ببرم؟

سرانجام تصمیم گرفتم که آن کار را بپذیرم، زیرا فرصت خیلی خوبی برایم بود و من فکر کردم چون یک قرارداد کوتاه‌مدّت است، می‌توانم برای یک سال، کمی کمتر یا بیشتر، آن را تحمّل کنم. امّا پذیرش آن کار، یکی از بهترین تصمیم‌های زندگی حرفه‌ای‌ام از آب درآمد. کارکردن با فناوری‌ای که از آن نفرت داشتم، باعث شد تا از زاویۀ متفاوتی به تمام فناوری‌ها نگاه کنم. به این نتیجه رسیدم که جاوا اصلاً زبان بدی نیست و دریافتم که چرا بعضی از برنامه‌نویسان آن را بر #C ترجیح می‌دهند .

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

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

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

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

اقدامات

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

منبع:
کتاب “مهارت‌های نرم: راهنمای زندگی تولیدکنندگان نرم افزار“، ترجمه‌ی “استاد بزرگوار، اب‍راه‍ي‍م ن‍ق‍ي‍ب‌زاده م‍ش‍اي‍خ“،
ناشر: “انجمن انفورماتیک ایران”

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

پیش‌گفتار:
داشتم نوشته‌های لینکدین را می‌خواندم نوشته‌ای توجه‌ام را جلب کرد. در یکی از بحث‌ها که به مهاجرت اشاره می‌کرد، یکی از طرفین نوشته بود: “خیلی خامی. حالا حالاها مونده تا بزرگ بشی و به پختگی برسی. همه این چیزها رو تو یکسال و نیم فهمیدی؟ البته از آدم بی هویتی که ظرف یکسال اسمش رو عوض می کنه شعور بیش از این هم انتظار نمی ره” (تا جایی که فهمیدم مخاطب اسمش را از دانیال به دنیل تغییر داده بود و انگار یک سال و نیم بود که در کشور دیگری زندگی می‌کرد). به خاطر آوردن یک سری از واژگان از شما پوزش می‌خواهم اما دلیل‌ش را جلوتر متوجه خواهید شد!

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

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

خاطره از بزرگسالی:
بعد از این که تحصیلم را در اینجا شروع کردم و برای زندگی به این شهر انگلیسی زبان آمدم، یکی از اولین چیزهایی که یاد گرفتم این بود که به خاطر تفاوت زبان و آوا، مردم اینجا نمی‌توانند یک سری کلمات فارسی را درست بیان کنند، همان طور که ما در بیان یک سری واژگان انگلیسی دچار دردسر می‌شویم. این موضوع باعث دشواری ارتباط دو طرفه شما با آنها می‌شود. برای مثال بیان کلمه‌ی “بی‌بالان” برای آنها راحت‌تر است تا کلمه‌ی “مهرداد”. تا جایی که فهمیدم وجود حرف “هـ” (h) وسط کلمه آنها را به دردسر می‌اندازد، در نتیجه “مهرداد” را “مِرداد” یا “مِداد” تلفظ می‌کنند. یا تلفظ “بی‌بالان” برای آنها خیلی دشوار است و به جای آن گفتن “بای-بلن” برای آنها راحت‌تر است.

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

خاطره از کودکان:
یکی از مسأله‌های خانواده‌های ایرانی در اینجا هنگامی که تصمیم می‌گیرند بچه‌دار شوند این است که اسمی برای نوزاد انتخاب کنند که هم ایرانی باشد و هم در زبان انگلیسی به راحتی قابل بیان باشد. در نتیجه اسامی مانند “کیان”، “رایان”، “دنیل”، “سارا” و “حنا” در اینجا زیاد شنیده می‌شود.

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

بسیار سفر باید تا پخته شود خامی صوفی نشود صافی تا درنکشد جامی
سعدی به لب دریا دردانه کجا یابی در کام نهنگان رو گر می‌طلبی کامی

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

پ.ن:
خوش‌بختانه “یوسف” را اینجا خیلی درست و دقیق‌ بیان می‌کنند! 😀 و خوش‌بختانه ناچار نیستم برای ارتباط با جامعه، نامی که مادر و پدر برای من انتخاب کرده‌اند را تغییر بدم!

“We all have two lives. The second one starts when we realize that we only have one.”

― Tom Hiddleston

پیش‌گفتار:
از نگاه من، مصاحبه‌ی استخدامی کار بسیار دشواری است، هم برای مصاحبه‌شونده و هم برای مصاحبه‌کننده. دشوارترین بخش آن از نظر من، “قضاوت شدن” و “قضاوت کردن” است. مصاحبه‌ی نامناسب می‌تواند “فرصت” یک همکاری موفق بین متقاضی و تیم/شرکت را بسوزاند. برداشت من این است که هزینه و هزینه‌ی فرصت مصاحبه با هر متقاضی، اگر به پول تبدیل شود، مبلغ آن کم نخواهد بود.

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

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

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

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

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

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

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

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

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

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

من کماکان داشتم می‌خندیدم! دیگر به جایی رسید که بدنم از شدت خنده درد گرفته بود!

پس‌گفتار:
امیدوارم فرصت همکاری موفق افراد با شرکت‌ها/تیم‌ها با “الگوسازی” پرسش‌ها و “ساده‌سازی” پاسخ‌های مصاحبه‌های استخدامی از دست نرود!
امیدوارم یادم بماند که حسن‌هایی هستند که ورزش مورد علاقه‌شان، ورزش انفرادی است ولی استاد کار تیمی‌اند و با این که عاشق تیم آلمان هستند ولی مانند یک برزیلی زیبا بازی می‌کنند!

گزیده:

I had a job interview at an insurance company once and the lady said ‘Where do you see yourself in five years?’ and I said ‘Celebrating the fifth year anniversary of you asking me this question. 🙂 Mitch Hedberg

پرسید گر کسی که کجاییم و کیستیم
یا در کدام خانه و میخانه زیستیم
گویید چون مسافر مجنون و بی‌قرار
با عشق آمدیم و گذشتیم و نیستیم

خط: دوست بزرگوار، ابوالفضل

چند وقتی است که به همراه یکی از دوستان، درس Machine Learning with Graphs دانشگاه استنفورد را هم‌خوانی و دنبال می‌کنیم. چند نکته به نظرم رسید که مناسب دیدم اینجا یادداشت کنم.

• همان طور که در خود درس گفته شده است “گراف‌ها مرزهای جدید یادگیری عمیق (ِِDeep Learning) هستند“
• چرا گراف؟ گراف‌، زبانی عمومی برای توصیف و تحلیل موجودیت‌ها و روابط / تعاملات بین آنهاست.
• آموختن یادگیری ماشین گرافی برای من به مراتب دشوارتر از یادگیری ماشین رایج و غیرگرافی است.
• کاربردهای یادگیری ماشین با گراف “شگفت‌انگیز” و تا حدی “ترسناک” است. باور کنید!

در اینجا فهرستی از نمونه کاربردهای یادگیری ماشین با گراف را می‌توانید ببینید.

• Node classification: Predict a property of a node /Example: Categorize online users-items
• Link prediction: Predict whether there are missing links between two nodes / Example: Knowledge graph completion
• Graph classification: Categorize different graphs / Example: Molecule property prediction–
• Clustering: Detect if nodes form a community / Example: Social circle detection
• Other tasks:
  — Graph generation: Drug discovery
  — Graph evolution: Physical simulation

اجازه دهید یک کار روزمره را به یک مساله گراف تبدیل کنیم:
فرض کنید که کاربران یک پیام‌رسان مانند تلگرام، واتس اپ یا اینستاگرام را به مانند گره گراف و پیام‌ باز-ارسالی (فوروارد شده) از یک کاربر به کاربر دیگر را هم به مانند یال گراف و تعداد پیام باز-ارسالی رد و بدل شده را مانند وزن یال در نظر بگیریم. اگر مدلی به کمک یادگیری ماشین با گراف طراحی کنیم، به نظر شما این مدل به چه سوالاتی می‌تواند پاسخ دهد!

و اما آخرین نکته‌ی جالب‌: آموختم که “گوگل اولین شرکتی بود که اینترنت را یک گراف دید“!

Reading more:
CS224W: Machine Learning with Graphs, Stanford / Winter 2021 (Slides, Video)
CS224W: Machine Learning with Graphs, Stanford / Fall 2019 (Slides, Video)

گزیده:
شاید ریاضی به ما یاد ندهد که چگونه عشق را “جمع کنیم” یا نفرت را “کم کنیم”، اما به ما امید می‌دهد که هر مساله‌ای راه حلی دارد.
ناشناس (مرجع)

… relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?

My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.

Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.

Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.

If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.

Avoid Starting with a One-Point Story
I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.

Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.

I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”

Why Use Two Values for a Baseline?
Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.

If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.

Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.

Reference: Mike Cohn, mountaingoatsoftware.com

Quote:
“The higher the price of information in a software team, the less effective the team is.”
― Yegor Bugayenko, Code Ahead: Volume 1