AI may be dubbed the great disruptor, but it’s really just an accelerator of whatever you already have. The 2025 DORA report places AI’s primary role in software development as that of an amplifier — a funhouse mirror that reflects back the good, bad, and ugly of your whole pipeline. AI is proven to be impactful on the individual developer’s work and on the speed of writing code. But, since writing code was never the bottleneck, if traditional software delivery best practices aren’t already in place, this velocity multiplier becomes a debt accelerator.

I don’t think LLMs change the value of rapidly building and releasing small slices of capability. The promise of LLMs is to increase the frequency of that cycle, and doing more in each release.

Even a legend of the industry like Grady Booch, who has been appropriately dismissive of AGI claims and is actively disdainful of AI slop posted recently that he was “gobsmacked” by Claude’s abilities. Booch’s advice to developers alarmed by AI on Oxide’s podcast last week? “Be calm” and “take a deep breath.” From his perspective, having watched and shaped the evolution of the technology first hand over a period of decades, AI is just another step in the industry’s long history of abstractions, and one that will open new doors for the industry.

…whether one wants those doors opened or not ultimately is irrelevant. AI isn’t going away any more than the automated loom, steam engines or nuclear reactors did. For better or for worse, the technology is here for good. What’s left to decide is how we best maximize its benefits while mitigating its costs.

✍️ Fragments: February 18

🔘 @TerminalNotes <- #ai

🔘 @TerminalNotes <- #life

🔘 @TerminalNotes <- #FREEDOM

اگر برنامه‌نویس Go هستید و الان به هر طریقی به دسترسی اینترنت دارید، میتونید داکیومنت‌های stdlib رو لوکال در دسترس داشته باشید؛ با pkgsite می‌تونید مشابه pkg.go.dev مستندات رو روی سیستم خودتون بالا بیارید. نصب:

go install golang.org/x/pkgsite/cmd/pkgsite@latest

بعد از نصب، مطمئن بشید دایرکتوری باینری‌های گولنگ توی PATH سیستم‌تون باشه، در غیر این صورت دستور pkgsite شناسایی نمیشه:

export PATH="$PATH:$(go env GOPATH)/bin"

بعد وارد یک پروژه که فایل go.mod داره بشین و دستور زیر رو اجرا کنید:

pkgsite -open .

حالا مستندات stdlib از آدرس زیر در دسترسه و میتونید سرچ کنید:

http://localhost:8080/std

نکته: یا اسم پکیج مورد نظر رو توی سرچ بزنید (مثل fmt یا net/http) یا مستقیم آخر آدرس رو
/std
بذارید تا لیست stdlib رو ببینید.

💠 سبک تر کردن دانلود

اگر سورس Go رو روی سیستم دارید، مسیرش رو بدید تا نیازی به دانلود دوباره داک نباشه (که توی این وضعیت اذیت نکنه):

pkgsite -open -gorepo $(go env GOROOT)

🔘 @TerminalNotes <- #programming #golang

اگر با Rust هم کار میکنید و از طریق toolchain اون یعنی rustup نصبش کردید همه مستندات stdlib بدون هیچ کار اضافه‌ای آفلاین آمادس:

rustup doc

🔘 @TerminalNotes <- #programming #rust

توی دنیای DevOps و SRE ارزش شما با «میزان عمق دانش از یک ابزار» سنجیده نمیشه، بلکه به این هست که چقدر خوب می‌تونید دانشتون از ابزارهای مختلف رو به هم متصل کنید تا یک مشکل واقعی کسب‌وکار رو حل کنین. اینجاست که بازدهی زمانِ یادگیری (ROI) از قانون 80/20 پیروی میکنه: یادگیریِ 20 درصد از قابلیت‌های یک ابزار، 80 درصد از نیازهای روزمره شما رو برطرف میکنه. اگه خیلی زود درگیر یادگیری جزئیات و ریزه‌کاری‌های یک ابزار بشید، وقت باارزشی رو هدر میدید که می‌تونستید صرف یادگیری کلیت سیستم و بقیه ابزارها کنید.

مثلا اکر جونیور هستین و ۴۰ ساعت وقت بذارید و داکیومنت‌های NGINX رو از سیر تا پیاز بخونید، شاید یاد بگیرین که چطوری بافرهای سطح پایینِ ورکرها (Workers) رو با زبان C دستکاری کنید و کلی کار خفن دیگه. اما یه کارآموز یا جونیور واقعا چند وقت یک‌بار به همچین چیزهایی نیاز پیدا میکنه؟ تقریبا هیچ‌وقت. توی این حالت بازدهی یادگیری شما پایینه، چون ۳۵ ساعت از اون ۴۰ ساعت رو صرف چیزهایی کردید که احتمالا تا سال‌ها به کارتون نمیاد.

📈 چطوری بازدهی (ROI) را بالا ببریم؟

پیاده کردن قانون 80/20 خیلی سادس: وقتی با ابزار جدیدی روبه‌رو میشید، سراغ 20 درصدی برید که برای راه‌اندازی و انجام یه کار واقعی به اون نیاز هست.

اما یه سوال مهم اینجا مطرح میشه: کدوم 20% رو باید یاد گرفت؟

راه درستش اینه که همیشه از یه سنیور یا تیم‌لید بپرسید؛ اگر در دسترس نیست از AI. بدون این راهنمایی، ریسک اینو دارید که اشتباهی چیزهای حیاتی رو «advanced» فرض کنید و skip کنید (یا برعکس).

💭 اما آیا این یعنی همیشه سطحی بمونیم؟

ممکنه بگید اگه تمام اعضای تیم فقط دانش سطحی و گسترده داشته باشن، سایت یا اپلیکیشن شما با قطعی‌های طولانی‌مدت مواجه میشه (که درسته). به همین دلیله که شرکت‌ها مهندس Senior استخدام میکنن؛ کسایی که در طول بیش از 7 سال کار، به تدریج دانش خودشون توی ابزارها رو عمیق کردن و تو شرایط بحرانی، جونیورها رو پشتیبانی میکنن.

این مدل توی صنعت به T-Shaped Engineer معروفه:

بخش افقیِ T: آگاهی گسترده از ابزارهای مختلف
بخش عمودیِ T: عمق واقعی در حداقل یک حوزه

هدف اینه که در مسیر رشدتون، به تدریج اون بخش عمودی رو بسازید، نه از روز اول.

🔘 @TerminalNotes <- #devops #sre

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

کتاب خوندن یکی از بهترین راه‌ها برای حفظ این حرکته. شاید این حرف کلیشه‌ای باشه و همه‌جا شنیده باشین (که البته درست هم هست)، اما صحبت الان من چیز دیگه‌ایه: چطوری باید با کتاب‌های حوزه IT رفتار کنیم؟

1. خوندن کتاب‌های IT با رمان فرق می‌کنه

وقتی خوندن یه کتاب فنی رو شروع می‌کنین، لزوما قرار نیست اون رو از فصل اول تا آخر پشت سر هم بخونین. برای اینکه بدونین دقیقا چقدر از یه کتاب رو باید مطالعه کنین، به همون قانون ۲۰/۸۰ که توی پیام قبل گفتم مراجعه کنید.
با بقیه کتاب مثل یه مرجع (Desk Reference) رفتار کنین؛ یعنی هر وقت برای حل یه مسئله به بخش خاصی نیاز پیدا کردین، همون بخش رو بخونین. این روش مزایای خودش رو هم داره: وقتی یه مفهوم جدید رو یاد می‌گیرین و همون لحظه ازش استفاده می‌کنین، ماندگاریش توی ذهن به مراتب بیشتر میشه.

2. مراقب کتاب‌های تاریخ‌گذشته (Outdated) باشین

توی دنیای IT، کتاب‌هایی که موضوعشون مرتب در حال تغییر و تحوله (مثل Docker) و بیشتر از 2 سال از انتشارشون میگذره، توی این حوزه منسوخ حساب میشن. پس اگه منابع به‌روزتر و بهتری در دسترس دارین، وقتتون رو صرف کتاب‌های قدیمی نکنین.

🔘 @TerminalNotes <- #book #it

🔘 @TerminalNotes <- #tmux

🔗 Tmux Cheat Sheet

🔘 @TerminalNotes <- #site #tmux

🔗 Docmost

An open-source team wiki and documentation platform built for internal knowledge sharing.

Good for:
• Shared notes and SOPs
• Team wikis and internal docs
• Real-time collaboration

🔗 AFFiNE

An open-source all-in-one workspace that combines docs, whiteboards, and visual planning.

Good for:
• Brainstorming sessions
• Mind maps and whiteboards
• Visual note-taking
• Flexible idea organization

🔗 Outline

An open-source team knowledge base and wiki designed for fast internal documentation and collaborative writing.

Good for:
• Team knowledge bases
• Shared knowledge in one place
• Collaborative wiki-style writing

🔘 @TerminalNotes <- #tool

چطور هرچیزی رو‌ یاد بگیریم؟

نوشته خشایار حاجی‌پور

۱/۲۱
بیشترِ آدم‌هایی که توی یاد گرفتنِ یه چیز شکست می‌خورن، نه تنبل‌ان نه کمهوش.
فقط یه فرمولِ ساده رو بلد نیستن.
ده سال زبان درس دادم و چند سال یوتیوب کار کردم — این همون چیزیه که هر بار جواب داده.

۲/۲۱
دو تا دام هست:
— یکی ادامه می‌ده ولی هیچ‌وقت خودش رو اصلاح نمی‌کنه.
— یکی دائم چیز جدید امتحان می‌کنه ولی هیچ‌جا نمی‌مونه.
هر دو تلاش می‌کنن. هیچ‌کدوم به جایی نمی‌رسن.

۳/۲۱
فرمولِ یاد گرفتنِ هر چیزی فقط دو عنصر داره:
استمرار + تکرار و اصلاح.
(consistency + iteration)
همین. نه بیشتر.

۴/۲۱
استمرار بدونِ اصلاح = صد بار یه راهِ غلط رو رفتن.
اصلاح بدونِ استمرار = هیچ‌وقت نموندن تا جواب بده.
هیچ‌کدوم به‌تنهایی کار نمی‌کنه. فقط کنار هم.

۵/۲۱
تصور کن سوارِ ماشینی و می‌خوای به یه مقصد برسی.
موتور جلو می‌برتت → استمرار.
فرمان جهت می‌ده → اصلاح.
فقط گاز بدی گم می‌شی؛ فقط فرمان بچرخونی تکون نمی‌خوری.
به مقصد می‌رسی وقتی هر دو رو داشته باشی.

۶/۲۱
چرا استمرار ضروریه؟
چون بدونش وارد «باغِ» یه مهارت نمی‌شی.
هر کسی می‌تونه دو ساعت راجع به یه چیز بخونه. ولی اهلِ کار با دو جمله می‌فهمه تو باغ نیستی.
فقط موندن تو رو می‌بره داخل.

۷/۲۱
استمرار، اثرِ مرکب می‌سازه.
هر چیزِ خوبی که دور و برت می‌بینی، نتیجه‌ی ادامه دادن در یه مسیره.
و نتیجه نمایی رشد می‌کنه: اولش کند، بعد یهو میترکه.
ولی فقط برای کسی که موند.

۸/۲۱
استمرار، تصویرت از واقعیت رو درست می‌کنه.
قبل از شروع، یه تصویرِ خیالی از کار داری.
لحظه‌ای که ادامه می‌دی، اون تصویر زمین تا آسمون عوض می‌شه — و تصمیم‌های بهتری می‌گیری.

۹/۲۱
دو دلیلِ دیگه:
اعتبار میان‌بر نداره؛ معتبرترین آدم‌ها مدتِ طولانی کارشون رو کردن.
و خلاقیت، ته استمراره. کسی که دو ماهه ساز می‌زنه آهنگسازِ بزرگ نمی‌شه. اول باید بمونی، تا بتونی نو بسازی.

۱۰/۲۱
ولی تکرارِ خالی بهترت نمی‌کنه — فقط همون شیار رو عمیق‌تر می‌کنه.
هزار بار یه حرکت رو غلط تمرین کن، می‌شی استادِ همون غلط.
استمرار سرعته، اصلاح جهت. سرعت در جهتِ غلط یعنی سریع‌تر شکست خوردن.

۱۱/۲۱
کلِ اصلاح، توی یه چرخه اتفاق می‌افته:
تلاش → فیدبک → اصلاح → تکرار.
فیدبک رو حذف کنی، داری حدس می‌زنی.
اصلاح رو حذف کنی، داری فقط تکرار می‌کنی.

۱۲/۲۱
یه چرخهی خوب:
— یه هدفِ مشخص داره (نه همه‌چیز با هم)
— سریعه
— کوتاهه
— فیدبک داره
— نتیجه‌ش روشنه
هرچی چرخه کوتاه‌تر، یادگیری سریع‌تر.

۱۳/۲۱
نکته‌ای که کم گفته می‌شه:
مغز وقتی بیشتر یاد می‌گیره که بین کار و استراحت نوسان کنی.
موقعِ کار اطلاعات رو «جمع» می‌کنی؛ موقعِ استراحت و خواب، مغز «بایگانی‌شون» می‌کنه.
برای همین خواب، نصفِ یادگیریه.

۱۴/۲۱
مثلِ شیر زندگی کن.
شیر یه‌سره نمی‌دوه. استراحت می‌کنه، بعد با تمامِ توان شکار می‌کنه، دوباره استراحت.
این نوسان هم یادگیری رو عمیق‌تر می‌کنه، هم نمی‌ذاره انرژیت ته بکشه.

۱۵/۲۱
مهم‌ترین حرفِ این رشته:
استمرار «بی‌وقفه موندن» نیست. استمرار هنر بازگشته.
حواس‌پرتی برای همه پیش میاد. برنده اونیه که بلده برگرده.
بازنده اونی نیست که یه روز نزد؛ اونیه که برنگشت.

۱۶/۲۱
و هر بار که برمی‌گردی، قوی‌تر می‌شی.
استمرار مثلِ ماهیچه‌ست: هرچی بیشتر ازش کار بکشی، قوی‌تر می‌شه.
هر بازگشت، بازگشتِ بعدی رو آسون‌تر می‌کنه.

۱۷/۲۱
چطور بمونیم؟
— چراییت رو روشن کن (دلیلِ مشخص نگهت می‌داره)
— آستانهی بازگشت رو بیار پایین («فقط ۵ دقیقه»)
— با بقیه انجامش بده
— به سیستم تکیه کن، نه انگیزه

۱۸/۲۱
برای اصلاح، فیدبکِ صادق لازمه — نه «عالی بود» دوست و فامیل.
فیدبکِ راست از سه جا میاد:
— بازارِ آزاد (آمار دروغ نمی‌گه)
— طبیعت (واقعیت دروغ نمی‌گه)
— آدم‌هایی که تعارف ندارن

۱۹/۲۱
دو قانونِ طلایی اصلاح:
۱) هر بار فقط یه چیزِ کوچیک رو بهتر کن. مغز یه‌جا فقط رو یه چیز تمرکز می‌کنه.
۲) چیزی که جواب داد رو قفل کن، دستش نزن، برو سراغِ ضعفِ بعدی.

۲۰/۲۱
خلاصه:
استمرار تو رو تو بازی نگه می‌داره. اصلاح راهیه که باهاش می‌بری.
یه چیز رو انتخاب کن. بمون. هر بار یه چیزِ کوچیک رو بهتر کن.
چون هیچ چیزِ خوبی در زندگی به دست نمیاد، مگر با استمرار.

۲۱/۲۱
این رشته، خلاصه‌ی یه کتابچه‌ست که کاملش رو نوشتم.
کتابچه‌ی «چطور هر چیزی رو یاد بگیریم؟» رو می‌تونید رایگان از کانالِ تلگرامِ خشایار تاکس دریافت کنید.

همه جا صحبت از هوش مصنوعی هست، اما نحوه درست استفاده ازش کمتر راجبش بحث میشه.

کلیت مسئله: لازم هست هرکس برای خودش «خط قرمز» داشته باشه تا دچار وابستگی بیش از حد نشه. این خط قرمزها برای هر کس، بسته به شغل و نیازش، متفاوته.

چرا باید خط قرمز داشته باشیم؟ که مغز رو همچنان در حالت «تقلا» (Struggling) نگه داریم. اگه همه چیز رو به هوش مصنوعی بسپاریم، خلاقیت و هنر حل مسئله در مغز ما به مرور ضعیف میشه.

نمونه شخصی:
به جای دادن پرامپتِ «این کد/برنامه رو برای من بنویس» به هوش مصنوعی:
۱. کد رو مینویسم و روی اون فکر میکنم.
۲. در آخر، کد را به AI میدیم برای ارزیابی دست خط یا بهینه کردن اون.

🔘 @TerminalNotes

منظور از «دست خط» خوانایی کد هست. یه نفر دست خطش خوبه همه میتونن بخون، یکی بدخطه.

🔗 How To Get Out of Tutorial Hell (Step by Step Guide)

🔘 @TerminalNotes <- #youtube

🔗 Tutorials Are KILLING Your Growth | Prime Reacts

🔘 @TerminalNotes <- #youtube

خلاصه ویدیو ها: چطور ابتکار عمل داشته باشیم و از صفر پروژه بنویسیم.

برای جونیور دولوپر برنامه نویسی یه جور crafting یا سر هم کردن هست بیشتر تا ابتکار عمل که به مرور به مرحله ابتکار هم میرسه.

🔗 Monkey see, monkey do.

🔘 @TerminalNotes

🔘 @TerminalNotes