فصل پنج -- یادگیری همیشگی

اگر اجازه دهیم خودمان، همیشه منتظریم که برخی از حواس‌پرتی‌ها یا مشکلات تمام شوند تا بتوانیم واقعا به کار خود بپردازیم. تنها افرادی که موفق می‌شوند، کسانی هستند که به شدت به دانش نیاز دارند و آن را در شرایطی که هنوز مناسب نیست، جستجو می‌کنند. شرایط مناسب هرگز نخواهد آمد.
—سی. اس. لوئیس، «یادگیری در دوران جنگ»، وزن شکوه و دیگر سخنرانی‌ها

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

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

گسترش دامنه اطلاعات شما

[L]یادگیری آنچه که نمی‌دانیم اغلب از انجام کارهایی که قبلاً می‌دانیم مهم‌تر است.
—جیم هایسمیث، اکوسیستم‌های توسعه نرم‌افزار چابک

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

مشکل
درک شما از توسعه نرم‌افزار محدود و تنها به جزئیات سطح پایین کارهایی که در شغل روزانه خود انجام می‌دهید، متمرکز است.

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

• در Google Reader (یا هر تجمیع‌کننده وبلاگ دیگر) ثبت‌نام کنید و شروع به دنبال کردن وبلاگ‌های توسعه نرم‌افزار کنید. با استفاده از تکنولوژی‌های ترجمه ماشینی مدرن، شما حتی نیازی به محدود کردن خود به کسانی که به زبان انگلیسی می‌نویسند ندارید. می‌توانید توصیه تیم او ریللی را دنبال کنید و وبلاگ‌های آنچه او به نام «آلفا گیک‌ها» می‌خواند را در حوزه‌های مختلف فناوری دنبال کنید. این افراد لزوماً بهترین برنامه‌نویسان نیستند، اما به‌طور جمعی آن‌ها تمایل دارند روندهای جدید را سال‌ها قبل از دیگران شناسایی کنند. به‌عنوان مثال می‌توانید از وبلاگ خود برای بازتاب موضوعاتی که از این وبلاگ‌نویسان می‌آموزید استفاده کنید.

• شروع به دنبال کردن برخی از شخصیت‌های مهم نرم‌افزاری در توییتر کنید و توجه کنید که آن‌ها روی چه چیزی کار می‌کنند.

• به یک فهرست پستی آنلاین با ترافیک متوسط مشترک شوید و سعی کنید به سؤالات افراد پاسخ دهید و مسائل آن‌ها را بازسازی کنید.

• به یک گروه کاربری محلی که به فناوری جدیدی علاقه‌مند است بپیوندید. فقط به‌طور خاموش شرکت نکنید—خودتان را به سازمان‌دهنده معرفی کرده و پیشنهاد کمک کنید.

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

• بعد از خواندن یک کتاب، با نویسنده آن تماس بگیرید و از او تشکر کنید و سوالی بپرسید. نویسندگان، سخنران‌ها و شخصیت‌های مهم ممکن است ترسناک یا مشغول به نظر برسند، اما اغلب از مکاتبه با خوانندگان لذت می‌برند.

• فراموش نکنید که صدها دوره آنلاین، پادکست و ویدئو (مثل سری تکنیک‌های Google Tech Talks) به صورت رایگان از طریق iTunes و YouTube در دسترس هستند.

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

دیو و شلنگ آتش‌نشانی
وقتی که در اواخر سال ۲۰۰۰ به من فرصت یادگیری Perl توسط کارفرمایم داده شد، من بلافاصله شروع به گسترش دامنه اطلاعات خود کردم. احساس می‌کردم که باید خیلی سریع‌تر از دیگران یاد بگیرم، بنابراین بعد از خواندن چند کتاب در مورد Perl، به دنبال هر فرصتی برای یادگیری بیشتر رفتم. من تصمیم داشتم که به سرعت به سطح بعدی به‌عنوان یک توسعه‌دهنده Perl برسم و می‌دانستم که فقط با خواندن یک کتاب در هر زمان این کار به اندازه کافی سریع نخواهد بود (باشه، من رقابتی هستم!). بنابراین به سایت http://perlmonks.org پیوستم، سؤالات را در کمپ.لانگ.پرل.میسک پرسیدم و پاسخ دادم، چند جلسه Perl Mongers رفتم و شروع به انجام Perl Golf (بله، به‌طور رقابتی) کردم. بعد از حدود یک سال از این روند، مجبور شدم برای حفظ سلامت روانم و ازدواجم مصرف اطلاعات خود را کاهش دهم. اما پیشرفت کرده بودم و منابع بیشتری داشتم وقتی که خود را دچار مشکل می‌دیدم.

سپس در بهار ۲۰۰۲، کتاب Extreme Programming Explained از Kent Beck را خواندم و فرصتی برای گسترش دامنه اطلاعات خود به دنیای توسعه تست‌محور، برنامه‌نویسی جفتی، طراحی شی‌گرا و الگوهای طراحی دیدم. باز هم دامنه اطلاعات خود را گسترش دادم، یک سری کتاب‌های عالی خواندم، شروع به حضور در یک گروه کاربری توسعه نرم‌افزار چابک محلی کردم، هزینه خود را برای حضور در کنفرانس XP/Agile Universe (که خوشبختانه همان سال در نزدیکی خانه‌ام برگزار می‌شد) پرداخت کردم، در لیست پستی برنامه‌نویسی افراطی شرکت کردم، شروع به خواندن وبلاگ‌های مرتبط کردم و بعد از آن شروع به نوشتن وبلاگ کردم. نتیجه این فصل از گسترش دامنه اطلاعات من، پیدا کردن شغلی در شرکت ThoughtWorks، یک شرکت مشاوره چابک بین‌المللی بود. حرفه و دوره کارآموزی من به‌طور غیرقابل‌برگشتی از فرصت‌های یادگیری که ThoughtWorks به من داد، تغییر کرد.

در حالی که از دوره کارآموزی به کارآموزی ارشد در اواخر سال ۲۰۰۵ گذار می‌کردم، یک فرصت دیگر در افق دیدم: Ruby on Rails در حال رشد بود. این فرصت را به من داد تا به Obtiva بپیوندم، یک شرکت مشاوره محلی که بیشتر با سبک زندگی من سازگار بود، جایی که استودیو نرم‌افزاری Obtiva را تاسیس کرده و برنامه کارآموزی Obtiva را آغاز کردم.

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

عمل

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

تمرین، تمرین، تمرین
افرادی که ما آنها را به عنوان استادان می‌شناسیم، خود را فقط برای بهتر شدن در مهارت خاصشان وقف نمی‌کنند. حقیقت این است که آنها عاشق تمرین هستند و به همین دلیل بهتر می‌شوند. و سپس برای تکمیل این دایره، هرچه بیشتر پیشرفت می‌کنند، بیشتر از انجام حرکات پایه‌ای به طور مداوم لذت می‌برند.
—جرج لئونارد، Mastery

مفهوم
شما می‌خواهید در کارهایی که انجام می‌دهید بهتر شوید و می‌خواهید مهارت‌های خاصی را در زمینه‌های جدید توسعه دهید.

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

راه‌حل
زمانی را برای تمرین مهارت خود بدون وقفه اختصاص دهید، در محیطی که بتوانید با خیال راحت اشتباه کنید.

در یک دنیای ایده‌آل، ما از تکنیک "تمرین آگاهانه" که در تحقیقات K. Anders Ericsson توصیف شده است استفاده می‌کنیم و یک مربی به شما یک تمرین اختصاص می‌دهد که بر اساس درک او از نقاط قوت و ضعف شماست. وقتی تمرین را تمام کردید، مربی با شما همکاری می‌کند تا عملکرد شما را با استفاده از یک معیار عینی ارزیابی کرده و سپس برای تمرین بعدی برنامه‌ریزی کند. مربی شما سپس با استفاده از تجربیاتش از تدریس به دیگر دانش‌آموزان، تمرینات جدید و چالش‌برانگیزی طراحی می‌کند که شما را وادار به تفکر در مورد مهارت‌های خود، یافتن عادت‌های کاری مؤثرتر و توسعه توانایی "دیدن" به صورت بخش‌های انتزاعی‌تر از دانش می‌کند. با گذشت زمان، این زنجیره از تمرینات باعث تقویت نقاط قوت و اصلاح ضعف‌های شما می‌شود. متأسفانه، ما در یک دنیای ایده‌آل زندگی نمی‌کنیم و شاگردان باید به منابع خود برای دستیابی به همان اثرات تکیه کنند.

در نرم‌افزار، ما در حین انجام کار خود تمرین می‌کنیم و به همین دلیل است که اشتباهات را در حین کار مرتکب می‌شویم. ما باید راه‌هایی برای تفکیک تمرین از حرفه پیدا کنیم. ما به جلسات تمرین نیاز داریم.
—دیو توماس

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

لورن بوزاویت و گروهی از توسعه‌دهندگان نرم‌افزار در پاریس، این استعاره هنرهای رزمی را یک قدم فراتر برده و یک دوژوی کد ایجاد کردند، جایی که افراد می‌توانند به طور منظم گرد هم بیایند و کاتاهای کد را به صورت عمومی انجام دهند. "آقای" باب مارتین که از دوژوی پاریس الهام گرفته بود، نیز کاتاهایی را در وبلاگ خود منتشر کرده و بر فواید تمرین این هنر تأکید کرده است:

مبتدی‌ها با عمل کردن یاد می‌گیرند، نه از طریق سخنرانی. آنها تمرین می‌کنند، تمرین می‌کنند، و تمرین می‌کنند... با تکرار مکرر این تمرینات، مهارت‌های خود را تیز می‌کنیم، بدن و ذهن خود را برای پاسخ دادن به اصول TDD و طراحی ساده آموزش می‌دهیم. ما سیم‌کشی می‌کنیم، و دوباره سیم‌کشی می‌کنیم، و دوباره و دوباره این کار را می‌کنیم.
—باب مارتین

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

بازخوردهای کوتاه باید در جلسات تمرین شما گنجانده شوند. در حالی که تمرین در تئوری خوب است، اگر بازخوردهای دوره‌ای دریافت نکنید، احتمالاً عادات بدی در حال شکل‌گیری هستند. این زیبایی دوژوی کد است: اجراهای عمومی در چارچوب یک جامعه کوچک و منسجم از صنعتگران. این نیاز به بازخورد مداوم با رشد شما به عنوان یک صنعتگر کاهش می‌یابد و به تدریج با مسئولیت شما برای انجام نقش مربی ارشد جایگزین می‌شود، و عادت‌های خوب را با تمرین کردن با توسعه‌دهندگان کم‌تجربه مدل می‌کنید.

یکی از دلایلی که استادان توصیف‌شده توسط جرج لئونارد عاشق تمرین هستند این است که آنها هر بار کمی متفاوت عمل می‌کنند. هدف از این تمرینات تقویت حافظه نیست، بلکه کشف ظرافت‌ها در حتی ساده‌ترین فعالیت‌های ماهرانه است. ممکن است مادربزرگ شما به شما گفته باشد که تمرین منجر به کمال می‌شود. او اشتباه می‌کرد. در واقع، تمرین منجر به دائمی شدن می‌شود. بنابراین، مراقب باشید که چه چیزی را تمرین می‌کنید و به طور مداوم آن را ارزیابی کنید تا مطمئن شوید که کهنه نشده‌اید. انتخاب صحیح آنچه برای تمرین هر روز انجام می‌دهید، تقریباً به اندازه خود عمل تمرین تکراری یک مهارت است. یک راه خوب برای اطمینان از اینکه تمرین‌های جالبی برای استفاده در جلسات تمرین خود دارید، این است که از کتاب‌های قدیمی مانند Programming Pearls، More Programming Pearls، یا Etudes for Programmers استفاده کنید. این کتاب‌ها به قدری قدیمی نوشته شده‌اند که مجبور بودند بیشتر بر اصول کامپیوتر ساینس تمرکز کنند تا چارچوب‌های مد روز. نویسندگان آنها درک می‌کردند که درک عمیق اصول پیچیدگی الگوریتمی و ساختار داده‌ها به ندرت مضر است و تقریباً همیشه مفید است. این موضوعات همچنین منبعی تقریباً نامتناهی از مشکلات جالب برای نگه داشتن جلسات تمرین شما تازه و آموزشی است.

عمل
یک تمرین در یکی از کتاب‌های ذکر شده پیدا کنید یا یکی از خودتان بسازید. مطمئن شوید که این تمرین کمی سخت‌تر از چیزی است که می‌دانید می‌توانید به راحتی حل کنید. شما باید برای اولین بار تلاش کنید تا آن را حل کنید. این تمرین را از ابتدا هر هفته به مدت چهار هفته حل کنید و مشاهده کنید که راه‌حل‌های شما چگونه تکامل می‌یابند. این چه چیزی را در مورد نقاط قوت و ضعف شما به عنوان یک برنامه‌نویس به شما می‌گوید؟ آن دانش را بگیرید و سعی کنید تمرین جدیدی پیدا کنید یا بسازید که تأثیر قابل اندازه‌گیری بر توانایی‌های شما داشته باشد. این روند را تکرار کنید.

مراجعه به بخش‌های دیگر

• "Breakable Toys" (صفحه 79) و "Concrete Skills" (صفحه 24).

اسباب‌بازی‌های شکستاندنی
تو هیچ کاری را به‌طور واقعی خوب انجام نمی‌دهی مگر اینکه آن را دوست داشته باشی، و اگر عاشق هک کردن باشی، به‌طور حتم در پروژه‌های خودت مشغول خواهی بود.
— پل گراهام، هکرها و نقاش‌ها

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

محتوا:
تجربه بر پایه شکست به‌اندازه (اگر نه بیشتر از) موفقیت ساخته می‌شود.

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

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

لینوس یک سیستم‌عامل اسباب‌بازی می‌سازد

از: torvalds@klaava.Helsinki.FI (لینوس بندیکت توروالدس)
گروه‌های خبری: comp.os.minix
موضوع: چه چیزی را بیشتر دوست دارید در می‌نیکس ببینید؟
خلاصه: نظرسنجی کوچک برای سیستم‌عامل جدید من
شناسه پیام: 1991Aug25.205708.9541@klaava.Helsinki.FI
تاریخ: ۲۵ آگوست ۱۹۹۱، ساعت ۲۰:۵۷:۰۸ به‌وقت گرینویچ
سازمان: دانشگاه هلسینکی

سلام به همه کسانی که از می‌نیکس استفاده می‌کنند،
من در حال ساخت یک سیستم‌عامل (رایگان) هستم (فقط به‌عنوان یک سرگرمی، و قرار نیست بزرگ و حرفه‌ای مثل گنو باشد) برای کامپیوترهای AT با پردازنده‌های ۳۸۶ (۴۸۶). این پروژه از آوریل شروع شده است و به‌زودی آماده می‌شود. من دوست دارم هرگونه بازخوردی در مورد ویژگی‌هایی که مردم در می‌نیکس دوست دارند یا ندارند دریافت کنم، چون سیستم‌عامل من تا حدودی شبیه به آن است (برای مثال، ساختار فیزیکی فایل‌سیستم مشابه به‌دلایل عملیاتی).
تا کنون، من bash (نسخه ۱.۰۸) و gcc (نسخه ۱.۴۰) را پورت کرده‌ام و به‌نظر می‌رسد که کار می‌کنند. این به این معناست که من به‌زودی چیزی عملی خواهم داشت و دوست دارم بدانم که بیشتر مردم چه ویژگی‌هایی می‌خواهند. پیشنهادات خوش‌آمد می‌باشد، اما قولی نمی‌دهم که آن‌ها را پیاده‌سازی کنم :-).
لینوس (torvalds@kruuna.helsinki.fi)
پی‌نوشت: بله، این سیستم‌عامل هیچ کدی از می‌نیکس ندارد و دارای فایل‌سیستم چندرشته‌ای است. این سیستم‌عامل قابل‌انتقال نیست (از تعویض تسک ۳۸۶ استفاده می‌کند و احتمالاً هرگز از چیزی جز هارددیسک‌های AT پشتیبانی نخواهد کرد، چون فقط همین‌ها را دارم :-)).

الگوی اسباب‌بازی‌های شکستاندنی (Breakable Toys) مشابه الگوی Be the Worst است، اما این الگو بیشتر در مورد یافتن تیمی است که در آن می‌توانید رشد کنید. اسباب‌بازی‌های شکستاندنی بیشتر به‌طور عمدی فرصت‌هایی را برای یادگیری ایجاد می‌کند، به‌ویژه با قدم گذاشتن فراتر از مرزها و ساختن پروژه‌های کامل نرم‌افزاری به‌تنهایی. این الگو همچنین با الگوهای The White Belt و Confront Your Ignorance مرتبط است، اما کمتر بر رها کردن دانش قبلی تمرکز دارد.

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

برای اطلاعات بیشتر
"Be the Worst" (صفحه ۵۸)، "Confront Your Ignorance" (صفحه ۲۸)، "Record What You Learn" (صفحه ۸۷)، و "Use the Source" (صفحه ۸۲).

استفاده از منبع کد

بهترین روش برای آماده‌شدن [برای برنامه‌نویس شدن] این است که برنامه بنویسید و برنامه‌های عالی که دیگران نوشته‌اند را مطالعه کنید. در مورد من، من به سطل‌های زباله در مرکز علوم کامپیوتر می‌رفتم و فهرست‌های سیستم‌عامل آن‌ها را بیرون می‌آوردم.
— بیل گیتس، برنامه‌نویسان در کار

محتوا
تازه‌واردان به دنیای نرم‌افزار آزاد معمولاً متوجه می‌شوند که وقتی سوالی می‌پرسند، پاسخ معمولاً به این شکل است: "از کد استفاده کن، لوک." این جمله حقیقتی اساسی را در مورد نرم‌افزار بیان می‌کند: کد، داور نهایی است. نیات برنامه‌نویس بی‌اهمیت است اگر کد با آن‌ها مغایرت داشته باشد. تنها با خواندن کد است که می‌توان سیستم را به‌طور واقعی درک کرد.

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

راه‌حل
برای یادگیری از کد دیگران، آن را پیدا کنید و مطالعه کنید. با برنامه‌های روزمره و ابزارهایی که استفاده می‌کنید شروع کنید. به‌عنوان یک کارآموز، یکی از باورهایی که می‌تواند شما را عقب نگه دارد، این است که افراد سازنده ابزارهایی که به آن‌ها وابسته‌اید، به‌نوعی متفاوت یا خاص‌تر از شما هستند. با مطالعه کد آن‌ها، می‌توانید مانند آن‌ها برنامه‌نویسی کنید و مهم‌تر از آن، می‌توانید فرآیندهای فکری که منجر به ایجاد زیرساخت‌هایی که اطراف شما را احاطه کرده، درک کنید.
هنگام بررسی یک پروژه متن‌باز، عادت کنید که نسخه جاری کد منبع را (ترجیحاً از سیستم کنترل نسخه آن) دانلود کنید تا تاریخچه آن را بررسی کرده و پیشرفت‌های آینده را دنبال کنید. ساختار کد را بررسی کنید و سعی کنید متوجه شوید چرا فایل‌ها به این شکل سازماندهی شده‌اند. ببینید آیا دلیلی برای نحوه مدولار کردن کد وجود دارد یا نه، و آن را با نحوه انجام این کار توسط خودتان مقایسه کنید.
سعی کنید کدها را بازنویسی کنید تا بفهمید چرا برنامه‌نویسان انتخاب‌هایی که کرده‌اند را انجام داده‌اند و ببینید اگر شما کد را می‌نوشتید، عواقب آن چه می‌شد. این کار تنها به شما درک بهتری از این پروژه‌ها نمی‌دهد، بلکه اطمینان حاصل می‌کند که می‌توانید آن پروژه‌ها را بسازید. و اگر راه بهتری برای انجام کاری پیدا کردید، موقعیت خوبی برای مشارکت در پروژه خواهید داشت.
هنگامی که در کد پایه پروژه پیش می‌روید، به‌طور حتم با تصمیماتی مواجه خواهید شد که به شدت با آن‌ها مخالفید. از خود بپرسید که شاید توسعه‌دهندگان چیزی می‌دانند که شما نمی‌دانید یا بالعکس. احتمال بدهید که این یک طراحی قدیمی است که نیاز به بازسازی دارد و فکر کنید که آیا ایجاد یک پیاده‌سازی آزمایشی از ویژگی ممکن است آموزشی باشد یا نه.
علاوه بر مطالعه کد دیگران (و در صورت درخواست، ارائه بازخورد)، سعی کنید افرادی را در اطراف خود پیدا کنید که علاقه‌مند به خواندن کد منبع شما باشند. اگر بتوانید بازخورد آن‌ها را بپذیرید و در عین حال ویژگی‌های شخصی آن‌ها را فیلتر کنید، به یک برنامه‌نویس بهتر تبدیل خواهید شد. و به یاد داشته باشید، برای اینکه به یک برنامه‌نویس ماهر تبدیل شوید، باید به دیگران کمک کنید تا رشد کنند، بنابراین به خواندن کد منبع دیگران نیز باز باشید.
یک رویکرد رایج در میان برنامه‌نویسانی که با آن‌ها مصاحبه کردیم، پیوستن به تیم یا پروژه‌ای است که از کد بازبینی یا برنامه‌نویسی جفتی (Pair Programming) استفاده می‌کند. این شیوه‌ها محیط‌هایی را ایجاد می‌کنند که در آن‌ها برنامه‌نویسان می‌توانند به‌طور امن زمانی را صرف مطالعه کد دیگران کنند، اجازه دهند دیگران کدشان را بخوانند و از یکدیگر یاد بگیرند. این گروه‌ها معمولاً برنامه‌نویسان بسیار قوی تولید می‌کنند.
این شیوه‌ها در بیشتر دپارتمان‌های علوم کامپیوتر دانشگاهی نادیده گرفته می‌شود، جایی که آن‌ها به این واقعیت توجه نمی‌کنند که برنامه‌نویسان شاغل بیشتر وقت خود را صرف مطالعه کد می‌کنند تا نوشتن آن. آن‌ها این رویکرد را اتخاذ کرده‌اند زیرا مجبور کردن هر دانشجویی به اختراع دوباره چرخ، آثار و پروژه‌هایی را ایجاد می‌کند که راحت‌تر قابل ارزیابی هستند. با این حال، آموزش خود برای بهتر شدن در کاری که بیشتر وقت کاری شما را می‌گیرد، یک بهینه‌سازی است که در درازمدت پاداش‌های بیشتری به همراه دارد.
این درست است حتی اگر کسانی که اغلب مسئول این محیط‌ها هستند، از اهمیت آن آگاه نباشند.

عملیاتی
یک پروژه متن‌باز پیچیده از نظر الگوریتمی مانند یک سیستم کنترل نسخه (برای مثال، Subversion، Git یا Mercurial) را انتخاب کنید. کد منبع پروژه را مرور کنید و الگوریتم‌ها، ساختارهای داده و ایده‌های طراحی که برای شما جدید هستند را یادداشت کنید. حالا یک پست وبلاگ بنویسید که معماری پروژه را توضیح دهد و ایده‌های جدیدی که آموخته‌اید را برجسته کنید. آیا جاهایی در کار روزمره خود می‌بینید که می‌توان از همان ایده‌ها استفاده کرد؟

برای اطلاعات بیشتر
"تمرین، تمرین، تمرین" (صفحه ۷۷).

تفکر در حین کار

بررسی خود دشوار است، اما من معتقدم که ما می‌توانیم بیشتر از مطالعه شکست‌هایمان نسبت به موفقیت‌هایمان بیاموزیم.
— نورم کرث، مرور پروژه‌ها

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

مسئله
با افزایش سال‌ها و پروژه‌هایی که در کارنامه دارید، خود را در انتظار یک اپیفانی می‌بینید که به‌طور معجزه‌آسا شما را "تجربه‌دار" کند.

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

یکی از تکنیک‌های مفید برای روشن‌سازی این نوع بازتاب، استفاده از چیزی مانند نقشه شیوه‌های شخصی است.
این ایده‌ای است که جو والنس در Extreme Tuesday Club لندن معرفی کرد. این روش شامل نوشتن آگاهانه کارهایی است که انجام می‌دهید و ارتباطات بین آن‌ها. پس از اینکه هر کس شیوه‌های خود را نوشت، گروه این شیوه‌ها را بررسی می‌کند. اگر نگاهی به صفحه وب "نقشه‌های شیوه‌های شخصی افراد" بیندازید، نقشه‌هایی که آده و چند توسعه‌دهنده دیگر ایجاد کرده‌اند را خواهید دید.
یکی از پیامدهای استفاده مکرر از این تکنیک این است که تغییرات در مجموعه شیوه‌های شما را برجسته می‌کند. برای مثال، از سال ۲۰۰۳ تا کنون، آده از "هرگز استفاده از اشکال‌زدای‌ها" به "اشکال‌زدایی با تست‌محور" و سپس به "استفاده آگاهانه از مقادیر ثابت هنگام پیاده‌سازی الگوریتم‌های پیچیده" منتقل شده است. وجود یک نقشه ملموس و قابل مشاهده از شیوه‌های شما باعث بازتاب عمیق‌تر در مورد تأثیر هر تغییر در تکنیک‌های شما می‌شود. در مورد آده، پذیرش توسعه تست‌محور منجر به ارزیابی مجدد تمامی شیوه‌های دیگر شد و نقشه به ابزاری برای تجسم این تغییر تبدیل شد.

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

در سال ۲۰۰۴، دیو بخشی از یک تیم XP بود که شامل چندین توسعه‌دهنده درجه‌یک جهانی بود. آنها شیوه‌ای استاندارد از برنامه‌نویسی جفتی داشتند: یکی تستی می‌نوشت و صفحه‌کلید را به جفتش می‌داد، جفتش آن تست را پاس می‌کرد، تست جدیدی می‌نوشت و صفحه‌کلید را به اولین نفر برمی‌گرداند. این شیوه از برنامه‌نویسی جفتی واقعاً هرگز مورد بحث قرار نگرفت؛ بلکه از تجربیات آن‌ها به‌طور طبیعی به وجود آمد.
دیو به پروژه بعدی خود پیوست و هنگام توضیح این شیوه برنامه‌نویسی جفتی به اعضای جدید تیم خود، متوجه شد که این شیوه نیاز به نام‌گذاری دارد. دیو در مورد آن وبلاگ نوشت، که واکنشی زنجیره‌ای ایجاد کرد که به سرعت به پیشنهاد نوشتن چند ستون برای سایت StickyMinds.com منجر شد. همه این‌ها فقط به این دلیل اتفاق افتاد که دیو به شیوه‌هایی که توسط توسعه‌دهندگان باتجربه‌تر معرفی شده بود، بازتاب نشان داد.

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

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

عملیاتی
یک نقشه شیوه‌های شخصی برای عادات کاری خود رسم کنید. بر ارتباطات بین شیوه‌هایی که مدت زیادی تغییر نکرده‌اند، تمرکز کنید. از خود بپرسید که نقشه شما چه تغییراتی می‌کند اگر متوجه شوید که یکی از این شیوه‌ها واقعاً غیرمولد است. یکی از این شیوه‌ها را به‌دقت بررسی کنید و ببینید آیا راه‌های دیگری برای رسیدن به همان هدف وجود دارد یا خیر. این راه‌ها نیازی به بهتر بودن ندارند؛ همین که متفاوت باشند کافی است. حالا از خود بپرسید اگر یکی از این شیوه‌های متفاوت را اتخاذ کنید، نقشه شما چه تغییراتی خواهد کرد؟

یادداشت کردن آنچه که می‌آموزید

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

محتوا
شما همان درس‌ها را بارها و بارها می‌آموزید. به نظر نمی‌رسد که آن‌ها به حافظه شما بچسبند. اغلب خود را در حال انجام کارهایی مانند راه‌اندازی CruiseControl، مدل‌سازی سلسله‌مراتب در SQL یا معرفی الگوها به یک تیم می‌بینید. به یاد دارید که کارهای مشابهی را در گذشته انجام داده‌اید، اما جزئیات دقیق از ذهن شما فرار می‌کند.

مسئله
کسانی که از تاریخ نمی‌آموزند، محکوم به تکرار آن هستند.

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

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

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

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

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

دیو در دوران کارآموزی‌اش، زمانی که دائماً مطالعه می‌کرد، یک فایل متنی نگه می‌داشت که در آن تمام نقل‌قول‌هایی که یادگیری‌اش را شکل می‌داد، می‌نوشت. در طول سال‌ها، آن فایل به بیش از ۵۰۰ نقل‌قول رسید و دیو در نهایت تصمیم گرفت آن را آپلود کرده و به اشتراک بگذارد. این منبع ارجاعی عالی برای دیو هنگام نوشتن مقالات و این کتاب شد.

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

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

برای اطلاعات بیشتر
"اسباب‌بازی‌های شکستاندنی" (صفحه ۷۹)، "هم‌روح‌ها" (صفحه ۶۴)، "دائماً مطالعه کنید" (صفحه ۱۰۲)، و "آنچه که می‌آموزید را به اشتراک بگذارید" (صفحه ۸۹).

آنچه که می‌آموزید را به اشتراک بگذارید

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

محتوا
شما مدتی است که یک کارآموز بوده‌اید. چیزهایی می‌دانید و مردم شروع به نگاه کردن به شما به‌عنوان منبعی از دانش می‌کنند.

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

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

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

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

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

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

برای اطلاعات بیشتر
"بدترین بودن" (صفحه ۵۸)، "هم‌روح‌ها" (صفحه ۶۴)، "یادداشت کردن آنچه که می‌آموزید" (صفحه ۸۷)، و "سقف را جارو کن" (صفحه ۶۸).

ایجاد حلقه‌های بازخورد

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

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

مسئله
ارزیابی خودتان فقط نسبت به توانایی‌هایی است که قبلاً داشتید و همیشه فاقد عینیت خواهد بود. تیم‌هایی که با آن‌ها کار می‌کنید، به‌راحتی می‌توانند حس شما از شایستگی خودتان را تغییر دهند.
کار کردن در تیمی بالاتر از متوسط می‌تواند شما را به این احساس برساند که یک ستاره‌اید در حالی که واقعاً بیشتر شبیه به یک خواننده پشتیبان هستید، یا می‌تواند اعتماد به نفس شما را از بین ببرد وقتی که همه به نظر می‌رسند خیلی شایسته‌تر از شما هستند. از طرف دیگر، یک تیم پایین‌تر از متوسط می‌تواند شما را دچار حس خودراضی کند. حتی اگر از الگوی تفکر در حین کار استفاده کنید، این تنها به شما کمک می‌کند تا گذشته را تحلیل کنید و نه برای آگاه شدن از وضعیت حال.

ایجاد حلقه‌های بازخورد

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

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

مسئله
ارزیابی خودتان فقط نسبت به توانایی‌هایی است که قبلاً داشتید و همیشه فاقد عینیت خواهد بود. تیم‌هایی که با آن‌ها کار می‌کنید، به‌راحتی می‌توانند حس شما از شایستگی خودتان را تغییر دهند.
کار کردن در تیمی بالاتر از متوسط می‌تواند شما را به این احساس برساند که یک ستاره‌اید در حالی که واقعاً بیشتر شبیه به یک خواننده پشتیبان هستید، یا می‌تواند اعتماد به نفس شما را از بین ببرد وقتی که همه به نظر می‌رسند خیلی شایسته‌تر از شما هستند. از طرف دیگر، یک تیم پایین‌تر از متوسط می‌تواند شما را دچار حس خودراضی کند. حتی اگر از الگوی تفکر در حین کار استفاده کنید، این تنها به شما کمک می‌کند تا گذشته را تحلیل کنید و نه برای آگاه شدن از وضعیت حال.

راه‌حل
مکانیزم‌هایی برای جمع‌آوری منظم داده‌های خارجی نسبتا عینی در مورد عملکرد خود ایجاد کنید. با درخواست بازخورد زودهنگام، مکرر و مؤثر، احتمال اینکه حداقل از ناتوانی خود آگاه شوید، افزایش می‌دهید.
مکانیزم‌های مختلفی برای به‌دست آوردن بازخورد وجود دارد. در یک سطح، این شامل استفاده از تکنیک‌هایی مانند توسعه تست‌محور یا زبان‌های با تایپ‌چک داینامیک با مفسران تعاملی است تا برنامه‌های شما سریعاً شکست بخورند. در سطح دیگری، ممکن است بازخورد را از طریق بازبینی کد یا برنامه‌نویسی جفتی دریافت کنید. امتحانات و گواهینامه‌ها نیز می‌توانند معیارهای مفیدی برای سنجش توانایی شما در مقایسه با دیگران باشند، اگرچه این‌ها اغلب تنها تکنیک آزمون‌دهی شما را تست می‌کنند نه مهارت شما را. یک راه دیگر برای به‌دست آوردن بازخورد این است که از افراد بپرسید که چطور فکر می‌کنند عملکرد شما بوده است؛ برای مثال، با کسانی که شما را برای یک شغل جدید یا ارتقاء مصاحبه کرده‌اند تماس بگیرید و نظر آن‌ها را بپرسید. حتی اگر شغل را نگرفته‌اید، می‌توانید از گفته‌های آن‌ها در مورد دلیل رد شدن خود، چیزهای زیادی بیاموزید. گاهی این بازخورد جنبه‌هایی از شخصیت شما را که از آن‌ها بی‌اطلاع بوده‌اید، آشکار می‌کند.

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

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

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

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

برای اطلاعات بیشتر
"تفکر در حین کار" (صفحه ۸۵) و "کمربند سفید" (صفحه ۱۸).

یاد بگیرید چگونه شکست می‌خورید

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

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

مسئله
مهارت‌های یادگیری شما موفقیت‌های شما را تقویت کرده‌اند، اما شکست‌ها و ضعف‌های شما همچنان باقی مانده‌اند.

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

برای مثال، آده مجموعه‌ای از صفحات را در ویکی خصوصی خود نگه می‌دارد که مهارت‌ها و محدودیت‌ها یا مرزهای فعلی خود را لیست می‌کند.
این به او این امکان را می‌دهد که انتخاب کند کدام مرزها را گسترش دهد (مثلاً تلاش برای نگهداری یک پایگاه داده کد بزرگ در یک زبان با چک تایپ داینامیک) و کجا از تلاش بی‌مورد دست بکشد (مثلاً پذیرفتن این که اسمبلر ۶۵۰۲ برای Commodore 64 احتمالاً هیچ‌گاه دوباره به شدت رایج نخواهد شد).

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

برای اطلاعات بیشتر
"نقشه خودتان را ترسیم کنید" (صفحه ۴۷).

جمع‌بندی

یادگیری دائمی می‌تواند به‌عنوان یک نعمت یا یک نفرین دیده شود. یادگیری چیزی جدید می‌تواند دردناک باشد، به‌ویژه وقتی تحت فشار و با کمترین راهنمایی انجام شود. اما، همان‌طور که یک ورزشکار باید پس از تمرینات سخت از درد عضلات عبور کند، توسعه‌دهنده نرم‌افزار نیز باید از ناهماهنگی ذهنی‌ای که با یادگیری چیز جدید به‌وجود می‌آید، عبور کند. این ناهماهنگی می‌تواند به نشانه‌ای خوشایند از پیشرفت تبدیل شود.
خودبازتابی، شناسایی شکست از طریق حلقه‌های بازخورد، و یادگیری نقاط ضعف خود ممکن است در نگاه اول منفی به نظر برسند، اما این الگوها به شما کمک می‌کنند تا جهل خود را کاهش دهید. گزینه دیگر، تمرکز صرف بر آنچه که قبلاً می‌دانید است، اما این روش به سوی تسلط بر مهارت نرم‌افزاری نمی‌رود؛ این روش تنها به تخصص در یک حوزه خاص منجر می‌شود.
فیلیپ آرمور در مقاله خود با عنوان "پنج سطح جهل" به نقش‌های جهل و دانش در توسعه نرم‌افزار اشاره می‌کند:
نرم‌افزار محصول نیست، بلکه یک وسیله برای ذخیره دانش است. بنابراین، توسعه نرم‌افزار یک فعالیت تولید محصول نیست، بلکه یک فعالیت به‌دست آوردن دانش است. دانش فقط سمت دیگر سکه جهل است، بنابراین توسعه نرم‌افزار یک فعالیت کاهش جهل است.