در سال ۱۹۹۵، واتس هامفری (Watts Humphrey)-معروف به پدر کیفیت نرم‌افزار- فرایند توسعه‌ی نرم‌افزاری معرفی کرد که برای توسعه‌دهندگان در سطح فردی طراحی شده بود.

این فرایند در عمل شکست خورد.

«فرایند نرم‌افزار شخصی» (Personal Software Process – PSP) به توسعه‌دهنده اجازه می‌داد فرایندی تعریف‌شده، قابل‌اندازه‌گیری و با امکان بهبود مستمر برای خودش داشته باشد. این فرایند روی کاغذ کار می‌کرد، اما سربار ثبت و مستندسازی‌اش عامل شکست این فرایند شد: ثبت زمان، ثبت خطاها و پر کردن فرم بعد از هر فعالیت. تقریبن هیچ‌کس نمی‌توانست این کارها را برای طولانی‌مدت انجام بدهد. هامفری بعدها به سراغ فرایندهای در سطح تیم (Team Processes) رفت. و ناگفته خود پیداست «تیم» کوچک‌ترین واحد طراحی فرایند در سی سال گذشته بوده است.

به باور من این موضوع در حال تغییر و تحول است.

نگاهی کنید به آن‌چه یک دستیار کدنویسی هوش مصنوعی (AI Coding Assistant) واقعن در اختیار شما می‌گذارد:

→ مهارت‌ها (Skills): توانایی‌های ازپیش‌تعریف‌شده و قابل استفاده‌ی مجدد برای انجام کارهای مشخص در چرخه‌ی حیات توسعه‌ی نرم‌افزار (Software Development Life Cycle – SDLC)، مانند تحلیل، طراحی، آزمون و بازبینی
→ زیرعامل‌ها (Subagents): عامل‌های تخصصی که هرکدام مسئول انجام وظیفه‌ای مشخص‌اند
→ هوک‌ها (Hooks): اقداماتی که در نقاط مشخصی از فرایند به‌صورت خودکار اجرا می‌شوند
→ فایل‌های حافظه (Memory Files): فایل‌هایی برای نگهداری قواعد، دستورالعمل‌ها و اطلاعاتی که عامل باید در طول کار به خاطر داشته باشد

به کمک آنها شما می‌توانید یک فرایند کامل بسازید؛ فرایندی که طراح آن خود شمایید.

این نگاه، تکرار داستان «ساخت ارتشی از عامل‌ها» (Army of Agents) که این روزها همه‌گیر شده نیست. عامل‌ها هیچ‌وقت موضوع اصلی این داستان نبوده‌اند. اصل ماجرا این است که این روزها ماشین (یا همان هوش مصنوعی)‌ می‌تواند همان سرباری که PSP را از پا درآورد یک تنه به دوش بکشد: ثبت پیوسته، اندازه‌گیری و اعمال قواعد.

هامفری درست می‌گفت؛ فقط سی سال زود گفته بود!

من اسم این ایده را «فرایند تک نفره» (Process of One) گذاشته‌ام و این روزها سخت مشغول فکر کردن و ساختن آن هستم.

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

این اصل مهندسی هوش مصنوعی (AI Engineering) را هم برای این کار می‌توان استفاده کرد: چیزی را که اندازه‌ نمی‌گیرید، درباره‌اش فقط می‌توانید حدس بزنید (if you don’t measure it, you’re guessing). پس برای ارزیابی کارایی فرایند شخصی‌ام مدام می‌پرسم : آیا واقعن داره کار می‌کنه؟

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

شما فرایند خودتان را چگونه طراحی می‌کنید؟

پانوشت:
ساخت یک کاتالوگ از این الگوها (Patterns) رو شروع کردم؛ تا امروز ۱۹ الگو با کمک ای‌آی بررسی و مدون شده‌. همه‌ی الگوها با یک ساختار یکسان نوشته شده‌: موقعیت (Situation)، مساله (Problem)، راهکار (Solution) و منبع (Source). می‌‌تونید اونها رو در این آدرس در گیت‌هاب پیدا کنید: لینک

گزیده:
بیرون ز تو نیست هرچه در عالم هست
در خود بطلب هر آنچه خواهی که توئی
مولانا

اگر هر روز برای برنامه‌نویسی از هوش مصنوعی استفاده می‌کنید، احتمالاً متوجه یک موضوع عجیب شدید: هرچه بیشتر با دستیار هوش مصنوعی‌تون حرف می‌زنید، احمق‌تر می‌شه.

بیشتر برنامه‌نویسان این موضوع را حس می‌کنند اما نمی‌تونند نامی روی اون بگذارند؛ گفتگو را شروع می‌کنید و دست‌یارتون فوق‌العاده عمل می‌کنه. یک ساعت بعد- همان مدل و همان کار- دستورهای قبلی شما رو فراموش می‌کنه و خطاهایی رو که قبلاً رفع کرده بود، دوباره تکرار می‌کنه. شما خودتون و روش کارتون و احتمالن دانش‌تون رو مقصر می‌دونید، اما این کارتون منطقی نیست.

«مَت پوکاک» (Matt Pocock) این وضعیت رو منطقه هوشمند (Smart Zone) و منطقه کندذهن (Dumb Zone) می‌نامد. مدل در ابتدای یک نشست (Session) بسیار سریع و دقیقه، اما کیفیت‌ کارکردش قبل از اینکه ظرفیت گفتگوی شما با اون (چت) واقعاً «پُر» بشه، افت می‌کنه. و بخش غافلگیرکننده داستان اینجاست: «حافظه‌ی کاری» (Working Memory) یا «پنجره‌های کاری» (Context Windows) بزرگی که همه درباره‌اش صحبت می‌کنند، در عمل، فضای هوشمند بیشتری در اختیارتون نمی‌ذارند؛ فقط منطقه کندذهن بزرگ‌تری در اختیارتان می‌گذارند.
[حافظه‌ی کاری یا پنجره‌ی کاری، حداکثر متنی است که یک مدل زبانی می‌تونه در هر زمان ببینه یا به خاطر بسپاره]

شرح فنی: طول پنجره‌ی کاری مؤثر یک مدل زبانی، بسیار کوتاه‌تر از پنجره تبلیغ‌شده‌ی اونه. دلیل‌ش اینه که با طولانی شدن گفتگوی شما با مدل زبانی، تمرکز مدل بین توکن‌های (کلمات) بیشتری پخش و در نتیجه تمرکز اون ضعیف‌تر و کم‌رنگ‌تر می‌شه، جزئیاتِ بخش میانی متن نادیده گرفته می‌شه (پدیده «گم شدن بخش میانی متن» یا Lost in the Middle) و مدل مدام بر اساس اشتباهات قبلی خود که هنوز در تاریخچه چت باقی مونده‌اند، به کارش ادامه می‌ده.

بنابراین، راه‌حل این مشکل نوشتن یک پرامپت (Prompt) بهتر نیست؛ بلکه داشتن یک حافظه کوتاه‌تره: یک کار رو انجام بدید، گفتگوی اون کار رو پیش ببرید و بعد که تموم شد، همه‌ چی رو پاک کنید و روز از نو و روزی از نو.

برای کارهای بزرگ‌تر، حافظه را به خارج از گفتگو منتقل کنید: هدف نهایی کارتون رو توی یک فایل مشخصات (Specification) بنویسید، مسیر رسیدن به هدف رو به کارهای کوچک و مستقل از هم تقسیم کنید و به هر کار یک حافظه/پنجره (Context) تر و تمیز و نو اختصاص بدهید. هدف این نیست که هر چیزی که هوش مصنوعی احتمالاً می‌تونه بدونه بهش بدهید؛ هدف اینه که دقیقن همون چیزی رو که برای کار پیشِ رو نیاز داره، در اختیارش بگذارید.

پس یادتون نره: دستیار شما هیچ‌وقت خسته نمی‌شه، فقط پُر می‌شه.

ویدیو و کارگاه فوق‌العاده‌ی مَت پوکاک با عنوان “Full Walkthrough: Workflow for AI Coding” را توصیه می‌کنم که ببینید. من از این کارگاه چیزهای زیادی یاد گرفتم.

منبع: کارگاه مَت پوکاک با عنوان Full Walkthrough: Workflow for AI Coding.: [لینک]

یک نکته کاربردی از این کارگاه: یک شمارنده توکن (Token Counter) رو در محیط کارتون و جلوی چشم داشته باشید. به محض تمام شدن یک کار، گفتگوی خودتون با دست‌یار هوش‌ مصنوعی‌تون رو پاک کنید. یک نشست (Session) جدید، همیشه از یک پرامپت هوشمندانه بهتر عمل می‌کنه.

گزیده:
هر نفس نو می‌شود دنیا و ما
بی‌خبر از نو شدن اندر بقا
مولانا

بعد از ماه‌ها که «نوشتن‌ام نمی‌آمد» (و شما خواننده‌ و دوست عزیزم می‌دانید که چرا)، به «نوشتن» روی آورده‌ام. امید که روزهای بهتر و درخشان‌تری پیش روی همه‌ی ما و میهن‌مان باشد.



گزیده:
چند بار امید بستی و دام برنهادی
تا دستی یاری‌دهنده،
کلامی مهرآمیز،
نوازشی ،
یا گوشی شنوا
به چنگ آری؟

چند بار
دامت را تهی یافتی؟

از پای منشین!
آماده شو که دیگر بار و دیگر بار
دام بازگستری.

پیش‌گفتار:
سیاهی لشکر نیاید به کار
یکی مرد جنگی به از صد هزار

اندرو اِنگ (Andrew Ng)، بنیان‌گذار DeepLearning.AI و یکی از بنیان‌گذاران Google Brain، پیام روشن و در عین حال چالش‌برانگیزی برای توسعه‌دهندگان نرم‌افزار که نظاره‌گر دنیای هوش مصنوعی‌اند دارد:
“هوش مصنوعی جایگزین توسعه‌دهندگان نرم‌افزار نخواهد شد، اما توسعه‌دهندگان نرم‌افزاری که از هوش مصنوعی استفاده می‌کنند، جایگزین کسانی خواهند شد که استفاده نمی‌کنند. آینده کدنویسی، سمفونی بین حل مسئله توسط انسان و ظرفیت هوش مصنوعی برای اجرای سریع آنهاست. ارزش اصلی شما از نوشتن کد به معماری، اشکال‌زدایی و مهم‌تر از همه، هدایت دست‌یارهای هوشمند تغییر می‌کند. یاد بگیرید که به زبان هوش مصنوعی صحبت کنید تا به یک مهندس ۱۰-برابر قوی‌تر تبدیل شوید.”

این بخش‌هایی است از سخنرانی اندرو انگ با عنوان «از کدنویسی تا محصول در چند ساعت — واقعیت جدید توسعه‌ی مبتنی بر هوش مصنوعی» که برخی از نکات مهم آن را در زیر آورده‌ام.

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

۱) تمرکز و نگاهی نو بر سرعت
سرعت، بزرگترین پیش‌بینی‌کننده (predictor) موفقیت برای پروژه‌های نوآورانه است. هوش مصنوعی عامل افزایش این سرعت است: سرعت ساخت نمونه‌های اولیه و محصولات مستقل کوچک را ده برابر و سرعت تولید محصولات نهایی و آماده‌ی استفاده را حدود ۵۰٪ افزایش می‌دهد.

۲)‌ فلسفه‌ی نوین نرم‌افزار
شعار جدید تیم‌های باهوش (smart) این است که “سریع حرکت کن و پاسخ‌گو باش (move fast and be responsible.). ” این شعار به این معناست که نمونه‌هایی (prototypes) در محیطی امن و ایزوله و خیلی سریع ساخته شوند و سپس به نمونه‌های مقیاس‌پذیر انتخاب‌شده،‌ ایمنی و امنیت افزوده می‌شود.

۳) کد در قالب فراورده (Artifact-خروجی)
از آنجا که هوش مصنوعی می‌تواند کد را بنویسد، کد به عنوان یک خروجی، ارزش کمتری پیدا می‌کند. چنین اتفاقی باعث می‌شود تصمیمات مهم، مانند معماری یا طراحی پایگاه داده، بیشتر شبیه یک “درب دوطرفه”‌ می‌شوند (یعنی برگشت‌پذیرند، به عبارت دیگر تصمیم‌هایی که اگر اشتباه باشند، می‌توان به‌راحتی اصلاح‌شان کرد). چنین قابلیتی امکان (iteration) تکرار بیشتر و حتا از نوسازی از ابتدا را فراهم می‌کند.

۴) گلوگاه (Bottleneck) جدید
همانطور که ساخت نرم‌افزار آسان‌تر می‌شود، تصمیم‌گیری در مورد اینکه چه چیزی بسازیم (what to build)، به بزرگترین گلوگاه تبدیل می‌شود. اِنگ این را “گلوگاه مدیریت محصول” (product management bottleneck) می‌نامد.

۵) افزایش و بهبود شهود (Honing Your Intuition)
توسعه‌دهندگان باید برای توسعه و افزایش شهود و قضاوت درونی خود از کاربران برای تصمیم‌گیری درباره‌ی محصولات تلاش کنند. هدف از جمع‌آوری داده‌های کاربر، آموزش شیوه‌ی قضاوت شماست، نه فقط استفاده از آنها برای تصمیم‌گیری در یک مورد خاص.

۶) یادگیری کدنویسی
این توصیه که مردم نباید کدنویسی یاد بگیرند زیرا هوش مصنوعی آن را خودکار خواهد کرد، “یکی از بدترین توصیه‌های شغلی تاریخ است.” هر گام خودکارسازی (از اسمبلی گرفته تا زبان‌های سطح بالاتر و هوش مصنوعی) کدنویسی را با ارزش‌تر و در دسترس‌تر کرده است.

۷) مهارت‌های ضروری در آینده
مهم‌ترین مهارت در آینده این است که بتوانید به یک کامپیوتر دقیقن بگویید که از او انتظار دارید چه کاری انجام دهد(tell a computer exactly what you want it to do). دانستن زبان کامپیوتر و کدنویسی، درک عمیق‌تری برای کنترل دقیق‌تر ابزارهای هوش مصنوعی فراهم می‌کند.

۸) نقش مهندس هوش مصنوعی (AI Engineer)
ما با کمبود “مهندس هوش مصنوعی” رو به رو هستیم. مهارت‌های مورد نیاز برای این نقش نوظهور عبارتند از: آشنایی با کدنویسی به کمک هوش مصنوعی، تخصص در بلوک‌های ساختاری هوش مصنوعی (AI building blocks, including RAG, agent workflows)، مهارت‌های نمونه‌سازی سریع (rapid prototyping skills) (از جمله دانش پایه فول‌استک – basic full-stack)، و مهارت‌های اولیه مدیریت محصول و قضاوت کاربر (user judgment).

۹) مهندسی سریع (Rapid Engineering):
اندرو اِنگ اصطلاح “مهندسی سریع” (Rapid Engineering) را به “وایب کدینگ” (vibe coding) ترجیح می‌دهد. او فرایند کار با دستیارهای کدنویسی هوش مصنوعی را به عنوان یک “تمرین فکری عمیق” (deeply intellectual exercise) توصیف می‌کند، نه صرفاً تکیه بر “احساسات” (vibes)

ویدیوی سخنرانی: Andrew Ng: From Code to Product in Hours – The New Reality of AI Development

گزیده:
ندارد.

هوش مصنوعی صرفاً یک ابزار جدید نیست؛ بلکه انقلابی در بنیادهای مهندسی نرم‌افزار است. مارتین فاولر، یکی از تأثیرگذارترین چهره‌ها در حوزه‌ی اَجایل و معماری نرم‌افزار، معتقد است که ورود AI بزرگترین دگرگونی در این صنعت از زمان گذار از زبان اسمبلی به زبان‌های سطح بالا است.
توصیه می‌کنم حتمن این ویدیوی ارزشمند را که لینک آن در ادامه آورده‌ام ببینید.

https://www.youtube.com/watch?v=CQmI4XKTa0U

پیش‌گفتار:
در دنیای توسعه‌ی نرم‌افزار، کدنویسی تنها بخشی از ماجراست. جنبه انسانی ماجرا، نه کمتر که شاید بیشتر از جنبه‌ی فنی ماجرا در موفقیت پروژه تاثیرگذاره. جنبه‌ی انسانی توسعه‌ی نرم‌افزار، اون‌جا که از «کنار هم کد زدن» به «دیدن‌های گاه به گاه از راه دور و از پشت نمایشگر» و بعد به «هم‌تیمی‌های ندیده» تبدیل می‌شه به مراتب سخت‌تر و پیچیده‌تر می‌شه.

چند وقت پیش راهنمایی رو در وب‌سایت پروژه‌ی SQLModel دیدم که بسیار آموزنده بود. رهبر این پروژه‌، سباستین رامیرز (معروف به @tiangolo) خالق FastAPI یکی از فریم‌ورک‌های معروفِ توسعه‌ی وب توی پایتونه. بخشی از این راهنما رو که خود رامیرز برای برای مدیریت کارها در مخرن کدها (Repository Management Tasks) نوشته در ادامه آوردم. هدفِ بخش غیرفنی این راهنما، نه تنها ترویج رفتار حرفه‌ای، بلکه ایجاد یک فرهنگ پایدار در جامعه‌ی توسعه‌دهندگان نرم‌افزاره؛ فرهنگی که حتی در لحظات پرچالش و دعواهای فنی، اولویت با احترام به افراد و قدردانی از تلاش‌های آنهاست.

گفتار: آدم خوبی باشید!
مهم‌تر از همه چیز اینه که آدم خوبی باشید. 😊
اگه شما رو به تیم اضافه کردند معنی‌اش اینه که شما احتمالن آدم فوق‌العاده خوبی هستید، اما می‌ارزه که دوباره اون رو یادآوری کنیم .🤓

برای وقتی که شرایط سخت می‌شه!

وقتی شرایط خوبه، کارها آسون‌تره و نیازی هم به دستورالعمل‌های زیاد و طولانی نیست. اما برای وقتی که شرایط دشواره یک‌سری راهنما هست که در ادامه می‌آرم.

سعی کنید جنبه‌ی مثبت ماجرا رو ببینید. به طور کلی، اگه افراد رفتار غیردوستانه‌ای ندارند، سعی کنید از تلاش و علاقه‌شان تشکر کنید، حتا اگه باهاشون در مورد اون موضوع (بحث فنی یا پی‌آر) موافق نیستید، ازشون به خاطر علاقه‌مندی‌شون به پروژه یا وقتی که گذاشتن تا یه کاری توی پروژه انجام بدند تشکر کنید.

بیان احساسات توی متن کار سختی‌یه، از ایموجی‌ها برای بیان احساسات‌تون استفاده کنید. 😅

در بحث‌های فنی و پی‌آرها، خیلی اوقات افراد ناراحتی‌شون رو مستقیم و بدون فیلتر بیان می‌کنند، خیلی وقت‌ها غلو می‌کنند، شاکی می‌شند، طلبکارند و از این جور کارها. این کارها واقعن درست نیستند و وقتی کسی این کارها رو می‌کنه باعث می‌شه اولویت ما برای حل مشکل‌اش بیاد پایین. با این‌حال سعی کنید اول نفس عمیقی بکشید و بعد جواب‌های آرام و مودبانه‌ای به طرف بدید.
سعی کنید طعنه و کنایه‌‌ نزنید و نظرات پرخاشگرانه‌ی منفعل ندید[۱]. اگر چیزی نادرسته، به جای کنایه‌ زدن، بهتره (با حفظ آرامش و ادب) حرف‌تون رو مستقیم و بی‌پرده بگید[۲].

تلاش کنید تا جای ممکن دقیق و بر اساس واقعیت‌‌ها صحبت کنید و کلی‌گویی‌ نکنید.

برای بحث‌هایی که سخت‌تره مثلن رد کردن یه پی‌آر، می‌تونید از من بخواید که اون رو خودم مدیریت کنم.

پانوشت:
۱- پرخاشگری منفعل (Passive-aggressive behavior) نوعی درشتی کردن فردی به فرد دیگر به‌صورت غیرمستقیم است. پرخاشگری منفعل بیان غیرمستقیم خصومت است مثلاً به شکل تعلل، طعنه، یکدندگی، ترشرویی، یا انجام ندادن عمدی و چندبارهٔ وظایفی که به شخص محول شده‌ است [ویکی‌پدیا]. چند نمونه:
* «باشه،‌ هر جور تو بگی …» (با وجود عدم رضایت)
* «اشکالی نداره، مثل همیشه خودم انجام‌اش می‌دم.»
* «فکر می‌کردم این رو می‌دونی» (باید بدونی ولی نمی‌دونی)‌

۲- طعنه (طعنه‌ی تلخ به انگلیسی – bitter sarcasm) به معنای سخنی تلخ، با بیانی برنده، و تمسخر و دست انداختنی است که معمولاً با ریشخند هزل یا دست کم گرفتن بیان می‌شود [ویکی‌پدیا]. چند نمونه:
*‌ «به به، باز گل کاشتی! چه می‌کنه این بازیکن!»
*‌ «چه عجب! بالاخره افتخار دادید تشریف آوردید! آفتاب از کدوم طرف در اومده!»
* «دست‌ات درد نکنه این کار رو داری می‌دی به من! بیکار بودم حوصله‌ام سر رفته بود»

—–
آدرس راهنمای اسکیو-ال-مدل:
https://sqlmodel.tiangolo.com/management-tasks/#when-things-are-difficult

گزیده:
ندارد!

پیش‌گفتار:
دوستی دارم که رشته‌ی هنر خونده و علاوه بر دانش عکاسی، تجربه‌ی زیادی هم در این زمینه داره. یک بار برام تعریف می‌کرد که با گروهی که چندتاشون اون رو نمی‌شناختند جایی بودند و ازش خواستند که ازشون عکس بگیره. می‌گفت بعد از این که عکس گرفتم به رسم معمول، عکس‌ها رو نشون همه دادم که ببینند توی عکس خوب افتادند یا نه. بعد از این که از کیفیت عکس و … تعریف کردند یکی از افرادی که با هم آشنایی نداشتیم برگشت گفت «مدل گوشی‌تون چیه؟»

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

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

این تغییرات سریع و بنیادی ابزارهای هوشمند به قدری «غیرعادی‌ها» را به «عادی» تبدیل کرده که تا چند وقت دیگه اگه یه نفر بیاد و یک کد تر و تمیز رو به شما نشون بده احتمالن ازش می‌پرسید که «مدل دست‌یار هوشمندتون چی هست؟». بدون این که ازش بپرسید که شما علاوه بر دست‌یار، چه چیزهایی خوندید یا تجربه کردید.

گزیده:
شما عکس نمی‌گیرید، شما اون رو خلق می‌کنید. انسل آدامز