مهندس شدن با تصمیم شروع میشه، نه با کدنویسی!

یکی اینطوریه که بمونه توی یه شرکت و با چالش های واقعی درگیر بشه،
مدل اون یکی اینه که بیرون، خودش مسیر یادگیری و رشدش رو بسازه.

اگه یادگیری هدفی باشه از مسیر مهندسی، یادگیری واقعی کجا اتفاق میوفته!؟

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

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

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

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

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

میدونیم هر دوش در نوع خودش تجربه هایی برای هر فرد و شرکت می تونه به ارمغان بیاره.

به‌نظر شما تجربه واقعی تر که منجر به این بشه که سریعتر در این مسیر مهندسی به نتیجه قابل قبولی رسید کجاست؟
(قابل قبول: مهندسی که بتونه از پسِ مسائل یک پروژه بر بیاد و در زمان ممکن به انجام برسونه در عین حال زمان برای زندگی کردن خودش داره و اون رو هم مدیریت میکنه)

◽ وقتی وسط فشار پروژه و تیم تصمیم میگیری؟
◽ یا وقتی تنها، با علاقه ت میسازی و یاد میگیری؟
◽ !؟
(هرکسی یه مدل رشد داره، ولی تجربه شنیدنش همیشه کمک میکنه دید بازتری داشته باشیم.)

🔗 LinkedIn

هالووین در گیت هاب 🎃

#استخدام
ما در شرکت سازه‌های هوشمند داده‌بنیان کارو در حال توسعه‌ی یک نرم‌افزار مالی/حسابداری تحت وب هستیم و به دنبال برنامه‌نویس بک‌اند (.NET 8 / C#) با مهارت‌های زیر هستیم

🔹 مهارت های مورد نیاز:
ASP .NET Core 8 / C# 11-12
Entity Framework Core 8
SQL Server
REST API، JWT Auth، Git / GitFlow



✨ مهارت‌های امتیازی:
Unit Testing، Docker، Redis، RabbitMQ، CI/CD، Azure/AWS, Clean Architecture، DDD، Design Patterns

شرایط همکاری:
• نوع همکاری: تمام‌وقت (ساعت ۸:۳۰ تا ۱۶:۳۰)
• محل کار: سمنان یا تهران (امکان همکاری دورکار برای نیروهای توانمند - به شرط فعالیت و دردسترس بودن طی ساعات کاری مشخص شده - وجود دارد)
• حقوق: توافقی بر اساس سطح توانایی
• زمان کاری: شنبه تا چهارشنبه / پنجشنبه ها یک هفته درمیان

لطفاً رزومه خود را با عنوان «Backend Developer – [سطح مهارت شما]» به @ryhnjhr79 ارسال کنید.
در صورت تمایل، لینک GitHub یا نمونه پروژه‌های خود را نیز ضمیمه نمایید

بزرگترین دروغ این روزهای بازار کار برنامه‌نویسی

🔗 YouTube

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

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

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

از میان این همه رزومه… واقعاً کی به مصاحبه می‌رسه؟

واقعیت اینه:
تو استخدام فنی دنبال «بهترین رزومه» نیستیم، دنبال بهترین فیت برای تیمیم.
و خیلی‌ها نه به خاطر مهارت کم، بلکه به خاطر ارائه‌ی اشتباه رد می‌شن.

اینجوری رزومه‌ها رو غربال می‌کنم:

• مرحله اول: ۳۰ ثانیه تصمیم‌گیری
🛑 رد فوری اگر:
- تکنولوژی‌های اصلی Job Denoscription نیست
- رزومه عمومی و کپی‌پیست برای همه پوزیشن‌ها
- لینک‌ها باز نمی‌شن (یه 404 = بی‌دقتی)
- غلط املایی و فرمت شلخته
- رزومه ۵ صفحه‌ای با اطلاعات نامرتبط
- بات برای پر کردن GitHub = رد سریع

✅ ادامه می‌دم اگر:
- حداقل ۶۰٪ match با JD
- رزومه شخصی‌سازی‌شده برای ما
- لینک‌ها سالم و قابل بررسی
- خوانا، خلاصه و مرتب

• مرحله دوم: ۲–۳ دقیقه بررسی عمیق‌تر
✔️ تجربه کاری (اولویت اصلی)
- ثبات شغلی؟ مشروع و منطقی؟
- پروژه‌ها مرتبط؟
- شرح وظایف و تأثیر واقعی؟

✔️ Tech Stack
- واقعاً باهاش کار کرده یا فقط لیست کرده؟
- توضیح پروژه‌محور؟ (نه فقط نام تکنولوژی)

✔️ LinkedIn
- پروفایل زنده و حرفه‌ای؟
- تاریخ‌ها با رزومه همخوان؟

✔️ GitHub / Portfolio
- پروژه واقعی و قابل اجرا؟
- کامیت‌های طبیعی و منظم (نه ۱۰۰ کامیت در یه روز 😅)

🎯 چه کسی دعوت می‌شه؟
✔ رزومه مخصوص همین موقعیت
✔ پروژه واقعی با لینک و نتیجه
✔ پروفایل لینکدین مرتب و واقعی

❌ چه کسی رد می‌شه؟
- اغراق («expert در همه‌چیز» 😎)
- لینک‌های خراب
- تناقض رزومه و LinkedIn
- پروژه مصنوعی برای پر کردن رزومه

🎁 نکته مهم برای کارجوها

👶 Junior:
۳ پروژه واقعی > ۱۰۰ کامیت بی‌معنی

🧑💻 Mid/Senior:
ارزش واقعی = تجربه، حل مسئله، تأثیر کاری

GitHub داشتن خوبه؛ ولی همه‌چیز نیست.

✅ چک‌لیست قبل از ارسال رزومه
☑ رزومه مخصوص این آگهیه؟
☑ لینک‌ها سالم‌اند؟
☑ تکنولوژی‌های JD برجسته شد؟
☑ < ۲ صفحه و خواناست؟
☑ لینکدین آپدیت؟
☑ حداقل ۲ پروژه واقعی؟


من دنبال آدم کامل نیستم…
دنبال آدم واقعی، دقیق و مسئولم.

🔗 LinkedIn

۱۰ کتابی که شما را به یک مهندس نرم‌افزار و معمار ۱۰ برابر بهتر تبدیل می‌کنند:

۱. برنامه‌نویس عمل‌گرا (Andy Hunt & Dave Thomas)
- درس‌های کاربردی برای تمام مراحل مسیر شغلی.
- آموزش سازگاری، کنجکاوی و یادگیری مداوم.

۲. کدنویس پاک (Robert C. Martin)
- یادگیری حرفه‌ای‌گری، انضباط و مسئولیت‌پذیری.
- یک توسعه‌دهنده عالی بودن فقط به نوشتن کد نیست — نگرش هم مهم است.

۳. الگوهای طراحی به روش Head First (Eric Freeman & Elisabeth Robson)
- روشی سرگرم‌کننده و تصویری برای یادگیری الگوهای طراحی.
- بالاخره می‌فهمید این الگوها در پروژه‌های واقعی چطور کار می‌کنند.

۴. معماری نرم‌افزار به روش Head First (Raju Gandhi, Mark Richards, Neal Ford)
- راهنمایی دوستانه و عملی برای معمارانه فکر کردن.
- عالی برای توسعه‌دهندگانی که می‌خواهند وارد دنیای معماری شوند.

۵. ساخت معماری‌های تکاملی (Neal Ford, Rebecca Parsons, Patrick Kua)
- یاد بگیرید سیستم‌هایی طراحی کنید که با زمان رشد و تغییر کنند.
- تغییر همیشگی است — این کتاب به شما می‌آموزد چطور با آن کنار بیایید.

۶. الگوهای معماری سازمانی (Martin Fowler)
- درک نحوه ساختاردهی و اتصال سیستم‌های بزرگ.
- مناسب برای پروژه‌های سازمانی یا بلندمدت و در مقیاس وسیع.

۷. طراحی اپلیکیشن‌های داده‌محور (Martin Kleppmann)
- مطالعه‌ای ضروری برای طراحی سیستم‌های مدرن.
- پایگاه‌داده‌ها، مقیاس‌پذیری و پردازش داده را به زبانی ساده توضیح می‌دهد.

۸. طراحی دامنه‌محور (Eric Evans)
- یادگیری مدل‌سازی منطق پیچیده کسب‌وکار با سادگی.
- دیدگاه شما را در گفتگو با توسعه‌دهندگان و مدیران تغییر می‌دهد.

۹. ساخت میکروسرویس‌ها (Sam Newman)
- راهنمای کامل برای ایجاد سیستم‌های توزیع‌شده.
- پر از درس‌های عملی و مصالحه‌های دنیای واقعی.

۱۰. الگوهای معماری نرم‌افزار سازمانی (Martin Fowler)
- مرجع کلاسیک برای حل مشکلات رایج طراحی.
- وقتی آن را بخوانید، این الگوها را همه‌جا خواهید دید.

▶️ نکته حرفه‌ای:
فقط این کتاب‌ها را نخوانید.
از هر کتاب یک ایده را در پروژه بعدی‌تان به کار ببرید — این همان جایی است که رشد واقعی اتفاق می‌افتد.

این کتاب‌ها برنامه‌نویس‌ها را به متفکران،
و مهندسان را به معماران تبدیل می‌کنند.

🔗 LinkedIn

۱۰ راز که توسعه‌دهنده‌های ارشد برای ساخت کنترلرهای ۱۰ برابر بهتر استفاده می‌کنن — و توسعه‌دهنده‌های میانی و تازه‌کار ازش بی‌خبرن

چی هستن این رازها؟ 👇

۱. کنترلرها رو باریک نگه دار
- کنترلر جای منطق تجاری نیست.
- فقط باید مسئول دریافت درخواست و ارسال پاسخ باشه.
- منطق رو منتقل کن به سرویس‌ها یا لایه‌ی اپلیکیشن تا کد تمیز و قابل تست بمونه.

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

۳. برای مدیریت خطاها از ProblemDetails استفاده کن
- مدل‌های خطای سفارشی رو کنار بذار.
- از ProblemDetails استفاده کن — فرمت استاندارد و داخلی برای خطاهای API.
- پاسخ‌های خطا رو منسجم و قابل فهم می‌کنه.

۴. از کنوانسیون‌های [ApiController] بهره ببر
- از [ApiController] استفاده کن — اعتبارسنجی مدل، بایند کردن داده‌ها و تولید پاسخ رو خودش انجام می‌ده.
- کدهای تکراری کمتر، کد تمیزتر بیشتر.

۵. برای دغدغه‌های مشترک از فیلترها استفاده کن
- لاگ‌گیری، اعتبارسنجی یا مدیریت خطا رو توی هر کنترلر تکرار نکن.
- از فیلترهایی مثل ActionFilter یا ExceptionFilter استفاده کن تا این موارد رو به‌صورت سراسری مدیریت کنی.

۶. از محدودیت‌ها و الگوهای مسیر استفاده کن
- محدودیت‌هایی مثل {id:int} یا {slug:alpha} رو به مسیرها اضافه کن تا درخواست‌های نامعتبر رد بشن.
- این کار نقطه‌های پایانی API رو قابل پیش‌بینی و خودمستند می‌کنه.

۷. از نتایج تایپ‌شده استفاده کن
- به‌جای IActionResult از Ok<T>()، NotFound() یا Results<T>() استفاده کن.
- وضوح، تست‌پذیری و مستندسازی Swagger رو بهبود می‌ده.

۸. اعتبارسنجی رو درست انجام بده
- توی هر متد کنترلر اعتبارسنجی دستی انجام نده.
- از [ApiController] و Data Annotation استفاده کن — اعتبارسنجی خودکار با پاسخ‌های ۴۰۰ تمیز.

۹. نقطه‌های پایانی رو منطقی گروه‌بندی کن
- مسیرها رو بر اساس دامنه یا ویژگی گروه‌بندی کن، نه لایه‌ی معماری.
- نقطه‌های مرتبط رو کنار هم نگه دار — API راحت‌تر مقیاس‌پذیر و قابل پیمایش می‌شه.

۱۰. از کش خروجی استفاده کن
- با OutputCache نتایج پرتکرار رو کش کن تا پاسخ‌ها سریع‌تر بشن.
- بار روی دیتابیس کم می‌شه و اپلیکیشن حس روان‌تری پیدا می‌کنه.


🔗 LinkedIn

متغیرها (Variables) — جرقه‌ی ذخیره‌ی فکر

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

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

اگه بخوام حاصل جمع قبلی رو نگه دارم چی؟ نمی‌تونم هر بار از اول حساب کنم!

اونجا بود که مفهوم متغیر (variable) به‌دنیا اومد — جایی توی حافظه که یه مقدار رو نگه می‌داره،
مثل مغز انسان که یه چیز رو موقتاً یادش می‌مونه.

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

بخش اول