Geniuses Group

🧩 قطعه‌ی گمشده‌ی پازل موفقیت | بازخوانی متفاوت مهارت نرم اولین نشست از مجموعه «قطعه‌ی گمشده‌ی پازل موفقیت» به موضوعی اختصاص داره که شاید کمتر از کدنویسی درباره‌ش حرف زده بشه، اما تأثیرش روی مسیر حرفه‌ای ما انکارنشدنیه. توی این دورهمی قراره با نگاهی متفاوت، نقش مهارت‌های نرم رو در شیوه‌ی فکر‌ کردن، ارتباط، همکاری، تصمیم‌گیری، رشد شغلی و تجربه‌ی کار حرفه‌ای بررسی کنیم. 🎙 مهمان این نشست: امید حکایتی مدیر ارشد تکنولوژی Geniuses.Group، پژوهشگر و معمار نرم‌افزار. امید با تمرکز بر فلسفه‌ی علم، علوم شناختی و مدل‌سازی، سال‌هاست روی بازتعریف مفاهیم بنیادی مهندسی نرم‌افزار کار می‌کنه. اگه دوست داری این بار از زاویه‌ای متفاوت به یکی از مهم‌ترین قطعه‌های پازل مسیر حرفه‌ایت نگاه کنی، خوشحال می‌شیم همراه ما باشی. 💚 📍ثبت‌نام: https://jameeno.com/events/019ff111-8db9-70de-ac50-69ae8f123d0b 🔗 پروفایل لینکدین امید حکایتی: https://www.linkedin.com/in/omidhekayati?utm_source=share_via&utm_content=profile&utm_medium=member_ios

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI) 🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت می‌کنند؛ ابزارهای جدید معرفی می‌شوند، دوره‌های آموزشی برگزار می‌شود و هر روز اصطلاحات تازه‌ای وارد اکوسیستم می‌شوند. اما…

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI) 🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت می‌کنند؛ ابزارهای جدید معرفی می‌شوند، دوره‌های آموزشی برگزار می‌شود و هر روز اصطلاحات تازه‌ای وارد اکوسیستم می‌شوند. اما احساس می‌کنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را به‌درستی #مدل نکرده‌ایم. 🚨وقتی کلمهٔ Agent را می‌شنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی می‌رود، در حالی که Agent مفهومی بسیار قدیمی‌تر و عمومی‌تر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده می‌گیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همان‌طور که یک کارمند، یک پیمانکار، یک نرم‌افزار، یک سرویس یا حتی یک سازمان نیز می‌تواند نقش یک Agent را ایفا کند. و دقیقاً همین‌جا است که نگاه ما به #مسئله تغییر می‌کند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم. اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار می‌گذاریم و دوباره همان اشتباهات را با نام‌های جدید تکرار می‌کنیم. ⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت می‌دهیم، در واقع سال‌ها قبل از ظهور هوشواره هم وجود داشته‌اند. - وقتی مسئولیت را مبهم واگذار می‌کنیم... - وقتی انتظار خروجی را شفاف تعریف نمی‌کنیم... - وقتی زمینهٔ لازم را منتقل نمی‌کنیم... - وقتی دانش سازمان در ذهن افراد باقی می‌ماند و به دانش مشترک تبدیل نمی‌شود... نتیجه معمولاً قابل پیش‌بینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است. ⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقش‌های کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سال‌ها قبل از ظهور هوشواره نیز وجود داشته‌اند و احتمالاً سال‌ها بعد از تغییر فناوری‌های امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی می‌کنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواست‌ها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عامل‌ها. ⏳شاید هنگام خواندن این متن با خودتان گفته باشید: - ما هم مدام خروجی‌هایی می‌گیریم که با انتظارمان فاصله دارند. - هر بار باید دوباره همه چیز را توضیح بدهیم. - افراد مختلف برداشت‌های متفاوتی از یک درخواست دارند. - دانش پروژه بیشتر در ذهن افراد است تا در مستندات. - با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است. اگر چنین نشانه‌هایی را در #سازمان خود می‌بینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. این‌ها معمولاً نشانه‌هایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیت‌ها یا ضعف در مدل‌سازی مسائل سازمان هستند. این‌ها با تعویض ابزار حل نمی‌شوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند. 🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال می‌کنیم؛ کمک به سازمان‌ها برای ساختن سیستم‌هایی که پایداری آن‌ها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدل‌های ذهنی دقیق‌تر، مدیریت دانش بهتر و تعامل مؤثرتر میان عامل‌ها شکل بگیرد.

اگر به بازاندیشی بنیادین در نحوه ساخت نرم‌افزار علاقه دارید، پروژه #معمار ارزش دنبال کردن داره 🧐 اکثر پروژه‌های نرم‌افزاری بر پایه یک زبان یا یک سیستم‌عامل خاص طراحی می‌شن؛ یعنی اون زبان یا OS هست که قواعد بازی رو تعیین می‌کنه. Memar (معمار) این رابطه رو برعکس می‌کنه: در این چارچوب، فریم‌ورک مرجع اصلی تصمیم‌گیری معماری‌ست و زبان برنامه‌نویسی (Khayyam)، سیستم‌عامل (PersiaOS) و پروتکل‌های شبکه (Chapar، GP، sRPC) صرفاً کامپوننت‌هایی هستن که در دل همون معماری تعریف می‌شن، نه برعکس. یکی از دلایل مهم وجود چنین چارچوبی، توسعه در کنار #هوش_مصنوعی هست. وقتی قواعد معماری به‌صورت صریح و از پیش مشخص تعریف شده باشن، هوش مصنوعی برای پر کردن جاهای مبهم مجبور نیست خودش پیش‌فرض بسازه؛ پیش‌فرضی که می‌تونه مسیر توسعه رو دچار خطا کنه. ساختار مشخص یعنی مسیر تصمیم‌گیری هم برای انسان و هم برای ابزارهای هوش مصنوعی روشن‌تره. این پروژه چند سال هست به‌صورت مستقل در حال طراحی و توسعه‌ست. هدف ساختن یک محصول با عجله نیست؛ ساختن زیرساختی پایدار و چندنسلی هست. تصمیمات معماری مستندسازی و نقد می‌شن. جزئیات بیشتر در کامنت‌ها

#خشم ما از #جنایت های بیشمار حکومتی جنایتکار که به هیچ یک از اصول #حقوق_بشر پایبند نیست، در کلمات گنجانده نمی‌شود. چون نگارنده اعتقاد شدیدی به چرخه خشونت فزاینده داره، به هیچ عنوان قصد افزایش حس خشم خود و دیگران را نداره ولی واقعا اتفاق‌های این چند هفته خارج از ظرفیت فکری و تحملی هر انسان آزادی هست. از طرفی قطعی #اینترنت و #فیلترینگ هیچ تاثیری بر هیچ اتفاق تروریستی و امنیتی مورد ادعای این حکومت بی‌خرد نداره، صرفا برگ زرین دیگری از رفتار غیر عقلانی این حکومت فشل می‌باشد که نشان میده ذره‌ای #خرد دیگر در بدنه تصمیم‌گیر آن وجود ندارد که صرفا بحران تولید میکند نه ظرفیت #توسعه و رشد جامعه. امیدوارم هر چه سریعتر این روزهای دردآور به پایان برسه و روزهایی سراسر از زیبایی همراه با امید به زندگی بهتر برای همه پیشرو باشه. #علم اگر اشتباه کند اشتباهش را خواهد پذیرفت. اما مذهبی تو را می‌کشند تا ثابت کنند #دین هرگز اشتباه نمی‌کند. “#Science may be wrong. #Religion never is.” So they kill you to prove it. — Bertrand Russell

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

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

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

🧠چرا تقابل کاذب (سندروم "VS") گفتمان در اکوسیستم های توسعه رو مسموم می‌کنه؟ 🚨خیلی خلاصه اگر بخوایم با انتزاع پایین و در سطح خود #علم صحبت کنم، می خوایم یادآوری کنیم که یادمون به انواع مغالطه‌های پنهان در گفتمان‌های فنی و خطاهای شناختی مون باشه. به راحتی نذاریم ذهن‌مون آلوده بشه چون ممکنه راه نجات آسانی از این آلودگی ها برامون مهیا نشه. 🔬اخیراً در جاهای مختلف دست نوشته هایی را دیدم که اصلا انتظار این مدل نگارش‌ها را نداشتم و نگارنده ها دنبال مقایسه سیب و پرتقال هستند، شاید در ذات بگید میشه مقایسه کرد، منم میگم باشه میشه ولی هدف چی هست؟ مثلا جایی تیتر زدن که آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟ (تقابل DDD با تیم های کوچک) یا رحیم فیروزی عزیز در کانالش نوشته "سادگی یا اسکیلبیلیتی؟" و جایی نوشته شد بیاین در مورد "FP vs OOP" صحبت کنیم. اما چرا همیشه این سندروم "VS" اینقدر جذاب مطرح میشه در صورتی که ترکیبی از مغالطه‌هایی مثل false dichotomy (#دوگانه_کاذب) و confirmation bias، بحث‌ها رو ساده‌انگارانه می‌کنه و راه گفتمان واقعی رو می‌بنده. ⏳در پست DDD مثل همیشه قصد اینه بگن DDD تقریبا همیشه برای توسعه در سازمان های large scale هست! حتی برای اینکه جلوی بعضی ایرادات را از همان ابتدا بگیرند، تعریف های عجیبی از مدل سازمان مورد نظر میدن که بزرگی سازمان یا تعداد کارمند را صرفا قبول ندارند! انتخاب اشتباه موضوع باعث شده همش دنبال توجیح باشند. اینجا قصد نداریم بگیم DDD بدرد چه نوع توسعه ای می خوره چون اعتقاد راسخ دارم که این رویکرد توسعه بدرد هر نوع توسعه نرم افزاری می خوره و اصلا ارتباطی به سایز پروژه یا سازمان نداره. این موضوع را به شکل عمیق در آینده ای نزدیک در جلسات #خوانش کتاب DDD اریک ایوان مطرح خواهیم کرد. ⏳در مقاله رحیم عزیز واقعیت اینه سادگی و اسکیلبیلیتی دو موضوع کاملا مجزا و حتی کاملا بی ربط به هم هستند. هر چند نیاز بود رحیم عزیز مشخص کنه منظورش از "سادگی" دقیقا چی هست؟ چون وقتی در مقابل مقیاس پذیری قرارش میدیم چندین برداشت میشه ازش داشت، مثلا من احساس کردم منظورش اینه در ابتدای توسعه هر مدلی دوست داری برو جلو، بعدا که نیاز شد تغییرش میدی! ولی این تفکر آیا با اصول #علمی در یکسو هست؟ اگر همه مهندسان دنیا اینو بگن چه بلایی سر #پایداری جامعه ها میاد؟ فکر کنید یک تیم توسعه ساختمان بگن فعلا یک طبقه ساختمان بسازیم، اگر استقبال خوب بود بعدا 20 طبقه دیگه روی این ساختمان میسازیم! این نوع نگاه ممکنه نشان از کمبود دانش موثر در توسعه بخصوص #توسعه_پایدار باشه. ⏳در موضوع FP و OOP هم همین‌طوره مثلا FP از اصول OOP مثل encapsulation عملا استفاده می کنه و اونا تکمیل‌کننده‌ن همدیگن نه چیزی در تقابل! 💬 اوضاع وقتی بدتر میشه که گوینده یا نگارنده در مقام توجیح بازم بخواد موضوعات بی ربط دیگر را به مسیر گفتمان بیاره، مثلا با آوردن صفت هایی مثل over-engineering (پیچیدگی بی‌جا) یا micro-optimization (بهینه‌سازی‌های جزئی بی‌فایده) فاجعه‌ای تمام عیار رقم می خوره. کسی دانش و بینش ضعیفی داره به طور مثال نمی تونه تفاوت complicated و complex (همان‌طور که در تئوری سیستم‌ها می‌گن، پیچیدگی ذاتی نیست، بلکه از تعاملات می‌آد) را تشخیص بده و حتی ظرافت #سوال_باز بودن این حوزه ها را درک کنه و اصولا با مفهوم خود کلمه #سیستم آشنایی کافی را ندارد و حرف از سیستم (محصول) پیچیده میزنه. یا جزییات و تفاوت های ساده‌سازی واقعی (simplification) رو از ساده‌انگاری (oversimplification) تشخیص نمیده ولی با ابهام کامل قصد داره مسیر روشنی را به دیگران هدیه بده! 😉 وای به روزی که این شخص تصمیم‌گیر باشد! سازمان (جامعه، شرکت، تیم، ...) رو به مسیر اشتباه می‌بره و هیچ‌کس جرات نمی‌کنه بگه "شاه لخته!" 😅 🔗 بیاید بحث‌هامون رو بر اساس مکمل بودن و واقعیت بسازیم، نه تقابل‌های کاذب و ساختگی. 🌟 نظر شما چیه؟ 🌟 🌟 شما کدوم "VS" بی‌ربط دیگه دیدید؟ کامنت بذارید! 🌟 🔗 در پست بعد موضوع مهم و خیلی مرتبط با این حوزه یعنی #یادگیری_تطبیقی (Adaptive Learning) را کمی بیشتر مطرح می کنیم که یادمون باشه یادگیری، اصول خیلی مهمی داره و نباید دنبال مقایسه های اشتباه باشیم و هر موضوعی و هر فردی نیاز به بررسی و توسعه یکتایی داره.

🧠 #تکنولوژی (#فناوری) چیست؟ 🔬از دید نگارنده بهترین تعریف برای فناوری میشه "دانش (تکنیک‌ها، مهارت‌ها، روش‌ها و فرایندها، ...) توسعه (ایجاد یا تغییر) سیستم ها (ابزارها، دانش ها، ...) برای تحقق اهداف مورد نظر". جالب شد، بازم کلمه سیستم رخ نمایی کرد! کلمه دانش در تعریف را هم میشه به #علم در تعریف #مهندس و #مهندسی (در این نشست در مورد تعریف مهندس صحبت کردیم) ارتباط داد و اگر متخصص های حوزه فناوری از علم در توسعه فناوری استفاده کنند، قطعا سیستم های با کیفیت تری توسعه داده می شود. 🪄از این به بعد هر جا با کلمه تکنولوژی (تک، ...) برخورد کردید با نگاهی دقیق تر موضوع را بررسی و مورد نقد و کنکاش قرار بدید. مثلا بهتر می توانیم درک کنیم که چرا در یک سازمان CTO (Chief Technology Officer) بایستی حتما دانش به شدت موثر و نسبتا عمیقی از مفاهیم مرتبط با سیستم های در حال توسعه داشته باشد، رفع مسئولیت از خود با عنوان "کمبود دانش موثر" قابل پذیرش نیست و کسی باید قبول مسئولیت کند که توانایی کسب یا نقد دانش منتقل شده از متخصص حوزه مرتبط را داشته باشد. اینجا قبلا عمیق توضیح دادیم. 🪄یادمون باشه فناوری محدود به موجودیت های عینی (موبایل، کامپیوتر، تلسکوپ، ...) نمیشه و موضوعات ذهنی (سازمان، گفتمان، ...) هم در این دسته می توانند قرار بگیرند. 🪄 در #فلسفه_علم هم تاکید می شود که مرز بین علم و فناوری برای هر اندیشمندی باید مشخص شود. یادمون باشه فناوری ارتباط عمیقی (سیستم، ...) با #تفکر_سیستمی و #تفکر_انتقادی که در گروه هم بهشون زیاد میپردازیم، دارد. ⏳راستش این پست را خیلی وقت بود می خواستم نگارش کنم ولی جنگ نالازم و پیش بینی پذیر (توییت بنده چندین ماه قبل از جنگ) گذشته، حوصله نگارش را گرفته بود، اتفاقاتی که به راحتی میشد از وقوع آنها جلوگیری کرد فقط و فقط اگر اراده و عواقب تصمیمات و صحبت های هر فرد در هر جایگاهی در #حکومت جمهوری اسلامی مشخص و گریبان گیر آنها بود. ولی بیایید #جنگ را به همین موضوع فناوری ارتباط بدیم. در ذات جنگ هم مانند هزاران موضوع دیگر یک فناوری محسوب می شود. شاید شنیدید که میگن اگر جمهوری اسلامی مثلا به فلان رادار یا هواپیما دسترسی داشت، قطعا برنده جنگ بود و ... این مدل گزاره ها صرفا از یکسری مغزهای کوچک زنگ زده تراوش می کنه! آیا درست تر این نیست که یادمون باشه تکنولوژی در خدمت کیفیت زندگی انسان ها همیشه باید باشه؟ یعنی آیا فناوری دیگه مثل #گفتمان را از ما گرفتند که که به بدترین فناوری ها متوسل بشویم؟ باز نکته مهم این هست که یادمون باشه هر تکنولوژی آداب و رسوم خودش برای استفاده را دارد، یعنی نمی شود حرف از گفتمان زد ولی در عمل به دنبال وقت خریدن و گذر زمان باشیم! ⏳یا بحث #سیاست گذاری جدید در بعضی از شهرهای ایران مبنی بر ممنوعیت غیر مستقیم داشتن حیوان خانگی! واقعا چرا اینقدر سطحی نگر؟؟ واقعا نمی دانند: سبک زندگی خود نوعی تکنولوژی می باشد شاید در نگاه اول این گزاره به شدت عجیب باشد. تکنولوژی شاید در ذهن خیلی از ما ارتباط غیر مستقیم با سبک زندگی داشته باشه ولی ارتباط مستقیم بهش دادن برای خیلی ها ممکنه عجیب باشه! ولی بیایید برای روشن تر شدن موضوع بر اساس تعریف بالا که نسبتا جامع و مانع می باشد موضوع را بیشتر بررسی کنیم. یادمون باشه سبک زندگی اگر به عنوان یک سیستم بهش نگاه کنیم، در تفکر سیستمی گوشزد میشه که باید به ابعاد مختلف ماجرا دقت بشه و نمیشه به فناوری های دیگر مانند خانواده، حریم خصوصی، ... را نادیده بگیریم و به شکل ساده انگارانه سعی در تغییر صرفا سبک زندگی داشته باشیم. ⏳ #تجربه_زیسته خود حکومت در قلمروی جغرافیای ایران و حتی جهان ثابت کرده منع انسان ها از چیزی به شکل #قانون با #ضمانت_اجرایی پلیس اصولا با شکست مواجه می شود ولی همانطور که همیشه می گوییم تا وقتی روی #تجربه_زیسته بیش از اندازه خودش حساب باز کنیم، همین آثار مخرب را خواهد داشت. یعنی درس نگرفتن بدلیل عدم وجود خروجی مناسب به شکل و اصولی که در #علم بهشون دست یافته ایم. در #تجربه_علمی ما سعی در ایجاد چندین خروجی به عنوان گزاره ها و در ادامه تبدیل به ترجیحا یک خروجی موثر به نام #فرضیه و در ادامه تبدیل آن به #نظریه داریم که به شکل خیلی موثر و راحت قابلیت انتقال بین انسان ها را دارا باشد بدون نیاز به مطالعه در مورد چیستی (#تفکر_انتزاعی) برای همه انسان های درگیر در موضوع. پس در خصوص این موضوع علوم مختلف مثل علوم اجتماعی، علم حقوق، حکمرانی، سیاست و ... به شکل کاملا دقیق موضوعات مرتبط را مطرح کرده اند و نیاز به مراجعه به تجربه زیسته آن هم در سیستم در حال کار نیست! دوستان توسعه نرم افزار می دانند که چقدر کار بدی هست در کدهای یک نرم افزار در حال اجرا بخواهیم تغییری ایجاد کنیم! 🔗 شما تا حالا به فناوری به چه شکلی نگاه میکردید؟ آیا نگاه مشترکی با نگارنده داشتید؟

Geniuses Group pinned «🔗 #خوانش کتاب Learning Systems Thinking: Essential Non-Linear Skills and Practices for Software Professionals از نشر o'reilly 🤝 پس از بررسی و همفکری با همراهان همیشگی، #کتاب بعدی برای خوانش گروهی انتخاب شد. هر چند اینبار بر خلاف دفعه های قبل هنوز خوانش…»

🧠 #تفکر_سیستمی و #تفکر_انتقادی دو رکن جدانشدنی حل مسائل (بخصوص مسائل پیچیده) هستند. 🔬در مدل سازی و تفکر بر پایه نظریه سیستم ها، یکی از موضوعات واضح و بدیهی تا جای امکان کنار گذاشتن هر نوع پیش فرض (بررسی بیشتر در #تفکر_انتزاعی) در مدل کردن است. یکی از اهداف مهم تفکر انتقادی، شناسایی پیش فرض ها می باشد، چیزی که در مدل کردن یک سیستم برای درک و احیانا تغییری در سیستم بسیار مهم هست. ⏳توی دنیای امروز که سیستم‌ها هر روز پیچیده‌تر (complex) می‌شن، توانایی مدل‌سازی دقیق و بدون #سوگیری برای درک و بهبود این سیستم‌ها، یه مهارت کلیدی برای تصمیم گیران ارشد و کساییه که می‌خوان به سطوح بالای دانش و مهارت (حل مسئله) برسند. تفکر سیستمی به ما این امکان رو می‌ده که سیستم‌ها رو به صورت یه کل یکپارچه ببینیم و تعامل بین اجزای مختلفشون رو تحلیل کنیم. اما این مدل‌سازی وقتی واقعاً اثرگذار می‌شه که بتونیم پیش‌فرض‌های ذهنی‌مون رو با تفکر انتقادی به چالش بکشیم و از واقعی بودن پایه‌های #مدل هامون مطمئن شیم. 💬 این موضوع توی توسعه نرم‌افزار خیلی ملموس‌تره. فرض کنیم توی طراحی یه سیستم، به اشتباه "اینروزا همه کاربران به اینترنت پهنای باند بالا و پایدار دسترسی دارن." اگه این پیش‌فرض رو نقد نکنین، ممکنه توسعه به نحوی پیش بره که برای بارگذاری داده‌ها بهینه نباشه و توی دنیای واقعی، عملکرد سیستم رو برای خیلی از کاربران مختل کنه. اینجا تفکر انتقادی به کمک میاد تا این فرض رو زیر سؤال ببره و با داده‌های واقعی، شما رو به سمت توسعه (طراحی یه معماری) انعطاف‌پذیرتر و مقیاس‌پذیرتر هدایت کنه، مثلاً با درک عمیق تر مفهوم Cache و مفاهیم و تکنیک های مرتبط مثل lazy loading یا حتی بازطراحی فرآیندهای نرم‌افزار برای کاهش پیچیدگی محاسباتی یا انتقال بار پردازشی به client یا edge نودها و کاهش انتقال اطلاعات در شبکه های غیر پایدار اینترنت. 💬 یا در موضوع #حکمرانی #قانون فکر کنیم که همیشه #حکومت ها نیاز هست در پیاده سازی و نظارت به اجرای قانون باید به شکل انحصاری عمل کنند تا بتوانیم مطمئن بشیم قوانین (خواسته های جمعی آحاد جامعه) پس از نگارش به شکل متون با مدل مشخص، به شکل صحیح در جامعه، جاری می شوند. بذارید مثال عینی بزنیم که بشه مبنای فکری ما برای ایجاد تمرین های مشابه. فرض بگیرید جامعه به دلایل مختلف برای شناسایی وسایل نقلیه به یک توافق جمعی می رسد، آیا پیش فرض اینکه ما حتما نیاز به یک سازمان واحد برای ایجاد پروتکل های مورد نیاز و اجرای اون پروتکل ها داریم؟ اگر صرفا پیش فرض های گذشته در ذهن ما به شکل قوی وجود داشته باشد که #تجربه_زیسته همه جامعه ها به احداث سازمانی با عناوینی مانند سازمان راهنمایی و رانندگی ختم شود، پاسخ ما به سوال مطرح شده در جهت حل یک مسئله (شناسایی وسایل حمل و نقل) قطعا شبیه به گذشته خواهد شد، ولی با قوی شدن انواع تفکر در ما، قطعا در دام پیش فرض ها گرفتار نخواهیم شد و با پی بردن به اینکه تصمیم گذشتگان بر پایه عدم وجود سیستم های کامپیوتری بوده است، می توان تصمیم های به شدت بهینه تری در حل پرسش ها در حال، ایجاد کنیم. 💬 به بیان ساده‌تر، تفکر سیستمی بدون پشتوانه تفکر انتقادی می‌تونه به مدل‌های غیرواقعی و ناکارآمد منجر بشه. برای همین، در جلسات خوانش کتاب یادگیری تفکر سیستمی در Geniuses.Group قراره این دو مهارت رو عمیق‌تر بررسی کنیم و ببینیم چطور ترکیبشون می‌تونه به راه‌حل‌های نوآورانه و پایدار برای روبرویی با مسائل پیچیده منجر بشه.

یادروز استاد سخن، سعدی شیرازی واقعا باید قدر استادان بزرگی مانند سعدی را پاس داشت که با چه هنرمندی تمام عیاری، کلماتی را کنار هم قرار داده اند که نشان از درک والای آنها از عمق معانی کلمات مورد استفاده آنها دارد. به یاد همه بزرگان ایران خواستم یادآوری کنم که توسعه زندگی صرفا در حوزه تکنولوژی نیست، دیگر حوزه ها مثل هنر هم از جایگاه به شدت بالایی در افزایش کیفیت زندگی نقش دارند. ویدئو این پست هم کاری از هنرمندان معاصر عزیزی هست که واقعا با هنرمندی تمام عیار قدرت کلمات بزرگان گذشته را همراه با موسیقی زیباتر در ذهن و روح ما اثر گذار می کنند. شعر این قطعه، غزل شمارهٔ ۴۸۴ سعدی و غزل شمارهٔ ۶۰۷ می باشد. بیا که در غم عشقت مشوشم بی‌تو // بیا ببین که در این غم چه ناخوشم بی‌تو شب از فراق تو می‌نالم ای پری‌رخسار // چو روز گردد گویی در آتشم بی‌تو ... من چرا دل به تو دادم که دلم می‌شکنی // یا چه کردم که نگه باز به من می‌نکنی دل و جانم به تو مشغول و نظر در چپ و راست // تا ندانند حریفان که تو منظور منی ...

🔗 #خوانش کتاب Learning Systems Thinking: Essential Non-Linear Skills and Practices for Software Professionals از نشر o'reilly 🤝 پس از بررسی و همفکری با همراهان همیشگی، #کتاب بعدی برای خوانش گروهی انتخاب شد. هر چند اینبار بر خلاف دفعه های قبل هنوز خوانش کتاب قبل یعنی DDIA تمام نشده است ولی به دلیل اهمیت موضوع و نیاز به مطرح شدن هر چه سریع تر موضوع خوانش را موازی شروع خواهیم کرد. در کامنت های همین پست، جزییات شرکت در جلسات و صوت ضبط شده جلسات را قرار میدیم. مثل همیشه اگر فرصت شرکت در جلسات را نداشتید می تونید در فصل 5 کانال در کست باکس هم صوت جلسات این کتاب را گوش بدید و اگر سوال، ابهام یا نقد/پیشنهادی بود همینجا مطرح کنید. 🧠 در جلسات قصد هست همانطور که کتاب در جای، جای آن هم تاکید داره با نحوه #تفکر کردن و با نگاهی عمیق تر به #تفکر_سیستمی آشنا بشیم که با توجه به اینکه #نرم_افزار در ذات در دسته #سیستم_پیچیده قرار میگیرد و در عمل در تعامل با سیستم های پیچیده دیگر مثل جوامع انسانی، اقتصاد و ... در ارتباط هست، عملا فقدان این تفکر در الگوهای ذهن #توسعه_دهنده ها مساوی با #تصمیم_گیری های با ریسک به شدت بالا در جهت تصمیم گیری های ضعیف خواهد بود. به هیچ عنوان یادگیری این مهارت تفکر کردن همراه با تمرین های مرتبط را از دست ندهید. یادمون نره صرفا خواندن سریع اینگونه منابع (مثل این کتاب) کمک چندانی به ما نمی کنه و نیاز به خوانش عمیق داریم، ما هم سعی می کنیم خوانشی کاملا عمیق ارائه بدیم. ✨ Self-awareness, also known as metacognition, is the ability to understand and adapt your thinking patterns. Practicing with your own thinking is, perhaps unsurprisingly, the foundation of thinking in systems. ✨ In a world so interconnected by software, systems thinking is an essential skill for navigating the compounding sociotechnical complexity in software development.

🌏🥳 سال نو مبارک 💐🌳 🧠 قبلا هم بارها اشاره کردیم جشن گرفتن مناسبت ها بر اساس الگوهای توافق شده جمعی، برای انسان ها کلی مزایا داره، یکی از این مزایا خروج ما از روتین های فکری و علمی گرفتار شده در آنها هست. پس به راحتی از کنار این مناسبت ها گذر نکنیم! 💬پیشنهاد می کنم سال جدید را با دقت به اینکه #تفکر یک حالت درونی ما انسان ها هست، بیشتر برای ارتقا این خصیصه درونی وقت بذاریم تا بتونیم درک بهتری از جهان پیرامون خودمون داشته باشیم. وقتی تاکید فراوان به یادگیری انواع تفکر مثل #تفکر_سیستمی یا #تفکر_انتقادی داریم، منظور ارتقا حالت درونی خودمون هست، نیاز نیست به سرعت انتظار داشته باشیم در خروجی های ذهن خودمون تغییری را مشاهده کنیم، یادمون باشه #توسعه امری زمان بر هست. به خودمون فرصت بدیم و از زندگی نهایت #شادی و #لذت را ببریم.

تبیین عمیق تر #معماری و #معمار در ادامه پست تبیین کلمه معماری و معمار، و چند مثال در این پست، بیایید مثالی در حدود فرآیندهای پایین تر را بررسی کنیم، که مشخص شود چرا معماری نرم افزار بر خلاف باور رایح صرفا تصمیمات کلان نمی باشد و شامل تمام فرآیندهای یک سیستم می شود. قبل از اینکه وارد مثال بشیم، موضوعی در دیگر پست ها مثل این نوشته بهش همیشه اشاره می کنیم که به اشتباه جداسازی تیم ها یا تخصص هایی با نام فرانت و بک اشاره می شود، پیشنهاد می کنم کمی آن موضوعات را مطالعه، تامل و تفکر نمایید. با مثال این نگارش بیشتر موضوع واضح می شود که توسعه فرآیندها باید با نگاهی به کل سیستم انجام بشه، نه مدل های خطی و محدود و به نوعی ساده انگارانه و جداسازی شده مثل تیم محصول، بک و فرانت! احتمالا با الگوی Retry آشنا هستید، الگویی که در ذات بدلیل فهم ناقض و فقدان #تفکر_سیستمی می تواند #تجربه_کاربر را دچار خدشه کند. به طور مثال حتی اگر قرار به پیاده سازی این الگو باشد، عموما این الگو توسط فرآیندهای سیلو شده در تیم های بک اند انجام میپذیرد! بدلیل عدم نگاه سیستمی و وجود مرزهای بوجود آمده (فرانت/بک) فرآیند به شکل صحیح قابلیت ترسیم حتی برای خود توسعه دهندگان نیز ندارد. به دلیل همین فقدان ها یعنی نبود دانش موثر در تصمیم گیری ها، حتی شاید از پیاده سازی این الگو بدلیل پیچیدگی ها زیاد آن صرفنظر می شود و براحتی فراخوانی مجدد فرآیند را به شکل ناشیانه ای به کاربر منتقل می کنند. کاربر کلافه از فرآیندهای ناقض و خسته کننده، اگر با بازار رقابتی روبرو باشد قطعا به عنوان یک کاربر ناراضی سازمان را رها می کند و در اکثر اوقات حتی بدون داده مناسب برای سازمان و حتی خود فرد در خصوص چرایی این اتفاق، سازمان صرفا تماشاگر از دست دادن سهم بازار خواهد بود. هر چند متاسفانه در سازمان های وابسته به حکومت کشورها، این موضوع مهم بدلیل ذات انحصارگرایانه ارائه خدمت عملا منجر به ترک سازمان نمی شود ولی منجر به مشکلات اجتماعی مثل بالا رفتن سطح خشونت در جامعه خواهد شد. اتفاقی که متاسفانه در خیلی از اوقات صرفا با سرکوب معلول (خشم، ...)، بدون حل علت، به دنبال پنهان کردن آنها هستند. وقتی حرف از حل ریشه ای مشکلات می کنیم، نگاه خطی به هیچ عنوان موثر نمی باشد و قطعا نیاز به #تفکر_سیستمی خواهیم داشت. بگذارید یک مثال واقعی هم که قبلا بهش برخورد کردم را اینجا مطرح کنیم. در نرم افزار ازکی (azki.com) وقتی قصد ثبت یک پلاک جدید دارید و سرویس مورد نظر به هر دلیلی در دسترس نباشد، به شکل عجیبی اول درخواست با استفاده از پروتکل HTTP با کد وضعیت 200 پاسخ داده می شود ولی در عملا در بدنه خطایی ارسال می شود با مضمون به زبان فارسی "در حال حاضر امکان ثبت پلاک وجود ندارد."! متاسفانه بدلیل error handleing ضعیف این نرم افزار، اولا کاربر اصلا متوجه نمی شود که خطایی رخ داده، چون خطایی نمایش داده نمی شود! مشخصا سرویس در سمت سرور قصد برقراری ارتباطی با سرورهای بیمه مرکزی یا پلیس راهور را دارد و بدلیل عدم پاسخگویی آنها، امکان ثبت مهیا نمی باشد. هر چند مشخص نیست. بدلیل ذات طولانی بودن مدت درخواست (16 ثانیه) می شود حدس زد که در سمت سرور حداقل چندبار تلاش (الگوی نام برده شده) اتفاق افتاده است! ولی آیا کاربر عادی 16 ثانیه صبر میدهد بدون اینکه بداند فرآیند در بدون چه وضعیتی می باشد؟ قطعا اگر داده مناسب جمع آوری شود براحتی می توان ادعا کرد بالای 50% از کاربرها به عنوان وجود مشکل به مرورگر دستور بارگزاری مجدد صفحه را می دهند! قصد نیست در چند خط کوتاه پاسخ قطعی به موضوع بدهیم، ولی از دید شما بهتر نیست فرآیند به شکل عمومی تر دیده بشه و در سمت نرم افزار کاربر، در هر حال فرآیند اخذ اطلاعات و نمایش به عنوان پلاک جدید با یک وضعیت مثلا در حال بررسی نمایش داده شود و در فرآیندهای مستقل تر موضوع تایید پلاک انجام پذیرد؟ و موضوع الگوی تکرار بدون نیاز به دخالت کاربر در زمان مناسب تر انجام پذیرد؟ عموما وقتی در حال ایجاد یک خطا هستید به این فکر کنید که مخاطب خطا کیست؟ آیا اصولا نیاز به وجود این خطا می باشد یا نیاز به اصلاح یا ایجاد فرآیند درست دیگر در جهت حل مشکل در فرآیند. در کامنت های همین پست عکس های مرتبط با ازکی را قرار میدهم که ملموس تر باشد موضوع. حال اگر تمایل داشتید به الگوی مطرح شده و ارتباط موضوع با معماری نرم افزار و نقش (role) معمار (یا معماران همراه با معمار ارشد) در سازمان خود کمی تامل و تفکر کنید. به عنوان تمرین ذهنی پرسش های مناسب در این مسیر ایجاد کنید و سعی کنید پاسخ های محتمل را ایجاد کنید. با دیگر دوستان یا همکاران خود در خصوص پاسخ های مطرح شده گفت گو کنید تا پاسخ احتمالی مناسب را بیابید. اگر هم تمایل داشتید زیر همین پست سوال و جواب های خود را برای همفکری بیشتر با دیگر اعضا ثبت نمایید.

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

🧠 #تمرین عملی با #تجربه_زیسته دو موضوع متفاوت می باشد وقتی در جمع های مختلف موضوع تفاوت انواع تجربه (اینجا بخوانید) را مطرح می کنم، اولین سوالی که مطرح میشه اینه که "مگه میشه بدون تجربه زیسته چیزی را عمیق یاد گرفت!؟" با کمی بحث و بررسی، متوجه شدم بسیاری از افراد "تمرین عملی" و "تجربه" (منظورشون تجربه زیسته) را یکی در نظر میگیرند! سوالی که من همیشه می‌پرسم این است: "آیا هر کسی که در یک حوزه تخصصی یا مهارتی صرفا در اثر گذر زمان و کسب تجربه (زیسته)، ادعای تخصص کند، واقعا متخصص آن حوزه است؟" جواب معمولا "خیر" می باشد. این افراد بدون مطالعه معتبر و موثر دانش انباشت شده و تمرین کافی، به راحتی دچار انواع خطاهای شناختی و اشتباهات مهلک می شوند. ⏳سوال معروف در حوزه #پزشکی_مبتنی_بر_شواهد (ویکی پدیا، پست هایی به قلم دکتر صمدی) این می باشد که شما حاضرید سلامتی خود را در اختیار پزشکی قرار دهید که مدعی این می باشد که مثلا بالای 30 سال تجربه در برخورد با بیماران یک بیماری خاص (مثلا صرع) را داشته و هیچ گونه داده دیگر مبنی بر مثلا درصد بهبود یا مرگ ناشی از روش های مبنی بر تجربه خودش را به شما ارائه ندهد؟ تفاوت تجربه زیسته و علم و دانش با روش شناسی های حاصل از تجربه علمی دقیقا در اینجا می باشد که هر چیزی امکان تبدیل به دانش مکتوب و مستند را نخواهد داشت به جز اینکه روش های مشخصی را طی کند. 🔬 یادمون باشه تمرین کردن برای ایجاد #بینش، پس از یادگیری #دانش مورد نیاز کاربرد دارد و بدون یادگیری موثر اولیه دانش مورد نظر، تمرین یا تجربه (زیسته) کردن صرفا میشه یکسری آزمون و خطای بی حاصل و گمراه کننده! 💬 در نهایت در جهت تمرین انواع #تفکر مانند #تفکر_انتقادی ، #تفکر_سیستمی و #تفکر_انتزاعی در زیر این پست سعی می کنم چت هایی که با چت بات ها با مدل های #ذهن_مصنوعی (قبلا اشاره کردیم چرایی اشتباه کلمه #هوش_مصنوعی) در جهت بررسی موضوعات خاص و چالش بر انگیز داشتم را منتشر کنم تا ببینید به چه راحتی می‌توانند این چت بات ها بدلیل وجود دانش غیر موثر و غلط حاصل از تجربه های زیسته اشتباه در اختیار آنها در زمان یادگیری (train شدن)، دچار انواع خطای شناختی و انواع مغالطه می شوند. هر چند اگر ما استدلال های قوی مطرح کنیم، عموما چت بات ها سریع از این خطاها و مغالطه ها مثل مغالطهٔ حفظ پیش‌فرض دوری می کنند. اگر شما هم دوست دارید در جهت تایید یا رد موضوع استدلال های خود را مطرح کنید. و اگر هم دوست داشتید متن چت های خود را با چت بات ها که منجر به تغییر نظر چت بات ها و تذکر اشتباهات اونا بوده را منتشر کنید که بقیه هم بتونن با نحوه گفت و گوی شما بیشتر آشنا بشوند.