مهارت‌های نرم یا نحوه اندیشیدن؟ چرایی نیاز به تغییر نگرشمان (خوانش متفاوت از #مهارت_نرم)

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

- تعریف: بیایید با تعریف دو کلمه در این عبارت، شروع کنیم. بنظر تعریف جامع و مانع برای #مهارت میشه "توانایی انجام یک کار" و با توجه به مکان قرار گیری کلمه "نرم" یعنی به عنوان پسوند کلمه مهارت و تعریف ارائه شده، میشه "ذهنی". پس تعریف کلی عبارت میشه "توانایی انجام یک کار ذهنی" و وقتی میگیم کسی دارای مهارت نرم هست یعنی توانایی ذهنی کافی برای انجام کارهای مرتبط را داره.

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

- دلایل ابهام: اگر کمی به جملات گفته شده این بخش دقت کنیم قطعا با کمی کنکاش و #تفکر_انتقادی می تونیم متوجه بشیم که چرا استفاده از عبارت مهارت نرم این‌روزها به نوعی گمراه کننده هست تا کمک کننده. مثلا اگر مهارت سخت را بجای کارهای بدنی، به اون بخش از تخصص های ذهنی یک #مهندس (هر رشته ای) که مثل توسعه نرم افزار که کار کاملا ذهنی می باشد، منتقل کنیم، اصولا جداسازی سخت/نرم صحیح می شود؟ مثلا برای یک سرباز توانایی حل مسئله مهارت نرم بود ولی برای یک مهندس این توانایی در اصل مهارت سخت هست! پس دیگر چه چیزی مهارت نرم می باشد؟ اگر قرار است به یک حوزه بگوییم مهارت نرم برای تو مهارتی جانبی ولی مهم هست ولی در جای دیگه بگوییم مهارت نرم برای تو مرزی با مهارت سخت ندارد، حرف عجیبی نزده ایم؟؟

#تلنگر_ذهنی:
- یادمون باشه به جای پژوهش (مطالعه و یادگیری) روی معلول ها یعنی خروجی سیستم (فکری)، روی علت یا نحوه اندیشیدن خودمون کار کنیم. یعنی بجای خوندن کلی مطلب در خصوص موضوع ذهنیت قربانی

جمع‌بندی:
در نهایت بنظر بجای گفتن "یادگیری مهارت های نرم خیلی مهمه" از این به بعد بگیم "یادگیری نحوه اندیشیدن پایه های اساسی #به_زیستی فردی و اجتماعی است" اینجوری بجای ایجاد ابهام و هدایت به سمت و سوی نامشخص، فرد به راحتی به کلی منبع موثر میرسه.
با بخش هایی از شعری از مولانا این پست را خاتمه میدم.
*هر کسی کو دور ماند از اصل خویش باز جوید روزگار وصل خویش
*هر کسی از ظن خود شد یار من از درون من نجست اسرار من

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

#تجربه فقط یک نوع نیست! چرا نباید تجربه‌ی زیسته و علمی را یکی بدانیم؟

یکی از موضوعاتی که معمولاً نادیده گرفته می‌شود و نیاز به دقت زیادی دارد، تفاوت بین انواع تجربه است. بسیاری فکر می‌کنند تجربه فقط یک نوع دارد و مثلاً می‌گویند: "تا تجربه نکنی، چیزی را یاد نمی‌گیری!" اما این جمله یک اشتباه بزرگ دارد: تجربه‌های مختلفی وجود دارند، مثل #تجربه_زیسته (که بیشتر شخصی و احساسی است، ویکی) و #تجربه_علمی (که سیستماتیک و مبتنی بر روش‌های دقیق است، روش‌شناسی یا متدولوژی ). این دو نوع تجربه زمین تا آسمان با هم تفاوت دارند!

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

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

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

قبلا در این پست اشاره شد که #ارتباط_برقرار_کردن و داشتن تنوع انواع دوست در #دایره_دوستی ما مهم هست و باید بدونیم برچسب های مختلفی برای انواع دوست وجود داره، مثلا در پی نوشت این پست گفتیم که در زبان عربی ۱۲ لایه دوستی یا برچسب برای دوستان وجود داره! پس بعد از درک اهمیت این موضوع، باید پاسخ بدیم چجوری بین دوستان مختلف خودمون تمایز قائل بشیم یا حتی چجوری از ابتدا به یک فرد اجازه بدیم وارد دایره شناختی فردی (برچسب دوست) ما بشه. یکی از راه های موثر امکان شروع یک گفت و گو در هر فرصتی هست.
شاید برای شما هم پیش اومده باشه در جمعی از افراد باشید و ندونید چجوری سر صحبت را باز کنید تا باهاشون عمیق تر آشنا بشید و حتی یک روز تفریحی خوب را بگذرونید. عبارت کلیدی questions to ask in friends group شما را به لیست جذابی از سوالات میرسونه که می تونه در جمع دوستان فارغ از تخصص افراد باعث ایجاد مشارکت و گفت و گو بشه. یکی از لیست های معروف 36 questions that might lead to love هست که توسط یک روان شناس معروف تهیه شده و سوالات به شدت جذابی داره، پیشنهاد می کنم حتما یکبار در یک جمع همخوانی کنید و پاسخ بدید به سوالاتش. یادمون باشه در اکثر لیست سوال ها با این عبارت کلیدی، اشاره میشه که همون اول شفاف بگید که هر فردی دوست نداره می تونه براحتی سوال را رد کنه و جواب نده و مخاطب خاصی برای سوال ها نگذارید و اصرار اضافه هم نکنید کسی جواب بده، مثل بازی های جرات یا حقیقت!

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

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

رفقا ما دنبال یک Growth Hacker مشتی هستیم که به ما در Extend اضافه بشه، کار فول تایمه و موضوع به شدت خلاقیت شما عزیز دل رو میطلبه. زبان انگلیسی هم برای ما اولویت داره.
روز های کاری ما دوشنبه ها تا جمعه است، از ساعت 14 تا 22:30
اگه سوال داشتید به خود من مستقیما میتونین پیام بدید. دمتون کلی گرم.

? We're Hiring a Growth Hacker at Extend! ?

Are you a tech-savvy problem solver with a passion for growth hacking? Join Extend, an innovative cash collection platform, and lead our efforts in lead generation and outreach!

What You'll Be Doing:

You'll be responsible for scraping and validating target customer emails using tools like ZeroBounce. Once you have those leads, you'll launch and manage cold email campaigns through SmartLead, carefully handling multiple domain variations to ensure our emails always land in the inbox.
In addition to that, you'll work closely with our team to create a weekly podcast tailored for our audience. You'll also be transforming these episodes into engaging clips for LinkedIn and turning emails into newsletters that promote the podcast.

What We're Looking For:

We need someone who is proficient in programming languages like Python, JavaScript, C#, Lua, or Rust.
Experience with scraping tools such as BeautifulSoup, Scrapy, etc. is essential.
You'll also need experience with NoSQL databases and data-driven system design.
Familiarity with cloud platforms like Azure, AWS, or Google Cloud is a plus.
If you have skills in email validation and cold email strategies, that's a big plus too! Plus, you'll be managing multiple email domains to keep our outreach efforts running smoothly.

Ready to join us and shape the future of cash collection? ?

Apply Now: Send your resume to [email protected]

For more details, check out our website.

به درخواست بهنیا آزاد(لینکدین) عزیز پست مربوط به #دعوت_به_همکاری شرکت فعال خودشون را اینجا میفرستم. قطعا موقعیت مناسبی برای افراد جویای کار هست.
به همین بهانه یک اشاره کوچکی هم داشته باشیم به مفهوم و چرایی استفاده از مفهوم #هک_رشد که همزمان به اهداف پست هامون که همانا #تلنگر_ذهنی باشه هم نزدیک بشیم.
همین اول کار بگم من با عنوان شغلی هکر رشد (Growth Hacker) مخصوصا وقتی با سو استفاده توسط بخشی از اکوسیستم به نفع خودشون مصادره شده، اصولا مخالفم مثل خیلی از عناوین شغلی دیگه مثلا DevOps یا UX Desinger یا BackEnd Developer یا FrontEnd Ddeveloper . دلیل مخالفت شدیدم با این عناوین ایجاد مسیر اشتباه ذهنی و عملی هم برای سازمان ها و هم برای اشخاص هست. باید مثل همیشه یادآوری کنیم توسعه نرم افزار نیاز به درک #سیستم_پیچیده داره پس تقلیل هر موقعیت شغلی در مسیر توسعه نرم افزار به چیزی کمتر از تایتل #توسعه_دهنده نرم افزار ارسال سیگنال اشتباهی در مسیر #یادگیری انتقال میده و در بلند مدت قطعا مشکل ساز خواهد بود.
در نهایت از دید نگارنده دوست عزیزمون بهنیا و تیمشون مثل دیگر سازمان ها دنبال یک توسعه دهنده نرم افزار هستند که مجهز به انواعی تفکر که بارها در موردشون نوشتیم مثل #تفکر_انتقادی و #تفکر_سیستمی که به شکل غیر علمی و عامیانه به اون فرد صفت #هکر میدیم.

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

#نقد‌ی به اپیزود over rated DDD پادکست code lodge
- نحوه معرفی مفهوم #توسعه دامنه محور (#DDD) با کلیات و جزییاتی گره خورد که بنظرم برای کسی که آشنایی کافی با این مفهوم نداشته باشه، اصولا می تونه باعث گمراهی بشه. حتی باید اشاره کنیم برداشت صحیحی نیست که بگوییم تعریف مفهوم DDD محدود به #ساختار معرفی شده در کتاب معروف به کتاب آبی اریک ایوان می باشد. هر چند در گفت و گو اشاره ای به این موضوع مهم شد ولی در کل گفت و گو عملا اون بخش خیلی کوتاه براحتی می تونه در ذهن شنونده گم بشه، چون در تناقض با همین تیکه کوچک کلی فرضیات مطرح شد.
- برای پاسخگویی به سوالاتی که در ساختار مدنظر نویسنده کتاب آبی برای مفهوم DDD معرفی شده، محبور به صحبت های زیاد در حوزه تکنیکال شده، ولی اصولا این موضوعات تکنیکال ارتباط مستقیمی به ساختار معرفی شده در ذات DDD ندارد. به طور تقریبی بخش زیادی از صوت به جداسازی حوزه های فنی و بیزینسی پرداخته شد که در DDD اصولا حوزه های فنی بایستی کاملا مسکوت باشند و هر کس (مانند اریک ایوان) صرفا برای ارائه ساختار (کلیاتی که منجر به توسعه چارچوب می شود) به این حوزه ها ورود می کند که البته از دید نگارنده این پست، بدلیل ایجاد اشتباهات شناختی، اصولا بهتر است در تبیین هر موضوع از آوردن مفاهیم غیر ضرور جلوگیری کنیم.
- در مسیر گفت و گو مشارکت کنندگان در صوت بمب باران کلمات را پیش گرفتند بدون اینکه تبیین صحیحی از ارتباط بین این کلمات و DDD به روشنی ارائه دهند. مثلا در برابر هم قرار دادن مفاهیمی مثل DDD و Modular Monolithic و ... و القای غیر مستقیم اینکه این مفاهیم در برابر هم هستند هم موضوعی که نقد جدی به مسیر گفت و گو وارد هست. شاید دو عزیز در گفت و گو منظورشون دقیقا در برابر هم قرار دادن این موضوعات نباشه ولی بر اساس عنوان این قسمت پادکست، اصولا دید منفی کاملا قالبی در خصوص این مفهوم در ذهن شنونده شکل میگیره.
- استفاده از عبارت "بررسی مضرات استفاده نادرست از Domain-Driven Design (DDD)" در معرفی این قسمت در کامنت اپیزود و اشارات غیر مستقیم زیاد به این مفهوم مثل گفتن اینکه هر پروژه نرم افزاری مناسب توسعه بر اساس DDD نیست، خود نشان دهنده درک نادرست از این مفهوم می باشد. از دید نگارنده این پست هیچ راه جایگزینی برای توسعه مناسب ماژول های نرم افزاری که بتوانند سایر الگوهای توسعه را رعایت کنیم به جز توجه ویژه به دامنه بندی صحیح ماژول ها (DDD) وجود ندارد. این رویکرد هیچ تضادی با دیگر نیازمندی ها و راه کارها مثل EDA ندارند و اصولا پاسخگوی یک بخش کوچک از ساختار توسعه هست ولاغیر. با توجه به این نکته استفاده نادرست از DDD اصولا معنای صحیحی ندارد و صرفا بایستی سعی در تبیین صحیح این مفهوم قدم برداریم.

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