<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های میتریل</title>
        <link>https://virgool.io/feed/@mithril_tech</link>
        <description>https://t.me/mithril_tech</description>
        <language>fa</language>
        <pubDate>2026-06-10 12:48:13</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/3949629/avatar/hGKEai.jpg?height=120&amp;width=120</url>
            <title>میتریل</title>
            <link>https://virgool.io/@mithril_tech</link>
        </image>

                    <item>
                <title>برای ارشد‌تر شدن باید کمتر کد زد :)</title>
                <link>https://virgool.io/@mithril_tech/%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D8%B1%D8%B4%D8%AF-%D8%AA%D8%B1-%D8%B4%D8%AF%D9%86-%D8%A8%D8%A7%DB%8C%D8%AF-%DA%A9%D9%85%D8%AA%D8%B1-%DA%A9%D8%AF-%D8%B2%D8%AF-rsjkrdwj5igy</link>
                <description>برای اینکه senior تر بشیم نیازه تا کارهایی بیشتر از فقط کد زدن انجام بدیم و قصد دارم در این پست، مختصرا به چارچوب Produce, Organize, Publish  بپردازم.داستان از اینجا شروع میشه که ما نباید فقط کد بزنیم و بلکه باید این توانایی رو داشته باشیم که در کنار تیم و همراه با دیگران کار کنیم و بقیه‌ رو از تاثیرات کارهایی که انجام می‌دهیم مطلع کنیم.خب حالا سه بخش از این چارچوب چی هستند:تولید کردن(produce) یعنی  مواردی مثل: کد‌زدن، نوشتن داکیومنت، بررسی کد‌های دیگران(code review) و …  هستش.سازماند‌هی و تسهیل (organize) کردن روند‌ها و روال‌ها، در راستای بهتر انجام شدن کار‌هاست. به عنوان مثال ارائه روش‌ بهتر برای کار درون تیم یا اصلاح روند برگزاری جلسات،‌ بهبود روند گزارش باگ‌های نرم‌افزار، اصلاح روند انجام code review و سایر مواردی از این قبل که یک رفتار یا روند درون تیم و سازمان رو تحت شعاع قرار می‌دهند.و مورد آخر هم انتشار(publish) کار خودتون در جلسات هستش که این جلسات میتونه شامل جلسات یک به یک با مدیر و هم‌تیمی هاتون باشه یا سایر جلساتی که در سازمانتون برگزار میشن و در راستای  تغییراتی هستند که شما و تیم شما انجام دادند(produce, organize) و فرصت این هست با بقیه افراد سازمان درباره کار‌هایی که کرده‌اید صحبت کنید. این باعث میشه که  کار شما بیشتر دیده بشه و در نهایت اثر‌گذاری شما و تیمتون بیشتر دیده میشه.در اکثر سازمان‌ها و شرکت‌ها، شما هر چه senior تر بشید(staff, principle, director) این انتظار بیشتر از شما میره که organize و publish  رو بیشتر از produce انجام بدید. * تصویر پست خلاصه‌ای از این صحبت‌هاست.* برگرفته‌ از کتاب The Software Engineer&#x27;s Guidebook</description>
                <category>میتریل</category>
                <author>میتریل</author>
                <pubDate>Fri, 23 May 2025 15:06:27 +0330</pubDate>
            </item>
                    <item>
                <title>چرا  گزارش کار شخصی مکتوب داشته باشیم ‌؟‌</title>
                <link>https://virgool.io/@mithril_tech/%DA%86%D8%B1%D8%A7-%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%DA%A9%D8%A7%D8%B1-%D8%B4%D8%AE%D8%B5%DB%8C-%D9%85%DA%A9%D8%AA%D9%88%D8%A8-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-swy57y5pf7fd</link>
                <description>خیلی از ما برنامه‌نویس‌ها و مهندس‌ها گزارش یا لیست از کارهایی که انجام داده ایم(work log) رو جایی نگهداری نمی‌کنیم. خب در برخورد اول هم بنظرمون بدرد نخوره یا به این فکر میکنیم که اون موارد رو توی جیرا یا ابزار مدیریت پروژه‌مون یا pull request های github یا gitlab داریم. یا دوست داریم به حافظه‌مون رجوع کنیم که معمولا در بهترین حالت یک هفته رو کم و بیش یادمونه :))دقیق تر درباره work log بگم که ما لیستی مکتوب از کارهایی رو که توی یک بازه زمانی انجام دادیم رو نگهداری کنیم، این می‌تونه شامل  جلسات، task‌ها ،‌ code review‌ها و … باشه که توی شرکتمون انجام دادیم.از خوبی‌هاش براتون بگم :  - در شرکت‌ها و مجموعه‌هایی که روند و مسیر شغلی(career path) مشخصی برای هر فرد وجود داره و شما طی بازه‌های زمانی مشخص مورد ارزیابی عملکرد قرار میگیرد میتونید ازش استفاده کنید.بجای اینکه شروع کنید در git شرکتتون یا ابزار مدیریت پروژه شرکتتون دنبال کارهایی که در ۶ ماه یا یک سال گذشته انجام دادید برگردید میتونید به اون داکیومنت شخصی‌ای که نوشتید رجوع کنید و همه چیز رو مرتب اونجا پیدا کنید (‌ در ادامه چند قالب برای این داکیومنت بهتون معرفی میکنم)- در شرکت‌ها و سازمان‌هایی هم که روند مشخصی برای ارتقا شغلی  و ارزیابی وجود نداره و فقط قدرت کلام شماست که حقوق شما رو مشخص میکنه :)) می‌تونید از این داکیومنت استفاده کنید که به موارد زیر در جلسه تمدید قرارداد جواب بدید:من فکر میکنم که شما در فلان پروژه عملکرد خوبی رو نداشتید.به نظرم شما در یک سال گذشته عملکردتون خوب نبوده و بر چه اساس باید این حقوق و مزایا موافقت کنیم؟و …- به نظرم وجه شخصی هم داره و شما خودتون میتونید چک کنید که عملکردتون آخر این ماه یا این هفته چطوری بوده؟‌چطوری بنویسم: خودم دوست دارم که ۲ هفته به ۲ هفته بنویسم ( هر sprint مجزا) و معمولا هم آخر هر روز یا دو روز یکبار مواردی رو که انجام دادم داخل فایل google doc مینویسم.ولی شما هر طوری که راحت‌تر هستید انجامش بدید مثلا هفتگی، ماهانه و کوتاه تر از این مدت‌ها مثلا روزانه شاید نیاز نباشه. چند تا قالب‌ها زیر این پست براتون قرار میدم که راحت تر بتونید شروع کنید.پ.ن:بخش‌هایی از متن از کتاب The Software Engineer&#x27;s Guidebook الهام گرفته شده است. قالب‌‌ها</description>
                <category>میتریل</category>
                <author>میتریل</author>
                <pubDate>Fri, 11 Apr 2025 17:27:13 +0330</pubDate>
            </item>
            </channel>
</rss>