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

از شاگردی تا استادی

#استخدام

☑️ توسعه دهنده دات نت
✅ داتکس (داده پردازان تدبیر سرمایه) (تهران)

💬 شرایط:
- آشنایی خوب با C Sharp و NET Core
- تجربه کار با Web API
- آشنایی با SQL Server و T SQL
- درک ساختارهای نرم افزاری + کار تیمی
- امتیاز: Git، معماری چندلایه، RESTful
- مسئولیت پذیر، منظم، دقیق + علاقه مند به یادگیری و چالش

🏅چرا اینجا؟
- حقوق توافقی + کار روی پروژه های جدی بازار سرمایه
- فرصت یادگیری، تعامل و پیشرفت در تیم حرفهای
- ارائه وعده صبحانه و ناهار
- پرداخت های مناسبتی
- اتاق بازی

📧 info@datxsoft.com
🏣 Datxsoft
🔗 LinkedIn

نگاهی به ذهن یک طراح

🔗 YouTube

#ویدئو_کدنویس

نقل‌قول آغازین کتاب الگو های کارآموزی

کسی که نمی‌داند و نمی‌داند که نمی‌داند، احمق است — از او دوری کن...

این نقل‌قول پایهٔ فلسفهٔ کتاب را می‌گذارد:
خودآگاهی نسبت به دانسته‌ها و نادانسته‌ها، تفاوت بین شاگرد واقعی و مدعیِ دانایی است.
شاگرد باید بداند که نمی‌داند — این نقطهٔ شروع رشد است.

مقدمه - الگوهای کارآموزی

شاگردی تأثیرگذار است، زیرا در انسان اشتیاقی مادام‌العمر برای تسلط بر هنر می‌کارد. این اشتیاق به یادگیری پیوسته، شاگرد را در مسیر تبدیل‌شدن به یک توسعه‌دهنده‌ی بزرگ قرار می‌دهد. — پیت مک‌بریـن

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

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

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

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

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

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

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

فکر می‌کنم شاگرد بودن یعنی این نگرش که همیشه راهی بهتر، هوشمندانه‌تر و سریع‌تر برای انجام کاری که کردی وجود دارد. — مارتن گوستافسون

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

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

در نهایت، شاگردی فقط درباره‌ی syntax و ابزار نیست؛ درباره‌ی یاد گرفتن حرفه‌ای بودن است، درباره‌ی شبیه شدن به کسانی که کدنویسی را مثل یک هنر زندگی می‌کنند.

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

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

فصل اول - الگوهای کارآموزی

🚀 برنامه‌نویس‌های Visual Studio! وقتشه یک لول برید بالاتر با AI

اگه هنوز داری کل کدت رو خودت می‌نویسی، خطاها رو خودت پیدا می‌کنی و تازه برای فهمیدن کدهای پروژه‌های جدید وقت می‌ذاری… باید بگم یک دنیا عقب موندی! 😅

امروز می‌خوام چیزی رو بهت معرفی کنم که برنامه‌نویسی با ویژوال استودیو رو به شکل دیوونه‌کننده‌ای سریع‌تر، تمیزتر و لذت‌بخش‌تر می‌کنه:
GitHub Copilot + Visual Studio 🤖🔥

با کوپایلت می‌تونی:
✅ کد رو به جای خودت بنویسه
✅ خطاها رو پیدا کنه و رفع کنه
✅ پیش‌بینی کد و تکمیل هوشمند داشته باشه
✅ کد پروژه جدید رو توضیح بده تا منطق و بیزنسش رو سریع بفهمی

🛠 چطور فعالش کنیم؟ (خیلی ساده!)
1️⃣ آخرین نسخه Visual Studio رو نصب یا آپدیت کن
→ موقع نصب، تو بخش Individual Components تیک GitHub Copilot رو بزن ✅

2️⃣ بعد از نصب، بالای ویژوال استودیو آیکن Copilot ظاهر می‌شه

3️⃣ وارد اکانت گیت‌هابت شو
→ بخش Settings > Copilot
→ دسترسی‌ها رو ALL ALLOW کن

4️⃣ برگرد به ویژوال استودیو و Sign in with GitHub Copilot
→ Continue → Done! 😎

5️⃣ از منوی View → GitHub Copilot Chat
→ حالا می‌تونی مثل ChatGPT باهاش حرف بزنی، کد بخوای، خطا بپرسی و حتی ریفکتورهای حرفه‌ای بگیری!

و نکته‌ی خفن‌تر:
✨ وقتی حالت Agent فعاله، خودش اتومات فایل می‌سازه، کد تولید می‌کنه، اصلاح می‌کنه و برنامه رو جلو می‌بره!
✨ روی کد راست‌کلیک کن → Ask Copilot → مستقیم همون‌جا ادیت، تولید کد یا رفع خطا 🔥

👇 یک جمله مهم
اگه برنامه‌نویس Visual Studio هستی و Copilot استفاده نمی‌کنی، داری ۳ تا ۵ برابر بیشتر وقت هدر می‌دی.

🔗 LinkedIn

ترجمه فارسی کتاب The Linux Command Line بالاخره کامل شد. این پروژه یک فورک از ریپوی اصلی بود و من همراه با یکی از دوستانم روی تکمیل ترجمه و ویرایش نهایی کار کردیم.

این کتاب یکی از منابع معتبر برای یادگیری ترمینال و دستورهای لینوکس به‌صورت کاربردی و قدم‌به‌قدم است.

نسخه کامل ترجمه، به‌صورت رایگان و متن‌باز از طریق لینک زیر در دسترس است:

https://github.com/hheydarian/TLCL-Persian

اگر این پروژه براتون مفید بود، خوشحال می‌شم با ⭐️ دادن، ازش حمایت کنید.

فصل دوم - الگو های کارآموزی

خالی کردن فنجان

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

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

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

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

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

خالی کردن فنجان فقط درباره‌ی تکنیک نیست؛ درباره‌ی نگرش است. نگرشی که می‌گوید:

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

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

در نهایت، پیام این فصل ساده اما قدرتمند است:
ذهنی که پر است، یاد نمی‌گیرد.
ذهنی که باز است، رشد می‌کند.

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

کیانوش مختاریان
مدیر و رهبر فنی سابق در گوگل

فرق کار تو گوگل و ایران چیه؟
همه رفتند ولی اون برگشته به ایران ...

#ویدئو_کدنویس

🔗 YouTube

۱۵۰ سوال برای آماده شدن در مصاحبه NET.

هر سؤال طوری طراحی شده که بهت کمک کنه درک واقعی‌تری از نحوه کار سیستم‌ها پیدا کنی—نه اینکه فقط برای مباحث تئوری آماده بشی.
فرقی نمی‌کنه هدف‌ت موقعیت جونیور، میدل یا سینیور باشه؛ این مجموعه بهت وضوح و اعتمادبه‌نفس لازم برای قبولی در مصاحبه‌ها رو می‌ده.

#استخدام

☑️ برنامه_نویس بک اند
✅ پرتو بیتا (تهران)

💬 شرایط:
- تسلط به NET 7+، Clean Architecture، DDD، CQRS
- رعایت Clean Code + استانداردهای کدنویسی
- رویکرد TDD و Unit Test و Integration Test
- کار با Git و TFS Board.
- مهارت Test Automation، Automated Build، Deploy
- تحلیل و رفع باگها

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

📧https://lnkd.in/dUx2HMVK
🔗 LinkedIn

فصل سوم - الگوهای کارآموزی

پیمودن راه طولانی

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

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

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

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

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

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

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

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

🎲7 بازی SQL که حسابی مهارت‌های تحلیل داده رو تقویت میکنه!


👨🏻💻 یکی از سخت‌ترین بخش‌های یادگیری SQL اینه که ساعت‌ها بشینی پای ویدئوهای آموزشی و یه عالمه آموزش تئوری ببینی. حوصله ات از آموزش‌های خشک و خالی سر میره مگه نه؟


💻 ولی اگه بشه با بازی کردن SQL رو یاد گرفت چی؟ اینجا ۷ تا بازی SQL رو معرفی می‌کردم که به نظرم هم سرگرم‌کننده هستن و هم یه جور تمرین حرفه‌ای برای تقویت مهارتهای SQL.


1️⃣ بازی SQL Island
https://lnkd.in/eEvx-Wgd
🤳 تصور کنین توی یه جزیره ناشناخته گیر افتادین! با استفاده از مهارت‌های SQL باید راه نجات خودتون رو پیدا کنین. ترکیب چالش و ماجراجویی، اونم توی دنیای SQL!


2️⃣ بازی SQL Murder Mystery
https://lnkd.in/e2pb9XEc
🤳 فرض کنید یه قتل توی شهر SQL اتفاق افتاده! حالا باید از دانش SQL استفاده کنین تا سرنخ‌ها رو کنار هم بذارین و قاتل رو پیدا کنید. جذابتر از این؟


3️⃣ بازی Lost at SQL
https://lnkd.in/eypHVzXH
🤳 تو یه دنیای پر از چالش‌های SQL گم شدین! باید معماها رو حل کنین تا به سطح بعدی برین.


4️⃣ بازی SQL Police Department
https://sqlpd.com/
🤳 اینجا شما به تیم پلیس SQL می‌پیوندین. قراره پرونده‌های مختلف رو حل کنین و همزمان کلی نکته جدید درباره SQL یاد بگیرین. یه تجربه هیجان‌انگیز و آموزنده!


5️⃣ بازی Querymon
https://lnkd.in/eiRv6riG
🤳 اگه تازه کارین و میخواین SQL رو از پایه یاد بگیرین، این بازی بهترین نقطهی شروعه!


6️⃣ بازی Schemaverse
https://schemaverse.com/
🤳 این یکی یه بازی استراتژی فضاییه که توی PostgreSQL پیاده شده. با دستورات خام SQL به ناوگان فضایی تون فرمان بدین و توی یه رقابت آنلاین، دیگران رو شکست بدین.


7️⃣ بازی CodinGame
https://lnkd.in/eQCUCtYQ
🤳 تمرین SQL همراه با چالشهای برنامه‌نویسی جذاب، توی یه پلتفرم که کلی زبان دیگه رو هم ساپورت میکنه.

🔗 LinkedIn

یکی از تصمیم‌های کلیدی در کار با زمان در ‎.NET، انتخاب بین DateTimeOffset.Now و DateTimeOffset.UtcNow هست. یک انتخاب اشتباه اینجا می‌تونه باعث باگ‌های پیچیده‌ای بشه که فقط در Time Zone های خاصی خودشون رو نشون میدن.

خلاصه تفاوت این دو:
DateTimeOffset.Now
زمان محلی سیستمی که کد روش اجرا میشه رو برمی‌گردونه. این مقدار کاملاً به Time Zone سرور یا کامپیوتر کاربر وابسته است.

DateTimeOffset.UtcNow
زمان جهانی (UTC) رو با Offset صفر (+00:00) برمی‌گردونه. این مقدار هیچ وابستگی به تنظیمات محلی نداره و برای همه در یک لحظه، یکسان و ثابته.

اصل کلی اینه: "با UTC ذخیره کن، با زمان محلی نمایش بده."
همیشه برای ثبت زمان در دیتابیس، لاگ‌ها یا هر نوع Storage دیگه‌ای، از DateTimeOffset.UtcNow استفاده کنید. این کار یک (Source of Truth) بدون ابهام و قابل مقایسه ایجاد می‌کنه.
نمایش زمان به کاربر نهایی باید در لایه UI و بر اساس Time Zone خود کاربر انجام بشه.
این رویکرد ساده، جلوی بسیاری از مشکلات در سیستم‌های توزیع‌شده (Distributed Systems) رو می‌گیره.

کارآموزی بریم یا نه؟

#ویدئو_کدنویس
🔗 YouTube

فصل چهارم - الگوهای کارآموزی

ارزیابی دقیق خود

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

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

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

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

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

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

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

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

همیشه تیمی را پیدا کن که در آن بتوانی دوباره شاگرد باشی.

معیار واقعی کیفیت نرم‌افزار: WTF در ساعت

روش های زیادی برای سنجیدن کیفیت نرمافزار وجود داره — از code coverage تا پیچیدگی و ابزارهای مختلف تحلیل.
اما یک معیار ساده همیشه دقیقتر از بقیه بوده:

WTF/H — «چند بار در ساعت میگی این دیگه چی بود؟»

یعنی چند بار وسط خوندن کد مکث میکنی و با خودت میگی «چی شد؟!»

همین معیار ساده خیلی چیزها درباره‌ی کیفیت کد و فرهنگ تیم مشخص میکنه:

WTF/H پایین:
ساختار مشخص، نام‌گذاری درست، رفتار قابل پیش‌بینی و تست‌های قابل اعتماد.
اینجا میتونی راحت فکر کنی و مشکل حل کنی.

WTF/H متوسط:
کد کار میکنه، اما فهمیدنش زمان میبره.
ترکیبی از تصمیم‌های قدیمی و میان‌برهای که هنوز موندن.

WTF/H بالا:
فانکشن‌های طولانی، منطق نامشخص، تغییرات پرریسک.
هر تغییری میتونه مشکل درست کنه.


در نهایت کیفیت نرم‌افزار فقط به ابزار و استانداردها ربط نداره؛
به این ربط داره که مهندس بعدی چقدر راحت بتونه کد رو بخونه.

هرچه WTF/H کمتر باشه، توسعه سریع‌تر و تیم خوشحال تر.

🔗 LinkedIn