thisisnabi.dev [Farsi]

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

/learn

احیانا اگر claude دارین، این عناوینی که بصورت هفتگی بهتون میدم رو با این اسکیل /learn خودش بذارید، تر و تمیز، قدم به قدم موضوع رو یادتون میده. یه اسکیل هم خودم ساختم (three-lens-tutor) برای همین مورد با نگاه یک معمار نرم افزار و استراتژیست و استاد فلسفه، دوست داشتین داخل گیت هابم برید بردارین. https://github.com/thisisnabi/10x_developer_skills احیانا اگر اصلاحی خواستین روی اسکیل بدین بنظر روی گیت منم issue باز کنید که عزیزان دیگر هم داشته باشندش. @thisisnabi_dev

/learn

احیانا اگر claude دارین، این عناوینی که بصورت هفتگی بهتون میدم رو با این اسکیل بذارید، تر و تمیز، قدم به قدم موضوع رو یادتون میده.

7. Multileader replication —- 1. Designing Data Intensive Applications - Replication [6] @thisisnabi_dev

من واقعا دغدغه که بتونم این تضمین رو بدم که وقتی یک نفر به امید گرفتن سفارش کرکره مغازه اش رو میده بالا سفارش رو سالم برسونیم دستش. سخته اما شدنیه. @thisisnabi_10x_developer

کتاب خوب بخونید.

قرار نیست که در همه جای برنامه از AI استفاده کنیم، در جاهایی که نیاز به قطعیت هست همون کد های کثیف سابق باید بمونه :) اینجا توضیحات بیشتر دادم. @thisisnabi_dev

اگر قرار باشه دوباره درگیر ساختار های دست و پاگیر در فرایند توسعه نرم افزار بشیم باز رسیدن به خروجی زمانبر خواهد بود. و این دوباره تمرکز ما رو از نیت اصلی دور میکنه. چند روز پیش با یک پروداکت منیجر بصورت تمرینی روی یک PRD کار می کردم و با هم pair شده بودیم، یک داشبورد کامل رو با درنظر گرفتن اکثر جزئیات بیزینسی در 4.5 ساعت کار آماده کردیم. فرایند ها بنظرم کمی به این سمت میره که بیزینس دیگه از شما نمیپزیره یک کار رو چند ماه طول بدین، باید خیلی سریع به فکر ارائه خروجی باشید. برای همین بشخصه تمرکزم روی تغییر مدل کاری تیم و چیدن ساختاری برای رسیدن سریعتر به خروجی هست. حتی یک موضوعی که این روزها فکرم رو درگیر کرده اینه که دیگه اینقدر راحت مثل قبل نیرو در اختیارمون قرار نمیدن، دیدگاه رفته به سمتی که چرا یه بیزینس میلیارد دلاری توی سیلیکون ولی با 10 نفر پیش میره، شما هم برید به اون سمت، کارهای دست و پاگیرتون رو با AI پیش ببرید. این تغییر نشونه بیکارشدن ما نیست ولی بیزینس چی براش کمتر هزینه داشته باشه میره به اون سمت، تا بوده همین بوده. شما سعی کنید مسبب این کاهش هزینه باشید.

وقتی یه agent متونه کد بنویسه، قاعدتا می تونه API هم کال کنه. چرا من فکر می کنم MCP زیاد جواب نیست :/

6. Single Leader Replication —- 1. Designing Data Intensive Applications - Replication [6] @thisisnabi_dev

2 اسپرینت کار بود خدایی :)

من هر موقع موضوعی برام پیچیدس سعی می کنم یه گروه بندی از موضوعات بسازم و بعد کم کم هر گروه رو یاد بگیرم. این تصویر هم برای خودم کمک کننده بوده.

این موضوع جذابی هست، لینک مقاله اصلی هم درش گذاشتم. https://www.linkedin.com/posts/thisisnabi_ai-softwareengineering-aiengineering-share-7483907757029486592-6Lyh/?utm_source=share&utm_medium=member_desktop&rcm=ACoAABdqDr0BJIj7gy7oW3facT7ro7bITsW3Ay0

من توی این تعطیلات درگیر ریفکتور یه سیستم نسبتا بزرگ بودم که حدودا 2 روز زمان من رو گرفت. در تمام این 2 روزی که درگیر بودم یک بار هم به محدودیت مصرف توکن نخوردم. خیلی با حوصله برای دوست عزیزمون توضیح می دادم و اون هم زحمت انجام کار رو می کشید، اینکه دقیقا بدونید چی می خواید خیلی روی مصرف توکن (هزینه) تاثیر گذار هست. اینطوری نباشید که دیگه AI هست، چیزی که من بلدم ارزشی دیگه نخواهد داشت.

کتاب خوب بخونیم. این کتابه کمی گم هست و کم دیدم در موردش صحبت کنن، ولی واقعا کتاب خوبی هست. دیشب توی میت های 10x developer معرفیش کردم، گفتم اینجا هم برای شما هم بذارمش شاید کسی علاقه داشت بخوندش. کلا این سری کتاب های pragmatic خیلی ارزش خوندن دارن و نگاه آدم رو نسبت به موضوعی که قرار هست مطرح کنن، تغییر می دن. @thisisnabi_dev

5. Stream Processing من این منابع برام جذاب بوده، کتاب دومه رو وقت کردین پلن کنید که توی 3 ماه کامل بخونید :) 1. Designing Data-Intensive Applications E2 - Stream Processing [12] 2. Streaming Systems @thisisnabi_dev

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

بعد از چند سانحه معروف، از جمله حادثه پرواز Korean Air Flight 801 crash، مشخص شد که یکی از مشکلات، فرهنگ سازمانی بسیار سلسله‌مراتبی بود؛ کمک‌خلبان‌ها گاهی به جای اینکه مستقیم بگویند «اشتباه می‌کنید»، با تعارف یا اشاره غیرمستقیم حرف می‌زدند. این موضوع باعث شد صنعت هوانوردی کره آموزش‌های گسترده‌ای روی ارتباط مستقیم اجرا کند تا هر عضو خدمه، بدون ملاحظه جایگاه، در شرایط بحرانی واضح و صریح حرف بزند.