کانال تلگرام

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

پنج‌شنبهٔ این هفته قراره که به مدت یک ساعت دربارهٔ تغییرات اخیر هوش مصنوعی و تأثیری که روی شرکت‌های تکنولوژی گذاشته صحبت کنیم. همچنین نگاهی می‌کنیم به این‌که الان در چه وضعیتی قرار داریم و مهم‌تر از همه، چه کارهایی می‌تونیم انجام بدیم تا شغل و مسیر حرفه‌ای‌مون رو امن‌تر نگه داریم و از فرصت‌های موجود بیشترین استفاده رو ببریم. 📅 پنج‌شنبه ۲۹ آبان (20 Nov) 🕗 ساعت ۲۰ به وقت ایران (17:30 CET) 🔗 لینک گوگل میت 🗓 اضافه کردن به تقویم ...

هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه. سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، … تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن. به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره. ...

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

سال ۲۰۲۴ برای من سال پذیرش چالش‌ها و مسئولیت‌های جدید بود. توی این پست خلاصه‌ای از سالی که گذشت رو نوشتم. 2024 in Review

شاپیفای آماری از Black Friday امسال منتشر کرده که اعدادش حیرت آوره 🤯 پردازش 7TB خط لاگ در دقیقه پاسخ دادن به ۱۷۰ میلیون درخواست در دقیقه (2M rps) استفاده از ۲.۴ میلیون CPU Core بر روی کوبرنتیز پاسخ دادن به ۴۵ میلیون کوئری بر ثانیه با MySQL (!) پردازش ۶۶ میلیون پیام کافکا در ثانیه

چه کاری رو می‌تونستیم متفاوت انجام بدیم تا جلوی این اتفاق رو بگیریم؟ این سوالیه که بعد از رخ دادن یک باگ، یک دیپلوی اشتباه، پاک شدن اشتباهی داده‌ها یا حتی شکست خوردن یک پروژه از خودمون و از تیم می‌پرسیم. معمولاً خروجی این سوال تبدیل به تعدادی تسک و یا داکیومنت‌هایی مثلpost mortem می‌شه. دیروز این توییت رو از Lorin Hochstein خوندم که معتقد بود که این سوال، سوال خوبی نیست و ممکنه ریشهٔ اصلی مشکل رو نشون نده و از آماده شدن برای رخ دادن مجدد مشکل جلوگیری کنه. پیشنهاد داده‌ بود که به جاش سعی کنیم که لحظهٔ به وجود اومدن مشکل رو از زاویه دید افراد درگیر در اون بازهٔ زمانی ببینیم. ای پرسش رو مطرح کنیم که اون‌ها در اون زمان چی می‌دیدن و چه داده‌هایی در دست داشتن که به تصمیم‌گیری اشتباه منتج شده. با جواب دادن به این سوال‌ها شاید دقیق‌تر متوجه ریشهٔ تصمیم‌های اشتباه بشیم. ...

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

توی این پست نوشتم که همهٔ مدیرها دوست دارن اعضای تیمشون ownership بالایی نسبت به محصول داشته باشن. اما خیلی وقت‌ها این اتفاق نمی‌افته. طبق تجربهٔ من، اعضای تیم هم معمولاً کم‌ و بیش علاقه‌مندن که نسبت به کارها ownership داشته باشن. پس وقتی که دو طرف یک خواستهٔ مشترک دارن، چرا همیشه این اتفاق نمیفته؟ قبل از جواب دادن به این سوال خوبه که ابتدا به درک مشترکی از سه مفهوم Ownership، Responsibility و Accountability برسیم. توی فارسی تفکیک این سه مورد یکم سخته و بعضاً به جای هم به کار می‌رن. من تعریف این سه واژه روی از این نوشته برداشتم که به نظرم توضیح واقعی‌تری برای این مفاهیم ارائه داده. ...

تصور کنید مدیر تیمی هستید و این جملات زیر رو از یکی از اعضای تیمتون می‌شنوید: توی code baseامون تعدادی بدهی فنی مهم داریم که روند توسعهٔ فیچرهامون رو کند کرده. من اون‌ها رو با نوشتن میزان اهمیت و پیچیدگی حلشون لیست کردم. هفتهٔ بعد که مرخصی هستی من دیلی‌ها رو برگزار می‌کنم. دیروز یک مشکلی توی منطق کد پیدا کردم و درستش کردم. این هم گزارش خسارت‌های احتمالیه که به وجود آورده. من علاقه‌مندم که کل هماهنگی‌های فیچر جدیدمون رو خودم پیش ببرم. صرفاً می‌خوام که بر روی کارم نظارت داشته باشی تا مسیر رو اشتباه نرم. از جملات بالا چه حسی پیدا می‌کنید؟ ...