دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا شده ساعت‌ها روی نوشتن یک تکه کد وقت بگذارید و بعد از اینکه بالاخره کامل شد، از این بترسید که دیگران آن را ببینند و قضاوتتان کنند؟ چرا خیلی از برنامه‌نویسان ترجیح می‌دهند در تنهایی کار کنند و کارهایشان را از چشم همکارانشان پنهان نگه دارند؟
فصل دوم از کتاب «مهندسی نرم‌افزار در گوگل» به کوشش تیتوس وینترز، تام مانشریک و هایروم رایت و نوشتهٔ برایان فیتزپاتریک، به همین چالش‌های فرهنگی و اجتماعی می‌پردازد و نشان می‌دهد که چطور رفتار فردی ما بر کل تیم تأثیر می‌گذارد.
نخستین مسئله، خطای شناختی بزرگی است که نویسندگان آن را اسطورهٔ نابغه می‌نامند. بسیاری از ما فکر می‌کنیم نرم‌افزارهای بزرگ دنیا، مثل لینوکس، حاصل کار یک نفر در تنهایی بوده‌اند؛ در حالی که لینوکس با کار گروهی هزاران نفر شکل گرفته است. گزینه‌های پیش روی برنامه‌نویسان این است که کدهای خود را پنهان کنند تا کسی خطاهایشان را نبیند یا اینکه کارشان را زود به اشتراک بگذارند. معاملهٔ این روش این است که کار در تنهایی، سرعت پیشرفت را کم می‌کند و خطر اتلاف وقت روی مسیر اشتباه را بالا می‌برد. مثلاً تصور کنید ما ماه‌ها روی ساخت یک قطعه‌ی سخت‌افزاری در گاراژ خانه کار کنیم بدون اینکه با کسی مشورت کنیم، در حالی که همسایهٔ ما با کمک دوستانش همان را خیلی زودتر ساخته است.
دومین موضوع مهم، ضریب اتوبوس Bus Factor است؛ یعنی تعداد افرادی که اگر خدای نکرده با اتوبوس تصادف کنند، پروژه کاملاً متوقف می‌شود. مسئله این است که اگر فقط یک نفر همه‌چیز را دربارهٔ کد بداند، امنیت شغلی دارد اما پروژه در خطر جدی قرار می‌گیرد. گزینه‌های ما این است که دانش را انحصاری نگه داریم یا آن را بین اعضای تیم پخش کنیم. معامله این است که اشتراک‌گذاری دانش، احساس امنیت فردی را کم می‌کند اما دوام پروژه را تضمین می‌کند. برای نمونه، اگر مستندسازی و مالکیت مشترک وجود داشته باشد، با رفتن یک نفر پروژه زمین نمی‌خورد.
سومین چالش، اهمیت بازبینی کد (Code Review) به همراه چرخهٔ بازخورد است؛ یعنی بررسی تغییرات کد توسط همکاران پیش از ادغام. مسئله این است که اگر برنامه‌نویس کد خود را تا لحظهٔ نهایی پنهان کند، خطاهای بنیادی دیر کشف می‌شوند. گزینه‌ها این است که منتظر بمانیم کار کاملاً تمام شود یا به صورت تدریجی بازخورد بگیریم. ترفند معامله این است که پذیرش بازخورد اولیه ممکن است به غرور ما لطمه بزند اما هزینه‌های رفع خطا را به شدت کاهش می‌دهد. درست مثل کامپایلر که در کنار برنامه‌نویس است تا خطاهای کوچک را همان لحظه کشف کند، تیم هم به عنوان یک بازخورد زنده عمل می‌کند.
چهارمین مفهوم کلیدی، سه ستارهٔ تعامل اجتماعی یعنی تواضع، احترام و اعتماد است. مسئله این است که انسان‌ها موجوداتی غیرقابل‌پیش‌بینی هستند و بیشتر درگیری‌های کاری ریشه در کمبود همین سه اصل دارد. گزینه‌ها این است که وارد چالش‌های انسانی شویم یا مثل خیلی‌ها گوشه‌گیر شویم و فقط با ماشین کار کنیم. معامله این است که کار کردن روی مهارت‌های اجتماعی زمان‌بر است اما روابط صمیمانه همیشه طولانی‌تر از پروژه‌ها عمر می‌کنند. مثلاً رفتار دوستانه با همکاران باعث می‌شود وقتی کار گره می‌خورد، دیگران با اشتیاق به کمک ما بیایند.
پنجمین نکته، پذیرش شکست و ایجاد یک فرهنگ عاری از سرزنش است. مسئله این است که وقتی اشتباهی رخ می‌دهد، واکنش طبیعی ترس از اخراج یا توبیخ است. گزینه‌ها این است که شکست را پنهان کنیم یا آن را به عنوان فرصتی برای یادگیری مستند کنیم. معامله این است که اعتراف به اشتباه آسیب‌پذیر به نظر می‌رسد اما در نهایت اعتبار و اعتماد تیم را بیشتر می‌کند. برای نمونه، نوشتن تحلیل پس از مرگ Post-mortem به تیم کمک می‌کند ریشهٔ مشکل را پیدا کنند بدون اینکه انگشت اتهام را به سمت فرد خاصی بگیرند.
پیشنهاد من به شما این است که در پروژه‌های روزمره، تمرین کنید کدهایتان را زودتر با همکارانتان به اشتراک بگذارید و به جای دفاع از خطاهای خود، از بازخوردها به عنوان ابزاری برای رشد استفاده کنید.
توسعهٔ نرم‌افزار یک کار گروهی است و موفقیت واقعی زمانی به دست می‌آید که به جای تلاش برای قهرمان تنهای میدان بودن، بخشی از یک تیم همدل باشیم.