بازگشت به مهندسی مدرن و کار با هوش مصنوعی · فصل صفر — جای خودت را در مسیر پیدا کن · 2
بازگشت به برنامه‌نویسی بعد از چند سال: از کجا شروع کنیم؟
برنامه‌نویس بازگشته نمی‌داند کدام مهارت‌های قبلی هنوز معتبرند و کجا باید واقعاً بازآموزی کند. می‌تواند یک نقطه‌ی شروع شواهد-محور برای بازگشت به مهندسی مدرن انتخاب کند.
Returning to Programming After a Few Years: Where Should You Start? — en-US
خلاصهٔ درس
برنامه‌نویس بازگشته نمی‌داند کدام مهارت‌های قبلی هنوز معتبرند و کجا باید واقعاً بازآموزی کند.
می‌تواند یک نقطه‌ی شروع شواهد-محور برای بازگشت به مهندسی مدرن انتخاب کند.
خروجی این درس
می‌تواند یک نقطه‌ی شروع شواهد-محور برای بازگشت به مهندسی مدرن انتخاب کند.
پیش‌نیازها
این درس پیش‌نیازی ندارد؛ نقطه‌ی شروع است.
اگر چند سال از برنامه‌نویسی فاصله گرفته باشی، دو پاسخ وسوسه‌انگیز خیلی زود ظاهر می‌شوند: «همه‌چیز عوض شده، پس باید از صفر شروع کنم» یا «من قبلاً حرفه‌ای بوده‌ام، پس هنوز همان‌قدر آماده‌ام». هر دو پاسخ یک مشکل دارند: به سابقه تکیه می‌کنند، نه به شاهدی که نشان دهد امروز برای یک کار مشخص چه چیزی در اختیار داری.
این درس قرار نیست سابقه‌ات را پاک کند یا به تو مدرک «آماده‌بودن» بدهد. قرار است تجربهٔ قبلی را به قطعات کوچک‌تر و قابل‌بررسی تقسیم کنی: چه چیزی هنوز قابل‌اتکاست، چه چیزی نیاز به بازتنظیم و تمرین دوباره دارد، و چه چیزی واقعاً برای تو جدید است. خروجی درس یک نقشهٔ شواهد بازگشت به برنامه‌نویسی است؛ نقشه‌ای که بتوانی بر اساس آن یک نقطهٔ شروع محدود و قابل‌دفاع انتخاب کنی.
سابقه داری؛ اما سؤال این است که کدام بخش از آن هنوز کار می‌کند
فرض کن سه سال از کار روزمرهٔ کدنویسی فاصله داشته‌ای. هنوز می‌توانی دربارهٔ مدل‌سازی داده، ساختار یک تابع یا منطق خطایابی توضیح بدهی. در عین حال، وقتی با یک مسئلهٔ واقعی روبه‌رو می‌شوی ممکن است بعضی جزئیات از حافظه رفته باشند، بعضی روش‌های کاری به تمرین دوباره نیاز داشته باشند و بعضی موضوع‌ها اصلاً در دورهٔ قبلی کارت وجود نداشته باشند.
اگر همهٔ این‌ها را زیر برچسب «بلدم» یا «بلد نیستم» جمع کنی، نقطهٔ شروع خراب می‌شود. این درس به‌جای برچسب کلی، برای هر مهارت یا کار مشخص چهار چیز می‌خواهد:
- کار فعلی: دقیقاً چه کاری باید بتوانی انجام بدهی؟
- شاهد فعلی: امروز چه چیزی می‌توانی نشان بدهی، نه این‌که چند سال پیش چه عنوانی داشته‌ای؟
- وضعیت: این بخش فعلاً قابل‌اتکاست، نیاز به ترمیم دارد، شکاف جدید است، یا هنوز شاهد کافی نداری؟
- گام بعدی: با همین اطلاعات، منطقی‌ترین نقطهٔ شروع چیست؟
نقشهٔ تو باید یک «مرز ادعا» هم داشته باشد: این تصمیم فقط دربارهٔ همان مهارت و همان شاهد است. یک اجرای خوب در یک کار، آمادگی شغلی یا تسلط بر کل برنامه‌نویسی را ثابت نمی‌کند.
از عنوان شغلی شروع نکن؛ از کار قابل‌سنجش شروع کن
ممکن است قبلاً توسعه‌دهندهٔ ارشد، فریلنسر، مدیر فنی یا برنامه‌نویس یک حوزهٔ خاص بوده باشی. این اطلاعات زمینه می‌دهند، اما پاسخ نهایی نیستند. چیزی که برای شروع دوباره اهمیت دارد این است که تجربهٔ قبلی در یک کار مشخص هنوز به رفتار قابل‌مشاهده تبدیل می‌شود یا نه.
برای مثال، «سال‌ها با پایگاه داده کار کرده‌ام» هنوز معلوم نمی‌کند امروز چه چیزی قابل‌اتکاست. شاید بتوانی یک مدل رابطه‌ای را روشن توضیح بدهی و دربارهٔ کلیدها و وابستگی‌ها استدلال کنی؛ در همان حال، اجرای یک تغییر ساختاری روی یک سامانهٔ واقعی یا مدیریت خطای آن برایت نیاز به تمرین دوباره داشته باشد. این دو وضعیت می‌توانند هم‌زمان درست باشند.
پس واحد تصمیم را کوچک نگه دار: مهارت یا وظیفه، نه هویت حرفه‌ای.
مدل تصمیم: سابقه → کار فعلی → شاهد → وضعیت → نقطهٔ شروع
نقشهٔ شواهد بازگشت به برنامه‌نویسی پنج حلقه دارد.
۱) سابقه: قبلاً با چه چیزی کار کرده‌ای؟
سابقه فقط فهرست فناوری‌ها نیست. بنویس چه نوع مسئله‌ای را حل می‌کردی، چه تصمیم‌هایی می‌گرفتی و چه خروجی‌هایی می‌ساختی. این بخش سرنخ می‌دهد، اما هنوز شاهد فعلی نیست.
۲) کار فعلی: امروز چه توان مشخصی را می‌خواهی بسنجی؟
به‌جای «جاوااسکریپت بلدم؟» سؤال را کوچک‌تر کن: «آیا می‌توانم یک جریان ناهمگام را بخوانم، خطای آن را توضیح بدهم و برای رفتار نامطمئن یک تست مناسب طراحی کنم؟»
هرچه کار دقیق‌تر باشد، تصمیم کمتر به حافظه و اعتمادبه‌نفس وابسته می‌شود.
۳) شاهد: چه چیزی امروز قابل‌بررسی است؟
شاهد می‌تواند یک توضیح دقیق، یک طراحی، یک اصلاح خطا، یک قطعه‌کد کوچک، یک تست، یا دفاع از یک تصمیم باشد. مهم این است که با همان ادعایی که می‌خواهی بسنجی ارتباط داشته باشد.
«قبلاً زیاد انجامش داده‌ام» زمینه است. «الان می‌توانم این مسئله را حل کنم و توضیح بدهم چرا» شاهد قوی‌تری برای توان فعلی است.
۴) وضعیت: با شاهد فعلی در کدام حالت هستی؟
قابل‌اتکا برای این کار: شاهد فعلی نشان می‌دهد می‌توانی همین توان محدود را در سطح موردنیاز به کار ببری. این به معنی تسلط کلی نیست.
نیازمند ترمیم: مدل ذهنی یا بخشی از مهارت باقی مانده، اما اجرای امروز ناپایدار است، خطاهای تکرارشونده داری یا برای تکمیل کار به راهنمایی‌ای وابسته‌ای که باید دوباره تمرین شود.
شکاف جدید: شاهد فعلی نشان می‌دهد توان لازم برای این کار محدود را هنوز در سطح موردنیاز نداری، و سابقهٔ مرتبط هم مدل یا مهارت پایه‌ای قابل‌ترمیمی برای همان کار نشان نمی‌دهد. سابقه فقط کمک می‌کند «ترمیم» را از «یادگیری جدید» جدا کنی؛ اگر هنوز آزمون فعلی مناسبی نداری، وضعیت «شاهد کافی ندارم» است.
شاهد کافی ندارم: هنوز آزمایش مناسبی انجام نداده‌ای. این یک نتیجهٔ معتبر است؛ بهتر از حدس‌زدن است.
۵) نقطهٔ شروع: فقط به اندازهٔ همان وضعیت تصمیم بگیر
اگر یک مهارت برای کار مشخص قابل‌اتکاست، لازم نیست از مقدماتش دوباره عبور کنی؛ می‌توانی زودتر سراغ مسئلهٔ بعدی یا آزمون دشوارتر بروی. اگر نیازمند ترمیم است، تمرین باید همان ضعف را هدف بگیرد. اگر شاهد فعلی نشان می‌دهد با شکاف جدید روبه‌رو هستی، آن بخش را واقعاً یاد بگیر و بعد دوباره شاهد تولید کن. اگر شاهد کافی نداری، نخست یک آزمون کوچک بساز.
این تصمیم «مسیر نهایی تو» را برای همیشه تعیین نمی‌کند. با شاهد تازه می‌تواند تغییر کند.
نقشهٔ شواهد را با یک ردیف واقعی شروع کن
برای هر مهارت یا وظیفه یک ردیف بساز:
| بخش | چیزی که می‌نویسی |
|---|---|
| مهارت/وظیفه | یک توان محدود و قابل‌آزمایش |
| سابقهٔ مرتبط | تجربه‌ای که واقعاً به این کار مربوط است |
| آزمون فعلی | کاری که امروز انجام می‌دهی تا توان را بسنجی |
| شاهد | خروجی یا استدلال قابل‌بررسی |
| وضعیت | قابل‌اتکا / نیازمند ترمیم / شکاف جدید / شاهد ناکافی |
| گام بعدی | عبور، ترمیم هدفمند، یادگیری جدید یا ساخت آزمون بهتر |
| مرز ادعا | این ردیف چه چیزی را ثابت نمی‌کند؟ |
| شرط تغییر | چه شاهدی تصمیم را عوض می‌کند؟ |
دو قانون مهم:
اول، یک مهارت بزرگ را اگر لازم است به چند ردیف تقسیم کن. ممکن است «طراحی مدل داده» قابل‌اتکا باشد اما «اجرای مهاجرت و مدیریت ریسک آن» نیاز به ترمیم داشته باشد.
دوم، وضعیت را از روی شاهد انتخاب کن، نه از روی احساس راحتی. آشنا بودن یک API، دیدن کد مشابه یا به‌خاطرآوردن نحو، به‌تنهایی توان حل مسئله را ثابت نمی‌کند.
چیزی که مانده را نگه دار؛ چیزی که فرسوده شده را دقیق ترمیم کن
بازگشت خوب نه «شروع از صفر» است و نه «عبور از همه‌چیز به خاطر سابقه». هدف این است که هزینهٔ تکرار را پایین بیاوری، بدون این‌که شکاف واقعی را پنهان کنی.
فرض کن هنوز می‌توانی دربارهٔ جداسازی مسئولیت‌ها، ورودی و خروجی یک تابع و مسیر بروز خطا استدلال کنی. این بخش از مدل ذهنی ممکن است منتقل شده باشد. اما اگر در یک مسئلهٔ تازه نتوانی خطا را بازتولید کنی، فرضیه بسازی، شاهد جمع کنی و اصلاح را با تست بررسی کنی، مهارت خطایابی برای آن سطح هنوز «قابل‌اتکا» نیست.
در سمت دیگر، اگر کاری در تجربهٔ قبلی‌ات نبوده، این فقط یک سرنخ است، نه حکم «شکاف جدید». اول یک آزمون فعلی انجام بده. اگر همان حالا توان را نشان دادی، وضعیت می‌تواند «قابل‌اتکا» باشد؛ اگر آزمون نشان داد توان لازم وجود ندارد و پایهٔ قابل‌ترمیمی هم در سابقه نداری، آن‌وقت «شکاف جدید» تصمیم قابل‌دفاع‌تری است.
کمک هوش مصنوعی کجا مجاز است؟
می‌توانی از هوش مصنوعی بخواهی برای آزمون فعلی چند مسئلهٔ نمونه پیشنهاد کند، روی استدلالت ایراد بگیرد یا یک ضدنمونه مطرح کند. اما نباید از آن بخواهی بر اساس چند جمله دربارهٔ سابقه‌ات حکم کند که «تو آماده‌ای» یا «باید از این سطح شروع کنی» و همان حکم را شاهد فرض کنی.
تصمیم نهایی باید به چیزی وصل باشد که خودت بتوانی نشان بدهی یا دفاع کنی.
سه مثال: تجربهٔ قبلی یک چیز واحد نیست
مثال اول: مدل داده مانده، عملیاتش نیاز به بازتنظیم دارد
لیلا چند سال پیش روی سامانه‌های تجاری کار می‌کرد. وقتی یک مسئلهٔ سادهٔ دامنه به او داده می‌شود، می‌تواند موجودیت‌ها، رابطه‌ها و محدودیت‌های اصلی را توضیح بدهد و برای انتخابش دلیل بیاورد. این شاهد خوبی برای بخش مفهومی مدل‌سازی است.
اما وقتی از او خواسته می‌شود برای تغییر ساختار داده در یک سامانهٔ در حال استفاده، ریسک‌ها و راه بازگشت را طراحی کند، پاسخ او بیشتر بر خاطره و حدس تکیه دارد. نتیجهٔ نقشه نباید «پایگاه داده را بلدم» یا «پایگاه داده را فراموش کرده‌ام» باشد. دو ردیف لازم است: مدل‌سازی فعلاً قابل‌اتکاتر است؛ برنامه‌ریزی عملیاتی تغییر ساختار نیاز به ترمیم و شاهد تازه دارد.
مثال دوم: آشنایی با جاوااسکریپت، شاهد توان فعلی نیست
امیر نحو زبان را سریع به یاد می‌آورد و کدهای آشنا را می‌خواند. در یک تمرین تازه، وقتی چند عملیات ناهمگام با مسیرهای خطا ترکیب می‌شوند، علت رفتار را دقیق توضیح نمی‌دهد و تستی که می‌نویسد فقط مسیر موفق را می‌سنجد.
این نتیجه نمی‌گوید «امیر مبتدی است». می‌گوید برای همین توان محدود، آشنایی قدیمی کافی نیست و بخش استدلال دربارهٔ جریان ناهمگام، خطا و آزمون نیاز به ترمیم دارد.
مثال سوم: خطایابی در زمینهٔ تازه
سارا سال‌ها تجربهٔ خطایابی داشته، اما ابزار یا کد این تمرین را قبلاً ندیده است. یک خرابی تازه به او داده می‌شود. او ابتدا رفتار را بازتولید می‌کند، محدودهٔ مسئله را کوچک می‌کند، چند فرضیه را با شاهد رد می‌کند و در پایان اصلاحش را با یک آزمون قابل‌تکرار بررسی می‌کند.
اینجا آشنایی با همان کد یا ابزار موضوع اصلی نیست. الگوی حل مسئله در زمینهٔ تازه تکرار شده است. این شاهد معناداری برای انتقال مهارت خطایابی است؛ با این حال هنوز فقط دربارهٔ همان توان محدود حرف می‌زنیم، نه آمادگی برای هر نوع سامانه یا موقعیت شغلی.
سه میان‌بُر که نقطهٔ شروع را خراب می‌کنند
میان‌بُر اول: «همه‌چیز عوض شده؛ از صفر شروع می‌کنم»
مشکلش فقط اتلاف وقت نیست. وقتی چیزی را که هنوز می‌توانی انجام بدهی دوباره از سطح مقدماتی تکرار می‌کنی، فرصت سنجش مرز واقعی توانت را از دست می‌دهی.
ترمیم: یک کار کوچک اما واقعی انتخاب کن. اگر شاهد کافی داری، آن بخش را نگه دار و سطح بعدی را بسنج.
میان‌بُر دوم: «قبلاً حرفه‌ای بودم؛ پس هنوز بلدم»
سابقه ارزش دارد، اما به‌تنهایی شاهد فعلی نیست. حافظه می‌تواند بخش‌هایی از مدل ذهنی را نگه دارد و در عین حال اجرای دقیق فرسوده شده باشد.
ترمیم: برای ادعای موردنظر یک آزمون فعلی تعریف کن. تصمیم را بعد از دیدن خروجی بگیر.
میان‌بُر سوم: «فقط فناوری‌های جدید را فهرست می‌کنم»
فهرست ابزارها به‌سرعت تبدیل به مسابقهٔ نام‌ها می‌شود و به تو نمی‌گوید کدام توان مهندسی منتقل شده و کدام شکاف واقعاً مهم است.
ترمیم: از کار و توان شروع کن؛ فناوری فقط وقتی وارد نقشه شود که برای همان کار لازم است.
اگر سابقه‌ات قوی است، سطح آزمون را بالا ببر؛ نه این‌که آزمون را حذف کنی
برای یک برنامه‌نویس باتجربه، تمرین‌های مقدماتی ممکن است شاهد کمی تولید کنند. راه‌حل این نیست که بدون سنجش عبور کنی. راه‌حل این است که آزمون را فشرده‌تر و واقعی‌تر کنی.
به‌جای پنج تمرین نحوی، یک مسئلهٔ کوچک با ابهام، خطا یا محدودیت طراحی کن. به‌جای تعریف یک مفهوم، از خودت بخواه انتخابت را در برابر یک گزینهٔ دیگر دفاع کنی. به‌جای تکرار کدی که قبلاً دیده‌ای، همان مهارت را در زمینه‌ای تازه به کار ببر.
اگر موفق شدی، شاهد قوی‌تری برای عبور داری. اگر نشد، نقطهٔ ترمیم هم دقیق‌تر شده است.
نقطهٔ شروع می‌تواند برای مهارت‌های مختلف متفاوت باشد
لازم نیست یک برچسب واحد روی کل خودت بگذاری. ممکن است در یک هفته به این نتیجه برسی:
- طراحی سادهٔ داده: فعلاً قابل‌اتکا؛
- تست‌نویسی برای خطاهای پیچیده: نیازمند ترمیم؛
- یک موضوع معماری که قبلاً با آن کار نکرده‌ای، آزمون فعلی هم نبودن توان لازم را نشان می‌دهد و پایهٔ قابل‌ترمیمی در سابقه نداری: شکاف جدید؛
- استقرار یک سرویس: شاهد کافی ندارم و باید یک آزمون کوچک بسازم.
این ناهمگونی طبیعی است. نقشهٔ خوب دقیقاً برای دیدن همین تفاوت‌هاست.
نقشهٔ خودت را بساز؛ بعد یک ردیف را در زمینه‌ای تازه دوباره بسنج
دور اول: یک مهارت قدیمی را انتخاب کن
مهارتی را انتخاب کن که درباره‌اش نه کاملاً مطمئن هستی و نه کاملاً بی‌اطلاع. آن را به یک کار قابل‌آزمایش تبدیل کن.
مثال نامناسب: «بک‌اند».
مثال بهتر: «می‌توانم برای یک API کوچک، رفتار خطا را مشخص کنم و برای دو حالت شکست تست بنویسم.»
دور دوم: آزمون فعلی بساز
آزمون باید آن‌قدر کوچک باشد که بتوانی انجامش بدهی، اما آن‌قدر واقعی باشد که صرف آشنایی را پنهان نکند. پیش از شروع بنویس چه چیزی را به‌عنوان شاهد می‌پذیری.
دور سوم: وضعیت و گام بعدی را ثبت کن
فقط یکی از این‌ها را انتخاب نکن چون خوشایندتر است. دلیل را کنار وضعیت بنویس:
- قابل‌اتکا برای این کار؛
- نیازمند ترمیم؛
- شکاف جدید؛
- شاهد ناکافی.
برای «شکاف جدید»، نداشتن سابقه به‌تنهایی کافی نیست: آزمون فعلی باید نبودن توان لازم را نشان دهد و سابقهٔ مرتبط نیز پایهٔ قابل‌ترمیمی نشان ندهد. اگر هنوز آزمون مناسبی نداری، «شاهد ناکافی» را انتخاب کن.
سپس یک گام بعدی مشخص بنویس.
دور چهارم: آزمون «زمینهٔ تغییرکرده»
برای همان مهارت، مسئله‌ای بساز که ظاهرش با تجربهٔ قدیمی‌ات فرق دارد اما توان اصلی را هنوز لازم دارد. اگر فقط با دیدن نشانه‌های آشنا موفق می‌شوی، شاید چیزی که مانده «آشنایی» باشد نه «توان قابل‌انتقال».
اگر در زمینهٔ تازه هم بتوانی مسئله را تحلیل کنی، تصمیم بگیری و شاهد تولید کنی، نقشه‌ات دلیل قوی‌تری برای قابل‌اتکا بودن آن مهارت دارد. این آزمون هم به‌تنهایی تسلط کلی را ثابت نمی‌کند.
یک نقشهٔ قابل‌دفاع چه ویژگی‌هایی دارد؟
قبل از قبول نتیجه، چهار سؤال بپرس:
- آیا واحد تصمیم یک مهارت یا وظیفهٔ مشخص است، نه یک عنوان کلی؟
- آیا وضعیت از شاهد فعلی آمده، نه فقط سابقه یا احساس؟
- آیا گام بعدی متناسب با همان وضعیت است؟
- آیا مرز ادعا و شرط تغییر تصمیم نوشته شده‌اند؟
اگر پاسخ یکی از این‌ها «نه» است، نقشه هنوز برای انتخاب نقطهٔ شروع کافی نیست.
ارزیابی اصلی: همان روش را با کمک کمتر تکرار کن
در ارزیابی نهایی، یک مورد تازه می‌گیری که سابقهٔ قدیمی و توان فعلی در آن کاملاً هم‌راستا نیستند. باید تشخیص بدهی چه چیزی باقی مانده، چه چیزی به ترمیم نیاز دارد، چه چیزی جدید است و کجا هنوز شاهد کافی نداری. سپس یک نقطهٔ شروع محدود انتخاب می‌کنی و می‌نویسی چه شاهدی می‌تواند این تصمیم را عوض کند.
بخش انتقال مهم‌تر از حفظ نام چهار وضعیت است. اگر بتوانی مدل را در یک زمینهٔ تازه بازسازی کنی، نشان داده‌ای که روش تصمیم را فهمیده‌ای؛ نه این‌که کل مهارت فنی را اثبات کرده باشی.
چرا این درس فهرست «فناوری‌های منسوخ و جدید» نمی‌دهد؟
هدف درس ساختن یک روش پایدار برای سنجش بازگشت است، نه نگهداری فهرستی که با تغییر ابزارها قدیمی شود. برای انتخاب نقطهٔ شروع، سن یک فناوری به‌تنهایی تعیین‌کننده نیست؛ همان کار محدود را با یک آزمون فعلی و شاهد قابل‌بررسی بسنج. اگر ابزار یا قابلیت مشخصی برای کارت مهم است، آن را به‌عنوان یک ردیف جدا در نقشه قرار بده و توان فعلی‌ات را برای همان کار بررسی کن.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
چرا عنوان شغلی یا تعداد سال‌های سابقه به‌تنهایی برای انتخاب نقطهٔ شروع کافی نیست؟
Q2 application
فردی هنوز می‌تواند یک مدل رابطه‌ای را خوب توضیح دهد، اما برای طراحی یک تغییر ساختاری روی سامانهٔ در حال استفاده فقط به خاطره و حدس تکیه می‌کند. دو ردیف مناسب برای نقشهٔ شواهد او بساز و برای هرکدام وضعیت و گام بعدی را بنویس.
Q3 diagnosis
این استدلال را عیب‌یابی کن: «قبلاً توسعه‌دهندهٔ ارشد بودم، پس تست‌نویسی را لازم نیست دوباره بسنجیم.»
Q4 decision
برای یک مهارت قدیمی خودت، یک ردیف کامل نقشهٔ شواهد بنویس: کار، سابقهٔ مرتبط، آزمون فعلی، شاهد، وضعیت، گام بعدی، مرز ادعا و شرط تغییر تصمیم.
Q5 transfer
برای همان مهارت، یک مسئلهٔ زمینهٔ تغییرکرده طراحی کن که نشانه‌های آشنای قبلی را حذف کند اما توان زیربنایی را همچنان لازم داشته باشد. بگو چه نتیجه‌ای باعث می‌شود وضعیت نقشه را حفظ یا تغییر دهی.
ملاک‌های ارزیابی (rubric)
Critical dimensions
1. Decision and scope correctness — critical
Sufficient work makes a decision about a bounded skill/task rather than a global identity label. The state and next step do not claim more than the lesson supports.
2. Evidence adequacy — critical
The learner names inspectable current evidence that is relevant to the exact task. Past title, confidence, familiarity, or an AI verdict cannot substitute for evidence.
3. Non-claim honesty — critical
The artifact states at least one explicit claim boundary: what the current row does not prove.
4. Transfer — critical
The changed-context task preserves the underlying capability while changing surface cues. The learner explains what evidence would keep or change the state.
Blocking failure conditions
- a re-entry state with no supporting evidence;
- whole-person beginner/advanced classification from a single row;
- past history treated as sufficient proof of current capability;
- AI output treated as the final authority;
- transfer task is only a renamed copy of the original;
- claim boundary or update condition is missing in a blocking artifact.
Human decision policy
AI may suggest probes, counterexamples, or critique. The learner remains responsible for the final bounded state and next step.
What passing does not prove
Passing this lesson does not prove technical programming mastery, job readiness, or whole-program mastery.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
جریان تصمیم از سابقه به کار فعلی، آزمون، شاهد، وضعیت و گام بعدی؛ همراه با مرز ادعا و شرط تغییر تصمیم.
How do prior experience, a current probe, and evidence lead to a bounded re-entry state?
نمونهٔ نقشه‌ای که چهار مهارت را جداگانه در وضعیت قابل‌اتکا، نیازمند ترمیم، شکاف جدید و شاهد ناکافی نشان می‌دهد.
How can one returning programmer have different states across different skills?
اسکریپت ویدیوی اختیاری
بعد از چند سال فاصله، اولین سؤال این نیست که «من هنوز حرفه‌ای هستم یا نه؟». سؤال بهتر این است: «برای این کار مشخص، امروز چه شاهدی دارم؟»
یک مهارت بزرگ مثل «پایگاه داده» را به چند کار تقسیم کن. ممکن است مدل‌سازی داده هنوز قابل‌اتکا باشد، اما برنامه‌ریزی یک تغییر ساختاری در سامانهٔ در حال استفاده نیاز به ترمیم داشته باشد. این تناقض نیست؛ نقشه دقیق‌تر شده است.
برای هر ردیف، کار فعلی، آزمون، شاهد، وضعیت، گام بعدی، مرز ادعا و شرط تغییر تصمیم را بنویس. اگر شاهد نداری، حدس نزن؛ وضعیت «شاهد کافی ندارم» معتبر است.
در پایان، یکی از مهارت‌های قدیمی را در زمینه‌ای تازه امتحان کن. اگر توان اصلی بدون نشانه‌های آشنای قبلی هم ظاهر شد، شاهد بهتری برای انتقال مهارت داری. با این حال، همان شاهد فقط دربارهٔ همان توان محدود حرف می‌زند.
واژه‌نامهٔ رسمی درس
| Term | Policy | Boundary |
|---|---|---|
Return-to-Programming Evidence Map | در نثر فارسی «نقشهٔ شواهد بازگشت به برنامه‌نویسی» استفاده شود. | A bounded decision artifact, not a mastery certificate. |
Reliable for this task | «قابل‌اتکا برای این کار»؛ از «کاملاً مسلط» استفاده نشود. | Supported only for the tested task and evidence. |
Needs repair | «نیازمند ترمیم» برای مهارتی که بخشی از مدل/توان مانده اما اجرای فعلی به بازسازی هدفمند نیاز دارد. | Task-level repair need, not global learner classification. |
New gap | «شکاف جدید»؛ فقط وقتی شاهد فعلی نشان می‌دهد توان لازم برای کار محدود هنوز در سطح موردنیاز وجود ندارد و سابقهٔ مرتبط نیز پایهٔ قابل‌ترمیمی نشان نمی‌دهد. | History is context, not sufficient evidence. No suitable current probe means Not enough evidence; a successful current probe may support Reliable even without prior experience. |
Not enough evidence | «شاهد کافی ندارم» یا «هنوز شاهد کافی ندارم»؛ عدم قطعیت نتیجهٔ معتبر است. | Defers judgment until a better probe exists. |
Claim boundary | «مرز ادعا»؛ مشخص می‌کند یک ردیف چه چیزی را ثابت نمی‌کند. | Prevents evidence from being inflated into broad mastery. |
Update condition | «شرط تغییر تصمیم»؛ شاهدی که با دیدنش وضعیت یا گام بعدی باید بازنگری شود. | Revisability, not instability. |
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)