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

تبیین عمیق تر #معماری و #معمار

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

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

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

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

🌏🥳 سال نو مبارک 💐🌳

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

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

🔗 #خوانش کتاب 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.

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

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

🧠 #تفکر_سیستمی و #تفکر_انتقادی دو رکن جدانشدنی حل مسائل (بخصوص مسائل پیچیده) هستند.

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

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

💬 این موضوع توی توسعه نرم‌افزار خیلی ملموس‌تره. فرض کنیم توی طراحی یه سیستم، به اشتباه "اینروزا همه کاربران به اینترنت پهنای باند بالا و پایدار دسترسی دارن." اگه این پیش‌فرض رو نقد نکنین، ممکنه توسعه به نحوی پیش بره که برای بارگذاری داده‌ها بهینه نباشه و توی دنیای واقعی، عملکرد سیستم رو برای خیلی از کاربران مختل کنه. اینجا تفکر انتقادی به کمک میاد تا این فرض رو زیر سؤال ببره و با داده‌های واقعی، شما رو به سمت توسعه (طراحی یه معماری) انعطاف‌پذیرتر و مقیاس‌پذیرتر هدایت کنه، مثلاً با درک عمیق تر مفهوم Cache و مفاهیم و تکنیک های مرتبط مثل lazy loading یا حتی بازطراحی فرآیندهای نرم‌افزار برای کاهش پیچیدگی محاسباتی یا انتقال بار پردازشی به client یا edge نودها و کاهش انتقال اطلاعات در شبکه های غیر پایدار اینترنت.

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

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

🧠 #تکنولوژی (#فناوری) چیست؟

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

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

سبک زندگی خود نوعی تکنولوژی می باشد

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


🔗 شما تا حالا به فناوری به چه شکلی نگاه میکردید؟ آیا نگاه مشترکی با نگارنده داشتید؟

🧠چرا تقابل کاذب (سندروم "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) را کمی بیشتر مطرح می کنیم که یادمون باشه یادگیری، اصول خیلی مهمی داره و نباید دنبال مقایسه های اشتباه باشیم و هر موضوعی و هر فردی نیاز به بررسی و توسعه یکتایی داره.

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

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

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

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

ویدئو پیوست، اجرای مشترک سینا ساعی و سروین ضابطیان در مرحله فینال رئالیتی شوی کارناوال با اجرای قطعه با مضمون رها کردن هست، پیشنهاد می کنم تماشا کنید و لذت ببرید.