کتاب روان‌شناسی پول: درس‌های ابدی درباره‌ی ثروت، طمع و خوشحالی (The Psychology of Money: Timeless lessons on wealth, greed, and happiness) را به همراه چند تن از دوستان عزیزم خواندم.

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

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

اجازه دهید بدون لو دادن مطالب کتاب،‌ چند نمونه را با هم بررسی کنیم.
– در این کتاب توضیح می‌دهد که پول‌داری (rich) با ثروت‌مندی (wealthy) تفاوت دارد و آن چه باید به دنبال آن بود ثروتمندی است!

– جای دیگر کتاب درباره‌ی مفهومی به نام «کافی بودن» (enough) توضیح می‌دهد و تاکید می‌کند که «مقدار کافی بودن» موضوعی است شخصی و بعد توضیح می‌دهد که چگونه می‌توان از این مفهوم برای «آزادی مالی» استفاده کرد.

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

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

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

گزیده:
انسان‌ها کارهای احمقانه‌ای با پول می‌کنند ولی هیچ انسانی احمق نیست!
مورگان هاوسل – روان‌شناسی پول

به تازگی گوگل در یک وب‌نوشت، مجموعه‌ای از نمونه کاربردهای هوش مصنوعی را معرفی کرده است. این نوشته شامل ۳۲۱ نمونه‌ی کاربردی از حوزه‌های مختلفی مانند خرده‌فروشی و کالاهای مصرفی، خودرو و لجستیک، سلامت است. مرور این نوشته برای آشنایی با کابردهای هوش مصنوعی و هم‌چنین ایده گرفتن برای شناسایی کاربردهای مشابه در حوزه‌ی تخصصی می‌تواند مفید باشد.

صحنه‌ای از مجموعه تلویزیونی “بازی تاج و تخت” (Game of Thrones) است که توی اون «لیتل فینگر» (شخصیت مرموز،‌ حیله‌گر و تشنه‌ی قدرت این سریال) رو به «سانسا استارک» می‌کنه و می‌گه:
«همیشه دلم می‌خواست یه کشتی داشته باشم. ولی الان [که یه کشتی دارم] دلم می‌خواد چند تا کشتی داشته باشم. عجیبه! مگه نه؟!»
و سانسا ازش می‌پرسه: «چی عجیبه؟»
و بعد لیتل فینگر ادامه می‌ده:‌ «مهم نیست که چی می‌خوایم. مهم اینه که وقتی به دست‌اش می‌آریم یه چیز دیگه می‌خوایم.»

. . . هر سو مرا کشيد پي خويش در به در
اين خوش پسند ديده‌ی زيبا پرستِ من.
شد رهنمای اين دلِ مشتاق بی‌قرار،
بگرفت دستِ من.

و آن آرزوی گم شده، بی ‌نام و بی ‌نشان،
در دورگاهِ ديده‌ی من جلوه می‌نمود.
در وادیِ خيال مرا مست می‌دواند،
وز خويش می‌ربود.

از دور می‌فريفت دلِ تشنه‌ی مرا؛
چون بحر، موج می‌زد و لرزان چو آب بود.
وانگه که پيش رفتم با شور و التهاب، ديدم سراب بود!
الف.سایه.

بهترین راه برای دریافت پاسخ درست در اینترنت، پرسیدن پرسش درست نیست! بهترین راه، نوشتن پاسخ نادرست است.

ورد کانینگهم (Ward Cunningham)

مرجع تصویر: xkcd.com

طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح‌ پایین یکی از پیچیده‌ترین سیستم‌های نرم‌افزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم می‌دانیم و پیاده‌سازی (implementation) را هم روشی می‌‌دانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.

تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز می‌کند یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و می‌فهمند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.

نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های پنهان یا غیرشفاف» (The Law of Implicit Interfaces)‌ گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند]. به عبارت دیگر، در صورتی که رابط (interface) به تعداد کافی استفاده‌کننده داشته باشد، مجموع استفاده‌کنندگان خواسته یا ناخواسته به بخش‌های مختلف پیاده‌سازی وابسته خواهند شد. نتیجه‌ی چنین اتفاقی، سخت‌تر شدن اعمال تغییرات در پیاده‌سازی رابط‌ها است زیرا از این نقطه به بعد، پیاده‌سازی نه تنها باید با بخش مستندشده و شفاف رابط‌ها (explicitly documented interface) تطبیق داشته باشد بلکه باید با بخش پنهان و غیرشفاف رابط‌ها (implicit interface) که ناشی از روش استفاده‌‌ از آنهاست نیز هم‌خوانی داشته باشد. ما معمولن این پدیده را «سازگاری با خطا برای خطا« (bug-for-bug compatibility) می‌نامیم [«سازگاری با خطا برای خطا» یا «سازگاری با خطا» تکنیکی است که در آن خطاها یا رفتارهای نادرست نسخه‌‌ی قبلی یک نرم‌افزار در نسخه‌ی جدید آن با آگاهی و خودخواسته باقی گذاشته می‌شوند. مترجم]

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

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

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

هویرام کیست؟

هویرام رایت (Hyrum Wright) دانشمند ارشد (Principal Scientist) ادوبی (Adobe) است و قبل از آن، مهندس نرم‌افزار در گوگل بود. او روی ابزارها و زیرساخت مدیریت تغییر کد در مقیاس بزرگ کار می‌کند و سال‌های زیادی را صرف بهبود کتابخانه‌های زیربنایی و مبتنی بر سی‌پلاس‌پلاس گوگل کرده است. او یکی از نویسندگان کتاب Software Engineering at Google نیز است.

منبع: www.hyrumslaw.com

گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه!
ناشناس

نمونه ۳:
در ریاضیات یک سری گزاره‌ها یا درست هستند یا نادرست. مثلا یک عدد نمی‌تواند هم از سه بزرگ‌تر باشد و هم کوچک‌تر! این گزاره‌ها با موضوعات آمار و احتمال و حتا منطق فازی هم متفاوت هستند. این گونه گزاره‌ها نمی‌توانند هم درست باشند و هم نادرست.

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

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

بعدها در جایی دیدم که اگر عدد 6 انگلیسی را بین دو نفر بگذارید که یکی از راست و دیگری از چپ به آن نگاه کند،‌ یکی می‌گوید این عدد ۹ است و دیگری می‌گوید این عدد ۶ است. هر چند که عدد ۶ ثابت است ولی آن دو از دو منظر متفاوت به آن می‌نگرند و در نتیجه هر دو درست می‌گویند: یکی می‌گوید 6 و دیگری می‌گوید 9. نظر من می‌تواند کاملن مخالف نظر شما باشد ولی هر دو نظر و در یک زمان درست باشند!

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

گزیده:
رها کن حرف هندو را ببین ترکان معنی را
من آن ترکم که هندو را نمی‌دانم نمی‌دانم

نمونه ۲:
از مبحث بازخورد (فیدبک) در مدارهای الکتریکی آموخته بودم که که بازخورد دو نوع است:‌ بازخورد مثبت و بازخورد منفی. بازخورد مثبت باعث افزایش و بهبود خروجی سیستم می‌شود و بازخورد منفی باعث کاهش خروجی سیستم. وقتی شما به یک فرد دیگر بازخورد می‌دهید، یا بازخوردتان مثبت است (تعریف و تمجید می‌کنید)‌ یا بازخوردتان منفی است (نقد می‌کنید و ایراد می‌گیرید).

شوک ۲: بازخورد منفی کو؟
همان طور که گفتم بر اساس آموخته‌های درس مدارهای الکتریکی باورم این بود که بازخورد افراد به همدیگر یا بازخورد مثبت است یا بازخورد منفی! تا این که به صورت کاملن اتفاقی ویدیویی از یک کلاس آموزشی در کورسرا دیدم که استاد درس پیش از اعلام اولین تمرین درس، کمی در مورد بازخورد صحبت کرد. او می‌گفت که بازخوردهای شما یا باید مثبت باشد یا سازنده. پس از شنیدن این صحبت‌ها دچار این شوک ذهنی شدم و از خود می‌پرسیدم که پس بازخورد منفی کجا رفت! اثر این شوک ذهنی نه‌تنها بر ذهن که بر رفتار و گفتارم هم اثرات شگرف گذاشت. تازه متوجه شدم که چقدر از سختی‌هایی که در زندگی برای خودم ایجاد شده یا برای دیگران ایجاد کرده‌ام،‌ می‌توانست با تغییر مدل ذهنی و جایگزین کردن بازخورد «سازنده» به جای بازخورد «منفی» به وجود نیاید.
پس از گذشت سال‌ها، هنوز آن لحظه‌ای که آن خانم دکتر در کورسرا داشت در مورد روش بازخورد و تصحیح تمرین‌‌ها توضیح می‌داد را به یاد می‌آورم. می‌توانم درباره‌ی تاثیر آن ساعت‌ها صحبت کنم. آرزو می‌کردم که زمانی که کم و سن سال‌تر بودم آن را یاد می‌گرفتم.

پس گفتار:
به قول مولانا «چه دانم‌های بسیار است لیکن من نمی‌دانم»