⚙️ مطلب بعدی...

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

💬 سوالات و دغدغه‌ها رو بدونم روی ابهام‌ها بیشتر توضیح خواهم داد... 😊

📇 سلسله‌مراتب مهندسی نرم‌افزار و ساختار سازمانی (بخش اول)

سلسله‌مراتب مهندسی نرم‌افزار موضوع مهمیه، هم برای سازمان که بخواد با ساختار مناسب به اهداف و برنامه‌هاش برسه و بهره‌وری‌اش رو بهبود بده؛ هم افراد انگیزه برای رشد و یادگیری و رقابت داشته باشن. پس داشتن یه ساختار سازمانی درست + ساز و کار ارزیابی و رشد سرمایه‌انسانی، نه تنها حیاتیه، بلکه یه چالش بُرد-بُرد برای سازمان و افراده.

قبل از توضیح در مورد انواع سلسله‌مراتب مهندسی نرم‌افزار، باید بدونیم » چجوری ساختار سازمانی مناسب رو انتخاب کنیم؟

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

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

۱. اندازه شرکت
*️⃣استارتاپ‌ها: ساختار مسطح (Flat) با نقش‌های چندوجهی.
*️⃣شرکت‌های بزرگ: سلسله‌مراتب واضح با تخصصی‌سازی نقش‌ها.

۲. پیچیدگی محصول
*️⃣سیستم‌های پیچیده: نیاز به نقش‌های تخصصی (مثل مهندس بهینه‌سازی یا مهندس MLOps یا...).
*️⃣محصولات ساده: ساختار عمومی‌تر.

۳. فرهنگ سازمانی
*️⃣ساختار مبتنی بر نوآوری با آزادی عمل بالا برای مهندسان.
*️⃣ساختار متمرکز بر مشتری با تیم‌های مستقل (Squads).

۴. اهداف رشد
*️⃣اگر هدف توسعه سریعه: ساختار Agile با تیم‌های Scrum/کانبان.
*️⃣اگر هدف پایداریه: ساختار سلسله‌مراتبی با فرآیندهای دقیق (CMMI).

❓حالا چجوری نیازهای سازمان رو تشخیص بدیم؟

۱. نیازسنجی (Gap Analysis):
*️⃣چه مهارت‌هایی در تیم موجود نیست؟
*️⃣آیا ارتباط بین تیم‌ها کُنده؟
*️⃣آسیب‌شناسی محصول و تیم چی بهمون می‌گه؟

۲. مقایسه با شرکت‌های مشابه (Benchmarking):
*️⃣بررسی ساختار شرکت‌هایی با اندازه و حوزه فعالیت مشابه که «شرایط، بضاعت و استعداد مشابه دارن». طبیعتا اگر شرکتمون ۲۰۰ نفره و سیستم اداری تولید می‌کنه، اینکه بگردیم یه شرکت ۲۰۰ نفره نوآور در آمریکا یا ژاپن رو الگو کنیم منطقی نیست (گرچه خیلی‌ها این کار رو می‌کنن و بعد می‌بینیم staff engineer شون رفته مرخصی تا امتحان مدار منطقی‌اش رو نیوفته 😁)

۳. تعریف نقشه راه (Roadmap):
*️⃣باید نقشه‌راه کوتاه‌مدت، میان‌مدت و چشم‌انداز بلندمدت خوبی از کسب‌وکار و محصول داشته باشیم. یا اینکه هر وقت تغییر کردن بشینیم و ساختار سلسله‌مراتب و سازمانمون رو مرور کنیم ببینیم هنوز متناسبه؟! مثلا اگر هدف تبدیل شدن به یک شرکت مبتنی بر داده است، نقش‌هایی شاید اضافه کنیم، یا اگر قراره شرکت رشد بزرگی کنه، سلسه‌‌مراتبمون تغییر می‌کنه و نقش‌های جدیدی اضافه می‌شن. نقشه راه باید منطبق با واقعیت‌ها باشه، منطقی و قابل حصول باشه (به بیان ساده به قد و قواره‌مون بیاد و با توان و شرایط جور باشه)

۴. انعطاف‌پذیری:
*️⃣ساختار باید قابلیت تطابق با تغییرات بازار یا فناوری رو در خودش پیاده‌سازی کنه. آیه نازل نشده شرکت از روز اول ساختار ابدی و ثابت داشته باشه، ساختار باید در خدمت اهداف و بضاعت و استعداد مجموعه باشه. حالا شما برای تیم ۳ نفره CTO نداشته باشی هم می‌شه، ایشالا شدی ۱۰ تا تیم اونوقت CTO بگیر.

این بخش اول بود، لازم بود توضیح بدم که نقش‌ها و انواع سلسه مراتبی که در قسمت بعدی معرفی خواهم کرد، فقط نمونه‌هاییه که سازمان‌های مختلف بر اساس نیاز و شرایط‌شون ایجاد کردن. مثلا Distinguished Engineer یا Developer Advocate نقش‌هایی است که برخی سازمان‌ها بنا به ضرورت، اهداف و نیازشون ایجاد کردن و دارن، دلیل نمی‌شه همه داشته باشن.

از اون طرف اگر ما نقش‌ها و مسئولیت‌ها رو درست نشناسیم در انتخاب مسیر شغلی شاید انتخاب‌های غیر بهینه‌ای کنیم. پس افراد باید بدونن مسیر رشدهای مختلف چیه تا هم نقشه رشدشون رو ترسیم کنن هم سازمان متناسب رو برای کار کردن انتخاب کنن. از طرفی سازمان‌ها هم باید تکلیفشون مشخص باشه تا بتونن چرخه تربیت و رشد سرمایه‌انسانی رو ترسیم و اجرا کنن. شما برای تربیت نیروی انسانی باید افرادی رو داشته باشی که «بلد باشن و شایستگی» هدایت نیروی انسانی رو داشته باشن. نه اینکه هر وقت مدیر رفت نفر بعدی رو مدیر کنی! یا هر کی شوآف بیشتری داشت ارتقاء بدی!

🌱 لطفا دقت شود: «هدایت» با «راهنمایی» بسیار فرق داره! هدایت یعنی من دست شما رو بگیرم ببرمتون به مقصد مشخص برسونم. ولی راهنمایی یعنی بهتون آدرس رو بگم. لیدرشیپ نوعی از هدایت است، وگرنه راهنمایی توی اینترنت زیاده!

دوست دارید ادامه بدم و قسمت دوم و بعدترش رو داشته باشیم؟
💬 نظر؟ تجربه؟ سوال؟

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش دوم, گوگل!)

خب حالا که فهمیدیم انتخاب ساختار سازمانی بستگی به نیازها و شرایط داره، بریم سراغ یه نمونه واقعی: گوگل!
گوگل یکی از شرکت‌هاییه که ساختار مهندسی مدون و تعریف‌شده‌ای داره و خیلی‌ها تو مسیر شغلی‌شون دوست دارن بدونن که این مسیر رشد توی گوگل چطوره. البته دوباره تأکید کنم: ساختار گوگل برای گوگل خوبه! کپی کردنش بدون توجه به اندازه، اهداف، و فرهنگ سازمانی شما مثل این میمونه که کت و شلوار سایز ۳XL بخری ولی قدت ۱۲۰ باشه! 😁

۱. سطح Software Engineer I (L3)
📌 تجربه و دانش: معمولاً تازه‌واردها، فارغ‌التحصیلان دانشگاه یا کسانی که صفر تا دو سال تجربه دارن
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های ساده و متوسط تحت نظر مهندسان ارشد
➖ یادگیری استانداردهای گوگل، سیستم‌ها و بهترین شیوه‌های کدنویسی
➖ توسعه ویژگی‌های کوچک (مثلاً یک دکمه جدید در جیمیل)

✅ مهارت‌ها:
➖ تسلط به یک زبان برنامه‌نویسی (مثلاً پایتون یا جاوا)
➖ آشنایی با مفاهیم پایه الگوریتم و داده

۲. سطح Software Engineer II (L4)
📌 تجربه و دانش: معمولاً چند سال (۲ تا ۵ سال) تجربه کاری در پروژه‌های واقعی
❓ مسئولیت‌ها:
➖ طراحی و پیاده‌سازی ویژگی‌های متوسط (مثلاً بهبود سرعت بارگذاری یوتیوب)
➖ مشارکت در طراحی‌های کوچک و همکاری نزدیک‌تر با تیم‌های دیگه (تیم‌های کراس‌فانکشنال)
➖ کمک به تازه‌واردها برای درک بهتر فرآیندهای مهندسی و مشارکت در تصمیم‌گیری‌های فنی

✅مهارت‌ها:
➖ تسلط به طراحی سیستم‌های توزیع‌شده
➖ توانایی رفع باگ‌های پیچیده

۳. سطح Senior Software Engineer (L5)
📌 تجربه و دانش: معمولاً ۵ تا ۱۰ سال تجربه، فرد باید بتونه راه‌حل‌های فنی جامع و بهینه ارائه بده؛ یا کل پروژه رو از صفر تا صد هدایت کنه
❓ مسئولیت‌ها:
➖ رهبری پروژه‌های فنی بزرگ‌تر (مثلاً توسعه قابلیت‌های جدید در Google Maps)
➖ تصمیم‌گیری‌های فنی و ارائه راه‌حل برای چالش‌های پیچیده (مثلاً سیستم کش‌سازی پیشرفته)
➖ کمک به رشد مهندسان جوان‌تر (منتورینگ L3 و L4ها)

✅ مهارت‌ها:
➖ تسلط به معماری ابری (مثلاً Google Cloud)
➖ توانایی حل مسائل مقیاس‌پذیر (Scale)

۴. سطح Staff Software Engineer (L6)
📌 تجربه و دانش: معمولاً بالای ۱۰ سال تجربه، کسی که بتونه تصمیمات کلیدی فنی بگیره
❓ مسئولیت‌ها:
➖ هدایت تیم‌های مهندسی در مسیر درست و رهبری فنی چندین تیم (مثلاً هماهنگی بین تیم‌های جستجو و تبلیغات).
➖ طراحی معماری و تعیین استراتژی فنی سیستم‌های بزرگ و پیچیده. (مثلاً بهبود الگوریتم‌های جستجو)
➖ ارتباط بین تیم‌های مختلف و اطمینان از یکپارچگی سیستم (مثلاً یکپارچه‌سازی AI در محصولات مختلف)

✅ مهارت‌ها:
➖ دید کلان به چالش‌های سازمان
➖ توانایی تاثیرگذاری روی مدیران ارشد

۵. سطح Senior Staff Engineer (L7)
📌 تجربه و دانش: ۱۵+ سال تجربه، این سطح برای متخصصین عمیق در یک حوزه فنی در نظر گرفته شده (مهندسینی که در صنعت شناخته شده‌اند)
❓ مسئولیت‌ها:
➖ تعریف استراتژی‌های فنی برای تیم‌های مختلف
➖ طراحی سیستم‌های حیاتی یا راه‌حل‌هایی که مقیاس‌پذیری و کارایی بالایی دارن (مثلاً زیرساخت‌های امنیتی گوگل)
➖ تعامل مستقیم با VPها و C-Levelها برای شکل‌دهی به نقشه راه فنی
➖ انتشار مقالات تحقیقاتی یا ثبت پتنت

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Machine Learning یا Distributed Systems).
➖ رهبری بدون اختیار رسمی (Influence بدون Title).

۶. سطح Principal Engineer (L8)
📌 تجربه و دانش: عموما ۲۰+ سال تجربه و سطحی که فقط تعداد کمی از مهندسان بهش می‌رسن
❓ مسئولیت‌ها:
➖ تصمیم‌گیری‌های استراتژیک در مقیاس شرکت
➖ راهنمایی چندین تیم بزرگ و پروژه‌های بین‌سازمانی
➖ بررسی و حل مشکلاتی که روی عملکرد کل گوگل تأثیر دارن

۷. سطح Distinguished Engineer / Google Fellow (L9 - L10)
📌 تجربه و دانش: یکی از بالاترین جایگاه‌های مهندسی که فقط تعداد محدودی بهش می‌رسن
❓ مسئولیت‌ها:
➖ تعیین مسیر فنی کلان برای گوگل یا توسعه فناوری‌های تأثیرگذار در صنعت (مثلاً تصمیم به توسعه TensorFlow)
➖ نمایندگی گوگل در کنفرانس‌های جهانی (مثلاً Google I/O)
➖ هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی)
➖ تعامل با مدیران اجرایی (مثل CTO) برای نوآوری و آینده‌نگری

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖ شبکه ارتباطی قوی با دانشگاه‌ها و مراکز تحقیقاتی
💡 نکته مدیریتی: L8ها مشاوران اصلی ساندار پیچای (مدیرعامل گوگل) هستن!

جمع‌بندی:
سلسله‌مراتب گوگل برای شرکتی با ۱۷۰ هزار کارمند و محصولات جهانی طراحی شده. اگر سازمان شما ۵۰ نفر است، دنبال استخدام L8 نباشید! 😂
موفقیت در گوگل (و هر شرکتی) به تاثیرگذاری (Impact) وابسته است، نه صرفاً سال‌های تجربه. پس به جای تقلید کورکورانه، ساختاری طراحی کنید که متناسب با قد و بالای سازمان شما باشه!

💬 شرکت بعدی چی باشه؟ (کامنت کنید)
بوکینگ؟ مایکروسافت؟ اپل؟ Miro؟ ING؟ Meta؟ Ayvens؟

اگر مثال شرکت‌های دیگه رو ادامه بدم، ری‌اکشن: ⚙️
اگر این بحث کافیه، ری‌اکشن: 🤪

✨🚀 تفاوت output، outcome و impact

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

❓ «یکم بیشتر توضیح میدین منظورتون از Impact چیه؟»

به احترام پرسش خوب ایشون سعی می‌کنم در حد بضاعت پست تلگرامی توضیح بدم.

توی مباحث لیدرشیپ فنی، ۳ تا کلمه داریم که دونستن معانی اون‌ها مهمه:

💡 در مورد Output (خروجی)

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

⚙️ مثال:
➖ تعداد خطوط کد نوشته‌شده، یا ماژول‌های تکمیل‌شده
➖ ویژگی (Feature) جدیدی که به محصول اضافه شده
➖ مستندات فنی یا طراحی رابط کاربری

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

===========================

💡 در مورد Outcome (نتیجه)

تعریف: نتیجه به تأثیرات و تغییراتی اشاره داره که به واسطهٔ یک خروجی در رفتار یا وضعیت کاربران، کسب‌وکار یا فرایندهای داخلی به وجود می‌یاد. Outcome معمولاً روی «ارزش» تمرکز داره؛ اینکه خروجی تولیدشده چه مشکلی را حل کرده یا چه بهبودی ایجاد کرده.

⚙️ مثال:
➖ افزایش رضایت کاربران به‌دلیل اضافه شدن یک قابلیت مهم در نرم‌افزار
➖ کاهش زمان پاسخ‌گویی سرور پس از بهینه‌سازی کد
➖ بهبود نرخ تبدیل (Conversion Rate) یا رشد کاربران فعال روزانه (DAU)

✅ ویژگی: نتیجه معمولاً به معنای دستیابی به بهبود یا حل مشکل مشخصی است. اندازه‌گیری اون اغلب به شاخص‌های عملکردی (KPIs) یا داده‌های تحلیلی وابسته است (مثلاً بررسی نرخ ریزش کاربران قبل و بعد از اضافه‌شدن فیچر جدید).

===========================

💡 در مورد Impact (تأثیر یا اثرگذاری کلان)

تعریف: Impact سطحی کلان‌تر از «نتیجه» است که نشون می‌ده تغییرات ایجادشده چه اثرات عمیق یا پایدار در جامعه، بازار، استراتژی کلان شرکت یا حتی صنعتی که شرکت توش فعالیت می‌کنه، داشته است. Impact فراتر از یک «دوره کوتاه» یا «مقیاس کوچک» است و غالباً در بلندمدت ارزیابی می‌شود.

⚙️ مثال:
➖ تغییر جایگاه شرکت در بازار نرم‌افزار (مثلاً تبدیل شدن به یکی از پیشروان صنعت)
➖ تأثیر مثبت بر جامعه: ایجاد اشتغال، بهبود زندگی مشتریان یا حل یک مشکل فراگیر اجتماعی
➖ تحول فرایندهای یک سازمان بزرگ که مشتری شرکت شماست (مثلاً یک سیستم سازمانی که کیفیت خدمات دولتی رو ارتقا داده است)

✅ ویژگی: تأثیر کلان ممکن است با معیارهای مالی (نظیر افزایش چشمگیر درآمد یا ارزش سهام) یا با شاخص‌های غیرمالی (مثل ارتقای آگاهی جمعی، تغییر رفتار اجتماعی) سنجیده بشه. گاهی برای سنجش دقیق Impact نیاز به گذر زمان و بررسی ابعاد گوناگون نتایج است.

===========================

⚙️ اینم بگم که گاهی ما تصور می‌کنیم فجایع و چرندیاتی که تولید کردیم impact یا outcome یا output بوده! اکثریت غالب شرکت‌های نرم‌افزاری‌ای که تپه‌ی سالم توی صنایع مختلف و سازمان‌های دولتی، بانک‌ها، و... باقی نگذاشتن، معتقدند که تاثیر عمیق و بسزایی با محصولات بی‌کیفیت و گاها آشغالشون گذاشتن، اینکه نتیجه بد شده، از کاهلی و وضع بد دیگران بوده!

لذا این خیلی خیلی مهمه که «ملاک سنجش و ارزش‌گذاری» عملکردمون «استاندارد و جهانی» باشه... وگرنه: «خود گویی و خود خندی... عجب مرد هنرمندی!»

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش سوم, مایکروسافت!)

حالا که گوگل رو مرور کردیم، و مفهوم impact در سازمان رو دیدیم، بنا به نظر و پیشنهاد شما، بریم سراغ مایکروسافت ۲۲۸هزار کارمند داره که متناسب با ساختار و نیازهاش، نردبان شغلی خاص خودش رو داره:

۱. سطح L59 - Software Development Engineer I (SDE I)

📌 تجربه و دانش: فارغ‌التحصیل‌های تازه‌کار یا ۰ تا ۲ سال تجربه.
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های مشخص‌شده تحت نظر مهندسان ارشد
➖ یادگیری ابزارها و سیستم‌های داخلی مایکروسافت
➖ شرکت در Code Reviewها و مستندسازی ساده
➖ رفع باگ‌های جزئی و تست کد

✅ مهارت‌ها:
➖ آشنایی با #C یا ++C
➖ فهم پایه از مفاهیم شیءگرایی

۲. سطح L60 - Software Development Engineer II (SDE II)

📌 تجربه و دانش: معمولاً ۲ تا ۵ سال تجربه، کسی که بتونه مشکلات فنی پیچیده‌تر و پروژه‌های کوچیک رو حل کنه.
❓ مسئولیت‌ها:
➖ توسعه ویژگی‌های جدید و بهینه‌سازی‌های بزرگ‌تر (مثلاً بهبود سرعت اجرای Azure Functions)
➖ شروع به گرفتن تصمیمات طراحی در پروژه‌ها
➖ همکاری با تیم‌های دیگر برای یکپارچه‌سازی سیستم‌ها

✅ مهارت‌ها:
➖ تسلط به طراحی APIها
➖آشنایی با Azure یا سرویس‌های ابری.

۳. سطح L61-L62 - Senior Software Engineer (SSE)

📌 تجربه و دانش: معمولاً بالای ۵ سال تجربه، کسی که بتونه استقلال بیشتری در تصمیم‌گیری‌های فنی داشته باشه
❓ مسئولیت‌ها:
➖هدایت فنی پروژه‌های مهم (مثلاً توسعه قابلیت‌های جدید در Microsoft 365)
➖ارائه راه‌حل‌های بهینه برای مشکلات پیچیده.
➖طراحی معماری سیستم‌های توزیع‌شده (مثلاً بهبود زیرساخت Azure)
➖منتورینگ و کمک به SDEهای سطح پایین‌تر.

✅ مهارت‌ها:
➖ تخصص در حوزه‌هایی مثل ابر، AI یا امنیت
➖توانایی حل مسائل مقیاس سازمانی

۴. سطح L63-L64 - Principal Software Engineer

📌 تجربه و دانش: معمولاً ۸-۱۲ سال تجربه، فردی که می‌تونه چند تیم رو از نظر فنی هدایت کنه.
❓ مسئولیت‌ها:
➖ طراحی سیستم‌های با مقیاس بالا
➖ رهبری تیم‌های فنی و ایجاد هماهنگی بین تیم‌های مختلف (مثلاً هماهنگی بین تیم‌های Xbox و کلود)
➖ تعیین استراتژی فنی برای محصولات استراتژیک (مثلاً توسعه NET Core.)
➖ نظارت بر روند توسعه و تأثیرگذاری در تصمیم‌گیری‌های کلان محصول.

✅ مهارت‌ها:
➖ دید کلان به چالش‌های کسب‌وکار و فناوری
➖توانایی مذاکره با مدیران ارشد (مثل VPها)

۵. سطح L65-L66 - Partner Software Engineer

📌 تجربه و دانش: یکی از بالاترین سطوح مهندسی فنی در مایکروسافت، معمولاً ۱۲+ سال تجربه.
❓ مسئولیت‌ها:
➖تصمیم‌گیری‌های استراتژیک برای کل محصولات یا سرویس‌های بزرگ مایکروسافت.
➖ارتباط مستقیم با مدیران ارشد
➖هدایت چندین تیم مهندسی در راستای اهداف کلان.
➖طراحی سیستم‌های حیاتی (مثلاً معماری جدید Azure AI).

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).

۶. سطح L67 - Distinguished Engineer

📌 تجربه و دانش: افرادی که تأثیر مستقیمی روی کل صنعت دارن، تعداد این افراد خیلی کمه (مثال: دیوید فولر)
❓ مسئولیت‌ها:
➖مشارکت در تعیین استراتژی‌های بلندمدت مایکروسافت
➖هدایت تحقیقات پیشرفته و توسعه فناوری‌های آینده
➖تعامل با مدیران اجرایی و تأثیرگذاری در مسیر کلی شرکت
➖انتشار مقالات یا ثبت اختراعات کلیدی.

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).
➖رهبری بدون نیاز به عنوان رسمی (با Influence و Respect).

۷. سطح L68+ - Microsoft Technical Fellow

📌 تجربه و دانش: بالاترین سطح فنی در مایکروسافت! این افراد تأثیرگذارترین چهره‌های تکنولوژی شرکت هستن (اینقدر که مدخل ویکی‌پدیا دارن!)
❓ مسئولیت‌ها:
➖نوآوری‌های کلان در فناوری
➖ارائه راهبردهای تکنولوژیکی در سطح جهانی
➖ارتباط مستقیم با CEO و تعیین مسیر استراتژیک شرکت
➖هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی یا HoloLens)

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖شبکه ارتباطی با دانشگاه‌ها و دولت‌ها


🔀 مایکروسافت دو مسیر مجزا برای پیشرفت داره:
➖مسیر فنی (IC - Individual Contributor) که از SDE I تا Technical Fellow میره.
➖مسیر مدیریتی که از Engineering Manager تا VP of Engineering ادامه پیدا می‌کنه.

➖ برخلاف گوگل که سلسله‌مراتبش با L3, L4, … مشخصه، در مایکروسافت عناوینش از SDE I تا Technical Fellow سازماندهی شدن.
➖همون‌طور که توی گوگل دیدیم، توی مایکروسافت هم هر چی بالاتر می‌ری، مهارت‌های غیر فنی مثل لیدرشیپ و تصمیم‌گیری استراتژیک اهمیت بیشتری پیدا می‌کنن.

💬 بحث؟ نظر؟
➖ قسمت بعدی و پایانی این بحث، یک شرکت کوچک و متوسط رو به صورت کلی توضیح می‌دم.

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش چهارم و پایانی, شرکت‌های SME!)

🛠 چرا سلسله‌مراتب مهندسی برای شرکت‌های کوچک و متوسط مهمه؟
شرکت‌های کوچک و متوسط (SMEs) معمولاً چابک‌تر از غول‌هایی مثل گوگل و مایکروسافت هستن، ولی اگر نقش‌ها شفاف نباشه، افراد جای رشد نداشته باشن و سازمان فاقد ساختار منطقی باشه، انگیزه تیم پایین میاد و رشد شرکت متوقف می‌شه. آدم‌ها می‌رن یا فسیل می‌شن! و دیگه نقطه قوت چابکی تبدیل می‌شه به اسباب درجا زدن...

👨‍💻 هدف از طراحی نردبان شغلی اینه که:
✅ مسیر پیشرفت مشخص باشه
✅ افراد بدونن برای ارتقا به چه مهارت‌هایی نیاز دارن و پوزیشن‌ها سلیقه‌ای پخش نشده
✅ شرکت بتونه استعدادها رو پرورش بده، نه فقط استخدام و اخراج کنه
✅ هم رشد فردی اتفاق بیفته، هم رشد سازمانی

🔹 سلسله‌مراتب پیشنهادی برای یک شرکت پویا و مقیاس‌پذیر

۱. سطح Junior Software Engineer 👶

📌 ویژگی‌ها: ۰ تا ۲ سال تجربه، تسلط روی اصول برنامه‌نویسی و یکی دو تکنولوژی
🔹 مسئولیت‌ها:
✅ یادگیری استانداردهای کدنویسی و فرآیندهای شرکت
✅ توسعه تسک‌های کوچک تحت نظر افراد ارشد
✅ نوشتن تست‌های ساده و رفع باگ‌های سطحی
🎯 شرایط ارتقا: تسلط به ابزارهای توسعه شرکت، بهبود درک معماری نرم‌افزارها

۲. سطح Software Engineer 👨‍💻 (مهندس نرم‌افزار)

📌 ویژگی‌ها: ۲ تا ۵ سال تجربه، توانایی توسعه ویژگی‌های مستقل
🔹 مسئولیت‌ها:
✅ پیاده‌سازی و بهینه‌سازی بخش‌های اصلی اپلیکیشن
✅ مشارکت در طراحی‌های کوچک و کدنویسی با کیفیت بالا
✅ همکاری با تیم‌ها یا نقش‌های دیگه مثل QA و DevOps
🎯 شرایط ارتقا: ارائه راه‌حل‌های بهینه‌تر (نه شوآف!) و درک بهتر از طراحی سیستم‌ها

۳. سطح Senior Software Engineer 🔥 (مهندس نرم‌افزار ارشد)

📌 ویژگی‌ها: ۵ تا ۸ سال تجربه، مهارت در حل مشکلات پیچیده
🔹 مسئولیت‌ها:
✅ معماری و طراحی سیستم‌های قابل مقیاس
✅ هدایت کد ریویوها و منتورینگ اعضای تازه‌کار
✅ بهینه‌سازی عملکرد و افزایش کیفیت کد
🎯 شرایط ارتقا: توانایی تصمیم‌گیری‌های فنی مهم، رهبری پروژه‌های بزرگ‌تر

۴. سطح Lead Engineer / Tech Lead 🚀 (رهبر فنی تیم)

📌 ویژگی‌ها: ۷ تا ۱۰ سال تجربه، تخصص در طراحی و راهبری سیستم‌های پیچیده
🔹 مسئولیت‌ها:
✅ راهبری تیم‌های توسعه از نظر فنی
✅ تصمیم‌گیری در انتخاب تکنولوژی‌ها و معماری‌های نرم‌افزار
✅ تعامل با مدیران محصول و تضمین اجرای درست پروژه‌ها
🎯 شرایط ارتقا: تجربه کافی در مدیریت تیم‌های مهندسی، درک استراتژی فنی

۵. سطح Software Architect 🏛 (معمار نرم‌افزار)

📌 ویژگی‌ها: ۱۰+ سال تجربه، توانایی طراحی سیستم‌های بزرگ و توزیع‌شده
🔹 مسئولیت‌ها:
✅ طراحی معماری نرم‌افزار و مستندسازی راهکارهای فنی
✅ مشاوره به تیم‌های مهندسی برای اتخاذ بهترین شیوه‌ها
✅ حل چالش‌های مقیاس‌پذیری و بهینه‌سازی سیستم‌ها
🎯 شرایط ارتقا: داشتن دیدگاه کلان و استراتژیک به سیستم‌های نرم‌افزاری

۶. سطح Engineering Manager 🎯 (مدیر مهندسی)

📌 ویژگی‌ها: مهارت در هم مدیریت افراد، هم درک فنی سیستم‌ها
🔹 مسئولیت‌ها:
✅ مدیریت و هدایت تیم‌های توسعه و تخصیص منابع
✅ تسهیل همکاری بین تیم‌های مختلف (مثلاً محصول، DevOps، QA)
✅ اجرای فرآیندهای رشد و ارتقای مهندسان نرم‌افزار
🎯 شرایط ارتقا: اثبات توانایی در هدایت چند تیم و موفقیت در اجراهای استراتژیک

۷. سطح CTO (Chief Technology Officer) 🏆 (مدیر ارشد فناوری)

📌 ویژگی‌ها: بالاترین سطح فنی، توانایی هدایت کل دپارتمان مهندسی
🔹 مسئولیت‌ها:
✅ تعیین مسیر فنی و تکنولوژیک شرکت
✅ تصمیم‌گیری در مورد فناوری‌های آینده و رشد تیم مهندسی
✅ ارتباط با سایر مدیران اجرایی و سرمایه‌گذاران برای هم‌راستا کردن استراتژی فنی با کسب‌وکار
🎯 شرایط ارتقا: تجربه گسترده در رهبری فناوری و ایجاد محصولات موفق

✨ چند نکته خیلی مهم برای اجرای این مدل در شرکت‌های کوچک و متوسط:
🔹 انعطاف‌پذیری حفظ بشه! یه استارتاپ ۱۰ نفره قطعاً نیازی به CTO یا چندین سطح از روز اول نداره، ولی وقتی رشد کنه، نیازش ایجاد می‌شه.
🔹 جایگاه‌های میانی حذف نشن! بین یه Junior و یه Senior باید مسیر رشد منطقی باشه، وگرنه انگیزه تیم کم می‌شه.
🔹 فرهنگ یادگیری و رشد ایجاد بشه! مسیر پیشرفت افراد نباید صرفاً روی «سال‌های تجربه» باشه، بلکه توانایی و خروجی مهم‌تره.
🔹 وقتی برخی پوزیشن‌ها رو به هر دلیلی ندارید، هیچ اشکالی نداره از مشاور «شایسته» استفاده کنید، خیلی بهتر از اینه که چون کسی رو ندارید بهش برچسب سنیور یا معمار یا کوفت بچسبونیم.
🔹 پوزیشن‌های لیدرشیپ، فقط مهارت فنی نیاز ندارن، باید بتونه تعامل سازنده و مناسب با سایرین داشته باشن و کمک به رشد بقیه کنن

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

😊 پایان این بحث
خوشحال می‌شم فیدبک بدید 🌱

🧪مقایسه دو مکتب معروف Unit Testing یعنی کلاسیک (Detroit) و لندن (Mockist)

1️⃣ تست «پیاده‌سازی» در مقابل تست «قرارداد»

🎩 کلاسیک: تست «فقط خروجی و رفتار نهایی» رو مورد ارزیابی قرار می‌ده؛ نیازی به دونستن جزئیات داخلی نیست. مثلاً اگر کد توابع کمکی رو تغییر بدیم ولی نتیجه نهایی تغییر نکنه، تست‌ها تغییر نخواهند کرد و فقط اگه Assertمون پاس شه، تست پاس شده.

🎡 لندن: تست‌ها بر اساس نحوه‌ی فراخوانی وابستگی‌ها و جزئیات پیاده‌سازی دقیق نوشته می‌شن. این یعنی تغییرات جزئی در داخل کلاس (حتی بدون تغییر در خروجی نهایی) ممکنه باعث شکست تست‌ها بشه؛ حتی اگه مثلا مقدار برگشتی یک متد دقیقا همونی باشه که قبلا بوده.

2️⃣مکان‌یابی باگ

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

🎡 لندن: چون تست‌ها به صورت دقیق تعاملات کلاس‌ها رو چک می‌کنن، در صورت خطا معمولا به سرعت متوجه می‌شیم که مشکل کجاست.

3️⃣ مدیریت وابستگی‌های پیچیده

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

🎡 لندن: با استفاده از Mock‌ها می‌شه وابستگی‌های «سطح اول» رو شبیه‌سازی کرد بدون اینکه لازم باشه کل گراف وابستگی‌ها رو راه‌اندازی کنیم.


🤔 اگر کنجکاوی که با کد هم تفاوتش رو ببینی: ری‌اکشن ⚙️

به احترام ⚙️ گذارهای عزیز 😁 کد مثال با 📱 و 📱 رو در کامنت مطلب قرار دادم.

💬 کامنت نظر و تجربه داری بیا بحث کنیم 😉

📎💡 توضیح ساده Read Your Own Writes Consistency یا (RYW) توی سیستم‌های توزیع‌شده

وقتی یه سیستم بزرگ داریم با تعداد زیاد کاربر یا درخواست همزمان، یکی از چالش‌های اصلی اینه که هر کاربر بتونه تغییراتی که خودش ایجاد کرده رو بلافاصله ببینه. مثلاً وقتی توی یه شبکه اجتماعی پست میذارید، انتظار دارید همون لحظه پستتون رو ببینید، نه اینکه چند ثانیه صبر کنید. به این قابلیت میگن Read Your Own Writes یا RYW (خیلی‌جاها own حذف می‌شه و در نتیجه read your writes می‌شه RYW).

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

⚙️راهکارها:

*️⃣استفاده از region-aware routing یعنی تمام درخواست‌های کاربر به یک منطقه مشخص هدایت بشه تا از تأخیرهای ناشی از تبادل داده بین مناطق مختلف جلوگیری بشه.

*️⃣استفاده از CRDTها (Conflict-Free Replicated Data Types) برای ادغام تغییرات هم به کار می‌رن تا توی مواقعی که چندین کاربر همزمان روی یه داده تغییر ایجاد می‌کنن، همگی به صورت یکپارچه به‌روز بشن

*️⃣استفاده از Session Token یعنی اطلاعاتی در مورد آخرین تغییراتی که کاربر ایجاد کرده رو نگه توی این توکن‌ها نگهداری کنیم.

یه روش دیگه که خیلی جالب عمل می‌کنه، استفاده از خواندن مبتنی برQuorum-Based Reads With Vector Clocks هست. توی این روش، وقتی می‌خوایم یه داده رو بخونیم، از چند سرور درخواست می‌دیم و آخرین نسخه رو بر اساس زمان‌بندی منطقی انتخاب می‌کنیم. همچنین تکنیک‌هایی مثل read repair وجود دارن که وقتی می‌بینیم داده‌ها به‌روز نیستن، به‌طور خودکار اون‌ها رو دوباره از دیتابیس اصلی می‌خونن و تازه می‌کنن. (برای این مورد باید پراکنده جغرافیایی وسیعی داشته باشیم تا توجیه پیدا کنه).

در نهایت، باید بگم که رسیدن به یه سیستم با Read Your Own Writes consistency توی مقیاس بزرگ نیازمند برنامه‌ریزی دقیق و نظارت مداوم هست. نمونه‌های موفق توی دنیای واقعی مثل پلتفرم‌های شبکه‌های اجتماعی، سایت‌های تجارت الکترونیک و ابزارهای همکاری آنلاین ثابت کردن که با استفاده از این تکنیک‌ها، می‌شه تجربه کاربری فوق‌العاده‌ای رو تضمین کرد. ولی برای سیستم‌هایی که مثلا توی یک کشور و حتی توی یک دیتاسنتر هستن اگر چالش RYW داشته باشیم، احتمالا و تکیه می‌کنم احتمالا یه مشکلی توی طراحی و پیاده‌سازی داریم...

‼️استانداردسازی خطاهای REST API با Problem Details (RFC 7807)

وقتی بحث طراحی REST API میاد وسط، خیلیا فقط به CRUD فکر می‌کنن و اینکه یه سری endpoint که دیتا می‌گیرن و کوئری پاسخ می‌دن. اینکه API کار کنه و خطا نده کافی نیست، اگر استاندارد نباشه مشکلاتی متعاقب خودش به بار میاره که مفصله. استانداردهای طراحی API کمک می‌کنن که APIها قابل پیش‌بینی، خوانا و سازگار باشن. برای همین هم REST API‌های اصولی، معمولاً از الگوهای استاندارد استفاده می‌کنن.

یکی از مشکلات رایج طراحی API، مدیریت و ارسال خطاهاست. خیلی از APIها به شکل‌های مختلف خطا برمی‌گردونن؛ یکی JSON میده، یکی XML، یکی فقط یه متن ساده، و بعضی‌ها هم فقط یه HTTP Status Code. اینجاست که RFC 7807 وارد می‌شه!

تعریف RFC 7807: استاندارد کردن جزئیات خطاها توی REST API

در حقیقت RFC 7807 استانداردیه که توش تعریف شده چطور APIها می‌تونن جزئیات خطاها (Problem Details) رو به صورت JSON یا XML برگردونن، به‌جای این که هر کی واسه خودش یه فرمتی اختراع کنه. فرمت پیشنهادی این شکلیه:

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "status": 403,
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/transactions/67890"
}

✅ اجزای کلیدی:

الف: type: یه URL که نشون میده این نوع خطا چیه (میشه مستندات مربوطه رو اینجا گذاشت)
ب: title: یه توضیح کوتاه و ثابت درباره‌ی نوع خطا
پ: status: همون HTTP Status Code که برمی‌گرده
ت: detail: توضیح دقیق‌تر در مورد این خطای خاص
ث: instance: آدرسی که خطا در اون رخ داده

✅ مزایای استفاده از Problem Details

*️⃣استاندارد بودن: همه جا یه فرمت ثابت داریم -> نرم‌افزار مونیتورینگ لاگ براش فرقی نمی‌کنه API از کجا و چه زبونی اومده، جزئیات خطا رو درست تشخیص می‌ده
*️⃣توسعه‌پذیری: می‌تونیم فیلدهای سفارشی اضافه کنیم
*️⃣مستندسازی بهتر: فرمت مشخص باعث میشه مستندات بهتری داشته باشیم
*️⃣پشتیبانی فریم‌ورک‌ها: اکثر فریم‌ورک‌های مدرن ازش پشتیبانی می‌کنن
*️⃣قابلیت اتوماسیون: ابزارها می‌تونن به راحتی خطاها رو پردازش کنن

🔗 متن استاندارد

💬 نظر شما چیه؟ از Problem Details استفاده می‌کنید؟ اگر کد مثال می‌تونه کمک کنه: ⚙️

#API_Design

🥸 اندر احوالات تست‌نویسی، باب TUnit

پسری را به کارگه کدنویسی همی بردندی تا شیوه‌ی کُدگری پیشه کند، استاد بگفت: «بِکُد، سپس بِتِست!» شاگرد مدتی استاده، بُکید، خسته شد؛ لَختی درنگ کرد و از برای تستیدن پرسید:

«استاد رخصت می‌دهی تا با MSTest بِتِستَم؟»
استاد بدو گفت: «بِتِست!»

باز مدتی بِتِستید، خسته شد، گفت: «استاد، اجازت باشد تا این بار به NUnit بگرایم و بِتِستم؟»
استاد گفت: «بِتِست!»

باز مدتی بِتِستید، باز خسته شد، گفت: «استاد، دلم هوای XUnit کرده است، رخصت می‌دهی تا به آن بِتِستم؟»
استاد گفت: «بِتِست!»

دیگر نایی در تنش نمانده بود، گفت: «استاد! مرا زین همه آزمون، امان ده! باشد که آخرین بار به TUnit 🧪بِتِستم و آنگاه بیاسایم؟»
💎 استاد گفت: «تو بِتِست، بمیر و بِتِست!»

* بِتِست: فعل امر تست نوشتن
* بُکید: فعل ماضی کد نوشتن، سوم شخص مفرد


✨⛏ درسته که مهم، تست نوشتنه، حالا بسته به نیازمون unit، integration, e2e, behaviour, stress, یا...
حالا اگر روی این موضوع توافق داریم، ولو به «تو بِتِست، بمیر و بِتِست!» و کنجاوید بدونید TUnit آیا یه قرطی‌بازی جدیده و یه بابایی آخر هفته بیکار بوده یه چیزی نوشته و چهار روز دیگه هم ولش می‌کنه، یا اینکه نه! یه نیازی بوده که با وجود MSTest و NUnit و XUnit یه لایبری تست‌نویسی جدید به وجود اومد؟!

اگر سواله، بگید تا بیشتر در موردش بگم و یه مقایسه با اون ۳ تا پیرمرد داشته باشم...

ری‌اکشن برای توضیح بیشتر: ⚙️

💬 تجربه، نظر؟

⛏✨ طراحی API و مفهوم Idempotency

معنی idempotent : شاید بشه «همانندپذیر» رو معادل خوبی براش دونست؛ توی ریاضی «عدد ۱ در عملیات ضرب» همانندپذیر هست، چون هر چند بار که یک در خودش ضرب شه، باز هم ۱ به دست میاد. ولی ۲ اینطور نیست چون ۲ اگر در خودش ضرب شه می‌شه ۴.
پس idempotent عملیاتی هست که چندین بار اجرا کردنش، نتیجه‌ای مشابه با یک بار اجرا کردنش داره.

یکی از دغدغه‌های اصلی توی سیستم‌هایی مثل پرداخت‌ یا عملیات حساس، اینه که وقتی کاربر چندبار یک درخواست رو می‌فرسته، سیستمو نباید چندبار اون رو پردازش کنه. به بیان ساده‌تر، API ما باید idempotent باشه؛ یعنی خروجی و اثرش هر بار یکسان باشه، حتی اگر درخواست رو چند بار ارسال کنیم (حالا چه سهوی، چه تعمدی و با قصد بد!) مثلا کاربر اگر API پرداخت رو چند بار فراخوانی کنه ممکنه چند بار وجه از حسابش کسر بشه یا مواردی از این دست.

روش‌های طراحی APIهای Idempotent

1️⃣ استفاده از Idempotency-Key
یکی از روش‌های رایج برای حل این مشکل استفاده از یک کلید منحصر به فرد به نام Idempotency-Key است. وقتی کاربر یک درخواست حساس (مثلاً پرداخت) رو ارسال می‌کنه، یک کلید یکتا همراه درخواست ارسال میشه. سرور وقتی درخواست رو دریافت می‌کنه، اول چک می‌کنه که آیا قبلاً درخواستی با اون کلید دریافت شده یا نه.

POST /payments
Headers: {
  "Idempotency-Key": "abc123"
}
Body: {
  "amount": 1000,
  "currency": "IRR"
}

2️⃣ روش Optimistic Concurrency Control
استفاده از کنترل همزمانی خوشبینانه (Optimistic Concurrency Control). هر موجودیت (entity) یه نسخه یا شناسه تغییر (مثلاً ETag) داره. وقتی کاربر می‌خواد تغییراتی رو روی اون موجودیت اعمال کنه، نسخه موجودیت رو همراه درخواست می‌فرسته.
اگر نسخه‌ای که فرستاده شده با نسخه فعلی مطابقت داشته باشه، تغییر اعمال میشه؛ در غیر این صورت، یعنی کسی یا چیزی قبلاً تغییر ایجاد کرده و سرور خطا برمی‌گردونه.

PUT /orders/123
Headers: {
  "If-Match": "v1"
}
Body: {
  "status": "paid"
}

3️⃣ روش Conditional Requests
از Conditional Requests می‌شه استفاده کرد، یعنی با استفاده از هدرهای HTTP مثل If-None-Match یا If-Modified-Since وقتی کاربر درخواست می‌ده، سرور بررسی می‌کنه که آیا داده‌های موجود تغییر کرده یا نه.
اگر داده تغییر نکرده باشه، سرور یک پاسخ مشابه برمی‌گردونه بدون اینکه دوباره عملیات رو انجام بده. مثلا: فرض کن کاربر می‌خواد اطلاعات پروفایل خودش رو آپدیت کنه. همراه درخواست هدر If-Unmodified-Since ارسال میشه که نشان دهنده آخرین باریه که اطلاعات تغییر کرده‌اند. اگر اطلاعات بین اون زمان تغییر نکرده باشه، عملیات به درستی انجام میشه؛ در غیر این صورت، سرور خطا میده که نشان میده اطلاعات به‌روزرسانی نشده یا تغییر کرده.

💬 نظر؟ بحث؟ گپ بزنیم؟

#API_Design

🤪 در باب تفکیک انتقاد از هجمه!

ℹ️ این مطلب فنی نیست، رفرنس‌محور هم نیست، و تحلیل و نوشتار شخصی ( و طبیعتا محتمل‌به‌خطا) است!

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

شاید خیلی از ما ترجیح ندیم که ویدیو خیلی عمومی بسازیم و خودمون رو خواسته یا ناخواسته در معرض دید عموم قرار بدیم. ولی در مقیاس محدودتر امکان داره برای هر کدوم از ما پیش بیاد. امکان داره در یک گپ ۳ نفره توی شرکت یه سوتی سهوی بدیم؛ و احتمالا نمی‌پسندیم اون ۲ نفر حاضر در اون جمع کوچیک؛ ما رو دستمایه مسخره کردن یا قضاوتشون قرار بدن.

حالا بیایم این شرایط و فضا رو که کم‌وبیش دیده‌ایم یه مقدار بشکافیم...

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

- خواستگاه تعداد زیادی از این بازخوردها، ولو اینکه خیلی موجه و منطقی به نظر بیان، باز هم خشم است!

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

- هیچ اظهار نظری، اعم از یک نظر اشتباه، ناقص یا حتی مضحک در مورد یک تکنولوژی؛ یا یک شیوه صحبت کردن یا یک تُپُق یا... اینقدر ناموسی و مهم نیست... چرا فکر نکنیم یک نفر از ۸ میلیارد جمعیت زمین یه نظری داده! چقدر موثره مگه؟! اگر من اومدم اینجا در مورد API Design یا ... یه مزخرفی گفتم، شما برو تحقیق کن درستش رو یاد بگیر، یا درستش رو جایی بنویس...

- این روزها و سال‌ها جامعه ما (و حتی جهان) این‌قدر آکنده از خشم و تفرقه است که ای کاش ما سهمی حتی در حد یک لایک یا کامنت ولو بامزه، در این حجم از نجاست خشم و نفرت نداشته باشیم

🌱 نقد سازنده در هر موضوعی ۴ تا مولفه‌ی «لاینفک» داره: ۱: پرداختن به موضوع به جای مصداق ۲: همراه داشتن راه‌حل منطقی ۳: پرهیز از تعصب و خشم و هیجان ۴: باور به حق آزاداندیشی، هر کسی آزاده تا هر باور و نظری داشته باشه، و در صورت ضرر به دیگران، قانون باید براش تصمیم بگیره و بس.

💬 اگر این مطلب رو خوندید، اولا متشکرم 😊 دوم اینکه خوشحال می‌شم نظرتون رو بدونم...