در آخرین ساعات سال ۲۰۲۵، چند خطی درباره فرصتها و تهدیدهای اکوسیستم نرمافزاری ایران در سال پیشِرو نوشتم؛ اگر دوست داشتید مطالعه کنید و نظرتون رو به اشتراک بگذارید...
امین مصباحی
سال ۲۰۲۶، فرصتها و تهدیدهای اکوسیستم نرمافزار ایران…
امروز آخرین روز سال ۲۰۲۵ است؛ و میدونم این روزها سخته؛ برای همهمون. اما همین روزهای سخته که تصمیمهای امروز ما رو معنی میده. در حالی که برای خیلیها، ذهنشون نه آرومه، نه مطمئن، نه حتی امیدوار؛ این متن رو برای دلداری یا موعظه نمینویسم. میخوام صادقانه…
❤12👏4💯2
⬇️ خروجی وب مطالب کانال
(تولید شده با استفاده از TeleScribe)
Please open Telegram to view this post
VIEW IN TELEGRAM
techafternoon.mesbahi.net
Tech Afternoon - Technical Insights & Knowledge
Archive of Tech Afternoon Telegram channel posts
❤12
به خاطر میخی، نعلی افتاد
به خاطر نعلی، اسبی افتاد
به خاطر اسبی، سواری افتاد
به خاطر سواری، جنگی شکست خورد
به خاطر شکستی، مملکتی نابود شد
و همه این ها به خاطر کسی بود که میخ را خوب نکوبیده بود
این روزها که فشار اقتصادی بخش بزرگی از جامعه را فرسوده و مستاصل کرده، طبیعیه که نگاهها به سمت دولتها، سیاستها و تصمیمهای کلان بره. اما شاید بد نباشه در کنار این نگاه، از خودمون هم بپرسیم سهم ما، بهخصوص در لایههای تخصصی و حرفهای جامعه، در شکلگیری وضع امروز چی بوده.
بحث درباره سیاست، ایدئولوژی یا نزاع و انزوای کشور، اغلب دانشی به ما اضافه نمیکنه. اما خیلی از فسادها، ناکارآمدیها و بیعدالتیها، نه در اتاقهای دربسته سیاست، بلکه از دل سیستمها و نرمافزارهایی شکل گرفته که توسط تیمهای فنی طراحی و پیادهسازی شدن. نرمافزارهایی که قرار بوده شفافیت بیاورن، اما بهدلیل تصمیمهای اشتباه، سادهسازیهای خطرناک، یا تسلیم در برابر فشار برای تحویل سریع، به ابزار پنهانکاری تبدیل شدن.
مدیر محصولی که برای راضی نگه داشتن بالادست، کنترلهای حیاتی یک فرایند روحذف میکنه. مدیر فنیای که برای گرفتن یک جایگاه، یک نرمافزار ایزوله و بیکیفیت رو بدون یکپارچگی و بدون کنترل داده تحویل میده.
تیمی که گزارشهای ناقص و سطحی تولید میکنه و همین گزارشها، مسیر سوءاستفادههای بزرگ رو هموار میکنه. در بسیاری از این موارد، نه نیت فساد وجود داشته و نه منفعت شخصی. اما نتیجه یکی بوده. باز شدن دریچهای برای اتلاف منابع، بیعدالتی و فساد. خطاهایی که «سهوی» بودن، اما آثارشون واقعی و سنگین بودن.
مسئله این نیست که همه تقصیر رو به گردن مهندسها، تحلیلگرها یا تیمهای نرمافزاری بندازیم. مسئله اینه که بپذیریم مسئولیت حرفهای، فقط نوشتن کد یا تحویل فیچر نیست. تصمیمهای فنی، حذف کنترلها، نادیده گرفتن کنترل کیفیت داده و تسلیم شدن در برابر فشار زمان و سیاست، همگی اثر اجتماعی دارن؛ حتی اگر قصدی پشتشون نباشه.
من حداقل چندین مورد رو درگیر مشاوره یا اصلاح بودم که فساد در سایه ضعف نرمافزار شکل گرفته بود و تبدیل به معضل عظیم شده بود (بعضا مبالغشون با گذشت سالها و یک صدم شدن ارزش پول، هنوز هم چشمگیر و بزرگن). اکثرا هم این فساد و سوءاستفادهها، زیر سایهی ضعفهای ساختاری همین سیستمهای جامع مالی و بازرگانی و انواع همین «سامانه»های بزرگ شکل گرفته بودن. اگر دوستانی که واقعا دغدغه داشتن و درگیر چنین مسائلی هستن، با کمال میل حاضرم جلسه آنلاینی داشته باشیم و تجربیات رو به اشتراک بگذارم.
و دوستانی که علاقه دارن خودشون تحقیق کنن شاید این کلیدواژهها بد نباشن:
- Segregation of Duties (SoD)
- End-to-End Traceability
- Audit Logging & Observability
- Data Quality Management (DQM)
- Master Data Management (MDM)
- Reference Data Management
- Single Source of Truth (SSOT)
و همیشه مهندسها با ابزارها و روشهای فنی جلو فساد رو نمیگیرن؛ بلکه با پیادهسازی روشهای به ظاهر غیر نرمافزاری در دل نرمافزارها جلو فساد رو میگیرن؛ کلیدواژههای کمکی:
- Social visibility
- Self-regulation
- Nudge theory (تلنگرهای رفتاری)
- Accountability Mechanisms
- Awareness & Participation
- Principal-Agent Theory
- Theory of Change (ToC)
- Social Norms Theory
به خاطر نعلی، اسبی افتاد
به خاطر اسبی، سواری افتاد
به خاطر سواری، جنگی شکست خورد
به خاطر شکستی، مملکتی نابود شد
و همه این ها به خاطر کسی بود که میخ را خوب نکوبیده بود
این روزها که فشار اقتصادی بخش بزرگی از جامعه را فرسوده و مستاصل کرده، طبیعیه که نگاهها به سمت دولتها، سیاستها و تصمیمهای کلان بره. اما شاید بد نباشه در کنار این نگاه، از خودمون هم بپرسیم سهم ما، بهخصوص در لایههای تخصصی و حرفهای جامعه، در شکلگیری وضع امروز چی بوده.
بحث درباره سیاست، ایدئولوژی یا نزاع و انزوای کشور، اغلب دانشی به ما اضافه نمیکنه. اما خیلی از فسادها، ناکارآمدیها و بیعدالتیها، نه در اتاقهای دربسته سیاست، بلکه از دل سیستمها و نرمافزارهایی شکل گرفته که توسط تیمهای فنی طراحی و پیادهسازی شدن. نرمافزارهایی که قرار بوده شفافیت بیاورن، اما بهدلیل تصمیمهای اشتباه، سادهسازیهای خطرناک، یا تسلیم در برابر فشار برای تحویل سریع، به ابزار پنهانکاری تبدیل شدن.
مدیر محصولی که برای راضی نگه داشتن بالادست، کنترلهای حیاتی یک فرایند روحذف میکنه. مدیر فنیای که برای گرفتن یک جایگاه، یک نرمافزار ایزوله و بیکیفیت رو بدون یکپارچگی و بدون کنترل داده تحویل میده.
تیمی که گزارشهای ناقص و سطحی تولید میکنه و همین گزارشها، مسیر سوءاستفادههای بزرگ رو هموار میکنه. در بسیاری از این موارد، نه نیت فساد وجود داشته و نه منفعت شخصی. اما نتیجه یکی بوده. باز شدن دریچهای برای اتلاف منابع، بیعدالتی و فساد. خطاهایی که «سهوی» بودن، اما آثارشون واقعی و سنگین بودن.
مسئله این نیست که همه تقصیر رو به گردن مهندسها، تحلیلگرها یا تیمهای نرمافزاری بندازیم. مسئله اینه که بپذیریم مسئولیت حرفهای، فقط نوشتن کد یا تحویل فیچر نیست. تصمیمهای فنی، حذف کنترلها، نادیده گرفتن کنترل کیفیت داده و تسلیم شدن در برابر فشار زمان و سیاست، همگی اثر اجتماعی دارن؛ حتی اگر قصدی پشتشون نباشه.
من حداقل چندین مورد رو درگیر مشاوره یا اصلاح بودم که فساد در سایه ضعف نرمافزار شکل گرفته بود و تبدیل به معضل عظیم شده بود (بعضا مبالغشون با گذشت سالها و یک صدم شدن ارزش پول، هنوز هم چشمگیر و بزرگن). اکثرا هم این فساد و سوءاستفادهها، زیر سایهی ضعفهای ساختاری همین سیستمهای جامع مالی و بازرگانی و انواع همین «سامانه»های بزرگ شکل گرفته بودن. اگر دوستانی که واقعا دغدغه داشتن و درگیر چنین مسائلی هستن، با کمال میل حاضرم جلسه آنلاینی داشته باشیم و تجربیات رو به اشتراک بگذارم.
و دوستانی که علاقه دارن خودشون تحقیق کنن شاید این کلیدواژهها بد نباشن:
- Segregation of Duties (SoD)
- End-to-End Traceability
- Audit Logging & Observability
- Data Quality Management (DQM)
- Master Data Management (MDM)
- Reference Data Management
- Single Source of Truth (SSOT)
و همیشه مهندسها با ابزارها و روشهای فنی جلو فساد رو نمیگیرن؛ بلکه با پیادهسازی روشهای به ظاهر غیر نرمافزاری در دل نرمافزارها جلو فساد رو میگیرن؛ کلیدواژههای کمکی:
- Social visibility
- Self-regulation
- Nudge theory (تلنگرهای رفتاری)
- Accountability Mechanisms
- Awareness & Participation
- Principal-Agent Theory
- Theory of Change (ToC)
- Social Norms Theory
❤18👎7👍4💯1😐1
وقتی مهندسی شریک رنج میشه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…
حتی در مورد انتشار این مطلب مردد هستم...
ادامه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…
حتی در مورد انتشار این مطلب مردد هستم...
ادامه
امین مصباحی
وقتی مهندسی شریک رنج میشه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…حتی در مورد انتشار این مطلب مردد هستم؛…
💔23
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن!
مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی یکی از بهترین روشها برای یادگیری اون مهارتها به شمار میان.
این روزها که وضعیت ایران رو میبینم تصور میکنم راه نجاتی جز نسل بعدی برای آینده ایران نیست؛ لذا چند خطی رو در این مورد نوشتم که اگر علاقهمند بودید بخونید و نظرتون رو بگید.
لینک مطلب
مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی یکی از بهترین روشها برای یادگیری اون مهارتها به شمار میان.
این روزها که وضعیت ایران رو میبینم تصور میکنم راه نجاتی جز نسل بعدی برای آینده ایران نیست؛ لذا چند خطی رو در این مورد نوشتم که اگر علاقهمند بودید بخونید و نظرتون رو بگید.
لینک مطلب
امین مصباحی
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن!
فراتر از حرف و شعار، اگر واقعا باور داشته باشیم که آینده هر کشوری و به تبع اون آینده ایران، به کیفیت نسل بعدی گره خورده، ناچاریم روی یک موضوع مکث کنیم: توانایی حل مسئله. نه صرفا سواد، نه مدرک، نه حتی مهارت شغلی مشخص؛ بلکه اینکه انسان بتونه یک مسئله پیچیده…
❤14👍4👏4💯1
سلام؛
اگر امروز چند میلیون به سادگی فایلهاشون رو روی اینترنت آپلود میکنن و از هر نقطهی دنیا با یه URL ساده بهش دسترسی دارن، بخش بزرگی از این سادگی مدیون معماریایه که Amazon S3 حدود دو دهه پیش طراحی کرد.
تقریباً اکثر آبجکتاستوریجهای مطرح دنیا، چه از سمت Amazon، Microsoft، Google و چه نمونههای داخلی مثل آروان یا ستون، با API سازگار با S3 کار میکنن یا عملاً از همون مدل الهام گرفتهان.
ایده ساده ولی عمیق:
به جای فایلسیستم سنتی با سلسلهمراتب پیچیده، یک مدل object-based با namespace تخت، شناسه یکتا، متادیتا، و از پایه و اساس طراحیشده برای مقیاسپذیری افقی. نتیجه؟ ذخیرهسازی massively scalable با durability بالا و هزینه منطقی.
پروژههای متنباز مثل Ceph، MinIO و RustFS هم دقیقاً توی همین فضا رشد کردن و اکوسیستم S3-compatible رو تقویت کردن. این یعنی S3 فقط یک سرویس نبود؛ بلکه اینقدر خوب بود که تبدیل به یک قرارداد معماری شد.
اگر به طراحی سیستمهای توزیعشده، trade-off بین consistency و availability، یا تصمیمهای اولیهای که بعدها تبدیل به استاندارد صنعت شدند علاقه دارین، این گفتوگو توی کانال The Pragmatic Engineer از زاویه مهندسی و معماری نکات ارزشمندی داره. مصاحبه دقیق و فنی با معاون تکنولوژی AWS، خانم مایلان تامسون.
پیشنهاد میکنم اگر به زیرساخت و معماری علاقه دارید، بخشی از آخر هفته رو به دیدنش اختصاص بدید.
📢 در ضمن برای انتخاب موضوع مطالب آتی کانال خوشحال میشم پیشنهادهاتون رو کامنت کنید؛ اگر چیزی در موردشون بدونم یا تجربهای داشته باشم، حتمن در اولویت خواهند بود 😊
اگر امروز چند میلیون به سادگی فایلهاشون رو روی اینترنت آپلود میکنن و از هر نقطهی دنیا با یه URL ساده بهش دسترسی دارن، بخش بزرگی از این سادگی مدیون معماریایه که Amazon S3 حدود دو دهه پیش طراحی کرد.
تقریباً اکثر آبجکتاستوریجهای مطرح دنیا، چه از سمت Amazon، Microsoft، Google و چه نمونههای داخلی مثل آروان یا ستون، با API سازگار با S3 کار میکنن یا عملاً از همون مدل الهام گرفتهان.
ایده ساده ولی عمیق:
به جای فایلسیستم سنتی با سلسلهمراتب پیچیده، یک مدل object-based با namespace تخت، شناسه یکتا، متادیتا، و از پایه و اساس طراحیشده برای مقیاسپذیری افقی. نتیجه؟ ذخیرهسازی massively scalable با durability بالا و هزینه منطقی.
پروژههای متنباز مثل Ceph، MinIO و RustFS هم دقیقاً توی همین فضا رشد کردن و اکوسیستم S3-compatible رو تقویت کردن. این یعنی S3 فقط یک سرویس نبود؛ بلکه اینقدر خوب بود که تبدیل به یک قرارداد معماری شد.
اگر به طراحی سیستمهای توزیعشده، trade-off بین consistency و availability، یا تصمیمهای اولیهای که بعدها تبدیل به استاندارد صنعت شدند علاقه دارین، این گفتوگو توی کانال The Pragmatic Engineer از زاویه مهندسی و معماری نکات ارزشمندی داره. مصاحبه دقیق و فنی با معاون تکنولوژی AWS، خانم مایلان تامسون.
پیشنهاد میکنم اگر به زیرساخت و معماری علاقه دارید، بخشی از آخر هفته رو به دیدنش اختصاص بدید.
📢 در ضمن برای انتخاب موضوع مطالب آتی کانال خوشحال میشم پیشنهادهاتون رو کامنت کنید؛ اگر چیزی در موردشون بدونم یا تجربهای داشته باشم، حتمن در اولویت خواهند بود 😊
tech-afternoon
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن! مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی…
تفکر محاسباتی در بزرگسالی؛ بازسازی ظرفیت تحلیل و حل مسئله!
این مطلب، در ادامه یادداشتی است که در مورد مهارت «حل مسئله» برای کودکان نوشته بودم؛ منتها برای بزرگسالها.
مخاطب این مطلب: بعضی افرادی که ظاهرا در نقشهای فنی یا مدیریتی فعالیت میکنن، ولی به مرور از تمرین واقعی مسئلهحلکردن فاصله میگیرن.
مدیرهایی که بیشتر وقتشون صرف هماهنگی و جلسه میشه.
توسعهدهندههایی که در چرخه کارهای تکراری و نگهداری سیستمها محاصره شدن.
افرادی که تصمیم میگیرن، اما کمتر ساختار مسئله رو باز میکنن.
و شاید هر کسی که به این موضوع علاقهمند باشه...
مثل همیشه خوشحال میشم نظر یا تجربهتون رو بدونم 😊
این مطلب، در ادامه یادداشتی است که در مورد مهارت «حل مسئله» برای کودکان نوشته بودم؛ منتها برای بزرگسالها.
مخاطب این مطلب: بعضی افرادی که ظاهرا در نقشهای فنی یا مدیریتی فعالیت میکنن، ولی به مرور از تمرین واقعی مسئلهحلکردن فاصله میگیرن.
مدیرهایی که بیشتر وقتشون صرف هماهنگی و جلسه میشه.
توسعهدهندههایی که در چرخه کارهای تکراری و نگهداری سیستمها محاصره شدن.
افرادی که تصمیم میگیرن، اما کمتر ساختار مسئله رو باز میکنن.
و شاید هر کسی که به این موضوع علاقهمند باشه...
مثل همیشه خوشحال میشم نظر یا تجربهتون رو بدونم 😊
امین مصباحی
تفکر محاسباتی در بزرگسالی؛ بازسازی ظرفیت تحلیل
یکی از سوءبرداشتهای رایج اینه که «تفکر محاسباتی» مهارتیه مربوط به آموزش پایه و کودکان. در حالی که از منظر علوم شناختی، این مهارت بیش ازاینکه یک موضوع آموزشی باشه، یک الگوی پردازش اطلاعات و تصمیمگیریه که در تمام طول عمر میتونه تقویت یا تضعیف بشه. تفکر محاسباتی…
❤11
گاهی فکر میکنیم «سیستم ما که دو تا سرویس بیشتر نیست» یا «فعلا مونولیت هستیم، پس traceability فعلا اهمیتی نداره و هر وقت بزرگتر شد درستش میکنیم». ولی واقعیت اینه که زنجیرهی callها از همون روز اول وجود داره. حتی اگر فقط یک API به یک دیتابیس وصل باشه. مسئله این نیست که microservice داریم یا نه.
مسئله اینه که وقتی یک درخواست وارد سیستم میشه، آیا میتونیم مسیرش رو از ابتدا تا انتها ببینیم یا نه؟
حالا Traceability یعنی چه؟
یعنی بتونیم به این سوال ساده جواب بدهیم: این درخواست دقیقا از کجا اومده، از چه سرویسهایی عبور کرده، کجا کند شده، و چرا خطا داده؟
توی معماری microservice این موضوع حیاتیه، چون زنجیرهی callها طولانی و توزیعشده است. ولی حتی توی یک سیستم کوچک هم اگر این قابلیت رو نداشته باشیم، debugging زمانبر، و به حدس و گمان تبدیل میشه.
چرا حتی برای سیستمهای کوچک هم مهمه؟
برخی تصور میکنن Distributed Tracing مخصوص سیستمهای بزرگه. اما به تجربه:
- حتی یک سیستم سهلایه ساده هم بدون trace خوب، در زمان بروز مشکل، میتونه تبدیل به تاریکی مطلق بشه.
- وقتی یک feature ساده کند میشه، اگر trace نداشته باشی، شروع میکنی لاگها رو grep کردن و فرضیه ساختن.
- وقتی فرد جدیدی به تیم اضافه میشه، داشتن trace خوب، عملا بهترین مستند معماری زنده است.
پس Traceability باعث میشه:
- فرایند debugging از «حدس» به «مشاهده» تبدیل بشه
- به مرور blame culture توی تیم کمتر بشه، چون مسیر واقعی قابل دیدنه
- عملا bottleneckها خیلی سریعتر شناسایی بشن
- وابستگیها شفاف باشن
سه ستون اصلی Traceability
۱: اصل Context Propagation
یعنی باید context هر درخواست همراهش حرکت کنه. Trace ID و Span ID باید از سرویس A به B و C منتقل بشن. و اگر این زنجیره قطع بشه، عملا trace بیارزش میشه. استاندارد رایج امروز: W3C Trace Context. و این یعنی هدرهای استاندارد برای انتقال trace بین سرویسها.
۲: اصل Correlation بین Log و Trace
داشتن trace بدون لاگ بیفایده است. و داشتن لاگ بدون trace هم ناقصه. هر log مهم باید شامل:
trace_id
span_id
باشه تا بتونی از یک error log مستقیم بپری روی trace کامل اون درخواست. Structured logging اینجا حیاتیه (گرچه همه جا مهمه نه فقط توی traceability و متن آزاد و غیرساختیافته توی سیستمهای جدی قابل دفاع نیست.)
۳: طراحی درست Spanها
نام spanها باید پایدار و کمکاردینال باشه. به جای اینکه IDهای متغیر رو داخل نام span بگذاریم، اونها رو به صورت attribute باید ثبت کرد.
مثلا:
درست: HTTP POST /employee/{id}
غلط: HTTP POST /employee/1037685
اگر این موضوع رعایت نشه، هزینه و performance ابزارهای observability صدمه میبینه.
توی سیستمهای Async و Message-based
خیلی وقتها فکر میکنیم tracing فقط مربوط به HTTP است. ولی توی سیستمهای event-driven اگر context رو داخل header پیام منتقل نکنی، زنجیره عملا قطع میشه. برای publish و consume هم برای هر پیام باید span جداگانه وجود داشته باشه. وگرنه نمیفهمی این job واقعا نتیجهی کدوم درخواست بوده.
چند Best Practice عملی
- از یک استاندارد واحد استفاده کن. OpenTelemetry امروز انتخاب منطقیایه.
- سعی کنید sampling هوشمند داشته باشید. همه چیز رو صددرصد نگه داشتن، راهکار نیست.
- به هیچ وجه PII رو داخل trace و log نریزید. اگر لازمه، hash یا mask کنید (به صورت کلی complience رو جدی بگیرید).
- حتمن naming convention مشخص برای سرویسها و spanها داشته باشید.
- موضوع dependencyهای بیرونی مثل DB و external APIها رو حتما داخل trace بیارید.
- فقط errorها رو log نکنید، داخل span هم record کنید.
موضوع Traceability فقط ابزار نیست، فرهنگه! اگر تیم به این موضوع باور نداشته باشه، ابزار به تنهایی کمکی نمیکنه. باید در code reviewها به propagation دقت بشه. باید logging استاندارد enforce بشه. و باید observability contract بین تیمها تعریف بشه (توی سازمانهای بزرگتر وظیفه تیم اینتگریشن یا پلتفرم است)
جمعبندی: داستان Traceability چیزی نیست که «وقتی بزرگ شدیم» اضافه کنیم. این یکی از اون قابلیتهاییه که اگر از روز اول درست پیاده بشه:
- هزینهی debugging به شدت کاهش پیدا میکنه
- معماری شفافتر میشه
- رشد سیستم قابل کنترلتر میشه
- و در زمان بحران، تیم به جای سردرگمی، تصویر واضحی از واقعیت داره
سیستم بدون trace مثل شهریه که دوربین کنترل ترافیک نداره. شاید در روزهای آروم و تعطیلات مشکلی حس نشه. ولی در اولین روز پرکار و شلوغ، تازه میفهمی چی کم بوده.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
🪞روز مهندس، و داستان جناب هانسکریستیناندرسون که هنوز تمام نشده!
قرن ۱۹ میلادی، نویسنده سرشناس دانمارکی، در کنار داستانهای به ظاهر سادهای مثل دختر کبریتفروش یا جوجهاردک زشت، داستان لباس جدید پادشاه رو نوشت که احتمالا اکثر ما یا کتابش رو در کودکی خوندیم، یا کارتونش رو تماشا کردیم.
فکر میکنم بد نباشه جامعه مهندسی نرمافزار، گاهی جلو آیینه بایسته و ببینه که چقدر لُخت است! توی قصه «پادشاه لخت»، مشکل فقط یک پادشاه سادهلوح نبود. مسئله، یک اکوسیستم کامل بود:
- خیاطهای دروغین
- درباریان تأییدکننده
- جمعیتی که جرئت پرسیدن نداشت
و فقط یک کودک بود که گفت: چیزی تنش نیست!
اگر بخوایم صادق باشیم، ما هم در اکوسیستم نرمافزار، کم از اون دربار نداریم. و چقدر برای مناسب ظاهر شدن، نیاز به یادگیری و تلاش مضاعف داریم. خیاطهای دروغین امروز همیشه شیادهای بیرونی نیستن.
گاهی در لباس لیدر فنی ظاهر میشن که بدون threat model و بدون طراحی امنیتی، سیستم رو «production-ready» اعلام میکنن.
گاهی در قامت تیم محصول که زمان تحویل را بالاتر از امنیت و کیفیت مینشونن.
گاهی در نقش مدیر که بودجه آموزش، معماری، یا امنیت رو هزینه اضافی میدونن.
و گاهی هم در قامت مهندس باتجربهای که سالهاست چیز جدیدی یاد نگرفته ولی همچنان با اعتمادبهنفس حرف میزنه.
و درباریان؟
ما وقتی بدون خوندن دقیق PR رو تأیید میکنیم.
وقتی postmortem واقعی نمینویسیم.
وقتی ضعف امنیتی رو میدونیم ولی میگیم “بعداً درستش میکنیم”.
وقتی outage رو «اتفاق طبیعی» جا میزنیم.
مسئله این نیست که هک شدیم یا نشدیم. کند یا ناپایدار هستیم یا نه!
مسئله اینه که آیا اصول مهندسی رو جدی گرفتهایم یا نه.
اما سؤال جدی اینه:
چند تیم واقعاً اینها رو در عمل اجرا میکنند، نه فقط در رزومه؟
اگر بخواهیم جلوی آینه بایستیم، شاید بهتر باشد به جای شعار، این چکلیست رو از خودمون بپرسیم:
آیا ما اینها رو داریم؟
- اصول Security by Design، نه Security after Incident
- مفاهیم Threat Modeling مستند
- ساختار Secure SDLC واقعی، نه اسلاید پاورپوینت
- مکانیزمهای observability جدی
- ساختار Data Governance مشخص
- طبقهبندی داده و سیاست retention
- مدیریت دسترسی مبتنی بر اصل Least Privilege یا زیروتراست
- اصول Software Composition Analysis و مدیریت dependency
- ساختار Incident response plan تمرینشده
و...
اگر اینها نیست، ما فقط امیدواریم، مهندسی نمیکنیم.
روز مهندس شاید بیشتر از اونکه تبریک بخواد، احتیاج به صداقت داره.
صداقت با خودمون.
شاید وقتش باشه به جای تبریکهای شاعرانه، هرکدوممون یک ضعف مهندسی رو در تیممون جدی اصلاح کنیم. (جلو آینه بایستیم و لخت بودنمون رو ببینیم!)
لباس، با آرزو دوخته نمیشه.
با استاندارد، تمرین و مسئولیتپذیری دوخته میشه.
قرن ۱۹ میلادی، نویسنده سرشناس دانمارکی، در کنار داستانهای به ظاهر سادهای مثل دختر کبریتفروش یا جوجهاردک زشت، داستان لباس جدید پادشاه رو نوشت که احتمالا اکثر ما یا کتابش رو در کودکی خوندیم، یا کارتونش رو تماشا کردیم.
فکر میکنم بد نباشه جامعه مهندسی نرمافزار، گاهی جلو آیینه بایسته و ببینه که چقدر لُخت است! توی قصه «پادشاه لخت»، مشکل فقط یک پادشاه سادهلوح نبود. مسئله، یک اکوسیستم کامل بود:
- خیاطهای دروغین
- درباریان تأییدکننده
- جمعیتی که جرئت پرسیدن نداشت
و فقط یک کودک بود که گفت: چیزی تنش نیست!
اگر بخوایم صادق باشیم، ما هم در اکوسیستم نرمافزار، کم از اون دربار نداریم. و چقدر برای مناسب ظاهر شدن، نیاز به یادگیری و تلاش مضاعف داریم. خیاطهای دروغین امروز همیشه شیادهای بیرونی نیستن.
گاهی در لباس لیدر فنی ظاهر میشن که بدون threat model و بدون طراحی امنیتی، سیستم رو «production-ready» اعلام میکنن.
گاهی در قامت تیم محصول که زمان تحویل را بالاتر از امنیت و کیفیت مینشونن.
گاهی در نقش مدیر که بودجه آموزش، معماری، یا امنیت رو هزینه اضافی میدونن.
و گاهی هم در قامت مهندس باتجربهای که سالهاست چیز جدیدی یاد نگرفته ولی همچنان با اعتمادبهنفس حرف میزنه.
و درباریان؟
ما وقتی بدون خوندن دقیق PR رو تأیید میکنیم.
وقتی postmortem واقعی نمینویسیم.
وقتی ضعف امنیتی رو میدونیم ولی میگیم “بعداً درستش میکنیم”.
وقتی outage رو «اتفاق طبیعی» جا میزنیم.
مسئله این نیست که هک شدیم یا نشدیم. کند یا ناپایدار هستیم یا نه!
مسئله اینه که آیا اصول مهندسی رو جدی گرفتهایم یا نه.
من قبلاً دو اپیزود درباره تولید امن نرمافزار ساختم. درباره: SSDLC, STRIDE, Shift-left, SAST, DAST, IAST, RASP, SCA
در مورد بدهی فنی هم یه ویدیو کوتاه
اما سؤال جدی اینه:
چند تیم واقعاً اینها رو در عمل اجرا میکنند، نه فقط در رزومه؟
اگر بخواهیم جلوی آینه بایستیم، شاید بهتر باشد به جای شعار، این چکلیست رو از خودمون بپرسیم:
آیا ما اینها رو داریم؟
- اصول Security by Design، نه Security after Incident
- مفاهیم Threat Modeling مستند
- ساختار Secure SDLC واقعی، نه اسلاید پاورپوینت
- مکانیزمهای observability جدی
- ساختار Data Governance مشخص
- طبقهبندی داده و سیاست retention
- مدیریت دسترسی مبتنی بر اصل Least Privilege یا زیروتراست
- اصول Software Composition Analysis و مدیریت dependency
- ساختار Incident response plan تمرینشده
و...
اگر اینها نیست، ما فقط امیدواریم، مهندسی نمیکنیم.
روز مهندس شاید بیشتر از اونکه تبریک بخواد، احتیاج به صداقت داره.
صداقت با خودمون.
شاید وقتش باشه به جای تبریکهای شاعرانه، هرکدوممون یک ضعف مهندسی رو در تیممون جدی اصلاح کنیم. (جلو آینه بایستیم و لخت بودنمون رو ببینیم!)
لباس، با آرزو دوخته نمیشه.
با استاندارد، تمرین و مسئولیتپذیری دوخته میشه.
منظورم از اکوسیستم، فقط گروه خاصی نیست که ربطش بدیم به وقایع سیاسی و اجتماعی کنونی و بگیم اونا که از ما نیستن یا رفتنیاند و بعدش درستش میشه و از خودمون صلب مسئولیت کنیم.
از استارتاپهای متعدد خصوصی که هک شدن، تا بانک و سازمانی که با هک شدن دادههاش نابود شد و از روی پیامکها موجودی مردم رو بازسازی! کردن! تا نرمافزار دانشگاه تا... همه و همه گواهی بر لُختی جامعه نرم افزاریه!
❤19👍4🔥3👏1💯1
با فراگیر شدن GenAI، تبِ چیزی که بعدتر وایبکدینگ اسم گرفت هم روز به روز داغتر شد. لزوم ساختار دادن به تعامل توسعهدهنده و مدل زبانی، برای همین به تدریج فایلهای prompts.md و بعدتر instructions.md و پشتیبانی از tools و MCPها به گیتهاب کوپالوت اومدن (قبلا در مورد همه اینها توی کانال نوشتهام). ولی همونطور که مدلها پیشرفت کردن، ابزارها و ساختارهایی که کمک میکردن تا مدلها رو بهتر به خدمتِ ساختاردهی توسعه دربیاریم هم پیشرفت کردن. مثلا فایلهای prompts.md با وجود کاربردی بودنشون، خیلی زود محدودیتهاشون رو نشون دادن، پس پشتیبانی از instructions.md و tools هم اضافه شد. ولی جای چند تا چیز خالی بود:
- دانش دائمی، به خصوص، و تکرارشونده
- پشتیبانی از ورژن
- فقط فایل markdown نباشه، بشه بهش مثال و منبع و... هم معرفی کرد. عین دوره آموزشی؛ ولی خیلی سادهتر و سرراستتر از RAG ساختن
پس برای همین skills به وجود اومد، ساختاری که مهارت به خصوص، مثل دانش مرور کدها برای عدم تخطی از اصول امنیتی مورد توافق تیم/سازمان. یا حتی مهارت ایجاد تغییرات لازم برای استفاده از ORM جدید به جای ORM فعلی یا... ولی اینبار:
- باید یک فولدر باشه
- حتماً فایل SKILL.md داشته باشه
- میتونه همراهش اسکریپت، مثال، الگو، منابع آموزشی، و تعریف workflow داشته باشه
- هدفش اینه که دانش تکرارشونده و procedural رو در قالبی قابل اشتراک و بارگذاری تعریف کنه
- این یعنی Skills از نظر قابلیتهای عملیاتی و قابل استفاده مجدد خیلی جلوتر از فایلهای markdown ساده هست
.github\skills
.agents\skills
.claude\skills
ولی Skills یک استاندارد متنباز و جامعهمحوره که با مجوز Apache 2.0 توسط agentskills.io در دسترس عموم قرار داده شده؛ و چه Claude Code چه خانواده GitHub Copilot (plugin, CLI, SDK) و... ازش پشتیبانی میکنن و marketplaceهای به اشتراکگذاری skillها که زیاد شدن. به بیان خیلی ساده، Skill همون چیزیه که ما دوباره و دوباره میخوایم هوش مصنوعی انجام بده، ولی این بار در قالب یک بسته تعریفشده، نه پرامپت دستی.
🔧 ترکیب قابلیتها: میتونین چند Skill رو با هم ترکیب کنین تا workflowهای پیچیدهتر رو پوشش بدین.
📦 صرفهجویی در زمان و خطا: چون مراحل کاری، چکلیستها و اسکریپتها از قبل تعریف شدهان، نتایج قابل پیشبینیتر هستن.
🧠 مثال کاربردی:
فرض کنید هر بار که یک Pull Request در گیتهاب ایجاد میکنین، باید این کارها رو انجام بدید:
- اول چک کنه تیکت مرتبط با PR هر چی خواسته، توی تغییرات اومده و Acceptance criteria ها جا نیوفتاده از دست توسعهدهنده
- چکلیست امنیتی رو اجرا کنه
- تستهای یکپارچهسازی رو بررسی کنه
- معیارهای کیفی رو حساب کنه
- خروجی رو گزارش بده
به جای اینکه هر بار با پرامپت اینها را توضیح بدید، میتونید یک Skill بسازید با یک فولدر شامل: .github/skills/pr-review/SKILL.md و در ضمن فایلهای مثال و توضیح رو هم توی همین پوشه قرار بدید و توی فایل SKILL.md بگید ازشون استفاده کنه برای یاد گرفتن.
مثلا بنویسید:
- چه زمانی این Skill باید فعال بشه
- چه مراحلی رو باید انجام بده
- چه منابع یا چکلیستهایی همراه داشته باشه
بعدش هر ابزاری که از Agent Skills پشتیبانی کنه، مثل GitHub Copilot CLI یا Copilot coding agent، وقتی prompt مرتبط رو ببینه، این Skill رو بارگذاری و اجرا میکنه، بدون اینکه شما دوباره توضیح بدید.
🚀 چه چیزهایی میتونن به Skill تبدیل بشن؟
هر چیزی که تکرارشونده یا قابل استانداردسازی باشه:
- الگوی نوشتن مستندات (RFC، Arch review، design doc)
- چکلیستهای Code Review
- ایجاد template برای Issue و Task
- گامهای یونیت تست، تست یکپارچهسازی یا تست امنیت
- متدهای اتوماسیون workflowهای سازمانی
یا مثالهای اینجا یا اینجا یا اینجا
وقتی یک Skill تعریف میکنید، ابزارهای مختلفی که از استاندارد پشتیبانی میکنن میتونن ازش بهرهمند بشن و این یعنی دانش تیمی یا سازمانی رو قابل استفاده مجدد میکنین. Agent Skills داره تبدیل به استاندارد رایج برای تعریف تواناییهای هوش مصنوعی میشه. این یعنی دیگه نیاز نیست هر بار از صفر به هوش مصنوعی بگید چه کار کنه. شما میتونید مراحل، چکلیستها، اسکریپتها و دانش خودتون رو در قالب Skill تعریف کنین و ابزارهای مختلف مثل Copilot اونها را به صورت قابل استفاده مجدد بارگذاری کنن. این کار باعث میشه خروجیهای هوش مصنوعی قابل پیشبینیتر، استانداردتر و کمتر وابسته به پرامپت دستی باشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍5
بچههای معصومی که پرپر شدند، آرزو داشتن تا بزرگ بشن، موفق بشن و بهترینِ خودشون باشن...
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
💔27👎20❤6👍4
مصاحبهگر بودن در دل یه بحران
واقعبین باشیم، از پیِ بحران اقتصادی، بحران اجتماعی برخواست و از دل فاجعهی دیماه، جنگ اسفندماه؛ و این یعنی موج ورشکستگی شرکتها، موج تعدیلها و لزوم توجه به فرایند جذب نیرو و مهارت مصاحبه دادن و مصاحبه گرفتن. لذا تصور میکنم بد نباشه تا طی دو مطلب، از دو زاویه به موضوع نگاه کنیم.
بخش ۱: مصاحبهگر
الان که داری مصاحبه میگیری، احتمالاً طرف مقابلت چندین هفتهست که اینترنت کلن نداشته یا با دشواریهای زیادی منقطع وصل بوده. شاید توی شهرش یا همسایگیاش بمب خورده. شاید یکی از آشناهای نزدیکش کشته شده. شاید سه شب پشت سر هم درست نخوابیده.
و تو داری ازش میپرسی که تفاوت MPI و OpenMPرو توضیح بده.
این مطلب برای مصاحبهگرهاست، اونهایی که احتمالا مجبور خواهند بود مصاحبههای دقیقتری بگیرن چون بودجه و زمان کمتری برای قمار دارن و باید کاندیدی رو پیدا کنن که بتونه خروجی بهموقعتر، مستقلتر از AI و اینترنت بده و خلاصه اینکه آدم روزهای سختتر از گذشته باشه...
۱: بپذیر که شرایط عوض شده
در شرایط عادی، یه مصاحبهی ضعیف یعنی کاندیدا آماده نبوده. الان اما این معادله خیلی پیچیدهتره. آدمی که جلوی توئه ممکنه:
- دو ماه با قطعی اینترنت زندگی کرده، یعنی به LeetCode، دورههای آنلاین، و حتی جستجوی ساده دسترسی نداشته
- توی یه فضای روانی سنگین کار کرده (یا اصلاً نتونسته کار کنه)
- شغلش رو از دست داده نه به خاطر عملکرد، بلکه چون شرکت تعطیل شده
اگه اینها رو نبینی، داری یه ارزیابی ناقص میکنی؛ هرچقدر هم فرآیندت «استاندارد» باشه.
۲: قدرت دستته، این رو جدی بگیر
توی یه بازار کار نرمال، کاندیدا گزینه داره. الان نداره.
این یعنی فشار روانی مصاحبه برای طرف مقابل چند برابر شده. اضطراب بیشتر، اشتباه بیشتر، و تصویری که از طرف میگیری احتمالاً کمتر از واقعیتشه.
یه مصاحبهگر خوب این رو میدونه و فضا میده، نه از سر ترحم، بلکه چون میخواد ببینه این آدم واقعاً چیه؛ چون خودش هم تحت فشار است تا زمان، و بودجه شرکت رو برای بهینهترین خروجی و اثرگذاری تخصیص بده، نه برای کسی که بدون اینترنت، بدون راهنما، بدون AI دچار سردرگمی میشه.
۳: با منابع کمتر داری استخدام میکنی؛ این فشار رو روی کاندیدا خالی نکن
شرکتها الان کمتر استخدام میکنن. این یعنی هر نفر باید بیشتر کار کنه، هر استخدام ریسک بالاتری داره، و تیم تحمل اشتباه کمتری داره.
میفهمم که این فشار رو به مصاحبه منتقل میکنه. ولی فشار بیشتر روی کاندیدا، مصاحبه بهتری نمیده؛ فقط نشون میده کی بهتر تحمل اضطراب میکنه، که لزوماً همون کسی نیست که بهترین مهندسه.
چکلیست عملی، قبل از هر مصاحبه
۱. مصاحبه رو با جملاتی شروع کن که فضا رو باز کنه
نه از سر تعارف، بلکه یه چیز صادق: «میدونم اوضاع این روزا سنگینه. اگه وسط مصاحبه لازم داشتی یه لحظه وایسی، بگو.» این یه جملهست. ولی چیزهایی رو تغییر میده.
۲. سوالهایی که به اینترنت وابستهاند رو بازبینی کن
اگه کاندیدا با یه API یا فریمورک آشنا نیست، قبل از قضاوت از خودت بپرس: آیا ممکنه دو ماه به documentation دسترسی نداشته بوده باشه؟
۳. تمرکزت رو از «حفظیات» ببر روی «تفکر محساباتی و حل مسئله»
بپرس چطور فکر میکنه، نه چی حفظه. الان تفاوت این دو خیلی مهمتر از همیشهست.
۴. اگه عملکرد ضعیف دیدی، یه سوال ازش بپرس
«چیزی بوده این مدت که روی آمادگیت تأثیر گذاشته؟» ممکنه جواب تصویر کاملاً متفاوتی بده.
۵. feedback بده؛ حتی به رد شدهها
این یه چیز کوچیکه ولی الان وزن بیشتری داره. آدمی که رد شده و میدونه چرا، بهتر از آدمیه که فقط سکوت گرفته.
۶. دنبال آدم مناسب و تواناییهای «واقعبینانه» مورد نیازت باش، نه سوپرمن!
بیشتر از گذشته فکر کن دقیقا اون آدمی که مورد نیاز پروژه و پوزیشن است چه خصوصیاتی داره، نه آدمی که آرزو داری پیداش کنی و تمام چیزهایی که تا ۵ سال دیگه هم کاربردی توی محصول نداره رو مسلط باشه.
حرف آخر
مصاحبه گرفتن توی این شرایط یه مسئولیت اخلاقیه، نه فقط یه فرآیند HR.
تو داری در مورد معاش یه نفر تصمیم میگیری، کسی که شاید همین دیروز خبر بدی شنیده. این رو نمیگم که نرم باشی یا استانداردهات رو پایین بیاری. میگم که آدم باشیم. این دو تا با هم در تضاد نیستن.
قسمت بعدی: مصاحبهدهنده
1
واقعبین باشیم، از پیِ بحران اقتصادی، بحران اجتماعی برخواست و از دل فاجعهی دیماه، جنگ اسفندماه؛ و این یعنی موج ورشکستگی شرکتها، موج تعدیلها و لزوم توجه به فرایند جذب نیرو و مهارت مصاحبه دادن و مصاحبه گرفتن. لذا تصور میکنم بد نباشه تا طی دو مطلب، از دو زاویه به موضوع نگاه کنیم.
بخش ۱: مصاحبهگر
الان که داری مصاحبه میگیری، احتمالاً طرف مقابلت چندین هفتهست که اینترنت کلن نداشته یا با دشواریهای زیادی منقطع وصل بوده. شاید توی شهرش یا همسایگیاش بمب خورده. شاید یکی از آشناهای نزدیکش کشته شده. شاید سه شب پشت سر هم درست نخوابیده.
و تو داری ازش میپرسی که تفاوت MPI و OpenMPرو توضیح بده.
این مطلب برای مصاحبهگرهاست، اونهایی که احتمالا مجبور خواهند بود مصاحبههای دقیقتری بگیرن چون بودجه و زمان کمتری برای قمار دارن و باید کاندیدی رو پیدا کنن که بتونه خروجی بهموقعتر، مستقلتر از AI و اینترنت بده و خلاصه اینکه آدم روزهای سختتر از گذشته باشه...
۱: بپذیر که شرایط عوض شده
در شرایط عادی، یه مصاحبهی ضعیف یعنی کاندیدا آماده نبوده. الان اما این معادله خیلی پیچیدهتره. آدمی که جلوی توئه ممکنه:
- دو ماه با قطعی اینترنت زندگی کرده، یعنی به LeetCode، دورههای آنلاین، و حتی جستجوی ساده دسترسی نداشته
- توی یه فضای روانی سنگین کار کرده (یا اصلاً نتونسته کار کنه)
- شغلش رو از دست داده نه به خاطر عملکرد، بلکه چون شرکت تعطیل شده
اگه اینها رو نبینی، داری یه ارزیابی ناقص میکنی؛ هرچقدر هم فرآیندت «استاندارد» باشه.
۲: قدرت دستته، این رو جدی بگیر
توی یه بازار کار نرمال، کاندیدا گزینه داره. الان نداره.
این یعنی فشار روانی مصاحبه برای طرف مقابل چند برابر شده. اضطراب بیشتر، اشتباه بیشتر، و تصویری که از طرف میگیری احتمالاً کمتر از واقعیتشه.
یه مصاحبهگر خوب این رو میدونه و فضا میده، نه از سر ترحم، بلکه چون میخواد ببینه این آدم واقعاً چیه؛ چون خودش هم تحت فشار است تا زمان، و بودجه شرکت رو برای بهینهترین خروجی و اثرگذاری تخصیص بده، نه برای کسی که بدون اینترنت، بدون راهنما، بدون AI دچار سردرگمی میشه.
۳: با منابع کمتر داری استخدام میکنی؛ این فشار رو روی کاندیدا خالی نکن
شرکتها الان کمتر استخدام میکنن. این یعنی هر نفر باید بیشتر کار کنه، هر استخدام ریسک بالاتری داره، و تیم تحمل اشتباه کمتری داره.
میفهمم که این فشار رو به مصاحبه منتقل میکنه. ولی فشار بیشتر روی کاندیدا، مصاحبه بهتری نمیده؛ فقط نشون میده کی بهتر تحمل اضطراب میکنه، که لزوماً همون کسی نیست که بهترین مهندسه.
چکلیست عملی، قبل از هر مصاحبه
۱. مصاحبه رو با جملاتی شروع کن که فضا رو باز کنه
نه از سر تعارف، بلکه یه چیز صادق: «میدونم اوضاع این روزا سنگینه. اگه وسط مصاحبه لازم داشتی یه لحظه وایسی، بگو.» این یه جملهست. ولی چیزهایی رو تغییر میده.
۲. سوالهایی که به اینترنت وابستهاند رو بازبینی کن
اگه کاندیدا با یه API یا فریمورک آشنا نیست، قبل از قضاوت از خودت بپرس: آیا ممکنه دو ماه به documentation دسترسی نداشته بوده باشه؟
۳. تمرکزت رو از «حفظیات» ببر روی «تفکر محساباتی و حل مسئله»
بپرس چطور فکر میکنه، نه چی حفظه. الان تفاوت این دو خیلی مهمتر از همیشهست.
۴. اگه عملکرد ضعیف دیدی، یه سوال ازش بپرس
«چیزی بوده این مدت که روی آمادگیت تأثیر گذاشته؟» ممکنه جواب تصویر کاملاً متفاوتی بده.
۵. feedback بده؛ حتی به رد شدهها
این یه چیز کوچیکه ولی الان وزن بیشتری داره. آدمی که رد شده و میدونه چرا، بهتر از آدمیه که فقط سکوت گرفته.
۶. دنبال آدم مناسب و تواناییهای «واقعبینانه» مورد نیازت باش، نه سوپرمن!
بیشتر از گذشته فکر کن دقیقا اون آدمی که مورد نیاز پروژه و پوزیشن است چه خصوصیاتی داره، نه آدمی که آرزو داری پیداش کنی و تمام چیزهایی که تا ۵ سال دیگه هم کاربردی توی محصول نداره رو مسلط باشه.
حرف آخر
مصاحبه گرفتن توی این شرایط یه مسئولیت اخلاقیه، نه فقط یه فرآیند HR.
تو داری در مورد معاش یه نفر تصمیم میگیری، کسی که شاید همین دیروز خبر بدی شنیده. این رو نمیگم که نرم باشی یا استانداردهات رو پایین بیاری. میگم که آدم باشیم. این دو تا با هم در تضاد نیستن.
قسمت بعدی: مصاحبهدهنده
1
❤19
مصاحبهدهنده بودن در دل یه بحران
در ادامه بخش اول که مربوط به مصاحبهگر بودن نوشتم، ای مطلب یه مرور سریع روی مصاحبه دادنه. شاید قبلاً توی مصاحبهها، یه چیزهایی گفتی که کاملاً درست، نبودن! یه پروژه رو کمی بزرگتر نشون دادی. یه تکنولوژی رو گفتی «آشنام»، در حالی که فقط اسمش رو شنیده بودی. یه مسئولیت رو به اسم خودت ثبت کردی که teamwork بود.
الان جای اینها (white lies، بلوف) نیست، نه به خاطر اینکه اخلاقاً درست نیست (که نیست)، بلکه چون ریسکش برای خودت چند برابر شده.
چرا بلوف الان خطرناکتره
شرکتی که الان استخدام میکنه، احتمالاً قصد داره روی حداقل تعداد نیرو، حداکثر خروجی رو بگیره. یعنی اگه وارد بشی و اون چیزی نباشی که گفتی، خیلی سریعتر از قبل معلوم میشه؛ و خیلی سریعتر از قبل منجر به حذف میشه.
بدتر از اون: توی یه بازاری که کوچکتر شده، این چیزها بین آدمها میچرخه.
قبل از مصاحبه دادن، شرکت رو بشناس
این شاید مهمترین نکتهی این مطلب باشه و کمتر بهش اشاره بشه. الان دو سوال مهمتر از «آیا این شغل به دردم میخوره» وجود داره:
این شرکت شش ماه دیگه هنوز هست؟
و اگه هست، توی چه وضعیتی هست؟
بازار نرمافزار احتمالا در شرایط دشوار کنونی، بشه به سه گروه شرکت تقسیم کرد:
دسته اول: کمتر از پنج درصد: اونهایی که قبل از بحران بنیهشون رو ساختن. cash flow دارن، بدهی ندارن، و احتمالاً الان دست به کارهایی میزنن که توی شرایط عادی جرأتش رو نداشتن، چون رقیبها ضعیف شدن. اگه اینجا راه پیدا کنی، احتمالاً داری وارد جالبترین دورهی کاریشون میشی.
دسته دوم: اکثریت: شرکتهایی که زندهاند ولی توی فاز محافظهکاریاند. کمتر ریسک میکنن، کمتر استخدام میکنن، بیشتر نگران بقا هستن تا رشد. اینجا میشه کار کرد، ولی باید بدونی که داری وارد یه محیط پایدار ولی محدود میشی.
دسته سوم: شرکتهایی که اصلاً برنامه ندارن. یه روز استخدام میکنن، یه روز تعدیل. یه ماه حقوق نمیدن، یه روز لاین جدید محصول باز میکنن فرداش لغوش میکنن. اینجا وارد نشو! هرچقدر هم عنوان شغلی جذاب باشه.
چطور بفهمی کدوم دستهان؟
شرکتها این رو اعلام نمیکنن. باید دنبال نشونهها گشت، باید سابقه، بازار هدف و حتی مقدم بر محصولشون، «خط تولید نرمافزاریشون» رو بررسی کرد. نهایتا هم باید پرسوجو کرد، خصوصا از آدمهای درست.
قبل از مصاحبه: دنبال کسی بگرد که قبلاً اونجا کار کرده. نه برای اینکه بدگویی بشنوی، بلکه بپرسی «اگه الان جای من بودی، میرفتی؟»
توی مصاحبه: بپرس «بزرگترین چالشی که تیم الان باهاش روبروئه چیه؟». نه آخر مصاحبه، اول. جواب این سوال چیزهای زیادی بهت میگه. و تجربه و مهارت مذاکره/گفتوگو اینجا کمککننده خواهد بود.
روی اثبات توانایی کار کن، نه پر کردن خلاءها
یه اشتباه رایج اینه که آدمها قبل از مصاحبه سعی میکنن همهی ضعفهاشون رو پوشش بدن، یه دورهی سریع K8s، یه پروژهی نیمهکاره روی GitHub، یه آشنایی سطحی با granular scalability یا...
این انرژی رو بهتره بگذاری روی تعمیق دانش و مهارت پایه و اون چیزی که واقعاً بلدی، و سعی کن اونها رو قابل ارائه کنی (منظورم یه ارائهی با اعتمادبهنفس و مقتدرانه است). یه پروژهی کوچیک که کامله، از یه پروژهی بزرگ نیمهکاره خیلی بهتره. یه مشکل که واقعاً حلش کردی، از ده تا چیزی که «آشنام» ارزشمندتره.
مهارتهای نرم، و اینکه چرا الان جدیتر شدن
شاید بشه اینطور گفت که شرکتی که الان استخدام میکنه، داره روی یه آدم قمار میکنه، نه فقط روی مهارتش، روی اینکه توی شرایط سخت چطوره.
صبوری، قناعت، و اینکه بتونی با ابهام کنار بیای، اینها الان فقط «nice to have» نیستن. شرایط سختی که به همه از جمله شرکتها تحمیل شده، و کسی که این رو میدونه و باهاش کنار اومده، یه قدم جلوئه.
این رو نمیگم که تحمل بیاحترامی یا حقوق پایین رو توجیه کنیم چون نه تنها قابل توجیه نیست بلکه مذمومه. منظور اینه که آدمی که انتظاراتش با واقعیت و ظرفیت بازار، همآهنگ شده، توی مصاحبه هم این رو نشون میده، و مصاحبهگر میفهمه.
مهارتهای نرم دیگه، مثل کنترل هیجان، تمرکز و تفکیک فضای شخصی از کار (خصوصا این روزها که تشتت آراء بین افراد زیاده و باید فضای کار، تا حد امکان منفک از بحث و جدل باشه)؛ و یا تیمورک و انعطافپذیری و... همگی مهارتهایی هستن که در این شرایط خیلی واضحتر به چشم میان و ضروری به نظر میرسن.
در ادامه بخش اول که مربوط به مصاحبهگر بودن نوشتم، ای مطلب یه مرور سریع روی مصاحبه دادنه. شاید قبلاً توی مصاحبهها، یه چیزهایی گفتی که کاملاً درست، نبودن! یه پروژه رو کمی بزرگتر نشون دادی. یه تکنولوژی رو گفتی «آشنام»، در حالی که فقط اسمش رو شنیده بودی. یه مسئولیت رو به اسم خودت ثبت کردی که teamwork بود.
الان جای اینها (white lies، بلوف) نیست، نه به خاطر اینکه اخلاقاً درست نیست (که نیست)، بلکه چون ریسکش برای خودت چند برابر شده.
چرا بلوف الان خطرناکتره
شرکتی که الان استخدام میکنه، احتمالاً قصد داره روی حداقل تعداد نیرو، حداکثر خروجی رو بگیره. یعنی اگه وارد بشی و اون چیزی نباشی که گفتی، خیلی سریعتر از قبل معلوم میشه؛ و خیلی سریعتر از قبل منجر به حذف میشه.
بدتر از اون: توی یه بازاری که کوچکتر شده، این چیزها بین آدمها میچرخه.
قبل از مصاحبه دادن، شرکت رو بشناس
این شاید مهمترین نکتهی این مطلب باشه و کمتر بهش اشاره بشه. الان دو سوال مهمتر از «آیا این شغل به دردم میخوره» وجود داره:
این شرکت شش ماه دیگه هنوز هست؟
و اگه هست، توی چه وضعیتی هست؟
بازار نرمافزار احتمالا در شرایط دشوار کنونی، بشه به سه گروه شرکت تقسیم کرد:
دسته اول: کمتر از پنج درصد: اونهایی که قبل از بحران بنیهشون رو ساختن. cash flow دارن، بدهی ندارن، و احتمالاً الان دست به کارهایی میزنن که توی شرایط عادی جرأتش رو نداشتن، چون رقیبها ضعیف شدن. اگه اینجا راه پیدا کنی، احتمالاً داری وارد جالبترین دورهی کاریشون میشی.
دسته دوم: اکثریت: شرکتهایی که زندهاند ولی توی فاز محافظهکاریاند. کمتر ریسک میکنن، کمتر استخدام میکنن، بیشتر نگران بقا هستن تا رشد. اینجا میشه کار کرد، ولی باید بدونی که داری وارد یه محیط پایدار ولی محدود میشی.
دسته سوم: شرکتهایی که اصلاً برنامه ندارن. یه روز استخدام میکنن، یه روز تعدیل. یه ماه حقوق نمیدن، یه روز لاین جدید محصول باز میکنن فرداش لغوش میکنن. اینجا وارد نشو! هرچقدر هم عنوان شغلی جذاب باشه.
چطور بفهمی کدوم دستهان؟
شرکتها این رو اعلام نمیکنن. باید دنبال نشونهها گشت، باید سابقه، بازار هدف و حتی مقدم بر محصولشون، «خط تولید نرمافزاریشون» رو بررسی کرد. نهایتا هم باید پرسوجو کرد، خصوصا از آدمهای درست.
قبل از مصاحبه: دنبال کسی بگرد که قبلاً اونجا کار کرده. نه برای اینکه بدگویی بشنوی، بلکه بپرسی «اگه الان جای من بودی، میرفتی؟»
توی مصاحبه: بپرس «بزرگترین چالشی که تیم الان باهاش روبروئه چیه؟». نه آخر مصاحبه، اول. جواب این سوال چیزهای زیادی بهت میگه. و تجربه و مهارت مذاکره/گفتوگو اینجا کمککننده خواهد بود.
روی اثبات توانایی کار کن، نه پر کردن خلاءها
یه اشتباه رایج اینه که آدمها قبل از مصاحبه سعی میکنن همهی ضعفهاشون رو پوشش بدن، یه دورهی سریع K8s، یه پروژهی نیمهکاره روی GitHub، یه آشنایی سطحی با granular scalability یا...
این انرژی رو بهتره بگذاری روی تعمیق دانش و مهارت پایه و اون چیزی که واقعاً بلدی، و سعی کن اونها رو قابل ارائه کنی (منظورم یه ارائهی با اعتمادبهنفس و مقتدرانه است). یه پروژهی کوچیک که کامله، از یه پروژهی بزرگ نیمهکاره خیلی بهتره. یه مشکل که واقعاً حلش کردی، از ده تا چیزی که «آشنام» ارزشمندتره.
مهارتهای نرم، و اینکه چرا الان جدیتر شدن
شاید بشه اینطور گفت که شرکتی که الان استخدام میکنه، داره روی یه آدم قمار میکنه، نه فقط روی مهارتش، روی اینکه توی شرایط سخت چطوره.
صبوری، قناعت، و اینکه بتونی با ابهام کنار بیای، اینها الان فقط «nice to have» نیستن. شرایط سختی که به همه از جمله شرکتها تحمیل شده، و کسی که این رو میدونه و باهاش کنار اومده، یه قدم جلوئه.
این رو نمیگم که تحمل بیاحترامی یا حقوق پایین رو توجیه کنیم چون نه تنها قابل توجیه نیست بلکه مذمومه. منظور اینه که آدمی که انتظاراتش با واقعیت و ظرفیت بازار، همآهنگ شده، توی مصاحبه هم این رو نشون میده، و مصاحبهگر میفهمه.
مهارتهای نرم دیگه، مثل کنترل هیجان، تمرکز و تفکیک فضای شخصی از کار (خصوصا این روزها که تشتت آراء بین افراد زیاده و باید فضای کار، تا حد امکان منفک از بحث و جدل باشه)؛ و یا تیمورک و انعطافپذیری و... همگی مهارتهایی هستن که در این شرایط خیلی واضحتر به چشم میان و ضروری به نظر میرسن.
❤6👏2
ادامه مطلب قبل:
حرف آخر
حرف مطلب قبلم این بود که: قدرت دستته، پس مراقب باش. و این مطلب اینه که قدرت دست بازار است، پس هوشمند باش...
انتخاب شغل همیشه مهم بوده. ولی الان یه تصمیم اشتباه (یه شرکت یا یه پوزیشن اشتباه) میتونه شش ماه دیگه فرد رو دوباره توی همین موقعیت بذاره، ولی با انرژی کمتر و بازار سختتر.
پس قبل از اینکه فکر کنی چطور مصاحبه بدی، فکر کن کجا مصاحبه میدی و باید برای اون مصاحبه چجوری محیا باشی...
2
حرف آخر
حرف مطلب قبلم این بود که: قدرت دستته، پس مراقب باش. و این مطلب اینه که قدرت دست بازار است، پس هوشمند باش...
انتخاب شغل همیشه مهم بوده. ولی الان یه تصمیم اشتباه (یه شرکت یا یه پوزیشن اشتباه) میتونه شش ماه دیگه فرد رو دوباره توی همین موقعیت بذاره، ولی با انرژی کمتر و بازار سختتر.
پس قبل از اینکه فکر کنی چطور مصاحبه بدی، فکر کن کجا مصاحبه میدی و باید برای اون مصاحبه چجوری محیا باشی...
2
❤4👍3
سلام به همه؛
در طول یک سال گذشته، ایران ۳ دورهی تلخ و دشوار رو توی دفتر خاطرات چند هزارسالهاش نوشت. مرور کردنش توسط منی که از دور شاهد بود و به قول نسیم طالب، پوستی در بازی نداشتم، شاید بیشتر یک متن احساسی یا مرثیه باشه. پس از تکرارش پرهیز میکنم. پرواضحه که شرایط روحی همه، و البته شرایط اقتصادی جامعه و شرکتها در تنگنای کمسابقهای قرار داره. وضعیت اینترنت و تعدیلها و... هم بار مضاعف است به دوش همه. این روزها که ارتباطات قطع بود، اخبار به صورت قطرهچکونی منتقل میشد و همه اضطراب حال عزیزانمون و ایران رو داشتیم، بارها با خودم مرور کردم که چه کمکی از دستم ساخته است تا سهمی هرچند ناچیز در کاستن از آلام ایران داشته باشم.
سادهترین پاسخی که برای پرسش «چه کاری از من برای ایران ساخته است» به ذهنم رسید، این بود که مشاوره و همفکری بتونه مفید باشه، برای همین هم بخشی از زمان شنبه و یکشنبهام رو برای این کار در نظر خواهم گرفت. حوزه تخصصی من معماری نرمافزار، سیستمهای توزیعشده، پردازش سریع، و بهینهسازی الگورتیمی است. و به طور خلاصه عمده تجربیات من طی بیست و چند سال گذشته، شرکتها یا پروژههایی بوده که مسئله اصلیشون دیتای بزرگ، پرفرمنس سیستمهای پیچیده یا معماری نرمافزار بوده. اگر کمکی از من ساخته بود از طریق همین تلگرام پیام بدید و خوشحال میشم صحبت کنیم.
به امید روزهای بهتر، و حالِ بهتر همگی 🌱
در طول یک سال گذشته، ایران ۳ دورهی تلخ و دشوار رو توی دفتر خاطرات چند هزارسالهاش نوشت. مرور کردنش توسط منی که از دور شاهد بود و به قول نسیم طالب، پوستی در بازی نداشتم، شاید بیشتر یک متن احساسی یا مرثیه باشه. پس از تکرارش پرهیز میکنم. پرواضحه که شرایط روحی همه، و البته شرایط اقتصادی جامعه و شرکتها در تنگنای کمسابقهای قرار داره. وضعیت اینترنت و تعدیلها و... هم بار مضاعف است به دوش همه. این روزها که ارتباطات قطع بود، اخبار به صورت قطرهچکونی منتقل میشد و همه اضطراب حال عزیزانمون و ایران رو داشتیم، بارها با خودم مرور کردم که چه کمکی از دستم ساخته است تا سهمی هرچند ناچیز در کاستن از آلام ایران داشته باشم.
سادهترین پاسخی که برای پرسش «چه کاری از من برای ایران ساخته است» به ذهنم رسید، این بود که مشاوره و همفکری بتونه مفید باشه، برای همین هم بخشی از زمان شنبه و یکشنبهام رو برای این کار در نظر خواهم گرفت. حوزه تخصصی من معماری نرمافزار، سیستمهای توزیعشده، پردازش سریع، و بهینهسازی الگورتیمی است. و به طور خلاصه عمده تجربیات من طی بیست و چند سال گذشته، شرکتها یا پروژههایی بوده که مسئله اصلیشون دیتای بزرگ، پرفرمنس سیستمهای پیچیده یا معماری نرمافزار بوده. اگر کمکی از من ساخته بود از طریق همین تلگرام پیام بدید و خوشحال میشم صحبت کنیم.
به امید روزهای بهتر، و حالِ بهتر همگی 🌱
❤29
شاید مرور این جمله ماریو کوینتانا، شاعر برزیلی، این روزها که شرایط مطلوبمون نیست، و شاهد احاطه شدن پروفایلهای لینکدین با حلقههای سبزرنگ هستیم؛ بد نباشه!
«اگر وقتت رو صرف دنبال کردن پروانهها کنی، ازت فرار میکنن. اما اگر وقتت رو صرف ساختن یک باغ زیبا کنی، پروانهها خودشون به سراغت میان.
با این حال، اگر هم نیومدن، دستکم تو یک باغ زیبا برای خودت ساختهای.»
غم، جنگ، اقتصاد، اینترنت و خیلی چیزها میتونن به سرعت باطری ما رو از انرژی خالی کنن، با اینکه گفتنش ساده است و عمل کردن بهش اونم به وقت ابتلا خیلی سخته؛ ولی خوبه اینقدری انرژی رو ذخیره نگه داریم برای ساختن اون باغ! اون باغ یادگیری و تمرینه؛ همین. شاید به سرعت موقعیت کاری یا اقتصادی مطلوب به سراغمون نیاد، ولی دستکم؛ مهارت و دانش قابل اتکا خواهیم داشت... دیر یا زود امیدوارم بازار خودش رو با شرایط، تنظیم کنه؛ چرا که انطباقپذیری و میل به تعادل، خصوصیت قدیمی نوع بشره. حالا توی این فرایند، «زمان» تنها دارایی غیرقابل جبران؛ و «دانش و مهارت» تنها پساندازیه که میشه بهش تکیه کرد.
این شرایطِ سختی که به صورت جمعی تحمیل شده رو شاید بشه با حرکت جمعی، بهتر مدیریت کرد؛ یعنی یادگیری جمعی؛ پس موضوعاتی که شما پیشنهاد میدید، و نه چیزی که من تنها براش تصمیم میگیرم؛ شاید حرکت جمعی ما باشه. موضوع بعدی رو از کامنت دوستان انتخاب کردم: «فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری». اینکه کِی و چرا monorepo، چرا و کِی gitflow یا github flow یا trunk یا... و مهمتر اینکه «فرهنگ» تیم چطور میتونه «روش» مورد استفاده رو به سمت کارآمدی یا عکسش پیش ببره.
If you spend your time chasing butterflies, they will run away. But if you spend your time creating a beautiful garden, then the butterflies will come to you.
However, if they don’t come, at least you have yourself a beautiful garden.
«اگر وقتت رو صرف دنبال کردن پروانهها کنی، ازت فرار میکنن. اما اگر وقتت رو صرف ساختن یک باغ زیبا کنی، پروانهها خودشون به سراغت میان.
با این حال، اگر هم نیومدن، دستکم تو یک باغ زیبا برای خودت ساختهای.»
غم، جنگ، اقتصاد، اینترنت و خیلی چیزها میتونن به سرعت باطری ما رو از انرژی خالی کنن، با اینکه گفتنش ساده است و عمل کردن بهش اونم به وقت ابتلا خیلی سخته؛ ولی خوبه اینقدری انرژی رو ذخیره نگه داریم برای ساختن اون باغ! اون باغ یادگیری و تمرینه؛ همین. شاید به سرعت موقعیت کاری یا اقتصادی مطلوب به سراغمون نیاد، ولی دستکم؛ مهارت و دانش قابل اتکا خواهیم داشت... دیر یا زود امیدوارم بازار خودش رو با شرایط، تنظیم کنه؛ چرا که انطباقپذیری و میل به تعادل، خصوصیت قدیمی نوع بشره. حالا توی این فرایند، «زمان» تنها دارایی غیرقابل جبران؛ و «دانش و مهارت» تنها پساندازیه که میشه بهش تکیه کرد.
این شرایطِ سختی که به صورت جمعی تحمیل شده رو شاید بشه با حرکت جمعی، بهتر مدیریت کرد؛ یعنی یادگیری جمعی؛ پس موضوعاتی که شما پیشنهاد میدید، و نه چیزی که من تنها براش تصمیم میگیرم؛ شاید حرکت جمعی ما باشه. موضوع بعدی رو از کامنت دوستان انتخاب کردم: «فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری». اینکه کِی و چرا monorepo، چرا و کِی gitflow یا github flow یا trunk یا... و مهمتر اینکه «فرهنگ» تیم چطور میتونه «روش» مورد استفاده رو به سمت کارآمدی یا عکسش پیش ببره.
❤21👏4
انتخاب Gitflow یا Trunk-Based Development؟
انتخاب Monorepo یا Multirepo؟
انتخاب GitHub Flow یا GitLab Flow؟
به نظرم سؤال اصلی این نیست که «کدوم بهتره؟»
سؤال بهتر اینه که «هر کدوم برای حل چه مسئلهای ساخته شده؟»
خیلی از تیمها مدلهایی رو از شرکتهای بزرگ کپی میکنن، بدون اینکه همون سطح از CI/CD، تست، ownership، feature flag، release management و tooling رو داشته باشن. نتیجهاش هم معمولاً شلختگی، merge conflict، releaseهای پراسترس و کیفیت ناپایداره.
طی این دو پست، که پاسخی به سوال یکی از دوستان کانال است؛ به فرهنگ و ساختار نسخهدهی رو از چند زاویه بررسی کردم:
ساختار repository: شامل Monorepo، Multirepo، Microrepo
مدلهای branching: شامل: Gitflow، GitHub Flow، GitLab Flow، Trunk-Based Development
و بعد ترکیب اینها در سناریوهای واقعی: مثل monolith، microservice، تیم کوچیک، چند تیم، SemVer، CalVer و چکلیست تصمیمگیری.
هدفم نسخه پیچیدن نیست؛ بیشتر اینه که انتخابمون از روی شناخت باشه، نه تقلید.
🔗 بخش اول
🔗 بخش دوم
3
Please open Telegram to view this post
VIEW IN TELEGRAM
امین مصباحی
فرهنگ و ساختار نسخهدهی در تیمهای نرمافزاری (بخش اول)
مقدمه:فرهنگ و ساختار نسخهدهی توی تیمهای نرمافزاری، با اینکه پیشینه طولانی داره و نسل اولش به دهههای ۶۰ و ۷۰ و میلادی برمیگرده و حتی ابزارهای مدرنترش مثل git توی بیستسالگیشون به سر میبرن؛ ولی کماکان موضوعی مهم و اثرگذار روی تیمهاست. و البته کم نیستن…
❤8
♻️ مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش اول)
توی بیشتر تیمهای نرمافزاری، تنش بین مدیر محصول و مهندس یه چیز آشنا و گاها حتی رایجه. یه طرف میگه «این فیچر باید تا آخر ماه آماده بشه»، طرف دیگه میگه «نمیشه» و این گفتگو هر بار همینجا تموم میشه. بدون اینکه کسی بپرسه چرا این الگو تکرار میشه.
این دو مطلب رو نوشتم که نشون بده ریشهی این تنش نه بدنیتیه، نه ضعف فردی؛ ساختاریه. و هر مشکل ساختاری، راهحل ساختاری داره. بخش اول به این پرداختم که این چالش از کجا شکل میگیره، چه مدلهای سازمانی اونو تشدید میکنه، و شرکتهای بزرگ چطور باهاش کنار اومدن. بخش دوم فلوی عملیاتی رو از لحظهی شکلگیری یه ایده تا رسیدنش به محیط عملیاتی مرحله به مرحله بررسی میکنم.
🔗 بخش اول
توی بیشتر تیمهای نرمافزاری، تنش بین مدیر محصول و مهندس یه چیز آشنا و گاها حتی رایجه. یه طرف میگه «این فیچر باید تا آخر ماه آماده بشه»، طرف دیگه میگه «نمیشه» و این گفتگو هر بار همینجا تموم میشه. بدون اینکه کسی بپرسه چرا این الگو تکرار میشه.
این دو مطلب رو نوشتم که نشون بده ریشهی این تنش نه بدنیتیه، نه ضعف فردی؛ ساختاریه. و هر مشکل ساختاری، راهحل ساختاری داره. بخش اول به این پرداختم که این چالش از کجا شکل میگیره، چه مدلهای سازمانی اونو تشدید میکنه، و شرکتهای بزرگ چطور باهاش کنار اومدن. بخش دوم فلوی عملیاتی رو از لحظهی شکلگیری یه ایده تا رسیدنش به محیط عملیاتی مرحله به مرحله بررسی میکنم.
🔗 بخش اول
در ضمن این مطلب رو بنا به سوال یکی از دوستان کانال نوشتم. اولویت فعلیم برای موضوع مطالب، چالشها و سوالهای شماست؛ پس اگر پیشنهادی دارید خوشحال میشم مطرح کنید.
امین مصباحی
مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش اول)
بخش اول: ریشهشناسی یک تنش ساختاری مقدمه: دعوای ظاهری، مشکل ساختاری این گفتوگو تکراری، بین مدیرمحصول و مهندس نرمافزار رو توی خیلی از تیمهای نرمافزاری میبینیم:– مدیر محصول یه فیچر رو تعریف میکنه+ مهندس نرمافزار: «اینجوری نمیشه»– مدیر محصول: «چرا…
❤13
♻️♻️ مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش دوم)
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث میشه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ چه کسی در هر مرحله مالک است؟ چه ابزاری کمک میکنه؟ و شرکتهای بزرگ این مسیر رو چطور طی میکنن؟ در این بخش به همین سوالها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظهی تولد تا استقرار، از شش مرحلهی مجزا عبور میکنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
مطلب کامل رو از لینک زیر مطالعه کنید:
🔗 بخش اول
🔗 بخش دوم
💬 نظر و تجربه شما چیه؟
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث میشه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ چه کسی در هر مرحله مالک است؟ چه ابزاری کمک میکنه؟ و شرکتهای بزرگ این مسیر رو چطور طی میکنن؟ در این بخش به همین سوالها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظهی تولد تا استقرار، از شش مرحلهی مجزا عبور میکنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
Discovery → Shaping → Spec → RFC → Development → Release
مطلب کامل رو از لینک زیر مطالعه کنید:
🔗 بخش اول
🔗 بخش دوم
Please open Telegram to view this post
VIEW IN TELEGRAM
امین مصباحی
مدیر محصول و مهندس نرمافزار: همکاری یا تنش؟ (بخش دوم)
بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature…
❤10
نقش AI در آینده شغلی و حرفهای ما و البته خیلی رشتههای دیگه نه تنها غیرقابل انکاره، بلکه همراه با ملاحظاتی است که اگه ازشون غافل باشیم، شاید از گردونه رقابت حذف شیم یا در حالت خوشبینانهترش، نقشمون کمرنگ و موقعیتمون متزلزل بشه.
استفاده از AI برای توسعه نرمافزار، فقط این نیست که «چقدر سریعتر کد تولید میکنیم». مسئله مهمتر اینه که «چه کسی» «چه» تصمیمی رو «چرا» میگیره؟! «مدل» تصمیمگیر و تعیینکنندهی «جهت» است یا «دانش ما»؟!
برای درک این مطلب، یک قابلیت ساده مثل احراز هویت و دسترسی رو توی یک REST API را از سه سطح نگاه بررسی کردم:
سطح اول: پرامپتی که قابلیت رو مطالبه میکنه
سطح دوم: پرامپت مهندسیشده که جهتگیری و چگونگی رو تبیین میکنه
سطح سوم: Skill، Agent و استانداردسازی سازمانی
خلاصهی مطلبم اینه که:
امروز AI میتونه سرعت بده؛ اما جهت رو هنوز دانش مهندسی تعیین میکنه.
پس AI در توسعه نرمافزار؛ یه ضریبه.
اگر دانش داری، ضریبی که سرعتت رو بالا میبره. اگر دانش نداری، ضریبی که اشتباهاتت رو سریعتر تولید میکنه.
🔗 لینک مطلب
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍8