ما با هم مباحثه/مفاهمه نمی‌کنیم؛ بلکه با تصوراتمون از حرفهای همدیگه، مجادله می‌کنیم!
طی یکی دو سال گذشته، بارها در مورد موضوعاتی مثل آینده مهندسی نرم‌افزار، تأثیر AI روی مشاغل و تغییراتی که توی صنعت نرم‌افزار در حال رخ دادنه، نوشتم. بعضی وقت‌ها هم در حد توییت.
طبیعتاً هم انتظار نداشتم همه با حرف‌هام موافق باشن. اتفاقاً نقد و مخالفت، به‌خصوص از طرف کسی که تجربه و دانش متفاوتی داره، می‌تونه خیلی آموزنده باشه. اما گاهی زیر یک مطلب یا توییت، کامنت‌هایی می‌بینم که واقعاً حیرت می‌کنم!
از «تو اصلاً چی می‌فهمی AI چیه؟» گرفته تا انواع و اقسام اظهار لطف‌هایی که بهتره تکرارشون نکنم!
و اتفاقاً چیزی که توجهم رو جلب می‌کنه، صرفاً لحن تند این کامنت‌ها نیست. مسئله اینه که گاهی طرف مقابل اساساً درباره چیزی بحث می‌کنه که من نگفتم!
این اسکرین‌شات، فقط یه نمونه از لحن بعضی واکنش‌هاست. اما مسئله‌ای که بیشتر توجهم رو جلب می‌کنه، صرفاً لحن تند نیست. گاهی توی کامنت‌های دیگه می‌بینم که طرف مقابل اساساً داره درباره یه چیزی بحث می‌کنه که من نگفتم!
انگار به‌جای خوندن حرف گوینده و تلاش برای فهمیدن منظورش، صرفاً به شکار چند کلمه آشنا بسنده کرده و بدون اینکه بدونیم این حرف در چه زمینه‌ای، با چه پیش‌فرض‌هایی و درباره چه موضوع مشخصی زده شده، برداشت خودمون رو جای حرف گوینده می‌گذاریم. بعد هم کیبورد را گشوده و حواله می‌دهیم!
البته این مشکل فقط مختص دیگران نیست. بعید می‌دونم خود من هم در تمام این سال‌ها از چنین اشتباهاتی مصون بوده باشم.
نکته مهم اینه که هر مخالفت تند یا اشتباهی هم الزاماً ناشی از سوءتفاهم نیست. گاهی واقعاً درباره شواهد، اختلاف داریم، گاهی درباره ارزش‌ها و پیش‌بینی‌ها، گاهی حرف‌هامون مبهمه و گاهی هم یکی از طرفین اساساً دنبال گفت‌وگو نیست!
اما چیزی که توی این مطلب می‌خوام بهش بپردازم، یکی از ساده‌ترین و درعین‌حال عجیب‌ترین مشکلات گفت‌وگوست: ما خیلی وقت‌ها قبل از اینکه مطمئن بشیم درباره یک چیز مشترک حرف می‌زنیم، شروع به مخالفت می‌کنیم!
خاطره‌ی بیست ساله:
حدود سال ۲۰۰۶، وقتی دوره‌های رسمی مایکروسافت رو تدریس می‌کردم، مرتب با یه چالش تکراری روبه‌رو می‌شدم.
برای تدریس دوره‌هایی مثل ASP.NET یا مباحث معماری نرم‌افزار، به آموزشگاه‌ها و دانشجوها توصیه می‌کردم که اول دوره 536-70 یعنی Microsoft .NET Framework Application Development Foundation رو خوب بلد باشن.
منظور من سرفصل‌های رسمی آزمون 536-70 بود. یه کتاب با حدود ۱۰۵۰ صفحه با مباحثی مثل Threading، Reflection، Application Domains، Security، Serialization، Collections و خیلی چیزهای دیگه.
اما تصور اکثر افراد این بود که بتونن با #C کدنویسی کنن و وقتی می‌گفتم پیش‌نیاز دوره Foundation است، با قاطعیت می‌گفتند: «ما دات‌نت رو خیلی خوب بلدیم!»
و بعد از کمی گفت‌وگو مشخص می‌شد که اصلاً برداشت یکسانی از اون عبارت نداریم.
اینجا یک تفاوت مهم وجود داشت. منظور من یک تعریف سلیقه‌ای نبود. در چارچوب آموزشی مشخصی که درباره‌ش صحبت می‌کردیم، مایکروسافت به‌عنوان سازنده پلتفرم، برای Foundation سرفصل و معیار رسمی تعیین کرده بود. در مقابل، مخاطب از معنای رایج و عرفی «دات‌نت بلدم» استفاده می‌کرد.
البته اینکه کسی توی گفت‌وگوی روزمره بگه «دات‌نت بلدم» و منظورش کدنویسی با #C باشه، لزوماً اشکالی نداره. اما وقتی داریم درباره پیش‌نیاز یک دوره رسمی صحبت می‌کنیم، نمی‌تونیم معنای عرفی رو جای سرفصل‌ها و معیارهای فنی اون دوره بگذاریم.
همه تعریف‌ها در همه زمینه‌ها اعتبار یکسانی ندارند.
از طرف دیگه، امروز که به اون ماجرا نگاه می‌کنم، می‌بینم شاید من هم می‌تونستم به‌جای سؤال کلی «Foundation رو گذروندی؟»، از اول چند تا سؤال مشخص درباره Threading، Reflection یا Application Domains بپرسم و خیلی زودتر معلوم بشه اختلاف کجاست.
این الگو رو بعدها بارها و بارها توی مصاحبه‌های شغلی، مشاوره‌ها و گفت‌وگوهای تخصصی دیدم. و هنوز هم می‌بینم، فقط واژه‌ها و عبارت‌ها عوض شدن.
امروز هم همون داستان، با واژه‌های جدید!
امروز یکی می‌گه «من AI بلدم»، یکی می‌گه «AI جای مهندس نرم‌افزار رو می‌گیره» و یکی دیگه می‌گه «کدنویسی دیگه مهارت مهمی نیست». اما قبل از اینکه موافقت یا مخالفت کنیم، چند سؤال ساده وجود داره:
- منظورمون از «بلد بودن AI» چیه؟ استفاده از ChatGPT؟ طراحی و توسعه سیستم‌های مبتنی بر مدل‌های زبانی؟ آموزش مدل؟ طراحی Agent، ارزیابی و کنترل عملکردش؟ یا درک معماری و سازوکار مدل‌ها یا harness و…؟
- منظورمون از «مهندسی نرم‌افزار» چیه؟ نوشتن کد؟ ساختن محصولی که کار می‌کنه؟ یا طراحی و نگهداری سیستم‌هایی که باید سال‌ها در مقیاس واقعی کار کنند؟
- و منظور از «جایگزینی» چیه؟ حذف بعضی وظایف، تغییر ماهیت شغل یا حذف کامل یک حرفه؟ وقتی می‌گیم مهندسان نرم‌افزار حذف نمی‌شن، درباره چه کسانی با چه خصوصیات و توانمندی‌هایی صحبت می‌کنیم؟
گاهی هم اختلاف فقط سر تعریف یا شواهد نیست. وقتی درباره آینده شغل، تخصص و معیشت آدم‌ها حرف می‌زنیم، ممکنه نگرانی‌های شخصی و هویتی هم وارد بحث بشن. توی چنین شرایطی، صرفاً روشن کردن معنای چند واژه الزاماً اختلاف یا تنش رو برطرف نمی‌کنه. حتی اگه سر همه این تعریف‌ها به توافق برسیم، هنوز ممکنه درباره آینده مشاغل، سرعت پیشرفت AI یا پیامدهای اقتصادی اون اختلاف جدی داشته باشیم. این دیگه صرفاً اختلاف سر معنای واژه‌ها نیست؛ اختلافیه که باید با استدلال و شواهد بررسیش کنیم.
جالبه که گاهی ساعت‌ها درباره این موضوعات بحث می‌کنیم، بدون اینکه حتی پنج دقیقه برای روشن کردن معنای واژه‌ها، پیش‌فرض‌ها و ادعاهایی که مطرح می‌کنیم وقت گذاشته باشیم!
وقتی کلمات مشترک‌اند، ولی معناها نه
مفاهیمی مثل Verbal Dispute (اختلاف لفظی) و Common Ground (زمینه مشترک) به بخش‌هایی از این مسئله می‌پردازن که اگر دوست داشتید می‌تونید مطالعه کنین.
خیلی ساده، ممکنه دو نفر ظاهراً با هم اختلاف داشته باشند، درحالی‌که از یک واژه با دو معنای متفاوت استفاده می‌کنند.
یا حتی بدتر، هر کدوم به چیزی پاسخ بده که فکر می‌کنه طرف مقابل گفته، نه چیزی که واقعاً گفته!
به این وضعیت اصطلاحاً Talking Past Each Other هم می‌گن.
البته برای گفت‌وگو الزاماً لازم نیست درباره همه‌چیز تعریف یکسانی داشته باشیم. گاهی کافیه متوجه بشیم طرف مقابل یک مفهوم رو متفاوت تعریف می‌کنه و اون تفاوت رو در ادامه بحث لحاظ کنیم.
مثلاً اگر کسی بگه «AI مهارت برنامه‌نویسی رو بی‌ارزش می‌کنه»، به‌جای اینکه بلافاصله جواب بدیم «تو اصلاً نمی‌فهمی مهندسی نرم‌افزار چیه!»، می‌تونیم بپرسیم:
«منظورت اینه که مهارت نوشتن کد اهمیت کمتری پیدا می‌کنه، یا معتقدی مهارت‌هایی مثل طراحی معماری، تست و نگهداری سیستم هم کم‌ارزش می‌شن؟ چون به نظرم این دو ادعای متفاوتن.»
دقت کنید که هنوز هیچ‌کس با کسی موافقت نکرده! صرفاً داریم تلاش می‌کنیم بفهمیم دقیقاً سر چی اختلاف داریم.
یک راه ساده هم برای تشخیص اختلاف لفظی از اختلاف واقعی وجود داره: اگر معنای واژه‌ای رو که سرش بحث داریم روشن کنیم، آیا اختلاف از بین می‌ره؟ اگه بله، شاید بخش مهمی از اختلاف لفظی بوده. اگر نه، احتمالاً اختلاف واقعی‌تری وجود داره که باید سراغش بریم.
شبکه‌های اجتماعی چه بلایی سر این موضوع آوردند؟
به نظرم شبکه‌های اجتماعی، خصوصاً توییتر، این مشکل قدیمی رو تشدید کردن. ما توی فضایی که برای واکنش سریع و متن کوتاه طراحی شده، سراغ موضوعاتی می‌ریم که برای فهمیدنشون گاهی به چند فصل کتاب نیاز داریم!
یکی از خوبی‌های کتاب خوندن، البته کتاب خوب و نه هر کتابی، اینه که نویسنده معمولاً اول کار، شما رو با مفاهیم، پیش‌فرض‌ها و اصطلاحات آشنا می‌کنه. بعد استدلالش رو قدم‌به‌قدم پیش می‌بره. اما توی توییتر ممکنه یک جمله از یک بحث چندساعته یا یه مقاله چندصفحه‌ای جدا بشه و هزاران نفر درباره همون یک جمله اظهار نظر کنن.
تازه شاید کسی هم تلاش کنه منظورش رو توضیح بده، ولی به عقب‌نشینی یا توجیه متهم بشه! (البته اگر جد و آبائش مورد لطف قرار نگیرن!) البته مشکل فقط محدودیت کاراکتر نیست. سرعت واکنش، میل به دیده‌شدن و پاداشی که گاهی به تندترین و جنجالی‌ترین واکنش‌ها داده می‌شه هم بی‌تأثیر نیست.
از اون طرف، خودمون هم وقتی درباره موضوع پیچیده‌ای توی یه توییت کوتاه می‌نویسیم، باید بپذیریم که ممکنه بخشی از زمینه و پیش‌فرض‌های حرفمون رو منتقل نکرده باشیم.
فهم مشترک، مسئولیت مشترکه.
هم نویسنده باید تا جایی که می‌تونه روشن، دقیق و با در نظر گرفتن مخاطبش بنویسه، هم خواننده باید قبل از مخالفت تلاش کنه منظور نویسنده رو بفهمه.
اگر ده نفر از یک جمله من ده برداشت متفاوت دارند، بد نیست قبل از اینکه به فهم اون ده نفر شک کنم، یک بار هم به شیوه بیان خودم شک کنم!
البته شناخت زمینه و پیشینه گوینده هم برای فهمیدن منظورش مهمه، اما نه به این معنا که سابقه، مدرک یا جایگاه حرفهای کسی حرفش رو درست می‌کنه یا اون رو از نقد مصون نگه می‌داره. ممکنه کسی رو کاملاً درست بفهمیم و باز هم با دلایل محکم باهاش مخالف باشیم.
من عادت دارم گاهاً توی مباحثه‌ها دو چیز رو از همون اول درباره نظرم به مخاطبم می‌گم:
اول اینکه نظر من از طرف یکی از ۸ میلیارد آدم روی زمینه؛ همین! بنابراین اگر اشتباه باشه، قرار نیست بلایی سر بشریت بیاد! calm down حاجی!
دوم اینکه خیلی وقت‌ها پیشاپیش می‌گم «نظر من محتمل به خطاست». یعنی نه ادعای حقیقت مطلق دارم، نه فکر می‌کنم آخرین حرف رو زدم. اگه استدلال یا شواهد بهتری وجود داره، اتفاقاً خوشحال می‌شم یاد بگیرم.
در نتیجه لطفاً دنبال نبرد و چالش نباش داداش! قرار نیست یکیمون برنده بشه و اون‌یکی شکست بخوره و اهالی شهر بیان بهش تخم‌مرغ پرتاب کنن!
قبل از مخالفت، یک سؤال!
دنیل دنت توی کتاب Intuition Pumps and Other Tools for Thinking به قواعدی از آناتول راپاپورت برای نقد سازنده اشاره می‌کنه که برای من خیلی جالبن. یکی از مهم‌ترین توصیه‌هاش اینه که قبل از نقد کردن، حرف طرف مقابل رو اون‌قدر دقیق و منصفانه بازگو کنیم که خودش بگه: «بله، منظورم همین بود!»
البته ماجرا به همین‌جا ختم نمی‌شه. توصیه می‌کنه نقاط توافق و چیزهایی رو هم که از طرف مقابل یاد گرفتیم مطرح کنیم. بعد از همه این‌ها، تازه نوبت نقد و مخالفت می‌رسه.
به نظرم این مهارتیه که خیلی از ما، از جمله خود من، باید بیشتر تمرینش کنیم.
البته قرار نیست در هر کامنت دوخطی یک جلسه فلسفی برگزار کنیم! گاهی یک سؤال ساده کافیه. گاهی هم مشخصه طرف مقابل اصلاً دنبال گفت‌وگو نیست و ادامه ندادن بحث، انتخاب عاقلانه‌تریه.
حتی ممکنه در نهایت به این نتیجه برسیم که طرف مقابل کاملاً اشتباه می‌کنه. هیچ اشکالی هم نداره. قرار نیست برای داشتن گفت‌وگوی خوب حتماً به توافق برسیم.
ما معمولاً گفت‌وگو رو از جایی شروع می‌کنیم که باید به اونجا برسیم: از فرضِ فهم مشترک.
شاید بد نباشه دفعه بعد که جمله‌ای خوندیم و بلافاصله احساس کردیم باید پاسخش رو بدیم، قبل از باز کردن کیبورد از خودمون بپرسیم:
«من دارم به چیزی که این آدم گفته پاسخ می‌دم، یا به چیزی که فکر می‌کنم گفته؟»
و اگر خودمون نویسنده‌ایم:
«آیا حرفمون رو طوری بیان کردیم که طرف مقابل فرصت داشته باشه درست بفهمتش؟»
این اولین مطلب از مجموعه‌ای درباره «مهارت‌های نرم» است. نه فقط برای مهندسان نرم‌افزار، بلکه برای همه ما. (به بیان دقیق‌تر؛ می‌تونه اولین از یک مجموعه باشه؛ شاید هم تنها مطلب باشه)
اگر بحث مفیدی شکل بگیره، در مطالب بعدی سراغ مسائل دیگه‌ای هم می‌ریم. مثلاً اینکه چرا گاهی حتی وقتی متوجه اشتباه‌مون می‌شیم، باز هم حاضر نیستیم نظرمون رو تغییر بدیم؟ چرا بعضی وقت‌ها مخالفت با یک عقیده رو حمله به شخصیت خودمون تلقی می‌کنیم؟ و اصلاً چرا برای بعضی از ما، گفتن «نمی‌دونم» این‌قدر دشواره؟
این‌ها به نظر من موضوعات خیلی مهمی در مسیر رشد فردی و شغلی هستن؛ و حتی در مورد لیدرشیپ، ضروری هستن.